Settlement finality, explained for the people who sign off

A steering committee will spend an hour on how fast a payments platform settles and thirty seconds on whether a payment can be undone. Speed is a number on a slide. Finality decides who absorbs the loss when something goes wrong, which is much closer to what the committee is there to approve.

Finality is the moment after which a payment cannot be reversed by the system that made it. Before that moment there is a mechanism: a chargeback window, a settlement cycle that has not closed, a batch not yet submitted. After it, correcting a mistake means a second, separate payment in the opposite direction, and that requires the other party to agree to send it.

Three events, one phrase

The sentence the payment went through covers three separate things, and the gaps between them are where the risk sits.

1. 01Authorisation. The payer's institution confirms the funds exist and reserves them. Nothing has moved.
2. 02Clearing. Instructions are exchanged and both institutions agree what is owed. Nothing has moved.
3. 03Settlement. Value transfers between the institutions. Finality is a question only from this point onwards.

What a committee usually approves, without it being framed that way, is how much of the customer experience runs ahead of settlement. Showing a payment as complete at authorisation is good service, and it means the operator carries the exposure in the gap. That is a legitimate commercial choice. It should be a deliberate one, with somebody in the room able to say what the gap costs in a bad month.

Irreversible rails change the shape of the risk

Card rails were built around reversal, and a large part of their cost structure exists to fund it. A ledger that settles instantly removes the intermediaries, the delay and the reversal mechanism together. When we built the CRBT platform for Cruisebit on Ethereum smart contracts, the objective was instant settlement in place of multi-party clearing. Instant and final are the same property described from two directions.

The approver's job on a design like that is to check the operational controls have moved to match. A confirmation step before an irreversible send. Value limits by counterparty and by day. Maker and checker on treasury movements. A saved address book so destinations get selected instead of typed. Those controls are what replace the chargeback. If they are absent, the risk has not left the business so much as changed address.

Instant settlement moves the risk rather than removing it. Everything now depends on the moment before the button is pressed.

Reconciliation is the control that tells the truth

Two records exist for every payment: what the platform believes happened, and what the settlement system reports. They will disagree. The disagreements are usually dull. A transaction landing either side of a cut-off. A fee applied in one place and not the other. A retry that produced a duplicate because the first attempt timed out without answering. Reconciliation is the daily process that finds them while they are still small.

Four questions establish whether that control is real, and none of them require any technical knowledge.

1. 01How often does reconciliation run, and against which source of truth.
2. 02Who reads the breaks, by name, and what else is on that person's desk.
3. 03How old is a break allowed to get before it escalates, and to whom.
4. 04What happens on a day the process does not run at all.

The programmes that went badly followed the same pattern. A target for settlement speed was approved, a position on reversibility was never taken, and the operations team inherited the gap and discovered its value during an incident. Settlement speed is a performance question. Finality is a liability question. Only one of the two genuinely belongs to the people who sign.