rtgs

How it is built

Architecture overview

A real-time gross settlement system is the central bank's ledger for large, urgent payments between banks. Each participant holds a settlement account at the central bank; a payment instruction moves money from one account to another one payment at a time, immediately and finally, in central bank money (gross, not netted at the end of the day). Because nothing is netted, the system needs a lot of liquidity: a bank can only pay out what is in its account or what the central bank lends it for the day. The one idea that makes RTGS work is therefore a queue with a liquidity-saving brain: payments that cannot settle yet wait in a queue with a priority, and the system keeps looking for sets of queued payments that can settle together, so that scarce intraday liquidity is recycled instead of hoarded. Fedwire Funds Service, T2 (TARGET), CHAPS and BOJ-NET are the large examples, all built on this pattern and all linked to securities and foreign-exchange settlement.

Parts:

• Settlement accounts and ledger — one balance per participant (and per sub-account), debited and credited in one atomic step — Double-entry ledger, Money representation, bitemporal-data (no page yet)
• Settlement engine — takes instructions in a single order, checks funds, settles or queues, never twice — total-order-sequencer (no page yet), real-time-gross-settlement (no page yet), exactly-once-processing (no page yet), Idempotency keys, Payment state machine
• Queue and liquidity management — priorities, timed payments, reservations, gridlock resolution, intraday credit — payment-queue-gridlock-resolution (no page yet), multilateral-netting (no page yet), collateral-haircut-valuation (no page yet)
• Messaging and access — ISO 20022 high-value messages in, status and confirmations out, authenticated participants — iso-20022-messages (no page yet), Mutual TLS, x509-certificates (no page yet), Hardware security module (HSM), dual-control-approval (no page yet)
• Securities and FX links — settles the cash leg of a securities or currency trade together with the other leg — delivery-versus-payment (no page yet)
• Business day and calendar — opens and closes the day, rolls cut-offs, knows holidays per currency — business-day-calendars (no page yet), calendar-date-arithmetic (no page yet)
• Resilience and assurance — second site, state replication, proof of correctness, evidence trail — Raft, Deterministic simulation testing, Tamper-evident audit log, Reconciliation

 participant ──ISO 20022 msg──► gateway ──► validate ──► sequencer (one total order)
   (bank)      mTLS, signed       │        (schema,        │
      ▲                           │         business day)  ▼
      │ status / confirmation     │                  settlement engine ──► ledger (accounts)
      │                           │                    │        ▲             │
      └───────────────────────────┘                    │        │ optimisation│ journal
                                                       ▼        │ cycle       ▼
                                                   queue (priority, ───────► audit log + replica
                                                    timed, reserved)         (second site)
 securities system / CLS ◄──DvP / PvP link──► engine (cash leg)
 central bank ──intraday credit against collateral──► account limits

The system is small in message count compared with a card network, but each message is worth a lot, so the design buys correctness and finality with simplicity: one logical writer, a durable journal, and a second site that can take over.

How the parts fit together

Settlement accounts and ledger

Every participant has an account whose balance the central bank owes it. A payment is a transfer between two accounts, written as two entries that sum to zero (Double-entry ledger), so the total money in the system is conserved by construction and any imbalance is a bug, not a rounding choice. Amounts are integers in the currency's minor unit with the currency attached (Money representation); ISO 20022 carries a decimal amount plus a currency code, and the conversion from text to integer happens once, at the gateway. Two time axes matter to a ledger like this: when something was true in the world (value date, business day) and when the system learned it (a correction posted the next morning). Keeping both is what bitemporal-data (no page yet) is for, and it is what lets an operator answer "what did account X look like at 15:42 on that day, as we knew it then".

Settlement engine

The engine is the part that must never be wrong. For every instruction it does the same short sequence: check it is new, check the sender and receiver are in good standing and the day is open, check the sender's available liquidity, then debit and credit atomically, or put it in the queue. "Is it new" is the job of Idempotency keys: each message carries a sender-assigned identifier, and a repeat returns the earlier outcome instead of a second debit. Together with durable journaling this gives exactly-once-processing (no page yet) as an effect, even though the network only gives at-least-once delivery. The status of each instruction follows an explicit Payment state machine: received, validated, queued, settled, rejected, cancelled; transitions are guarded so a settled payment can never be cancelled and a queued one can be withdrawn only by its sender.

