Gridlock and how it is resolved

Gridlock is the state in which several banks are each waiting for funds from another bank in the group, so no payment can settle even though the group as a whole has enough liquidity. It is the settlement equivalent of four cars arriving at a junction at the same time and each waiting for the next to move. Gridlock is not a failure of any single bank: each bank may be solvent and may have payments queued that would, if released, fund the others. The problem is circular dependency, and it is a well-known risk in every real-time gross settlement system. The Bank for International Settlements PFMI requires system operators to have explicit gridlock resolution procedures. Why gridlock matters is that it can freeze a payment system for hours if nobody acts. A bank that expects an incoming payment will hold its own outgoing payments until the funds arrive, and the bank it is waiting for is doing the same thing. The queue grows, the settlement day stalls, and the operational risk rises because the longer payments sit unsettled, the more likely it is that a cut-off is missed or a customer commitment is broken. Gridlock is most likely late in the day, when liquidity is tight and banks are reluctant to release payments that might leave them short, and it is most dangerous in systems with a small number of large participants, where one bank queue can block the whole system. The parties are the participating banks whose queues are deadlocked, and the system operator that detects and resolves the gridlock. Detection is algorithmic: the operator monitors the queues and identifies a cycle of dependencies, where Bank A waits for Bank B, Bank B waits for Bank C, and Bank C waits for Bank A. Resolution is also algorithmic in most modern systems: the operator runs an offset that settles the cycle as a group, so that each bank receives the funds it needs at the same moment it pays them away. In T2 and CHAPS the gridlock resolution runs automatically, without any bank having to take action, which is why participants may not even notice that a gridlock occurred. In practice the resolution works by finding the smallest set of payments whose simultaneous settlement breaks the deadlock. The algorithm looks for a cycle of queued payments where each payment funds the next, computes the net position of each bank in the cycle, and settles all of them at once. If the cycle nets to zero for every bank, no liquidity is needed at all. If it does not net to zero, the banks with a net debit in the cycle must have enough balance or intraday credit to cover it. The operator typically runs this resolution every few minutes alongside the normal queue optimisation, and it logs every resolution so that the operations team can see how often gridlock occurs and how much liquidity it saved. A worked example shows the mechanism. Bank A has EUR 80 million queued to Bank B and is waiting for EUR 80 million from Bank C. Bank B has EUR 80 million queued to Bank C and is waiting for EUR 80 million from Bank A. Bank C has EUR 80 million queued to Bank A and is waiting for EUR 80 million from Bank B. No bank will release its payment, because each one needs the incoming funds first. The gridlock resolution settles all three payments simultaneously: each bank pays EUR 80 million and receives EUR 80 million at the same instant, so the net movement is zero and no liquidity is required. Without resolution, all three payments would sit in the queue until the end of the day. What happens when the gridlock cannot be resolved by offsetting is that the operator must intervene. The usual escalation is to ask the banks to provide liquidity, either by drawing intraday credit against collateral or by releasing a payment unconditionally, which breaks the cycle. If a bank refuses or cannot provide liquidity, the operator may remove its payments from the cycle and settle the remainder, or may extend the settlement day. The rulebook must define who decides, what the escalation path is, and how the decision is recorded, because a manual intervention in a live settlement system is a high-risk event that will be audited. The operational and accounting implications are that the operations team must monitor gridlock as a metric, not wait for a complaint. A system that gridlocks frequently is telling you that its participants are liquidity constrained or that the queue priorities are wrong. On the ledger, a gridlocked payment is still unsettled, so it remains in the in-transit account, and the end-of-day reconciliation must show it as queued, not settled. The treasury team must also understand that a gridlock resolution does not create liquidity: it only releases liquidity that was already in the system but trapped in a cycle. For a business analyst, gridlock is a test scenario, not a footnote. When you write test cases for a settlement system, you must include a gridlock scenario with at least three banks in a cycle, verify that the system detects it, verify that the resolution settles the cycle, and verify that the settlement report shows the correct net positions. You must also specify the alert that fires when a gridlock is detected, the maximum time a gridlock may persist before escalation, and the manual override procedure. A system that has never been tested for gridlock will fail its first real one in production. Takeaway: gridlock is a circular wait, and the cure is simultaneous settlement of the cycle, not more liquidity. Further reading: the BIS Principles for Financial Market Infrastructures (PFMI) for gridlock as a settlement risk; the Bank of England CHAPS documentation for the liquidity saving mechanism; the ECB T2 user guide for queue resolution. Last reviewed 7 November 2026. The operator that resolves gridlock fastest is the one that sees the whole cycle, not just its own queue.