Truss · System & integration map

What we have, and where it plugs in.

Two views on one page. Up top: the system we've built and how a transaction moves through it. Below: the simple operational picture, where Truss sits and how it connects to your bank and the payment rail. Click any box for detail; the dots show live flow.

1What we have, the system

The components that exist today and the path a transaction record takes: ingest → canonical store → event stream → reconciliation → detectors → dashboard. The simulator feeds it; the durable engine runs the retry and reversal workflows your bank executes.

Ingestion / APIvalidate · idempotency Canonical storePostgreSQL —source of truth Outbox → streamRedpanda —at-least-once Reconciliationledger vs settlement Operate dashboardproof · recovered · live Detectorsstuck · dup · missing Redisidempotency cache Simulatorsynthetic + oracle Durable engineretry & reversal
Dots = a transaction record moving through the pipeline.
In plain terms
  • Nothing gets counted twice. Every transaction enters through one door (the API), which enforces an idempotency key, so a retry can never become a double debit.
  • One book of record. PostgreSQL holds the single source of truth; the event stream reliably copies every change out for other tools, without ever becoming the truth itself.
  • The catch happens here. Reconciliation compares the bank's record against settlement truth, and the detectors turn stuck, duplicate, or missing-reversal patterns into incidents with deadlines.
  • A human can always confirm it. Everything surfaces in the dashboard, traceable back to the source records, we never ask anyone to take a number on faith.
  • Safe by design. The simulator constantly grades the whole pipeline, and the durable engine that acts on money only ever instructs your bank, never moves it.
Logical view

Click a component

Each box is a piece of the system that exists today. Select one to see what it does and where it lives in the repo.

Invariant: PostgreSQL is the one source of truth; everything else is a working copy or a projection.

2Where it sits, the simple picture

One line to remember: money moves along the rail; Truss plugs into your bank, watches every transaction, and flags what's broken, without ever touching the money.

TRUSS transaction reliability layer watches every transaction, and never touches the money OFF THE FUNDS PATH ghost caught watches · instructs · no money MONEY MOVES HERE, LICENSED PARTIES End customermobile · USSD Your bank / MFBour client · core banking NIBSS / Interswitchthe rail + settlement Other banksbeneficiaries
Watch the red dot: your bank shows success, settlement says failed → Truss flags it.
money (licensed parties) Truss watches & instructs, no money ghost / flagged
In plain terms
  • Money never goes through us. It moves along the rail between licensed parties, your bank, the switch (NIBSS / Interswitch), and the other banks. Truss is never in that path.
  • One place to plug in: your bank. Truss reads every transaction and the settlement result your bank already receives, no new rail integration, no NIBSS membership needed from us.
  • It flags what's wrong, early. Ghost successes (bank says paid, settlement says failed), stuck payments, and duplicates, usually before the customer calls.
  • It can tell your bank what to fix. Truss sends retry / reverse instructions back to your bank, which executes them. Truss never moves the money itself.
  • Your risk doesn't change. Because we're off the funds path and non-custodial, your regulatory exposure stays the same, and you can confirm every Truss finding against your own records.
Physical view

Click a box

The operational picture: who holds what, and how Truss connects without touching money. Select a box for the integration detail.

Custody: the bank remains the licensed party that moves value. Truss reads and instructs only.
*Retry / reversal instructions are issued to the client's own rail integration; the bank executes them. Truss · System & integration map · interactive.