Reader question: If several banks owe one another money at the same time, why should each bank fund every gross payment separately when some obligations can offset one another?
Payment-netting algorithms answer that question by converting a network of gross obligations into a smaller set of net obligations, subject to the legal and operational rules of the payment system. The mathematics can be expressed with matrices, directed graphs, queueing and constrained optimisation. The financial purpose is liquidity efficiency: settle valid obligations with less temporary funding while preserving settlement finality and controlling risk.
Page role and boundary
This article explains public payment-system mathematics. It does not describe confidential payment-system code, provide instructions for delaying obligations, or suggest how a bank should manage its actual settlement account. Real systems are governed by legal rules, central-bank procedures, credit and liquidity limits, operating schedules and participant obligations.
The page is narrower than Bukit Timah Tutor’s overview of how payment systems move money. That article asks how payment networks route and settle. This one asks a more mathematical question: how can a system identify offsetting obligations so that the same economic transfers consume less intraday liquidity?
Start with a directed obligation graph
Suppose three banks have queued payments:
- A owes B 100;
- B owes C 90;
- C owes A 80.
The gross payment value is:
100 + 90 + 80 = 270.
Yet the net positions are much smaller:
- A sends 100 and receives 80, so net position = −20;
- B receives 100 and sends 90, so net position = +10;
- C receives 90 and sends 80, so net position = +10.
The net positions sum to zero, as they must in a closed set of obligations:
−20 + 10 + 10 = 0.
This does not mean the original payments disappear. It means the system can sometimes settle them simultaneously using the smaller net liquidity requirements rather than funding every gross outgoing payment independently.
The obligation matrix
Let Mij be the amount bank i owes bank j. The diagonal is zero because a bank does not need to pay itself. For the three-bank example:
M = [[0,100,0],[0,0,90],[80,0,0]].
For participant i:
gross outgoing = row sum of M for i
gross incoming = column sum of M for i
net position = incoming − outgoing.
The matrix makes several checks possible immediately. The sum of all net positions must be zero. Every obligation must have one sender and one receiver. Removing or duplicating a payment breaks those invariants and should produce an exception before settlement.
Bilateral netting is the simplest offset
Suppose A owes B 100 while B owes A 70. If the rules permit bilateral offsetting, the pair has a net transfer of 30 from A to B.
Gross value = 170.
Net settlement amount = 30.
The liquidity reduction is large because two opposite edges between the same pair can be combined. Real-time gross settlement systems can also use bilateral offsetting without legally converting the entire system into deferred net settlement. The Reserve Bank of Australia’s RITS, for example, publicly describes an Auto-Offset facility that searches queued payments for offsetting payments between two members and, when the conditions are satisfied, settles them simultaneously on a gross basis.
Multilateral offsetting searches a larger graph
Bilateral matching misses cycles. In the A → B → C → A example, no pair necessarily has opposite payments, yet the three-payment cycle can still settle with much less liquidity if processed together.
This is why multilateral offsetting can be more powerful. BIS research on intraday liquidity describes multilateral offsetting as allowing queued payments among multiple participants to be offset when gross outstanding value exceeds net outstanding value. The wider search space can improve liquidity efficiency because it detects structures that pairwise matching cannot see.
Liquidity saving is not the same as legal netting
A critical distinction is often lost in simple explanations. A system can use an algorithm to identify a set of gross payments that can settle simultaneously without replacing those payments with one legally netted claim. In other systems, obligations may truly be netted and only the net positions are settled at a designated time.
That distinction matters because payment finality, insolvency law and settlement guarantees attach to legal rules, not merely to matrix arithmetic. The CPMI-IOSCO Principles for Financial Market Infrastructures therefore treat settlement finality and legal basis as core design issues.
Why queues create gridlock
Consider a gross-settlement system in which:
- A has 20 of available settlement liquidity but must pay B 100;
- B has 20 but must pay C 90;
- C has 20 but must pay A 80.
No individual payment can settle first if each requires the full gross amount. Yet the network as a whole is close to balanced. This is a gridlock problem: each participant is waiting for incoming liquidity that is itself waiting behind another outgoing payment.
A liquidity-saving mechanism can search the queue for a subset whose simultaneous settlement leaves every participant above its permitted lower bound. The search problem is:
find subset S of queued payments such that all participant balance constraints remain satisfied after settling S.
Among feasible subsets, the system can prefer one that maximises settled value, number of payments, priority score or another approved objective.
A simplified optimisation model
Let each queued payment k have value vk and decision variable xk ∈ {0,1}, where 1 means include the payment in the simultaneous settlement set.
A simple objective is:
maximise Σ vkxk
subject to, for every participant i:
starting balance + selected inflows − selected outflows ≥ required reserve or limit.
Real systems can add priority classes, timing constraints, bilateral or multilateral limits, collateral conditions and legal rules. This makes the problem more interesting than ordinary netting: it is a constrained subset-selection problem over a changing queue.
Queue order creates a second optimisation problem
If payments are processed strictly first-in-first-out, one large unfunded payment can block smaller payments behind it. Many systems therefore use variants of bypass FIFO, priority rules, repeated queue scans or offsetting searches.
RITS publicly describes a “next down looping” process that continually tests queued payments and can leave one unsettled while testing later items. The system also uses bilateral offset functionality. The Bank of England’s CHAPS liquidity-saving mechanism similarly illustrates the trade-off between waiting longer for offsetting flows and settling quickly with more liquidity.
This creates a cost surface:
total cost = liquidity cost + delay cost + operational risk cost.
Reducing liquidity usage to zero would not be useful if every payment waits until the end of the day. Settling everything immediately may require excessive prefunding. Good design searches between these extremes.
Worked example: a cycle that unlocks itself
Return to A owes B 100, B owes C 90, C owes A 80. Suppose each participant has 20 units of available liquidity and the system allows simultaneous settlement if no balance becomes negative.
After all three payments settle together:
- A: 20 − 100 + 80 = 0;
- B: 20 − 90 + 100 = 30;
- C: 20 − 80 + 90 = 30.
Every ending balance is non-negative, so the set is feasible under this simplified rule. Yet no participant had enough liquidity to send its largest payment individually at the start. The algorithm did not create money. It recognised that the topology of incoming and outgoing obligations made simultaneous settlement possible.
Why multilateral netting can fail even when the arithmetic balances
A zero-sum net-position vector is necessary but not sufficient. A candidate batch can still fail because:
- a participant lacks the required opening liquidity or collateral;
- a payment has higher priority and cannot wait;
- a legal or credit limit is breached;
- one payment is revoked or invalid;
- the settlement rules do not permit the proposed offset;
- a participant is operationally unavailable;
- the batch would settle after a finality deadline;
- currency or legal-entity boundaries prevent combining obligations.
This is another example of a mathematical theme that appears throughout banking: net arithmetic does not remove state constraints.
Inputs and outputs
A generic liquidity-saving engine can be represented with these inputs:
- queued payment instructions and values;
- sender and receiver identifiers;
- participant settlement balances;
- credit, debit or reserve limits;
- payment priority and deadline;
- revocability and status;
- legal and system-rule eligibility for simultaneous settlement;
- queue-entry time and ordering policy.
Outputs can include a selected settlement subset, updated participant balances, remaining queue, liquidity used, liquidity saved relative to a benchmark and reasons why excluded payments did not settle.
Failure modes
Double-counted instruction: a payment is represented twice in the matrix, distorting both gross value and net positions.
Stale balance: the optimiser uses an old settlement balance and releases a set that is no longer feasible.
Priority inversion: low-priority payments consume liquidity while a time-critical instruction waits.
False netting assumption: the engine treats legally non-nettable obligations as if a mathematical offset were sufficient.
Gridlock blindness: the system keeps testing payments one by one and never searches for a feasible cycle.
Delay gaming: participants strategically delay outgoing payments to wait for incoming liquidity, shifting costs to the system.
Single-objective optimisation: the algorithm maximises liquidity saving but ignores settlement delay or operational resilience.
Diagnostics and verification
- Zero-sum check: the participant net-position vector for a closed batch must sum to zero.
- Conservation check: total gross outgoing value must equal total gross incoming value across the batch.
- Balance replay: independently recompute every participant’s post-settlement balance from the selected instructions.
- Subset feasibility test: verify all balance, limit and priority constraints after simultaneous settlement.
- Duplicate and missing-ID tests: ensure each payment instruction is unique and represented exactly once.
- Counterfactual benchmark: compare liquidity usage and delay against pure RTGS, bilateral offsetting and alternative queue rules.
- Gridlock test: construct cycles that cannot settle individually but can settle jointly and confirm the algorithm detects them.
- Stress test: remove one participant or reduce available liquidity and observe whether the algorithm stops safely rather than creating an impossible batch.
- Finality test: verify that a mathematically selected set also satisfies the system’s legal settlement conditions.
Alternatives and counterexamples
Pure RTGS settles each payment individually and immediately when conditions are satisfied. That can reduce inter-participant credit exposure because settlement is final one payment at a time, but it can demand more intraday liquidity. Deferred net settlement can greatly reduce liquidity needs but concentrates settlement at specified cycles and therefore requires strong controls around finality and participant default.
Hybrid systems attempt to obtain some advantages of both. More recent research has explored additional designs. BIS Project Titus, for example, tested an auction-based liquidity-saving mechanism using participant bids and side payments rather than relying only on conventional queue netting. Its simulations found liquidity savings relative to conventional RTGS processing, but the work is a proof of concept rather than a universal replacement for existing mechanisms.
The lesson is not that one settlement design is mathematically best everywhere. The trade-off depends on legal finality, liquidity cost, delay tolerance, operational design and systemic-risk objectives.
What would falsify confidence in a netting algorithm?
Confidence should fall if the net-position vector does not reconcile to the gross instructions; if a replay produces a negative balance where the engine reported feasibility; if priority payments are repeatedly delayed by lower-priority sets; if liquidity savings disappear under realistic outage scenarios; if legal netting assumptions cannot be supported; or if the engine’s selected batch cannot be reproduced from the recorded queue state.
The strongest verification is changed-surface verification: alter one balance, one payment, one priority or one participant and confirm that the selected settlement set changes for a reason that can be explained.
Connections across Bukit Timah Tutor
Payment netting connects naturally to intraday-liquidity forecasting, because queue design determines how much temporary settlement funding participants need. It also connects to foreign-exchange settlement and payment-versus-payment, where netting and timing interact with principal risk. For the data side, ISO 20022 validation shows why a payment must be structurally valid before it should enter the settlement queue.
Current status and update triggers
Current public central-bank systems continue to use a range of gross, net and hybrid liquidity-saving mechanisms. The Reserve Bank of Australia publicly documents RITS queueing and Auto-Offset functions, while the Bank of England reported enhanced liquidity-saving algorithms in its renewed RTGS service. BIS work published in 2025 also explored auction-based alternatives through Project Titus.
Re-check this article when major RTGS systems materially change queue or liquidity-saving rules, when PFMI guidance changes, or when new settlement mechanisms move from experiments into production and alter the trade-off between liquidity use, delay and finality.
Primary and high-quality references
- CPMI-IOSCO, Principles for Financial Market Infrastructures.
- Bank for International Settlements, Intraday liquidity around the world, including discussion of bilateral and multilateral offsetting.
- Reserve Bank of Australia, About RITS.
- Reserve Bank of Australia, Payment System Design and Participant Operational Disruptions — Simulator Algorithms.
- Bank of England, RTGS and CHAPS Annual Report 2024/25.
- Bank for International Settlements, Project Titus: market-based liquidity efficiency in RTGS systems.
Educational boundary: This article teaches matrices, graphs, queueing and constrained settlement using public financial-infrastructure concepts. It does not provide operational instructions for a live payment system.