Settlement Systems

Settlement versus payment: where the obligation is discharged

In most flows the payment instruction and the settlement that discharges it are separate events, frequently hours apart and frequently handled by different systems. The instruction names the parties, the amount, and the rail, then is validated and routed through the payment system. Those steps confirm the obligation and move it toward discharge; the settlement asset itself moves only when the payer’s account is debited and the payee’s credited at the settlement institution.

Card networks show the gap plainly. Authorization and clearing run continuously, while settlement of the underlying interbank positions lands on a separate cycle — often net, often once a day. Instant-payment schemes split the same way. The end-customer credit is immediate and irrevocable, yet interbank settlement of the scheme’s positions can be deferred to a later cycle in central-bank money. For anyone reconciling flows or sizing intraday liquidity, the instruction timestamp and the settlement timestamp are two different data points.

Beyond timing, the boundary assigns ownership across two systems. The payment system governs routing, format, and participation: which rail an instruction travels and under what scheme conditions. The settlement system governs the asset, model, and finality point. A single end-to-end flow passes through both layers. It is routed as a payment, discharged as a settlement, and sometimes completed across institutions that share no direct account relationship. Routing, rail selection, and scheme participation are treated in payment systems; the mechanics below concern the discharge.

The settlement asset: central-bank money versus commercial-bank money

At the point of discharge, what actually moves is a claim on an institution. Its credit quality depends entirely on which institution stands behind that claim. This is the single most consequential property of any settlement arrangement, although both forms can read identically on a statement.

For direct participants in a central-bank system, central-bank money is the settlement asset: a balance held in the participant’s account at the central bank. The credit and liquidity profile is the strongest available in the currency because the balance is a liability of the issuing central bank and is available on demand. Systemically important systems therefore use central-bank money for settlement. Direct access remains restricted to institutions that hold central-bank accounts — predominantly banks and a defined set of financial market infrastructures.

Below the direct-access layer, commercial-bank money is the operative settlement asset. It is a claim on a commercial bank — the balance a corporate or smaller institution holds in its bank account. When settlement occurs across the books of a commercial bank, the receiver’s discharged position becomes exposure to that bank’s credit and liquidity condition. Most corporate flows settle in this form because the company itself does not hold a central-bank account; it reaches the higher settlement layer through one or more banking tiers.

Through a correspondent or settlement bank, an entity without central-bank access can still use a rail whose underlying interbank layer settles in central-bank money. The corporate’s transfer settles in commercial-bank money on the correspondent’s books; the correspondent’s net position settles in central-bank money in the underlying system. Each tier of indirection inserts an institution between the parties and changes the claim held at discharge. Exposure mapping therefore depends on where the party sits in the tiering structure. Two transfers over the same scheme can leave the receiver exposed to different institutions depending on the correspondent path.

Settlement models

At account level, the settlement model determines how transfers are applied and how long obligations remain open before discharge. The design choice sets the liquidity a participant must hold to settle a given volume and the exposure that accumulates while transfers wait. Those two variables pull against each other.

Model	How settlement happens	Liquidity demand	Exposure window	Typical controls / mechanics	Examples
RTGS	Each transfer settles individually at full value	High	Minimal	Intraday liquidity, queues, central-bank credit	Fedwire, T2
DNS	Transfers accumulate and settle as net positions	Lower	Higher	Limits, collateral, prefunding, loss-sharing	CHIPS, ACH, SEPA net cycles
Hybrid	Continuous final settlement with liquidity-saving logic	Medium / variable	Low to controlled	Offsetting, queues, prefunding	T2, CHIPS

Real-time gross settlement (RTGS)

In an RTGS system, each transfer settles on its own, at full value, the instant it is processed. Settlement is gross because transfers are applied one by one, without offsetting; it is real-time because processing continues through the operating day. The settlement asset is central-bank money, so each discharged transfer is a final claim on the central bank when it posts. Fedwire Funds Service in the United States and T2 — the Eurosystem’s RTGS service, successor to TARGET2 — run this way.

