RTGS (real-time gross settlement) posts every payment individually and irrevocably the moment funds are debited from the sending bank's central-bank reserve account. DNS (deferred net settlement) queues payments through the day, offsets them multilaterally, and moves only the net position at a scheduled cycle. The tradeoff is liquidity cost versus intraday settlement risk. Fedwire Funds and TARGET2 are RTGS. Classic CHIPS pre-2001 was DNS; today's CHIPS is a hybrid netting-with-continuous-finality design. Stablecoin settlement is RTGS-shaped by default: every transfer is a gross, irrevocable ledger update. See the BIS CPMI glossary for the canonical taxonomy (BIS CPMI glossary).
Most explainers of the RTGS-versus-DNS split stop at the definitions. What matters operationally is which risk you buy and which cost you pay. RTGS eliminates intraday counterparty exposure but forces participants to fund every outbound payment with reserves at the moment it clears. DNS reduces the funding burden by an order of magnitude. The Fed's own research puts multilateral netting compression on large-value payments in the 90 percent range on typical days per BIS CPMI analysis (BIS CPMI research), but classical DNS keeps a live credit exposure between participants until the settlement cycle closes. Every large-value payment system in the world sits somewhere on that axis, and the choice shows up in the fees, the intraday liquidity requirements, and the failure modes.
How RTGS actually works
In an RTGS system, each payment instruction is processed and settled one by one, across the operator's books, in real time. The operator is almost always the central bank: Fedwire Funds Service is operated by the Federal Reserve Banks (FRBservices), TARGET2 (now the T2 service) is operated by the Eurosystem (ECB TARGET), CHAPS is operated by the Bank of England (Bank of England), SIC is operated by SIX Interbank Clearing on behalf of the Swiss National Bank (SIX Group), and BOJ-NET is operated by the Bank of Japan (Bank of Japan). Because settlement uses central-bank money and is final on posting, settlement risk in the classical sense goes to near-zero the moment the payment lands.
The cost of that finality is intraday liquidity. Every outbound payment consumes reserve balance at the sending institution the moment it hits the queue, and RTGS systems will refuse to release a payment if the sender has not funded it. Fedwire Funds settles enormous daily value on that model, and the Federal Reserve's annual statistics page publishes the current figure (Federal Reserve). That daily value is what banks have to pre-fund with reserves or replenish through intraday credit. Central banks manage the pressure with intraday overdraft lines and queue-management algorithms, but the underlying rule is the same: no reserves, no wire.
How DNS actually works
In a deferred net settlement system, payments are collected across the operating day and netted against opposing flows before any central-bank money moves. If Bank A owes Bank B 100 units in the morning and Bank B owes Bank A 90 units in the afternoon, the DNS operator settles a single 10-unit net position at cycle close instead of two gross transfers. Historically CHIPS (Clearing House Interbank Payments System) ran this way, with end-of-day multilateral netting through The Clearing House Payments Company (The Clearing House). The upside is dramatic liquidity compression. The downside is a live intraday credit exposure between participants: if a member fails before the settlement cycle closes, the surviving members share the loss under loss-sharing rules and pre-committed collateral pools.
The intraday credit risk in classical DNS is what motivated the CPSS Lamfalussy standards in the 1990s (BIS CPMI Lamfalussy report) and drove operators to adopt continuous or hybrid designs. Modern CHIPS, since its 2001 architecture change, releases payments continuously against a real-time bilateral and multilateral position check backed by prefunded balances, so payments settle with intraday finality inside the day, not just at cycle close (The Clearing House). A pure end-of-day DNS is rare in large-value systems today. The pattern survives in retail batch systems (ACH, SEPA batch runs) and in the settlement layer that sits under multilateral FX settlement.
Decision matrix: where each design lives
Axis | RTGS | DNS (classical) | Hybrid netting |
Settlement timing | Continuous, per-payment | Batched, end-of-cycle | Continuous with net position check |
Settlement risk | Near-zero on posting | Live intraday exposure until cycle close | Intraday finality inside collateralized net cap |
Liquidity load | High. Gross funding of every payment | Low. Only net position funded | Medium. Prefunded balance plus net optimization |
Failure mode | Payment queues if sender is short | Loss-sharing pool covers a failed member | Payment held until net cap and collateral clear |
Typical rail | Fedwire, T2, CHAPS, SIC, BOJ-NET | Retail ACH batch, classical CHIPS pre-2001 | Modern CHIPS, CLS FX PvP |
CLS Settlement is worth calling out separately: it settles the two legs of an FX trade payment-versus-payment across the RTGS systems of the 18 CLS-eligible currencies, using multilateral netting to compress the pay-in obligations at the participant level (CLS Group). It is not itself an RTGS, and it is not a classical DNS. It is a purpose-built settlement mechanism that borrows finality from underlying RTGS systems while capturing DNS-style netting efficiency.
SWIFT is neither RTGS nor DNS
A common confusion collapses SWIFT into the same category as Fedwire or CHIPS. SWIFT is a messaging network, not a settlement system. It transports standardized instructions (MT and ISO 20022 MX) between roughly 11,500 institutions across more than 200 countries (SWIFT). Actual settlement happens elsewhere: on correspondent-bank ledgers, or through the RTGS or netting rail sitting under the instruction. Describing a SWIFT payment as "settling on SWIFT" is a category error. The instruction rides SWIFT; the money moves on Fedwire, T2, CHAPS, or through a chain of correspondent debits and credits.
Why stablecoin settlement is RTGS by default
A stablecoin transfer is, mechanically, a gross posting to a distributed ledger. The state transition happens once, atomically, and cannot be reversed by a settlement cycle that has not yet closed. There is no queue of offsetting positions to net down. There is no intraday credit exposure between counterparties, because the transfer either lands and is final (block inclusion + finality guarantees on the underlying chain per Ethereum's finality spec, ethereum.org docs) or it does not land at all. The design shape matches Fedwire and TARGET2 far more closely than it matches classical CHIPS. That is the sense in which stablecoin infrastructure is "RTGS by default": the settlement primitive is gross, and it is final on posting.
The consequence is the same one central banks have lived with since Fedwire went live in 1918 and since CHAPS moved to RTGS in 1996 per Bank of England history (Bank of England): RTGS-shaped rails demand pre-funded balances. In stablecoins, the pre-funded balance is the sender's wallet. There is no intraday overdraft line from an operator standing behind the rail. Treasury operations that migrate from correspondent banking to stablecoin rails swap intraday credit for a real-time funding discipline, and the operational shape of the finance team changes accordingly.
When DNS-like batching still makes sense onchain
Two patterns keep DNS-style netting alive in stablecoin infrastructure. The first is L2 rollup batching: transactions are collected on an L2, compressed, and posted to the L1 as a single batch commitment. The economics look like DNS at the settlement layer, even though each transaction is individually final on the L2 the moment it is included. The second is cross-chain settlement compression, where an orchestration layer nets flows across chains and settles only the residual through a bridge or a canonical mint-burn. These patterns exist for the same reason DNS existed for large-value bank payments: they compress the settlement-layer funding requirement without changing the finality semantics the user experiences.
The design lesson from four decades of large-value settlement is that netting is a liquidity optimization on top of a finality primitive, not a substitute for one. Fedwire and T2 stayed RTGS because central-bank money is the finality primitive. CHIPS became a hybrid because netting-with-continuous-finality captured most of the liquidity savings without leaving a Herstatt-style exposure open through the day. Stablecoin systems are converging on the same answer: a gross, RTGS-shaped base layer with netting orchestration above it, sized to the operational reality that pre-funding is the price of finality.
Related reading
For the mechanics of specific rails, see our explainers on SWIFT's blockchain settlement pilot and Codex's institutional stablecoin architecture. For the underlying orchestration model, see how stablecoin cross-border payments compare to correspondent banking.
For the correspondent-banking chain that stablecoin rails collapse, see Correspondent Banking Explained: Why Cross-Border Payments Still Take Days.
For the correspondent-banking chain that stablecoin rails collapse, see Correspondent Banking Explained: Why Cross-Border Payments Still Take Days.
For the treasurer's view of the pre-funded balances that make correspondent chains expensive, see Nostro and Vostro Accounts: The Real Cost of Correspondent Banking.
For the three US wire settlement rails (Fedwire RTGS, CHIPS net with intraday finality, and CLS PvP for FX) compared side by side, see US Wire Settlement Rails Compared: CHIPS, Fedwire, and CLS in 2026.
