The Queue You Never See
It is the third hour of a liquidity crunch. You are the operations manager at a community bank with $150 million in assets, and nothing visible has gone wrong. The tellers are smiling. The branch manager is on a call about a mortgage pipeline. But somewhere in the settlement layer, your outgoing transfers have slid to the back of a queue you cannot see, cannot manage, and did not know existed until a title company called to ask where its funds were. By the time your compliance team pulls the thread, the bank has already missed two settlement windows and a closing.
This is not bad luck. It is architecture.
Wholesale interbank payment systems, the kind that clear hundreds of billions in transactions every day, are built around a logic that is rational at the network level and quietly brutal at the periphery. Understanding that logic means getting into the plumbing: how positions are netted, how queues are ordered, and why the institutions sitting furthest from the center of the network are structurally the first to be squeezed when conditions tighten.
Gross Versus Net: The Foundational Fork
Two broad architectures dominate wholesale payment infrastructure. In a real-time gross settlement system (RTGS), each payment is settled individually and immediately, one at a time, drawing directly on a participant's reserve balance held at the central bank. Nothing is batched. Nothing is netted. A payment goes out, the funds move, the books balance in real time.
In a deferred net settlement (DNS) system, payments accumulate throughout the day and are offset against one another. A bank that owes $400 million to counterparty A and is owed $380 million by counterparty B doesn't move $780 million; it moves $20 million at the end of the cycle. The netting is efficient. It also creates a window of exposure between the moment a payment is sent and the moment it actually settles.
Most major wholesale systems now sit somewhere between these poles. Fedwire in the United States operates as an RTGS. CHAPS in the United Kingdom does too, having migrated to direct RTGS participation from an earlier model. But even within an RTGS architecture, not every institution participates directly, and that distinction is where small banks begin losing ground. The difference between direct and indirect participation is, in a stress event, the difference between having a seat at the table and waiting outside for someone to pass a plate through the door.
The Correspondent Layer: Where the Structural Disadvantage Lives
Direct participation in an RTGS system typically requires holding an account at the central bank, meeting minimum capital thresholds, investing in certified connectivity infrastructure, and absorbing ongoing compliance costs. For a bank running $800 million in assets, those costs are proportionate. For a community bank with $120 million in assets, they are not.
So the smaller institution becomes an indirect participant. It routes its large-value payments through a correspondent bank, which holds the central bank account and manages the settlement position on the smaller bank's behalf. The community bank deposits funds with its correspondent, the correspondent includes those funds in its own settlement pool, and payments flow through the correspondent's account rather than directly. It functions, in calmer times, like a perfectly adequate arrangement. Calmer times are not the interesting case.
When liquidity gets tight, the correspondent faces its own intraday position management problem. It has a finite reserve balance. It has multiple indirect participant clients, each generating payment flow. And it has its own proprietary payment obligations. When the correspondent's intraday credit line from the central bank approaches its ceiling, allocation decisions begin. Those decisions are not random, and they are not neutral.
The correspondent will almost always prioritize its own payments first, then the payments of its largest indirect participants (those generating the most fee revenue or holding the largest deposit balances), and then, finally, the traffic from smaller clients. The smaller community bank's outgoing payments don't get blocked outright. They get queued. In an RTGS system, a queued payment is a payment that has not happened yet.
How the Queue Actually Works: A Concrete Walk-Through
Picture two banks using the same correspondent. Ridgefield Savings, a $150 million community bank, and Lakeview Commercial, a $2.1 billion regional bank. Both are indirect participants. Both have sent a batch of large-value payments at 9:30 in the morning.
The correspondent's intraday reserve position is already running tight: a large securities settlement from the previous evening settled late and drew down its overnight balance. The correspondent's queue management system, which ranks outgoing payments by a combination of client tier, payment size, and time sensitivity, places Lakeview Commercial's traffic in Priority Tier 1. Ridgefield Savings sits in Priority Tier 3.
By 11:00 a.m., the correspondent has cleared 94% of Lakeview's payment volume. Ridgefield's payments are still sitting at 41% cleared. One of those pending payments is a mortgage funding disbursement that Ridgefield promised a title company by noon. The title company, not receiving funds, holds up the closing. Ridgefield's operations team spends the next ninety minutes on the phone with the correspondent trying to get a single payment manually escalated. They succeed, but only after a fee and a supervisory override that the correspondent's relationship manager notes in the account file.
Multiply that by a genuine systemic stress event. The problem at scale becomes very hard to look away from.
The Gridlock Mechanism: When Caution Becomes Contagion
RTGS systems carry a specific vulnerability that network designers have known about for decades: gridlock. Because each payment requires a funded reserve balance before it can settle, participants sometimes hold back outgoing payments while waiting to receive incoming funds. If enough participants do this simultaneously, the system freezes. Everyone is waiting for everyone else, a financial version of four cars arriving at an unmarked intersection and none of them moving.
Central banks have developed gridlock resolution algorithms, typically bilateral or multilateral offsetting routines that identify cycles of mutual obligations and settle them simultaneously. Fedwire and CHAPS both run variants of this. The algorithms work, but they work for direct participants.
Indirect participants, sitting behind their correspondents, don't appear in the central bank's offsetting calculations at all. Their positions are invisible to the algorithm. The correspondent appears as a single node. When the algorithm resolves a gridlock cycle involving that correspondent, the freed-up liquidity gets allocated internally according to the correspondent's own priority rules, which returns us, with some inevitability, to Ridgefield Savings in Priority Tier 3.
The indirect participant's payments can only benefit from gridlock resolution after the correspondent has processed the resolution and chosen to pass the liquidity downstream. That second allocation step introduces delay and discretion. Small banks are exposed to both, with no contractual guarantee about how quickly either resolves.
Collateral, Credit Lines, and the Amplifying Effect of Thin Margins
Intraday credit from a central bank is rarely free. In most RTGS systems, it requires collateral, typically government securities or other high-quality liquid assets pledged to back an intraday overdraft facility. Direct participants can optimize their collateral portfolios specifically for this purpose, using repo markets to source securities overnight and holding them ready for morning pledge.
A community bank operating through a correspondent doesn't pledge collateral directly. The correspondent does. And the correspondent calibrates how much of its own collateral buffer it will effectively allocate to each indirect participant's flow, a calibration that follows, once again, the revenue and balance hierarchy.
There is an amplifying dynamic here that rarely gets discussed plainly, and it deserves to be. Small banks typically operate on tighter net interest margins than large ones. They have less capacity to hold large inventories of high-quality liquid assets that aren't earning yield. So even if a community bank wanted to become a direct participant, its collateral situation would likely be less favorable than a larger peer's, meaning it would face higher effective costs for the same intraday credit facility. The architecture doesn't just disadvantage small banks through the correspondent layer; it also makes the exit from that layer expensive. The door out is not locked, exactly. The toll is just set at a level that ensures most small banks never seriously consider paying it.
A Structural Fact, Not a Conspiracy
The distinction between what this is and what it isn't matters enough to state plainly. No one at the correspondent bank is targeting Ridgefield Savings. The priority tiering exists because correspondents face genuine intraday risk management obligations. If they extended equal priority to all clients regardless of size, they would be taking on concentrated risk that regulators would flag immediately. The queue logic is a rational response to a real constraint.
But rational at the system level and equitable at the participant level are different things, and conflating the two is an intellectual error that policymakers have been making for long enough that it has begun to look like a choice. The structure of wholesale payment infrastructure concentrates timing risk at the periphery. Small banks lose settlement access first not because they are less creditworthy in any fundamental sense, but because the network's plumbing routes liquidity through nodes that have no obligation to distribute it equally.
Regulators in several jurisdictions have explored tiered direct participation models that would lower the capital and connectivity bar for smaller institutions, allowing them to hold limited central bank accounts with restricted functionality. The tradeoffs are real: more participants means more complexity in gridlock resolution, more counterparties for the central bank to monitor, more surface area for operational failure. The efficiency argument for keeping the circle of direct participants small is not dishonest.
But the next time a community bank reports that a payment was delayed for reasons it couldn't explain or control, the explanation is sitting in a queue management algorithm it has never seen, running on a server it has no access to, inside a correspondent whose priorities were set long before the stress event began. The architecture decided. The consequences, as ever, were distributed unevenly.