Liquidity optimisation: queues, offsets and how banks fund a settlement day

Liquidity optimisation is the set of techniques that lets banks settle the maximum value of payments with the minimum amount of central bank money. The problem is simple to state and hard to solve: a bank payment queue holds payments waiting for funds, and each payment needs liquidity to settle, but the same liquidity can be reused once a payment settles and the funds arrive back. The optimisation question is the order in which queued payments are released, because releasing them in the right order frees liquidity that lets more payments settle. Every real-time gross settlement system, including T2, Fedwire and CHAPS, runs some form of queue optimisation, and the details are a core part of the system design. Why optimisation exists is that central bank money is scarce and expensive. A bank cannot hold unlimited balances at the central bank, because that money earns little or nothing and could be lent elsewhere, yet it must settle every payment it has promised. Intraday credit from the central bank helps, but it requires collateral, and collateral is also scarce. Queue optimisation is the third source of liquidity: it is free, because it comes from the payments themselves. The Bank of England, which operates CHAPS, publishes that its liquidity saving mechanism routinely saves participants billions of pounds of intraday liquidity every day by offsetting payments against each other before they settle. The parties are the participating banks, each with its own payment queue, and the central bank or system operator that runs the optimisation algorithm. Each bank submits its payments to the queue with a priority, usually urgent, high or normal, and the operator algorithm looks for offsetting pairs or groups. A pair offsets when Bank A owes Bank B and Bank B owes Bank A: instead of settling both gross payments, the system settles only the net difference, or settles both simultaneously so that neither bank needs to fund the gross amount. The algorithm must respect priorities, so an urgent payment is never delayed to let a normal payment offset. In practice the optimisation runs continuously through the settlement day. A simplified version works in three passes. First, the algorithm scans the queues for bilateral offsets, pairs of payments between the same two banks in opposite directions, and settles the net difference. Second, it looks for multilateral offsets, cycles of payments among three or more banks where each bank owes the next, and settles the cycle as a group. Third, it releases payments in priority order against each bank available balance, using the liquidity freed by the offsets. The European Central Bank T2 system runs its optimisation every few minutes, and the Bank of England CHAPS liquidity saving mechanism runs a similar cycle. A worked example shows the saving. Three banks each owe the next EUR 50 million: Bank A owes Bank B, Bank B owes Bank C, Bank C owes Bank A. Settled gross, each bank needs EUR 50 million of liquidity, EUR 150 million in total. Offset as a cycle, the three payments cancel exactly, no bank needs any liquidity, and the net settlement is zero. A less perfect example: Bank A owes Bank B EUR 100 million, Bank B owes Bank A EUR 60 million. Settled gross, Bank A needs EUR 100 million and Bank B needs EUR 60 million. Offset bilaterally, only the EUR 40 million difference moves, so Bank A needs EUR 40 million and Bank B needs nothing. The saving is EUR 120 million of liquidity for two payments. What happens when optimisation fails is that payments sit in the queue and the day ends with unsettled payments. The most common cause is a liquidity shortfall: a bank expected receipts that did not arrive, so its queue cannot release. The operator response is to let the bank borrow intraday credit against collateral, to let it reprioritise its queue, or to let it cancel low-priority payments. If the shortfall persists to the end of the day, the unsettled payments are either carried to the next day or returned, depending on the system rulebook. The operations team must know the rulebook answer in advance, because an unsettled payment at close of business is an incident, not a routine event. The operational and accounting implications are that the treasury team must forecast its liquidity need for the day, the payments team must prioritise the queue correctly, and the operations team must monitor the queue depth continuously. On the ledger, a queued payment is not yet settled, so it sits in a suspense or in-transit account, and the reconciliation team must be able to show the status of every queued item. A payment that is released from the queue and settles is booked to the settlement account immediately, and the intraday liquidity report must show the peak usage, because that is what the collateral requirement is based on. For a business analyst, liquidity optimisation is a functional requirement area with measurable acceptance criteria. When you specify a queue, you must define the priority levels, the offset algorithm, the frequency of the optimisation run, the conditions under which a payment can be cancelled or reprioritised, and the alerts that fire when the queue depth or the age of the oldest payment exceeds a threshold. You must also specify the reporting: the liquidity saved, the number of payments offset, and the peak intraday usage. A common mistake is to specify the queue as a simple first-in first-out list, which wastes liquidity and is not how any real system works. Takeaway: liquidity is not only bought with collateral, it is created by the order in which payments are released, and the queue algorithm is a liquidity policy. Further reading: the Bank of England CHAPS liquidity saving mechanism description for how offsetting works in production; the ECB T2 user guide for queue optimisation; the BIS Principles for Financial Market Infrastructures (PFMI) for the liquidity risk requirements. Last reviewed 7 November 2026.