How Liquidity Is Managed in Real-Time Settlement

Every payment is also a liquidity problem. A bank can only send money it actually has available at that instant, in the right settlement account. As payment systems have moved toward real-time and 24/7 operation, managing that liquidity has become one of the hardest engineering and treasury challenges in the industry. This post explains the mechanisms that make it work.

Gross versus net settlement

The starting point is how a system settles. In real-time gross settlement (RTGS), each payment settles individually and immediately in central bank money. Nothing is bundled. This eliminates settlement risk, because once a payment is made it is final, but it is liquidity-hungry: a bank must have the full amount on hand for every single payment, moment to moment.

In deferred net settlement (DNS), payments are exchanged throughout the day but only the net positions settle, at scheduled windows. If a bank sends £100m and receives £95m, it only needs to settle £5m. Netting dramatically reduces the liquidity required, but it introduces settlement risk between windows, which is why net systems require collateral or prefunding to guarantee the net obligations.

Prefunding instant payments

Instant payment schemes must reconcile two things that pull against each other: payments are final in seconds, but banks want to conserve liquidity. The common solution is prefunding. Participants place funds into a settlement account at the central bank (or a dedicated technical account) in advance, and every outgoing instant payment is checked against that prefunded balance in real time. The European instant scheme TIPS and the eurozone RT1 system both work this way, holding pre-funded liquidity that is debited and credited continuously.

The challenge is that instant systems run around the clock, including when wholesale funding markets are closed. A bank cannot easily top up its prefunded position at 2am on a Sunday, so treasury teams must forecast weekend and overnight flows and buffer accordingly, or use automated sweeps that move liquidity between accounts as thresholds are hit.

Liquidity-saving mechanisms

RTGS operators soften the liquidity burden with liquidity-saving mechanisms (LSMs). Rather than settling each payment strictly in order, the system holds payments in a central queue and periodically runs offsetting algorithms that match opposing payments and settle them together, so less liquidity is consumed. Techniques include:

• Offsetting and bilateral netting within the queue, settling matched pairs simultaneously.
• Multilateral optimisation, finding a set of payments across many banks that can all settle at once with minimal net movement.
• Reservation and prioritisation, letting banks earmark liquidity for urgent payments while lower-priority ones queue.

The art of settlement design is getting the finality and safety of gross settlement while consuming closer to the liquidity of a net system.

Intraday liquidity and central bank support

Central banks provide intraday liquidity to keep RTGS flowing. Typically a bank can obtain intraday credit against eligible collateral, letting payments settle even before incoming funds arrive, as long as the position is squared by end of day. Monitoring intraday liquidity has become a formal regulatory expectation; banks must be able to measure and report their largest intraday exposures.

Why timing and forecasting dominate

Because liquidity is finite and expensive, timing is everything. A bank that releases all its outgoing payments early in the day drains its account before incoming payments arrive, potentially causing gridlock. Sophisticated participants throttle and sequence payments, hold buffers, and rely on the system's optimisation runs to recycle incoming liquidity into outgoing payments. In 24/7 instant systems, this becomes a continuous, automated process rather than a daily treasury task.

Gridlock and its resolution

Gridlock is the pathological case: bank A is waiting for a payment from bank B before it can pay, while bank B is waiting on A, and neither can move first. RTGS systems specifically defend against this with the offsetting algorithms described above, periodically scanning the queue for a set of payments that, settled simultaneously, break the deadlock even though none could settle alone. This is why a central queue with optimisation is not a mere efficiency feature but a stability mechanism: without it, a liquidity-constrained system can seize up even when every payment is individually valid.

The cost of liquidity

Liquidity is not free. Collateral posted to obtain intraday credit, and balances left idle in settlement accounts to cover peaks, both carry an opportunity cost, so treasury teams actively minimise the liquidity they tie up while staying safely above the level that would cause payments to queue or fail. This tension, holding enough to keep payments flowing but not so much that capital sits idle, is the daily balancing act behind every settlement system, and it is why liquidity-saving design and accurate forecasting translate directly into real money saved.

Key takeaways

• Gross settlement (RTGS) is final and safe but liquidity-hungry; net settlement conserves liquidity but adds settlement risk.
• Instant schemes such as TIPS and RT1 rely on prefunded settlement accounts checked in real time.
• 24/7 operation makes overnight and weekend liquidity forecasting critical, since funding markets are closed.
• Liquidity-saving mechanisms use queuing and offsetting algorithms to cut the liquidity RTGS consumes.
• Central banks supply intraday liquidity against collateral, and regulators now expect banks to monitor intraday exposure.