Research library · Briefing paper

The intraday liquidity problem

FNA · 2026

The problem in numbers

  • Fedwire, the United States' large-value payment system, settles about $4.6 trillion a day. It runs no coordinating mechanism, and more than half that value settles in the final third of the day. Everyone waits for everyone else, and each bank funds a peak that exists only because of the waiting.
  • The United Kingdom's CHAPS shows that coordination works in production: its liquidity-saving mechanism cut the settlement banks' intraday liquidity requirement by about 20%, roughly £4bn a day, with no loss of throughput. The gridlock-resolution algorithm underlying that class of mechanism was formalized by Bech and Soramäki (2001).
  • On a five-bank synthetic model referenced to Fedwire, coordinating when banks submit payments reduces modeled in-scope peak net debit by ~49%, about $55.4bn on the modeled book. That is synthetic modeled evidence for the mechanism, not a forecast of any bank's outcome (see Data and methodology).

Liquidity is not scarce here; its use is uncoordinated. Coordinating when banks submit payments lowers the peak net debit that banks fund, and also improves the system's resilience under stress.

Intraday liquidity is a recurring cost

In Fedwire, the United States' real-time gross settlement (RTGS) system for large-value payments, each payment settles individually and irrevocably when Fedwire processes it. Submitting a payment starts that process. To submit a payment before the day's incoming funds have arrived, a bank must fund the gap itself, with central-bank reserves, collateral pledged for intraday credit, or a liquidity buffer held against the peak. That capacity is not free: reserves have an opportunity cost, collateral may be encumbered, and intraday credit and internal liquidity limits carry bank-specific costs. These are liquidity, balance-sheet and collateral effects, distinct from regulatory capital.

For a fixed included payment set and opening position, timing determines the largest cumulative flow gap between what the bank has paid out and received back. Pay before you are funded and the gap is yours to cover; pay after and incoming money recycles to fund the outgoing. The same flows in a different order can produce a different peak. Whether that changes an actual buffer depends on the bank's full account activity and approved stress methodology.

One useful flow-efficiency measure is the reuse ratio: value settled per unit of modeled intraday liquidity. Within that flow-only arithmetic, modeled liquidity needed = value settled ÷ reuse ratio. Actual liquidity resources also depend on balances, collateral, facilities, other account postings and the bank's stress policy.

What regulation requires, and what this model measures

For covered US firms, Regulation YY requires procedures to monitor intraday liquidity exposures, including expected gross inflows and outflows, time-specific obligations, intraday credit and the collateral or liquidity needed for payment- system obligations (12 CFR 252.34). Separately, its liquidity stress tests include a 30-day horizon, and the projected 30-day net stressed cash-flow need determines a buffer of unencumbered highly liquid assets, including cash, assets meeting the HQLA criteria and other qualifying assets (12 CFR 252.35). Corresponding requirements apply to covered foreign banking organizations under 12 CFR 252.156 and 252.157.

A bank's approved methodology may include stressed intraday-liquidity add-ons, and its treasury, risk and regulatory teams determine whether, and how much, a reduction in this modeled flow peak is recognized in actual liquidity resources, collateral or intraday-credit capacity. This modeled in-scope peak net debit (technical name LNNCP: the largest net negative cumulative position, in BCBS 248 terms) is a payment-flow metric, not total account funding or a 30-day HQLA requirement.

The economic translation is therefore a bank-owned sensitivity, not a product claim:

annual value = reduction in modeled in-scope peak × recognition factor × cost of liquidity

The recognition factor (0–100%) is the share the bank's approved methodology recognizes. The cost of liquidity is an annual rate that the bank supplies: what holding one unit of liquidity for a year costs it. It may combine reserve opportunity cost, collateral encumbrance, intraday credit and internal stress-buffer charges. The annual value is computed for each bank, at its own factor and rate, and summed over the banks. It is not a universal funding cost, a Fedwire fee or booked P&L. Under the Federal Reserve's current intraday-credit policy, collateralized daylight overdrafts are priced at zero and uncollateralized overdrafts at an annual 50 basis points using average negative end-of-minute balances, an explicitly different quantity from Sampo's modeled peak.

Why banks wait: a coordination problem

Recycled incoming money is the lowest-cost funding a bank has. So the locally rational move for every bank is the same: hold outgoing payments and wait for incoming ones. Each bank, looking only at its own queue, is right to do this.

But every bank's outgoing payment is another bank's incoming payment. When all banks wait, they withhold from each other the very inflows they are all waiting for. Payment value concentrates in the late afternoon, little value settles for most of the day, and each bank holds a large buffer against a peak that exists only because everyone is waiting. The system as a whole uses far more liquidity than the flows require.