To make the order of events unambiguous, the engine consumes instructions through a single total order (total-order-sequencer, no page yet). Debits and credits on a shared account depend on each other's order, and replaying the journal after a failure must give the same balances. A single logical writer, usually one thread or one state machine, is the simplest way to guarantee that; parallelism is added around it (validation, signature checking, message formatting) and not inside it.

Queue and liquidity management

When funds are short, the payment is queued instead of rejected. The central bank's liquidity tools are visible in the public description of T2: payment priorities, timed transactions, liquidity reservation, limits, liquidity pooling and optimisation procedures (source: ECB, T2). A reservation sets aside balance for urgent payments; a limit caps what one participant will send to another bilaterally; priority decides who waits.

The core algorithmic problem is gridlock: A owes B, B owes C, C owes A, each has too little cash to go first, and each waits for the others. Gridlock resolution (payment-queue-gridlock-resolution, no page yet) searches the queues for a set of payments that, settled simultaneously, keeps every participant within its available funds and limits. Bech and Soramäki (Bank of Finland Discussion Paper 9/2001) analysed such algorithms on real payment data from interbank systems; their results indicate it runs in real time and helps most when intraday liquidity is tight. Its relative, multilateral netting (no page yet), uses the same offsetting idea but at the end of a cycle, not payment by payment; modern RTGS runs the optimisation as a recurring entry-by-entry cycle with a fast "bilateral offset" step and a heavier "multilateral" step.

Liquidity itself comes from three places: the participant's own balance, incoming payments, and intraday credit from the central bank. Credit is provided against collateral or priced, depending on the central bank (see the Federal Reserve payment system risk policy for the US design). Valuing the collateral each day, with haircuts for price and liquidity risk, is a separate calculation (collateral-haircut-valuation, no page yet) whose output feeds each account's limit.

Messaging and access

High-value messages are ISO 20022 XML: the Eurosystem states that T2 uses ISO 20022, shared with T2S, TIPS and ECMS (source: ECB, T2); Fedwire Funds Service completed its migration to the ISO 20022 format in July 2025 (source: Federal Reserve Financial Services press release); the Bank of Japan reports an upgraded ISO 20022 message version on BOJ-NET (source: BOJ-NET page). The format (iso-20022-messages, no page yet) matters to design in three ways: structured fields replace free text and so rules can act on them, the message is larger, and message versions change, so the validator must be versioned like an API.

Access is by authenticated network connection: Mutual TLS with certificates issued under a central bank CA (x509-certificates, no page yet), and message-level signatures for non-repudiation. Keys live in Hardware security modules. Operator actions that change static data, move a participant between modes, or release a stuck queue are two-person operations (dual-control-approval, no page yet).

Securities and FX links

Large-value payments are usually the cash leg of something else. Delivery versus payment (no page yet) links a securities transfer and a payment so that one happens only if the other does. The BIS report on DvP describes three models: gross securities and gross funds, gross securities and net funds, and net for both (source: BIS CPSS, Delivery versus payment in securities settlement systems, 1992). RTGS fits model 1 and the cash leg of model 2. T2S, the Eurosystem's securities platform, settles against central bank cash; CLS settles currency trades payment-versus-payment. In both, the RTGS side exposes a "block this amount, then confirm or release" interface, and the securities side drives the second step.

Business day and calendar

The business day is a state of the system: opening, normal processing, cut-off for customer payments, cut-off for bank payments, end of day, then a gap for reports, collateral revaluation and maintenance. The calendar says which days are open for which currency: T2, for instance, is closed at weekends and on 1 January, Good Friday, Easter Monday, 1 May, 25 and 26 December for euro settlement (source: ECB, T2), and Fedwire's funds-transfer day begins at 9:00 p.m. ET on the preceding calendar day and ends at 7:00 p.m. ET (source: Federal Reserve Financial Services, operating hours). So the business date is not the calendar date. The rules live in business-day-calendars (no page yet), the shifting of a value date by "next open day" in calendar-date-arithmetic (no page yet). Time zones and daylight-saving changes are the classic trap: store timestamps in UTC, derive the business date from the rules.

