The payment took four seconds. Reconciling it took eleven days.
Ask anyone who runs operations at a remittance company, a PSP or a mobile money operator with cross-border flows, and you will hear a version of that sentence. The customer sees the fast part. The finance team lives in the slow part: matching what one system says happened against what another system says happened, in two currencies, across a timezone, with a fee deducted somewhere in between.
Three questions every payment must answer later
A payment is not finished when the recipient is credited. It is finished when three questions have mechanical answers:
- Who owes whom, and how much? The sending side's institution now owes the receiving side's institution something, in some currency.
- Has it been paid? That obligation has actually been discharged, gross or as part of a net position.
- Do both sides agree? The sender's records, the receiver's records and the settlement records all say the same thing.
Most cross-border pain in African payments lives in the gap between question one and question three.
Why it is hard here specifically
Too many hops. A payment from a wallet in one country to a wallet in another often passes through an aggregator, one or more banks and sometimes a correspondent in a third currency. The BIS has documented the long retreat of correspondent banking relationships, which has hit smaller markets hardest and pushed more flows through fewer, longer chains 1. Each hop has its own reference number and its own file format.
Too many currencies. The 14 markets Ultraner collects in use ten currencies between them. Even inside the CFA franc zones, XOF and XAF are separate currencies issued by separate central banks. Any cross-network flow involves at least one conversion, and the rate applied has to be the rate recorded.
Reports that arrive late, or never. Some rails publish a settlement report daily. Some publish one weekly. Some publish none that maps cleanly to individual transactions. When a report is missing, "reconciled" quietly becomes "assumed".
Fees taken in flight. When an intermediary deducts its fee from the principal, the amount received differs from the amount sent, and reconciliation has to explain the difference line by line.
The cost of all this lands on the end customer. The World Bank's remittance price data has long shown sending money to Sub-Saharan Africa to be more expensive than to any other region 3.
The design principle: record the obligation when the payment completes
The single most useful rule we adopted for Ultraner Network is simple to state. Every network transaction that reaches destination_accepted produces exactly one settlement obligation (who owes whom, how much, in which currency), created inside the same database transaction as the state change.
Not in a nightly job. Not from a report. In the same commit.
That means there is no window in which a payment exists and its obligation does not. If the state change rolled back, so did the obligation. Question one always has an answer, and the answer comes from the ledger, never from a participant's say-so.
Every financial claim should be reconstructable from the ledger alone.
Windows, netting and the reconciliation gate
Obligations accumulate into a settlement window per participant and per currency. A window closes on a schedule, daily or weekly, or on demand for high-volume participants.
Net by default. Between two participants, obligations in both directions are summed and only the difference settles. If A owes B 10 million in one direction and B owes A 7 million in the other, 3 million moves. For participants whose regulator or agreement requires it, gross settlement is available instead.
A gate before "settled". A window's net amount has to reconcile against the sum of its member obligations before its status can move to settled. That check is mechanical. It is the difference between "the window closed" and "the window is right".
International standards for payment infrastructure set the bar this design aims at: clear settlement finality, defined points at which obligations become irrevocable, and sound management of the risks between them 2.
Refunds, reversals and disputes without rewriting history
Corrections are where ledgers usually get corrupted. The network rules keep them additive:
- Reversal is allowed only from
authorizedorprocessing, before anything has settled. - Refund is the only correction after
settled. It creates a new obligation in the opposite direction rather than editing the original, because the original may already be netted into a closed window. - Dispute freezes the related obligation out of netting until it is resolved. At launch, that resolution is a human decision.
A participant that thinks an obligation is wrong disputes the transaction, not the ledger entry.
Reconciling against a rail that does not report
Reconciliation compares three things: the network's ledger, the participant's view, and the rail's own settlement data. When a rail publishes no settlement report, the honest result is that every transaction shows as missing from that side.
That is the correct signal, not a bug to suppress. A reconciliation screen that shows green because nothing was compared is worse than one that shows red because something could not be.
Where this sits today
The settlement and reconciliation model is built: obligations, windows, netting and the reconciliation gate run in the network's sandbox. What is deliberately not built is the movement of real money between participants' banks. That needs licensing and participant agreements first. No participants are live on the network today.
Regional infrastructure is moving in the same direction. PAPSS, the Pan-African Payment and Settlement System, was set up to settle payments between African countries in local currencies 4. A participant network and a settlement system are different layers, and they are complementary: one decides who owes whom, the other discharges it.
For your own operations team
If you run cross-border flows today, three checks are worth doing this quarter:
- For a sample of last month's payments, how long did it take to confirm each one end to end? The slowest decile tells you where your reconciliation really breaks.
- Where is each obligation first recorded? If it is "when the report arrives", you have a window where money exists in no ledger.
- How are refunds booked? If they edit the original record, your audit trail has holes.
The full settlement section is on the protocol page, and the overall architecture is on the network overview. If you want to test it against your own flows, connect explains how to get sandbox access. For merchant-side settlement to a bank account today, see the settlement capability.
