Clearing Versus Settlement | Two Different Jobs Hidden Inside One Payment

Start with four customers and two banks

Suppose two customers at Bank A owe money to two customers at Bank B. During the morning, Bank A sends S$10,000 to Bank B while Bank B sends S$7,000 back to Bank A.

The customer payments total S$17,000 in gross flow. But if the payment system permits netting, the banks may not need to exchange S$17,000 of settlement value. Clearing can determine that Bank A owes Bank B a net S$3,000.

That S$3,000 is the obligation after clearing. Settlement is the step where Bank A transfers the required settlement value and the obligation is extinguished under the system’s rules.

Layer	What happened
Gross customer instructions	S$10,000 A→B and S$7,000 B→A
Clearing result	Bank A owes Bank B net S$3,000
Settlement	Bank A transfers S$3,000 of the agreed settlement asset to Bank B

The clearing result is information about debt. Settlement is the performance of that debt.

Why clearing exists

Payment systems need to turn thousands or millions of individual instructions into precise obligations among participating institutions. Clearing can include validation, sorting, matching, calculation and sometimes netting.

• Is the instruction in the correct format?
• Which institution owes which other institution?
• Has the item already been processed?
• Can offsetting obligations be netted?
• Which settlement cycle should contain the item?
• Which participant must deliver settlement value and how much?

Clearing is therefore an information and obligation engine. It transforms a large set of transaction-level messages into a smaller, more manageable set of participant-level obligations.

Why settlement exists

A calculated obligation is still a claim. If Bank A owes Bank B S$3,000 after clearing, Bank B remains exposed until the obligation is discharged according to the settlement arrangement.

Settlement answers the harder question: what asset will the receiving institution accept as final payment?

Domestic interbank payment systems commonly settle in central-bank money for eligible participants. Other arrangements can use designated settlement institutions or different structures. The point is that the system defines an asset and a legal-operational moment at which the obligation is treated as fulfilled.

Gross settlement and net settlement solve different problems

Payment systems can settle obligations individually or after netting.

Approach	Strength	Trade-off
Gross settlement	Each payment reaches final settlement individually, reducing accumulated unsettled exposure.	Can require more intraday liquidity.
Net settlement	Offsetting payments reduce the amount of settlement liquidity needed.	Creates dependence on the clearing cycle and the successful settlement of the net position.

Neither is universally superior. System design reflects payment value, speed, liquidity, legal framework and risk tolerance.

Netting is mathematically elegant and institutionally demanding

Netting can dramatically reduce liquidity needs. If Bank A owes Bank B S$100 million while Bank B owes Bank A S$98 million, settling only the net S$2 million is efficient.

But the efficiency depends on rules that remain credible if a participant fails. What happens if Bank A cannot pay the S$2 million at settlement time? Can the cycle still complete? Are payments recalculated? Is collateral available? Are loss-sharing or default procedures defined?

The more a system compresses obligations, the more carefully it has to define what happens when one participant cannot perform.

Clearing risk is not the same as settlement risk

Clearing can fail because messages are invalid, duplicated, unmatched or miscalculated. Settlement can fail because a participant lacks the required settlement asset or because the settlement infrastructure is unavailable.

Risk	Example
Message risk	The payment instruction is corrupted or misrouted.
Clearing risk	The obligation is calculated incorrectly or not admitted into the cycle.
Liquidity risk	A bank knows exactly what it owes but cannot produce settlement value on time.
Settlement risk	The obligation remains outstanding because the final transfer does not complete.
Reconciliation risk	Participants disagree afterwards about which state was reached.

Keeping these risks separate makes incident diagnosis much faster.

Why settlement finality deserves its own concept

Settlement finality tells participants when the transfer is legally and operationally complete under the applicable system. That point matters because the receiver may use the incoming funds to make another payment.

Without a trusted finality rule, payment chains become fragile. If yesterday’s completed payment can unexpectedly unwind, today’s downstream payments may no longer be properly funded.

Finality is therefore an infrastructure property that supports economic confidence far beyond the payment operator itself.

Clearing can be centralised while banking remains decentralised

Customers hold deposits at many separate banks. A clearing system can still coordinate their payment obligations through common standards and rules. This gives banking an interesting structure: many private balance sheets connected through shared infrastructure.

The infrastructure does not erase the banks’ identities. Bank A still owns its assets and owes its customers. Bank B still owns its assets and owes its customers. Clearing provides a common language for obligations between them.

Why cards make the distinction especially visible

A card purchase can be authorised almost instantly while final clearing and settlement occur later. The merchant may receive a confirmation that the transaction can proceed even though the interbank obligation has not yet reached final settlement.

This is a useful reminder that payment systems often separate customer experience from institutional finality. Speed at the interface does not require every back-end state to be identical in time.

Why real-time systems still need clearing logic

Real-time payment does not abolish clearing. It compresses it. The system still needs to validate messages, identify participants, determine obligations and manage exceptions. The difference is that these functions happen quickly enough that the customer experiences them as one continuous event.

Fast systems therefore require exceptionally disciplined state management. An ambiguous payment state that persists for hours is inconvenient. The same ambiguity in a system promising seconds becomes a design failure.

Why banks watch queues

In high-value settlement systems, payments can queue when a bank lacks sufficient immediate liquidity or when sequencing rules delay release. Treasury may prioritise payments, obtain intraday liquidity or wait for incoming funds.

A queue is therefore not merely a technology object. It is a visible representation of the bank’s liquidity position and the system’s scheduling logic.

The quantitative route sits in the wider banking algorithms estate; this article owns the conceptual boundary only.

Four misconceptions to remove

Misconception	Better model
“Clearing means the money moved.”	Clearing determines obligations; settlement discharges them.
“Netting removes settlement risk.”	Netting reduces settlement amounts but creates dependence on successful completion of the net cycle.
“Real-time payment means there is no clearing.”	The clearing logic is compressed, not abolished.
“Settlement is only an accounting detail.”	Settlement finality determines when interbank obligations are actually finished.

A mastery test

1. What does clearing produce?
2. What does settlement extinguish?
3. How can netting reduce liquidity needs?
4. Why can a net settlement system still face participant-default risk?
5. Why does settlement finality matter to downstream payments?

If those answers are clear, clearing and settlement stop being a paired phrase and become two distinct pieces of banking architecture.

---