A real production card-auth trace, with timing, ledger postings, and decision rationale at every hop. The same view an analyst sees in the operator workspace.
A card authorisation is the cleanest demonstration of how the platform works. Inputs: a scheme webhook, a customer subaccount tree, a tier policy. Outputs: an approve/decline decision, two ledger postings, a journal entry, and a wallet UI update — all in under 80 milliseconds at p95.
Customer: Tier-2 verified, EU-resident, EUR primary. Card: virtual Visa, 3DS-2 enrolled, last used 2 days ago, no fraud flags. Merchant: regulated EU grocery chain, MCC 5411, no special handling. The auth is for €18.40 — well within velocity, well within tier limits, no risk-engine flags.
| Hop | Service | p50 | What happens |
|---|---|---|---|
| 1. ISO-8583 IN | Provider gateway | 12 ms | Auth-request lands at the gateway over the scheme webhook. Idempotency-key required at the boundary; duplicates dedup immediately. |
| 2. Auth service | Wallet service | 28 ms | Validates auth against open card state, customer subaccount tree, and active scheme rules. No state held outside the service. |
| 3. Risk + tier | Risk gate | 14 ms | Tier limits, velocity, KYT pre-flight if MCC is high-risk. Returns yes/no with a reason code, journaled. |
| 4. Ledger posting | Core ledger | 18 ms | Double-entry write: Dr customer:available · Cr customer:blocked. Block carries auth-id, scheme-ref, MCC, expiry. |
| 5. Auth response | Provider gateway | 8 ms | Approve / decline returned to scheme. p95 end-to-end < 80 ms; target 50 ms under normal load. |
Every hop produces a journal entry. The auth-service hop journals the validation result. The risk gate journals the score, the inputs, and the reason code. The ledger journals the posting. The provider gateway journals the response. An analyst opening the case in the operator workspace sees the same trace, the same hops, the same numbers, in the same order.
When something goes wrong (a decline that shouldn’t have happened, a posting that drifted, a customer complaint), the journal is the source of truth. The dashboard is a derived view. Every investigation starts from the journal — never from the dashboard.
The auth blocks €18.40 against the customer. The actual capture comes later — typically same day for grocery, can be up to 30 days for hotels and rentals. When the settlement file arrives, the ledger matches each capture against its block: full capture splits the block into a settled posting; partial capture splits it into settled + released; no capture before TTL expiry → block reverts.
The arithmetic is exact. The sum of all current blocks plus all settled captures plus all released amounts equals the original auth amount, every time. There is no "approximately" here — the ledger constraint forbids it.
A regulator on a routine inspection does not want to see your slide deck. They want to see a card auth from last Tuesday and ask: who decided this, on what basis, in how much time, and where did the money go? The trace above is the answer to all four questions, on every transaction, for seven years. That is the reason the platform is built the way it is.