Resilience and assurance

The ledger and queue are replicated to a second site. The usual design is synchronous replication of the journal to a nearby site and an asynchronous copy to a distant one, because the loss of one acknowledged payment is not acceptable; consensus-based replication (Raft) is the textbook way to get a leader with automatic failover and no split-brain, at the cost of a round trip per commit. A Deterministic simulation testing harness runs the whole engine in one process against a seeded fake network and disk, injecting crashes, duplicates, reordering and slow disks, and replays any failing seed exactly. Every state change is also written to a Tamper-evident audit log, and Reconciliation compares ledger totals, participant statements and the central bank's own books at day end.

Data and control flow

One payment, end to end:

1. The participant's system builds an ISO 20022 credit-transfer message with its own unique identifier, signs it and sends it over mutual TLS.
2. The gateway checks the certificate, the signature, the schema and the business day, then assigns a sequence number from the sequencer. Time: low milliseconds, dominated by signature and schema checks.
3. The engine looks up the identifier. If it was seen, it returns the earlier status. Otherwise it creates the instruction in state received.
4. It checks limits and available liquidity. If enough, it writes debit and credit to the journal, replicates the journal, and only then marks the instruction settled. The durable write plus replication is where most of the time goes.
5. If not enough, the instruction is queued with its priority and time rules. Every change to balances triggers a cheap check of queue heads, and a timer triggers the heavier optimisation cycle.
6. Settlement produces two confirmations (to sender and receiver) and an audit record; the payment is final from that moment.

End of day:

1. The engine stops accepting new instructions at the cut-offs, rejects or returns what is still queued, produces statements and reports, revalues collateral, and runs Reconciliation.
2. The calendar opens the next business date. Corrections to the closed day are posted as new entries with a value date, never as edits.

Scaling

The system is limited by consistency, not by volume, so the levers are different from a web service:

1. The single order. One writer settles one payment at a time. Lever: keep the settlement step minimal and in memory (a few comparisons and two balance updates), journal sequentially, batch journal writes across several payments, and move all parsing, signature checking and formatting to other cores.
2. Durable replication latency. Each settlement waits for the replica. Lever: nearby second site, group commit, and a replication protocol with a single round trip.
3. Optimisation cycles. Searching the queue for a settleable set is a combinatorial problem. Lever: heuristics instead of exact search, run on a timer and on balance-increase events, and cap the set size.
4. Message size and validation. ISO 20022 XML is large and slow to validate. Lever: compile schemas, validate in a worker pool, reject early.
5. More currencies or services. Lever: separate engines per currency or per service (T2 has a separate liquidity module and ancillary-system settlement), joined by explicit transfers, because a shared writer across them would be a bottleneck. For orientation on scale: the Eurosystem states that T2 processes euro payments worth close to the euro area's annual GDP every eight days (source: ECB, T2); the value per message, not the message rate, drives the requirements.

Failure modes

Real implementations

All central bank systems above are closed: no source is published, only public service descriptions. The open-source row is a building block for the ledger side, not a settlement system.

Sources

• CPSS-IOSCO, Principles for financial market infrastructures, 2012 (settlement finality, money settlements, liquidity risk, exchange-of-value settlement). PDF
• CPSS, Delivery versus payment in securities settlement systems, BIS, 1992. BIS
• M. Bech and K. Soramäki, Gridlock resolution in interbank payment systems, Bank of Finland Discussion Paper 9/2001. Bank of Finland
• ECB, T2 service description. page
• Bank of England, CHAPS. page
• Federal Reserve Financial Services, Fedwire Funds Service: service, operating hours, ISO 20022 migration
• Federal Reserve, payment system risk policy (daylight credit). page
• Bank of Japan, BOJ-NET. page