Economists recognize this as a prisoner's dilemma: each bank delaying is individually rational, yet the collective outcome is worse for everyone than if all submitted earlier. In Fedwire, which runs no coordinating mechanism, more than half the day's value settles in the final third of the day, mostly in the late afternoon: the pattern expected when every bank waits for the others.

The problem is structural. A bank cannot identify the full coordination opportunity from its own queue: paying early on its own can fund peers' recycling without a guaranteed benefit to the sender, which is why waiting is the rational default. Capturing the opportunity requires coordinating timing across the network, and how large that network saving is remains a hypothesis to measure on real bank data.

Finding a liquidity-efficient order

The order in which a day's payments are submitted matters. Just 500 payments can be arranged in 500! ways, about 1.22 × 10^1134 distinct sequences, vastly more than the roughly 10^80 atoms in the observable universe. No treasury desk, and no brute-force search, can explore that space. Sampo's rule, parts of which are patent pending, finds a liquidity-efficient payment schedule as the day progresses. Each minute, Sampo updates the payment schedule from the payment intents sent so far, rather than optimizing a fixed batch once.

Coordination also improves resilience

The uncoordinated equilibrium is also fragile. When every bank holds payments until late in the day, value concentrates in a short window, queues build, and the system depends on a large volume of settlement at the end of the day. In that state an operational outage, a late payment or a stressed bank has an outsized effect, because the payments most likely to gridlock are exactly the ones held in the queue.

Coordinated submission timing spreads settlement more evenly across the day. Earlier, steadier throughput means lower intraday peaks, shorter queues, and less value exposed to a single late-day failure. The property that improves liquidity efficiency, funding recycling sooner, is the same one that reduces the system's dependence on any single bank settling on time. This is why liquidity-saving mechanisms are treated as financial-stability infrastructure as well as liquidity-efficiency tools: CHAPS cut liquidity needs while holding throughput, and smoother intraday settlement is a recognized resilience benefit.

Why the problem has not been solved: confidentiality

The solution is simple in concept: coordinate when banks submit payments across the network so incoming funds arrive in time to recycle into outgoing ones. The obstacle is that coordination appears to require disclosure. To compute a payment schedule, someone needs the payment data. But a bank cannot share that data. Payment flows reveal client relationships, positions and strategy, and banks are bound by banking secrecy, client-confidentiality and data-protection obligations that prohibit disclosing them to a central service operator or to competitors. It is a legal and regulatory duty. So the choice has looked binary: keep the data confidential and live with the waste, or breach confidentiality to capture a shared saving. Banks have kept the data confidential, and the waste has continued.

The size of the opportunity

The comparison is with and without Sampo:

  • Without Sampo. Every in-scope payment is submitted at its own time, and FNA measures each bank's peak net debit. In the synthetic cohort, every payment has a unique own time.
  • With Sampo. Sampo advises banks to submit some payments early, never later than their own time. Its no-worse-off guard aims to reduce the risk that a bank is worse off. It is not a guarantee.

On the regenerated 125-day synthetic book (five-bank Fedwire-referenced core, 500 payments/day at or above a $500m threshold), Sampo reduces modeled in-scope peak net debit by ~49%. The cohort monthly peak net debit (the sum of each bank's monthly peak, found separately, averaged over the complete months February and March) falls by ~$55.4bn (49.3% weighted); on an average-day basis the reduction is 59.0% (59.4% weighted by the peak without Sampo), a ~$31bn mean daily difference. At 100% recognition and a bank-supplied cost of liquidity of 1% a year, that monthly figure implies an illustrative ~$554m annual value. No payment is modeled later than its own time. A bank is worse off on a day when its realised peak net debit with Sampo is above its peak without Sampo.

The 500-payment count is a fixed scenario input, not an observed system or bank statistic. Public Fedwire figures establish the overall scale of the rail but do not provide a published count for the selected $500m threshold. The assumed five-bank cohort and payment count must therefore be replaced with the banks' own data before drawing production conclusions.

Limits of the figure. This is a synthetic offline replay, not live bank data or realized funding. The metric excludes out-of-scope account activity, opening balances, collateral duration and other funding drivers; it is therefore "modeled in-scope peak net debit," not the bank's total intraday-liquidity requirement. The prototype also treats submission and settlement as the same model timestamp. A bank pilot must use authoritative RTGS sequence, observed submission times where available, and an agreed rail/operations buffer. Adherence and peer conduct remain the hardest live questions. This prototype is for validation, not production.

Back to the research library · Discuss a pilot