Settlement-Finality Reporting, Broken Down by Scheme and Currency
In payments there is a world of difference between a payment that looks done and one that is genuinely, irrevocably final. Settlement finality is the moment money has truly changed hands between institutions and cannot be pulled back. KibiPay's settlement report exists to answer one precise question: how much money has actually reached that state — and it answers it per rail and per currency.
Only SETTLED counts
The report's defining filter is WHERE status = 'SETTLED'. Nothing that is merely accepted, pending, or in-flight is included. A payment moves through a lifecycle of states across our canonical model, and only the terminal, final state qualifies here. That strictness is the whole value: a settlement report that counted optimistic states would be worse than no report, because it would overstate what is truly done.
Grouped by scheme and currency
The output is an aggregate: for each combination of scheme and currency, a settled_count and a settled_value. That two-dimensional cut is exactly what a treasury or operations team needs, because finality does not mean the same thing on every rail:
- An instant rail reaches finality in seconds, around the clock.
- A batch rail reaches it only after its scheduled settlement window closes.
- A blockchain rail reaches it when the network confirms the block.
Reporting settled totals per scheme means you can see, for each rail, how much has crossed its own finality line — and reporting per currency within that means a treasury team can reconcile settled positions against nostro balances in the right denomination.
Why finality reporting is its own report
It would be tempting to fold this into the general transactions roll-up. Keeping it separate is deliberate. The transactions report answers "what is the shape of all activity, in every state?" The settlement report answers a narrower, higher-stakes question: "what is safe to treat as done?" Those are different audiences asking different questions, and conflating them invites someone to read an in-flight total as a settled one.
The regulatory angle
Settlement-finality reporting also maps onto a real regulatory concern: settlement-finality regimes care about the exact point at which a payment becomes legally irrevocable, because that point determines what happens if a participant fails. A report that isolates the settled population, by scheme, gives you the raw evidence for that — how much is final on each rail, at any chosen point in time.
Same shape as everything else
Mechanically, it is the same clean interface as the rest of the suite: a from/to window, an optional tenant filter, JSON or CSV output, and it runs on the read replica so pulling a settlement position never competes with processing the next payment. Simple plumbing, in service of a question you never want to get wrong.
Why the SETTLED filter is the whole point
Everything about this report hinges on one filter, and it's worth dwelling on why. Across the platform's canonical lifecycle, a payment passes through optimistic-sounding states — submitted, accepted — long before it is truly, irrevocably done. A settlement report that counted any of those would systematically overstate what has actually settled, and an overstated settlement figure is not a small error: it's the kind of number a treasury team could act on and get badly wrong. So the report counts only payments in the terminal SETTLED state and nothing else. Grouping the result by scheme and currency then gives a treasury or operations team the cut they actually need, because finality lands at different moments on different rails — instantly on an instant rail, only after a window closes on a batch rail, on block confirmation for a blockchain rail — and settled balances have to be reconciled against nostro positions in the right denomination. Keeping this as its own report, rather than folding it into the general transactions roll-up, guards against the single most dangerous mistake in settlement accounting: reading an in-flight total as a final one. There is a genuine regulatory dimension to this as well — settlement-finality regimes care about the precise moment a payment becomes legally irrevocable, because that moment governs what happens if a participant fails, and a report that isolates the settled population by scheme is exactly the evidence that question demands. Mechanically it is the same clean interface as the rest of the suite: a windowed from/to, an optional tenant filter, JSON or CSV, all served from the read replica so a settlement pull never slows a payment down.