RTGS versus deferred net settlement
Settle each payment instantly, or run a tab and settle the net? The core trade-off between liquidity cost and settlement risk.
L0 Explain simply
Analogy: coffee tabs. You can pay for each coffee the moment you order it — safe for the café, but you need cash in your pocket all day. Or the café runs a tab and you settle once at closing — easier on your wallet, but the café is trusting you until then. Payment systems face exactly this choice. Some settle every single payment immediately, one by one, with money that is instantly and finally moved. Others let obligations pile up during the day, cancel out what banks owe each other in both directions, and settle only the difference at agreed times. Neither answer is simply better: paying instantly needs a lot of ready money, and running the tab means someone is exposed if a participant fails before closing time.
L1 Core concepts
Real-time gross settlement (RTGS) systems settle each payment individually — gross — and immediately, in central bank money, with finality at the moment of settlement. There is no credit exposure between participants: the money either moves now or the payment waits. Deferred net settlement (DNS) systems accumulate obligations, offset them multilaterally, and settle net positions at designated times. Netting is powerful — the amounts that finally move are a small fraction of the amounts cleared — so DNS is cheap on liquidity but leaves participants exposed to each other between settlement moments. The mapping to use cases follows: high-value interbank payments favour RTGS, where a large unsettled position is intolerable; high-volume retail batches favour DNS, where liquidity efficiency dominates.
L2 Practitioner view
Practitioners feel the difference as timing and funding. In an RTGS world, treasury must keep the settlement account funded through the day, large payments are scheduled deliberately, and a payment can sit in a queue purely for lack of liquidity while the bank is perfectly solvent. In a DNS world, life revolves around cycle cut-offs and the settlement moment: positions are forecast in advance, and the feared scenario is a participant failing to fund its net position — schemes carry defences for that, from collateral and net debit caps to loss-sharing agreements, precisely because unwinding a day's netting would be chaos. Many real systems are hybrids, mixing continuous settlement with liquidity-saving offsetting, so treat RTGS and DNS as poles of a spectrum rather than a strict binary.
L3 Technical details
A netting example with illustrative numbers: Bank Alfa owes Nordbank 900, Nordbank owes Meridian Bank 700, and Meridian owes Alfa 800 — 2,400 of gross obligations. Multilateral netting collapses this to positions against the system as a whole: Alfa pays 100, Meridian pays 100, Nordbank receives 200. Only 200 settles instead of 2,400, which is why deferred net settlement remains attractive despite its risk. That risk is managed, not ignored: international principles expect net settlement systems to hold collateral and committed liquidity sufficient to withstand participant failure, sized to the system's risk profile, alongside controls such as net debit caps. Modern RTGS services borrow netting's efficiency in the other direction, using liquidity-saving mechanisms that offset queued payments — the subject of the next topic.
L4 Standards & sources
The governing standard is the CPMI-IOSCO Principles for Financial Market Infrastructures (PFMI), the international benchmark for systemically important payment systems. Principle 8 (settlement finality) requires clear and certain final settlement no later than the end of the value date — preferably intraday or in real time — a bar RTGS meets by construction and a DNS system meets only at its designated settlement moments. Principle 9 (money settlements) expects settlement in central bank money where practical and available, with risks minimised and strictly controlled where commercial bank money is used instead. Principle 7 (liquidity risk) carries the DNS exposure burden: the system must hold sufficient liquid resources, in all relevant currencies, to complete same-day settlement even if the participant with the largest aggregate payment obligation defaults.
Sources & standards1
- Official requirement
Principles for financial market infrastructures ↗ — CPMI and IOSCO (Bank for International Settlements) · Principle 7 (Liquidity risk); Principle 8 (Settlement finality); Principle 9 (Money settlements)
Published by the CPSS (now CPMI) and IOSCO; contains 24 principles plus responsibilities for authorities. This site uses it only for high-level concepts such as settlement finality.
Sources for this topic3
- Official requirement
Principles for financial market infrastructures ↗ — CPMI and IOSCO (Bank for International Settlements) · Principle 4 (Credit risk); Principle 8 (Settlement finality)
Published by the CPSS (now CPMI) and IOSCO; contains 24 principles plus responsibilities for authorities. This site uses it only for high-level concepts such as settlement finality.
- Market practiceMarch 2003 edition
A glossary of terms used in payments and settlement systems ↗ — CPSS (now CPMI), Bank for International Settlements · definitions of real-time gross settlement and net settlement
Terminology has evolved since this edition; newer CPMI publications refine some definitions.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
What this simplifies: The three-bank netting example uses invented round numbers and one netting cycle; real systems net across many participants and cycles, and risk-control sizing is system-specific.
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.
Deepest material on this page: L4 — Standards & sources. Where a topic stops short of implementation depth, that is a deliberate coverage decision, not an oversight — see coverage.