For the sending participant, the constraint is cash timing. Every outgoing transfer needs central-bank money in the right account at the moment of release, and high-volume activity therefore pushes the liquidity requirement toward gross outgoing flow. Intraday liquidity management becomes a scheduling problem. Participants release outgoing payments against expected incoming ones, draw on central-bank intraday credit where available, and manage queues to avoid gridlock when obligations due exceed the balance on hand. Exposure stays near zero because each transfer is final on processing; the price is continuous liquidity availability.

Deferred net settlement (DNS)

For a participant with large offsetting inflows and outflows, DNS reduces the balance that must be available for settlement. A participant with $10bn of gross outgoing and $9.5bn of gross incoming settles a single net figure of $500m, so required liquidity runs to a fraction of throughput. That liquidity efficiency is the reason net systems exist.

The mechanism is cyclical. Through a defined window — commonly up to a day — the system accumulates transfers between participants while leaving them unsettled. At the end of the window it computes each participant’s net position across all counterparties, total incoming less total outgoing, and settles only those net balances. CHIPS settles high-value interbank transfers this way; ACH schemes and SEPA net cycles apply the same accumulate-then-net logic to large volumes of lower-value payments.

Exposure accumulates inside the cycle. Between submission and settlement, the receiving participant is owed value that has not been discharged, and a participant failure before cycle completion can push that exposure across every counterparty in the net. The system therefore needs controls that remain effective until settlement completes. Bilateral and multilateral limits cap position size, collateral or prefunding backs the exposure, and loss-sharing arrangements define how a default is absorbed so the cycle can still complete without unwinding.

Hybrid and liquidity-saving designs

For liquidity teams, the operational question in a hybrid system is how much gross funding the queue can save without moving finality to an end-of-day batch. These systems settle continuously and with finality, like RTGS, while using liquidity-saving logic inside the day.

Offsetting is the core mechanism. Incoming and outgoing transfers wait briefly in a central queue. The system matches opposing transfers against each other, draws only the net difference from the participant’s balance, and still settles each matched transfer individually and finally. Offsetting and queue-management algorithms run repeatedly through the day, releasing a transfer when an offsetting position or sufficient balance appears and holding it otherwise. T2 and CHIPS both carry this kind of offsetting and queue logic.

Prefunding adds a second lever. A participant posts balances in advance, transfers settle against those balances, and the exposure that would otherwise sit open is covered from the start. Liquidity sizing then depends on observable system behavior: how often the offsetting algorithm runs, how much liquidity it frees on a typical cycle, what balance the queue needs before releasing a held transfer, and what prefunding the system mandates. Those figures decide how much liquidity has to sit in the system and when.

Settlement risk and its mitigation

Settlement risk is the risk that a transfer fails to settle after a party has already performed its side. It follows directly from the model and timing above. Whenever one party gives value before it receives the matching value, or before the counterparty’s leg is final, an exposure opens. That exposure decomposes into components of different size and duration, and the mitigations used in practice reshape the exposure itself; the probability of counterparty failure is handled separately, through credit assessment.

Principal risk and the exposure window

One component dominates the others by size: principal risk, the exposure to the full value of a transfer. A party delivers what it owes, the counterparty fails before delivering in return, and the loss is the whole principal — replacement cost is a separate, smaller matter. Principal risk appears whenever the two legs of an exchange settle at different times: the party that settles first is exposed to the full amount until the second leg settles, and that interval is the exposure window.

Foreign exchange is where the window opens widest — two payments, two currencies, two systems, two timelines. A party that pays out the currency it sold before the bought currency arrives is exposed to the full principal of the purchase until that second leg settles; if the counterparty fails inside the window, the entire purchase principal is lost outright. This is Herstatt risk, after the 1974 failure of Bankhaus Herstatt: the bank was closed after it had taken in Deutsche Mark payments but before it had paid out the corresponding US dollars, leaving its counterparties exposed to the full value of the dollars they were owed. Herstatt remains the standard reference because it showed two things at once — the loss is the principal itself, and the window can stretch across time zones and operating-day boundaries.

How wide the window grows tracks the model and the timing. Central-bank-money settlement on an RTGS system keeps it small: each leg is final the instant it posts, so a single transfer’s window is momentary. Deferred netting stretches it across the cycle. Cross-system, cross-currency settlement stretches it furthest, because the two legs settle in infrastructures whose hours and finality timings never line up. Full-principal exposure turns on one specific condition — a counterparty that fails after the first leg is final and before the second leg settles. Trade size and counterparty identity set how much is at stake; the exposure itself exists only across that interval.

