Instant Payments Meet the Core: Re-Architecting a Bank Ledger for Real-Time, Irrevocable Postings

Most instant-payments programmes are scoped as a gateway project. They are actually a ledger project wearing a gateway badge, and the difference surfaces the first weekend the batch window that used to absorb every awkward posting is simply not there any more.

The Instant Payments Regulation, Regulation (EU) 2024/886, adopted in March 2024, obliges payment service providers in the euro area to receive instant credit transfers from 9 January 2025 and to send them from 9 October 2025, with payment and e-money institutions and non-euro Member States following through 2027 and 2028. The headline requirement is easy to quote: the payee’s account is credited within ten seconds, at any hour, every day, and the previous €100,000 ceiling on SEPA instant transfers is gone. What is harder to internalise is that this obligation lands on the ledger, not on the front door. A core built to net, queue and post in overnight batches was designed around assumptions the regulation quietly deletes.

The assumption batch cores were built on

A traditional core banking ledger treats the day as a unit of work. Transactions accumulate, provisional balances are held, and at a defined cut-off the batch runs: it applies postings, recalculates balances, resolves exceptions, reconciles against the settlement position and closes the books. Errors caught during the day sit in a suspense account and are unwound before close. The batch window is not an operational inconvenience; it is a design assumption. It is the moment when the ledger is allowed to be temporarily inconsistent, because nobody outside can see the intermediate state and everything is made right before morning.

Instant, irrevocable, twenty-four-hour posting removes that grace period. There is no moment when the ledger is off-line and allowed to be wrong. Every posting is externally visible the instant it lands, and under the scheme it is final: once the funds are credited, they cannot be pulled back by the sending institution. The batch core’s central coping mechanism — defer, suspend, reconcile later — is exactly what the regulation forbids in the payment path.

Irrevocability is the load-bearing word

Irrevocability is what makes this an architecture problem rather than a throughput problem. If a real-time posting could be reversed cheaply, you could bolt a fast path onto a slow core and clean up afterwards. You cannot. Once the receiving customer’s balance reflects an incoming instant payment, that money is spendable immediately, and there is no overnight reversal to lean on if the underlying posting was made on a wrong assumption about available balance, sanctions status or settlement cover.

This forces a decision most gateway-led programmes never make explicitly: is the authoritative balance the one the payment engine sees at the moment of decision, or the one the core will post minutes later? If those two can diverge — and in a batch core they routinely do — you have a window in which the engine authorises against stale state and commits an irrevocable transfer the ledger has not yet accounted for. The engineering task is to collapse that window to zero: the balance the payment decision is made against and the balance the ledger commits must be the same object, updated synchronously, or the guarantee is fictional. That is a re-plumbing of the ledger’s transaction boundary, not a feature on the payment rail.

Fraud and screening move inside the ten seconds

The regulation also relocates two controls that batch operations used to run at leisure. Fraud scoring can no longer be a next-day review of settled activity; on an irrevocable outbound payment there is no next day to catch it in, so the decision has to happen inside the same ten-second budget as the posting. Building real-time risk that clears within that budget without becoming the bottleneck is a discipline in itself, and I have written separately on keeping fraud controls inside the ten-second SLA.

Sanctions screening moves the other way. Because per-transaction screening cannot reliably complete within the window, the regulation directs providers to screen their own customer base against EU restrictive-measures lists at least daily, rather than screening every instant transfer in flight. That is a genuine architectural inversion — the control shifts from the transaction path to a standing dataset — and it changes what your systems must hold and how fresh it must be, a point I develop in re-architecting sanctions screening around daily lists. Neither control is a gateway concern. Both reach into the ledger and the customer master.

Reconciliation stops being an overnight job

The quietest casualty is reconciliation. In a batch world, the internal ledger and the settlement position are squared once a day; breaks are investigated the following morning. With continuous settlement and no batch close, reconciliation has to become a continuous function that detects and flags a divergence between what the ledger posted and what actually settled in near real time, because an unreconciled irrevocable payment is an unrecoverable loss, not a Monday-morning ticket. This is inseparable from liquidity and settlement-risk operations, which change shape entirely once the overnight window disappears — the operational side of that shift is its own subject, covered in running 24/7 liquidity and settlement-risk operations.

What a workable target architecture actually separates

The programmes that come through this cleanly tend to share a shape. They put a real-time posting engine in front of the legacy core rather than trying to make the batch core itself post in real time — an authoritative, synchronously-updated balance and posting service that owns the instant-payment path and treats the batch core as a system of record it reconciles against continuously. They make availability a first-class requirement, because a ten-second obligation with no maintenance window means the posting path cannot rely on nightly downtime and needs headroom for weekend and holiday peaks it never had to carry before. And they resist the temptation to keep the old suspense-and-sweep habit alive in the fast path, because irrevocability is precisely the thing that habit assumes away.

Whether that engine is a module of a modern platform or a service you place in front of an older one is the decision that then governs the whole build, and it is worth taking on its own terms rather than defaulting to whatever the incumbent vendor offers — a question I have set out in choosing a core banking platform for a small EU credit institution.

The failure mode is always the same, and it is always discovered late: a gateway that answers in under ten seconds sitting on a ledger that still believes it will get an overnight window to sort things out. The gateway passes the demo. The ledger fails the first busy Sunday, and in an irrevocable world it fails with money that has already left the building.