1. Why RTGS Payments Can End Up in a Queue
It is 10 a.m., and Bank A has only CNY 30 million available in its settlement account at the central bank. It needs to pay Bank B CNY 100 million. The instruction is correctly formatted, the beneficiary details are accurate, and the system is running normally. The payment cannot go through for one reason only: the paying bank does not have enough money in its account.
Real-Time Gross Settlement (RTGS) is often understood as "submitted means done." A more accurate description is that RTGS settles payment instructions one by one, in real time, provided they comply with the rules and are fully funded. If the funding condition is not met, the instruction has to wait. In Why Don't Payment Systems Settle Every Payment Immediately? Understanding RTGS and DNS, we compared the trade-offs between RTGS and Deferred Net Settlement (DNS): RTGS settles each payment individually and carries lower settlement risk, at the cost of tying up more liquidity. This article picks up from there and looks at what RTGS does with instructions when the paying bank is temporarily short of funds, and how it gets more payments settled with limited money.
A payment entering an RTGS system typically goes through the following stages:
| Stage | What the system does | Has money moved yet? |
|---|---|---|
| Submission | The paying bank sends the payment instruction to the system | No |
| Validation | Checks format, participant identity, account status, etc. | No |
| Funds check | Checks whether the paying bank's available balance is sufficient | No |
| Immediate settlement or queuing | Books the payment if the balance suffices; otherwise places it in a queue | Funds transfer if settled immediately |
| Retry | Reprocesses queued instructions when new funds arrive or an optimisation routine runs | Funds transfer only on successful settlement |
| Final settlement | Paying bank's account is debited, receiving bank's account is credited, settlement is final | Done |
When the balance is insufficient, many RTGS systems place the instruction in a queue rather than returning it straight away. A queued instruction can wait for funds the paying bank receives later, or for the system's optimisation routine to group it with other payments and settle them together. If a system simply rejected every underfunded instruction, the paying bank would have to resend it again and again, and the system would lose the chance to coordinate across multiple payments.
Queuing and settlement are two different things. Once an instruction is queued, the paying bank's account has not been debited, the receiving bank has not received anything, and the payment has not yet achieved settlement finality. Whether the paying bank can withdraw a queued instruction, and from what point it becomes irrevocable, depends on each system's rules. In the UK's CHAPS, for example, direct participants can change the priority of an instruction while it is queuing, and can also hold or cancel queued instructions[1].
The "real time" in RTGS is therefore conditional: a payment settles immediately only when funding and other rule-based conditions are all met. Queuing is the system's operational arrangement for instructions that cannot settle yet.
2. Once Payments Are Queued, Which Settles First?
How a queue is ordered determines which payments get the limited balance first. Staying with Bank A as an example, it has CNY 30 million in available settlement funds, and three payments are waiting in its queue:
| Payment instruction | Amount | Submitted at |
|---|---|---|
| Payment 1 | CNY 100 million | 10:00 |
| Payment 2 | CNY 20 million | 10:01 |
| Payment 3 | CNY 10 million | 10:02 |
If the system strictly applies First In, First Out (FIFO) and does not allow the head of the queue to be bypassed, the CNY 100 million first payment gets stuck at the front for lack of funds. The next two payments, CNY 30 million in total, have to wait behind it, even though Bank A's balance is exactly enough to cover them. This is known as Head-of-Line Blocking.
If the rules allow the system to skip an instruction at the head of the queue that cannot be paid yet, the outcome changes:
| Queue rule | Payments that can settle now | Bank A balance after settlement | Still waiting |
|---|---|---|---|
| Strict FIFO, no bypassing the head | None | CNY 30 million | All three |
| Bypass instructions that cannot be paid yet | Payments 2 and 3 | CNY 0 | Payment 1 |
With the same CNY 30 million, one rule settles nothing while the other settles two payments. The payee, Bank B, also receives CNY 30 million earlier and can use it to make its own payments.
Queue arrangements in real-world RTGS systems commonly fall into three categories.
Priority Scheduling. Participants mark the urgency of their payments, and the system decides the processing order accordingly. CHAPS direct participants use a priority code in the payment message to distinguish urgent from non-urgent payments: codes 10 to 49 are urgent and enter the urgent stream; codes 50 to 89 are non-urgent and enter the non-urgent stream; payments with no code specified are treated as non-urgent by default[1]. Urgent payments settle immediately if the balance allows, while non-urgent payments queue first and wait to be offset against other payments.
Queue reordering and repeated checks. When new funds come in, limits are adjusted or priorities change, the system rescans the queue and tries to settle instructions that did not settle earlier. Again taking CHAPS as an example, before each offsetting calculation, queued payments are first sorted by priority code and then rotated among "largest first," "smallest first," and "longest queued first," so that no payment gets stuck indefinitely. The top 500 payments of each participant enter the current round, and the rest roll over to the next[1].
Participants'own liquidity controls. A bank can set aside part of its balance for urgent payments, set limits on its net outflows to a single counterparty or to all counterparties, and specify that a payment is automatically promoted to urgent after queuing for a certain time. The Eurosystem's T2 likewise offers participants payment priorities, timed transactions, liquidity reservation, limits, liquidity pooling and optimisation procedures[3]. Behind these tools sits a whole framework of intraday liquidity management for banks.
3. When Two Banks Are Each Waiting for the Other's Money, Can Both Pay at Once?
Now consider a special case:
| Item | Bank A | Bank B |
|---|---|---|
| Initial available settlement funds | CNY 1 bn | CNY 0 |
| Payment due | Pay Bank B CNY 10 bn | Pay Bank A CNY 9 bn |
If processed one by one, both payments get stuck. Bank A needs to pay CNY 10 billion but has only CNY 1 billion; Bank B needs to pay CNY 9 billion and has nothing. A is waiting for B's CNY 9 billion to arrive before paying, and B is waiting for A's CNY 10 billion. Neither can move.
Look at the two payments from a different angle. If both settled at the same time, Bank A would pay CNY 10 billion and receive CNY 9 billion, a net outflow of CNY 1 billion, exactly what it holds. Bank B would receive CNY 10 billion and pay CNY 9 billion, a net inflow of CNY 1 billion. As long as the system can identify these two payments running in opposite directions and arrange for them to settle together at the same moment, both can be completed. This is the idea behind Bilateral Offsetting.
| Item | Bank A | Bank B |
|---|---|---|
| Opening balance | CNY 1 bn | CNY 0 |
| Paid | CNY 10 bn | CNY 9 bn |
| Received | CNY 9 bn | CNY 10 bn |
| Net position | −CNY 1 bn | +CNY 1 bn |
| Closing balance | CNY 0 | CNY 1 bn |
This arrangement is easily mistaken for net settlement. DNS typically accumulates payments over a period, calculates each participant's net position, creates a net settlement obligation, and then settles the net amounts at an agreed time. The arrangement above runs inside RTGS. The algorithm looks at net positions only to answer one question: if this group of payments is put together, does each bank have enough balance? If so, every original payment is booked in full, at the same time. In its LSM User Guide, the Bank of England calls this Gross Simultaneous Settlement and notes that it is legally different from net settlement, while the liquidity required is the same as if the payments had been netted[1].
The difference between the two shows up in Settlement Finality. Under gross simultaneous settlement, every payment selected into the group completes its own gross settlement; payments not selected stay in the queue, unaffected. When and in what form each payment becomes final is determined by the system's rules. We discussed the risks finality is meant to address in Can a "Successful Payment" Be Reversed? What Risks Does Settlement Finality Solve?, which interested readers may read alongside this piece.
In this article, payment matching or offsetting refers to the system searching queued payments for groups that can settle together. It is different from order matching in securities trading, where buy and sell orders are paired into trades. What offsetting reduces is the additional intraday liquidity needed to complete these payments; the payment obligations banks must meet are not reduced by a single payment.
4. Three Banks in a Loop: How Multilateral Offsetting Breaks Circular Waiting
Now extend the example to three banks:
| Payment direction | Amount to settle |
|---|---|
| A → B | CNY 10 bn |
| B → C | CNY 9 bn |
| C → A | CNY 8 bn |
Initial available settlement funds: Bank A CNY 2 billion, Bank B CNY 0, Bank C CNY 0.
Taken one at a time, none of the payments can settle on its own. Bank A has to pay CNY 10 billion but holds only CNY 2 billion, so it is waiting for C's CNY 8 billion. Bank B has nothing and needs A's CNY 10 billion before it can pay C. Bank C also has nothing and needs B's CNY 9 billion before it can pay A. The three banks are linked head to tail in a payment loop.
This state is called Gridlock. In aggregate, the group of payments is not short of money: if all three settled together, Bank A would need net liquidity of CNY 2 billion, exactly what it holds. The blockage comes from the order of execution; none of the three payments can be the one to go first.
Multilateral Offsetting puts the three payments together and calculates each bank's net position:
| Bank | Paid | Received | Net position | Opening balance | Closing balance |
|---|---|---|---|---|---|
| Bank A | CNY 10 bn | CNY 8 bn | −CNY 2 bn | CNY 2 bn | CNY 0 |
| Bank B | CNY 9 bn | CNY 10 bn | +CNY 1 bn | CNY 0 | CNY 1 bn |
| Bank C | CNY 8 bn | CNY 9 bn | +CNY 1 bn | CNY 0 | CNY 1 bn |
The three banks'net positions sum to zero, and no bank's balance goes negative after settlement, so the group can settle gross, all at once. CNY 27 billion of payments that had been stuck are completed using only CNY 2 billion of Bank A's liquidity. Breaking gridlock sometimes requires no extra money in the system, only a different way of executing the payments.
Multilateral offsetting is demanding, though, and a small change in conditions can change the result. Suppose Bank A had only CNY 1.5 billion. With the three payments put together, A's closing balance would be −CNY 0.5 billion, so the group cannot settle. The system can only keep waiting, either for A to receive other funds or for new payments to join the queue and form a new group that can settle.
Real systems face many more constraints than whether a balance goes negative:
- Available balance. Participants may not let queued payments draw on their entire balance. In CHAPS, non-urgent payments can use only the portion of the balance that the participant has allocated to the non-urgent stream[1].
- Limits. Participants can cap their net outflows to all counterparties or to a single counterparty. If a CHAPS participant sets a multilateral limit of £10 million, it cannot send more than £10 million in excess of what it has received from all other participants; a bilateral limit applies to one specific counterparty[1].
- Instruction status and rules. Held instructions, and instructions above a value cap awaiting manual release, cannot enter a group.
As soon as one bank in a group breaches a constraint, the algorithm has to remove some payments and recalculate. Removing one payment changes other banks'net positions too, which can trigger a chain of adjustments. CHAPS identifies payments that breach parameters set by participants, removes them from the current offsetting cycle and leaves them in the queue for the next one, while the remaining payments settle simultaneously[1]. The more participants and queued payments there are, the harder it becomes to find the group that settles as many payments as possible, and optimisation algorithms differ from system to system. We will not go into the specific algorithms here and leave them for a dedicated future piece.
5. How Real RTGS Systems Use These Mechanisms
The examples so far have been simplified. Below we look at large-value central bank payment systems in three different jurisdictions and how they use queue scheduling to save liquidity.
5.1 UK CHAPS: A Liquidity Saving Mechanism Built into RTGS
CHAPS is the UK's high-value sterling payment system. In April 2013, the Bank of England introduced a Liquidity Saving Mechanism (LSM) into this infrastructure[2].
The background was a regulatory shift. Before the 2007–2008 financial crisis, banks held liquidity buffers to cope with balance sheet stress, and intraday payments were also funded from those same buffers. Post-crisis regulatory reforms required banks to hold a separate pool of liquidity for day-to-day payments, raising the cost of holding liquidity. Banks now had an incentive to reduce the liquidity their payments required, which became one of the main reasons the Bank of England developed the LSM[1].
With the LSM in place, CHAPS payments settle in two streams: urgent and non-urgent. For most of the day, RTGS processes only urgent payments. Every two minutes, the system briefly pauses real-time settlement of urgent payments, for about 20 seconds on average, to run an Offsetting Cycle. Matching algorithms search the queue for groups of payments that offset one another without breaching any participant's parameters, and settle them simultaneously at the end of the cycle. Urgent payments that previously failed to settle for lack of funds are also brought into the offsetting cycle and placed at the front of the queue; payments submitted while a cycle is running go into the next one. Thirty minutes before the end of the CHAPS day, any payments still queuing are automatically promoted to urgent[1].
To support the two streams, each participant's settlement account balance is operationally split into two parts: one reserved for urgent payments only, called Headroom, and a non-urgent balance that all payments can use. The lower the non-urgent balance is set, the more non-urgent payments depend on offsetting to settle, saving more liquidity but possibly also waiting longer[1].
Two sets of figures are available on the LSM's impact, each tied to a specific period. Research in the Bank of England's Quarterly Bulletin for 2014 Q2 found that the LSM reduced CHAPS banks'intraday liquidity requirements by around 20%, or about £4 billion[2]. The 2021 User Guide states that in 2019 the LSM helped save approximately 20% to 30% of intraday liquidity across all CHAPS direct participants[1].
The LSM also changed banks'incentives to pay. Intraday liquidity is costly, and banks cannot control when others pay them, so they have reason to delay payments until incoming funds arrive. If every participant adopted this Receipt-reactive Behaviour, the whole system could become gridlocked, and whichever bank paid first would be at a disadvantage. With the LSM, payments submitted early are more likely to find offsetting payments, so banks are far less reluctant to pay first[1]. The Bank of England's 2014 research likewise concluded that the LSM reduced banks'incentives to adopt adverse behaviours to economise on intraday liquidity, enhancing the resilience and efficiency of CHAPS[2]. CHAPS rules also require participants to submit payments promptly and, in principle, allow banks to use their own internal schedulers only in contingency scenarios[1].
5.2 Euro Area T2: Two Components for Settlement and Liquidity Management
T2 is the Eurosystem's RTGS system. According to the European Central Bank, payment orders in T2 are settled one by one on a continuous basis in central bank money, with immediate finality, and there is no upper or lower limit on their value. T2 has two main components: Central Liquidity Management (CLM), which helps participants manage intraday liquidity across TARGET Services, and RTGS, which provides liquidity-saving features including payment priorities, timed transactions, liquidity reservation, limits, liquidity pooling and optimisation procedures[3].
5.3 Hong Kong CHATS: Liquidity Optimisation Tools in a Multi-Currency RTGS
Hong Kong's HKD RTGS system, also known as the Clearing House Automated Transfer System (CHATS), was launched in 1996. Interbank payments are settled continuously, one by one, across the books of the Hong Kong Monetary Authority, without netting. The liquidity-saving tools listed by the HKMA include the CHATS Optimiser, the RTGS Liquidity Optimiser, the Cross-Currency CHATS Optimiser and optimisers related to the Central Clearing and Settlement System (CCASS), all aimed at smoothing payment flows and helping banks use liquidity more efficiently[4].
The table below was compiled by Luminale from public materials published by the Bank of England, the European Central Bank and the Hong Kong Monetary Authority:
| System | Settlement method | Queuing and scheduling | Liquidity-saving arrangements |
|---|---|---|---|
| CHAPS (UK) | Bank of England RTGS, gross, one by one | Urgent and non-urgent streams, priority codes, rotating queue order | Offsetting cycle every 2 minutes with gross simultaneous settlement; bilateral and multilateral limits |
| T2 (euro area) | Central bank money, continuous one-by-one settlement, immediate finality | Payment priorities, timed transactions | Liquidity reservation, limits, liquidity pooling, optimisation procedures |
| CHATS (Hong Kong) | HKMA books, continuous one-by-one settlement, no netting | Per system rules | CHATS Optimiser, RTGS Liquidity Optimiser, etc. |
Sources for the table: Bank of England LSM User Guide (February 2021 edition) and Quarterly Bulletin 2014 Q2, the ECB's T2 overview page, and the HKMA's payment systems page[1][2][3][4].
Placed back in the broader framework of payment systems, queue scheduling and liquidity saving are operational arrangements within the settlement stage. They change the order and grouping in which the same set of payments settles in RTGS; the settlement asset is still central bank money, and settlement is still gross, payment by payment.
6. Conclusion: Completing More Settlement with Limited Liquidity
Back to the question in the title. Payments queue in RTGS because the paying bank's funds, or other rule-based conditions, are not yet in place. Queued instructions are scheduled according to rules such as FIFO, priorities and queue reordering, and different rules let the same balance settle different sets of payments. Liquidity-saving mechanisms search queued payments for bilateral or multilateral groups that offset one another and, under the system's rules, settle them simultaneously and in full, completing more payments with less liquidity.
The mechanism has its limits.
An LSM makes existing liquidity go further. It does not create settlement funds, nor can it replace sources of liquidity such as central bank intraday credit. When no matching payments can be found, the available balance is insufficient or a limit is reached, payments still cannot settle. Poorly chosen settings can even backfire: according to the CHAPS User Guide, if a participant switches on the setting that directs all incoming funds to top up headroom only while its non-urgent balance is zero, not a single non-urgent payment will settle[1].
Offsetting also has a waiting cost. The longer a payment queues, the better its chance of finding an offsetting match, but some payments are time-critical, such as securities settlement, cash legs of foreign exchange trades or customer payments close to a cut-off time, and cannot wait indefinitely for the sake of saving liquidity. CHAPS offers several ways to handle this: submitting the payment as urgent, setting a maximum queuing time after which it is automatically promoted to urgent, or force-settling it when the balance is sufficient[1].
A mature RTGS system settles every payment immediately when funds are sufficient, and when funds are temporarily short, it orders payments sensibly so that existing liquidity is put to the best possible use. Queuing lets payments wait; liquidity-saving mechanisms let payments that are waiting on one another find each other and settle together. The processing speed of a single transaction is only part of how efficient a payment system is. Whether the system as a whole can keep completing settlement with limited liquidity matters just as much, and that requires striking a balance among timeliness, finality, efficient use of liquidity and system stability.
References
[1]: Bank of England, CHAPS Liquidity Saving Mechanism User Guide, February 2021. https://www.bankofengland.co.uk/-/media/boe/files/payments/liquidity-saving-mechanism-user-guide.pdf ↩
[2]: Nick Davey and Daniel Gray, How has the Liquidity Saving Mechanism reduced banks'intraday liquidity costs in CHAPS?, Bank of England Quarterly Bulletin 2014 Q2, 2014-06-16. https://www.bankofengland.co.uk/quarterly-bulletin/2014/q2/how-has-the-liquidity-saving-mechanism-reduced-banks-intraday-liquidity-costs-in-chaps ↩
[3]: European Central Bank, What is T2?. https://www.ecb.europa.eu/paym/target/t2/html/index.en.html ↩
[4]: Hong Kong Monetary Authority, Payment Systems. https://www.hkma.gov.hk/eng/key-functions/international-financial-centre/financial-market-infrastructure/payment-systems/ ↩
Originally published by Luminale Fintech Observer: https://luminale.cn/articles/rtgs-queue-liquidity-saving-mechanisms-en