Two systems can move the same payments and present you two completely different invoices. One asks for cash on hand all day long. The other asks you to carry exposure to everyone else in the system until a settlement window closes. That choice, gross or net, is the most consequential design decision in any payment system, and it sits underneath every rail we cover later in this course.

Two ways to settle the same obligations

In a real-time gross settlement system, every payment settles individually, in full, the moment it is processed. There is no bundling. If you owe a counterparty $10 million and you are owed $9 million back a minute later, the system moves $10 million one way and $9 million the other. Each instruction is its own final settlement event. Fedwire and CHIPS are covered in the next module, but Fedwire is the canonical RTGS example: gross, immediate, irrevocable.

In a deferred net settlement system, the rail accumulates obligations across a window, a few hours or a full day, then settles the net position once or a handful of times. Nobody moves central bank money on each individual payment. The system tracks who owes whom, nets it all down, and settles the residual balances at the window close. ACH and most card networks live here, and we cover each in its own module.

The same flows go through both. What changes is when settlement becomes final and how much actual money has to move to make it final.

Bilateral netting, then multilateral netting

Netting comes in two strengths, and the difference matters.

Bilateral netting offsets obligations between two parties only. Bank A owes Bank B $100 million, Bank B owes Bank A $80 million, so A pays B $20 million net. Useful, but it only collapses one relationship at a time.

Multilateral netting offsets every participant's obligations against every other participant's, all at once, usually through a central counterparty or clearing house that sits in the middle. Instead of a web of bilateral pairs, each participant ends the window with a single net position against the system: either a net payer or a net receiver. This is where the liquidity savings get large, because obligations that would have required separate gross movements cancel against each other across the whole membership.

A worked netting example

Take four banks and the gross payments they send each other across a settlement window.

Add up the gross instructions: $50 + $30 + $40 + $20 + $35 + $25 + $15 + $45 million. That is $260 million of payments that an RTGS system would settle one at a time, each requiring funds on hand at the moment it goes through.

Now net multilaterally. Total each bank's outflows against its inflows.

The net payers, A ($30 million) and D ($15 million), fund $45 million between them. The net receivers, B ($35 million) and C ($10 million), collect $45 million. Total settled in central bank money: $45 million, against $260 million of gross instructions. Payers and receivers balance, as they must.

That is a settlement ratio of roughly 0.17. About one sixth of the gross value actually had to move. In real high-volume systems handling lower-value payments, the ratio runs far lower, which is exactly why batch rails exist.

The liquidity bill versus the risk bill

Here is the tradeoff stated plainly. Netting did not make the payments disappear. It deferred them and offset them. The value that did not move is the liquidity you saved, and it is also the exposure you carried.

RTGS sends you a liquidity bill. Because every payment settles in full immediately, you need funds available throughout the day to keep your outgoing payments flowing. Run short and your payments queue or fail. The system manages this with intraday liquidity: balances at the central bank, intraday credit, collateral, and queuing logic that releases payments as offsetting funds arrive. You pay in cash and collateral that has to sit ready.

Deferred net settlement sends you a risk bill. Through the window, settlement has not happened yet. Every participant is exposed to every other participant's ability to fund its net position when the window closes. If a net payer fails before settlement, the netting may have to be unwound, and everyone's positions recalculate, possibly leaving others short. That is settlement risk and netting risk, and it has its own module later in this course because it is where systemic failure actually lives.

So the same set of payments is cheap in liquidity and expensive in risk under DNS, or expensive in liquidity and cheap in risk under RTGS. There is no free version. You are choosing which bill to pay.

Why both exist, and why the line blurs

Systems do not pick one and stop thinking. High-value, time-critical payments where settlement risk is intolerable go gross, in real time. High-volume, lower-value flows where the netting savings are huge go through deferred net settlement. Most economies run both side by side for exactly this reason.

The interesting part is that the two converge. Shorten a DNS window and the netting benefit shrinks, because fewer payments accumulate to offset each other. Shrink the window to zero and you have rebuilt RTGS. Conversely, modern RTGS systems bolt on liquidity-saving mechanisms, offsetting algorithms that find and settle matching payments together, which is netting smuggled back in to cut the liquidity bill. The clean textbook line between gross and net is really a dial.

Gross or net is not a feature comparison. It is a decision about which scarce resource you are willing to commit: liquidity you must hold, or risk you must carry. Read every rail in this course by asking which bill it sends, and to whom.

When you design a funding model in the final module, this is the first question you will answer.

← Previous
Authorize, Clear, Settle: Three Events, Not One
Next →
Fedwire and CHIPS: Large-Value Clearing in the US