Payment-versus-payment and delivery-versus-payment

The structural fix is to make the two legs conditional on each other, so one settles only if the other does and the exposure window closes to zero. Payment-versus-payment (PvP) applies this to two cash legs — the standard mechanism against FX settlement risk. Each currency leg settles on confirmation that its pair will settle, so a party pays out only as it receives. CLS runs the dominant PvP arrangement for FX, settling both currency legs of an eligible trade simultaneously across many currencies in central-bank money; the exchange completes on both sides or on neither, and full-principal exposure never arises.

Securities settlement uses the same conditional logic under a different name. Delivery-versus-payment (DvP) ties a cash leg to a non-cash asset: the security transfers only if its payment transfers, and the payment only if the security does. PvP and DvP leave the probability of counterparty failure untouched — credit risk remains credit risk. What they remove is the principal exposure a failure would otherwise crystallize, by ensuring a failing party never holds one settled leg while the other stays unsettled. The residual exposure is replacement-cost risk: the cost of re-establishing the position at a new market price if the trade collapses — a materially smaller exposure than loss of principal, and managed on its own terms.

Across currencies and borders the window widens with every additional system and timeline in the chain, and the corridor-level question — how legs are sequenced and linked across jurisdictions to keep PvP intact — is worked through in cross-border settlement.

When settlement becomes final

After account posting, a transfer can still be vulnerable if legal finality has not attached. Settlement finality is the point where a settled transfer becomes irrevocable and unconditional, with legal protection against reversal even if a participant later enters insolvency. Before that point, a settlement that looks complete can in principle be unwound. The receiver’s position is settled in operation while remaining unsecured in law.

Across system rules and insolvency law, operational completion and legal finality may land at different moments. A transfer can post, show on a statement, and be treated as received while the legal protection against an insolvency clawback attaches at a separate point fixed by the system’s rules and governing law. The sequence can split into three moments. The transfer first becomes irrevocable to the sender, who can no longer recall it. It then settles against accounts. It later becomes final and irrevocable as a matter of law. RTGS settlement in central-bank money compresses those moments closely together; deferred net systems pull them apart because an instruction can be beyond the sender’s recall long before the cycle settles and legal finality attaches. For any given transfer a participant needs to know which protected moment governs it, because that moment determines when incoming value can be relied on as irreversibly its own; how that moment is fixed under each model is set out in settlement finality.

Settlement in ledger and reconciliation design

A ledger that posts and reconciles transfers inherits the settlement model as a design input. The model dictates which states a transfer can occupy and when the ledger may treat value as available. Mirror the underlying settlement timing and the ledger stays reconcilable; abstract it away and breaks accumulate.

Start with the states themselves. A transfer that has only been initiated, and a transfer that has settled but not reached finality, are different conditions from a transfer that is final and irrevocable. Collapsing them into a single “completed” state erases a distinction the settlement system still holds. Wherever the underlying system defers finality — a netting cycle, a cross-currency leg waiting on its pair, an instant credit waiting on interbank settlement — a real interval opens in which value sits credited to a party but not yet irreversibly theirs. A ledger that models that interval explicitly, as a provisional or pending-final state distinct from final, represents the exposure as it actually stands; one that posts the credit straight to final reports funds that can still be pulled back.

Breaks come next, and most of them trace to the same timing. A reconciliation break is a discrepancy between what the internal ledger records and what the settlement system confirms. The internal record posts on the instruction or on operational settlement; the external confirmation lands on the settlement system’s own cycle and finality timing. When those clocks differ — a deferred net cycle, an offsetting queue that releases a transfer later than it was submitted, a cross-system leg settling on a foreign operating day — the two records disagree until the slower side catches up, and the disagreement is a timing artifact rather than an error in either record. A reconciliation engine that holds the settlement model of each rail classifies expected timing differences as pending, waits out each rail’s known settlement and finality schedule, and escalates a break to investigation only after that schedule has passed without a matching confirmation. An engine blind to the model escalates every timing gap on sight, and buries the real exceptions under the expected ones.