Engineering

Reference architectures for instant settlement at national scale.

Feb 2026 · 18 min read · By the Engineering Practice

Instant settlement is not a latency problem. The wire-level round trip on FPS, SEPA Instant and FedNow is well within reach for any modern stack. The hard problems are liquidity, idempotency and exception handling — and they all surface at the moment a transaction commits irrevocably.

The shape of a working core

Production systems we have built for tier-one payment institutions share a common topology: a stateless ingress that validates and enriches ISO 20022 messages, an authorisation engine that owns balance and limit decisions, and a settlement coordinator that brokers the scheme handshake. Each layer is separately horizontally scalable, but the authorisation engine is the one that must be perfectly idempotent.

Liquidity is an architectural concern

24/7 settlement means the prefunded position at the scheme is consumed outside business hours, when treasury teams are not at desks. Architectures that succeed treat liquidity as a first-class signal: forecast, alert, and — where the scheme permits — automate top-ups with hard ceilings approved by treasury.

Exception handling is the product

In a batch world, exceptions are reconciled the next day. Under instant settlement, an unresolved exception is a customer complaint within minutes. The operating model has to absorb this: investigation tools, ops dashboards and the ability to issue a scheme-compliant return without a release.

What we would not do again

We have seen two anti-patterns repeatedly: shared databases between the authorisation engine and downstream ledgers (a single slow query stalls settlement), and synchronous fraud screening in the scheme response path (a model timeout becomes a scheme timeout). Both are addressable, but cheaper to avoid in the original design.