Gridlock and How Systems Resolve It

Gridlock is a situation where several banks are each waiting for funds from another bank in the group, and no bank can settle its queued payments because each one is waiting for the next. Imagine Bank A waiting for funds from Bank B, Bank B waiting for funds from Bank C, and Bank C waiting for funds from Bank A. Each bank has enough incoming payments to cover its outgoing payments, but none of them can move first. The system is stuck, even though the overall position is sound. Gridlock is a real risk in RTGS systems, and it tends to appear on busy days or when a large participant is delayed. Payment systems resolve gridlock with a process called gridlock resolution, which searches the queues for a set of payments that can settle together. The system looks for a cycle of queued payments where each bank's outgoing payments are covered by its incoming payments within the set, and then settles the whole set simultaneously. This requires the system to have a complete view of all queued payments and all account balances, and to be able to calculate whether a proposed set can settle safely. Gridlock resolution typically runs automatically at intervals, and it can also be triggered manually by the system operator when queues build up. Banks can also help prevent gridlock by managing their payment submission behaviour. Sending large payments early in the day, before incoming funds have arrived, increases the chance of queuing and gridlock. Spreading payments through the day, coordinating with major counterparties, and using liquidity forecasts to time large payments all reduce the risk. Some systems also encourage good behaviour by publishing queue information or by charging for excessive queuing. For a business analyst, gridlock is a reminder that payment systems are networks, and the behaviour of one participant affects all the others. Take a concrete gridlock in T2 on a busy morning. Bank A owes Bank B EUR 120 million, Bank B owes Bank C EUR 100 million, Bank C owes Bank A EUR 110 million, and each bank holds only EUR 30 million in its T2 account. No single payment can settle, because each bank is short of the amount it owes, yet the circle as a whole is sound: total inflows of EUR 330 million cover total outflows of EUR 330 million. The gridlock resolution algorithm finds the cycle, checks that every bank can cover its net position inside the set, and settles all three payments simultaneously, moving EUR 120 million, EUR 100 million and EUR 110 million in one atomic step. Without the algorithm, the three payments would sit in the queue until fresh funds arrived, possibly for hours. Gridlock resolution can fail, and operations must know what happens then. If the algorithm cannot find a settling set because one bank in the cycle is short even after netting, the payments stay queued and the system tries again at the next cycle, usually every few minutes. The operator can intervene by releasing a payment manually, by asking a bank to fund its account, or by splitting a large payment into smaller ones that can settle. In T2 the operator also has bilateral and multilateral offsetting, which settles two banks against each other before running the full resolution. A bank that repeatedly causes gridlock may face higher charges or a call from the central bank, because its payment behaviour is a risk to the whole system. For a business analyst, gridlock is a requirements topic, not just a theory topic. The hub must show operations the queue depth per bank, the age of the oldest queued payment, and which payments are blocked by gridlock rather than by a simple lack of funds. Test scenarios must include a three bank cycle, a cycle that cannot settle, and a cycle that resolves only after a funding payment arrives. The BA should also capture the liquidity saving features the bank uses, such as offsetting, prioritisation and reservation, because each one changes how the queue behaves. A payment product that cannot explain why a payment is queued will generate calls from customers and from counterparties, and the queue display is where that explanation starts.