Liquidity Management in Real-Time Payments Systems

What does RTP liquidity mean?

Liquidity in a real-time payments context is money that can settle a payment this second. That definition is narrower than the one bank treasury has used for decades, and the narrowing is the whole problem. Funds sitting in a correspondent account three hours away from your settlement position are not liquidity at 2 a.m. on a Sunday.

The shape of that requirement depends on the scheme. The Clearing House's RTP network settles from a prefunded joint account at the Federal Reserve Bank of New York, where funds earn no interest and don't count toward reserve requirements. FedNow settles in each participant's own Fed master account, and smaller institutions on either rail commonly hand the job to a funding agent or correspondent.

So on a prefunded rail, every dollar parked in the joint account is a dollar not earning anything, which means your buffer sizing decision is a permanent line item on the balance sheet.

How do banks fund continuous settlement?

Banks fund continuous settlement by holding a standing balance in the settlement account and topping it up as outflows draw it down. There's no end-of-day netting to smooth the peaks. Each payment either clears against your position at that moment or doesn't clear at all, so the funding question becomes a question of timing.

Volume is what makes the timing hard. The RTP network processed 115 million transactions worth $405 billion in the third quarter of 2025, and on October 3 that year it set a single-day record of 1.8 million payments. Growth at that pace means the buffer you sized during your pilot stops being right within a couple of quarters.

The balancing act is between two costs that pull in opposite directions. Idle funds cost you yield every hour they sit there, and a shortfall costs you a rejected customer payment plus whatever emergency funding you scramble for. Most institutions land on a standing floor plus a replenishment mechanism, and the sections below cover each half.

Prefunding creates dedicated settlement capacity

Prefunding means placing money into a scheme-specific account before any payment happens, so settlement capacity exists independently of your daily cash operations. On the RTP network, that balance is your Current Prefunded Position, and it sets a hard ceiling on what you can send.

The mechanics are unforgiving. The core infrastructure will reject the payment if a sending participant's prefunded position can't cover it, with no queue and no retry on the network's side. Your position falls below the requirement without stopping sends, but hitting zero stops them cold.

Buffer size follows your expected net outflow across the longest stretch you can't refund. If your funding access closes Friday evening and reopens Monday, the number that matters is peak weekend outflow, and averages will understate it badly.

Liquidity transfers replenish settlement balances

Liquidity transfers move money into the settlement account from wherever it normally lives, which is what keeps the buffer from being a one-way drain. Banks push funds between master accounts and the scheme's settlement account whenever the position runs down.

The Federal Reserve built this into FedNow directly. Its liquidity management transfer capability lets participants move funds to each other and, importantly, between master accounts and a private-sector joint account at a Reserve Bank, which covers RTP participants too.

That last part deserves attention if you're on RTP and assumed Fedwire hours were your only refill window. The joint-account leg means a weekend replenishment path exists, but only if you've enrolled and tested it before the night you need it. Enrollment isn't automatic, and discovering the gap at 11 p.m. Saturday is an expensive way to learn.

How is liquidity controlled intraday?

Intraday control replaces the periodic treasury check with a continuous loop of monitoring and automated action. A position that was healthy when someone looked at 4 p.m. tells you nothing about 4 a.m. That's the structural break from batch-era treasury, and no amount of extra staffing fixes it.

Regulators pointed at this well before instant rails scaled. The Basel Committee's monitoring tools for intraday liquidity framework, published in 2013, set out seven quantitative measures and required internationally active banks to apply them, while encouraging institutions to build their own stress scenarios.

Read that framework against a 24/7 rail and something becomes obvious. Those tools were designed around business-day payment systems with defined operating hours, so a bank meeting the letter of BCBS 248 can still be blind during the exact windows where instant payments create the most exposure. Nights and weekends need their own measurement.

Real-time visibility reveals funding positions

Visibility means one consolidated view of your settlement balance and in-flight transactions, updated as events occur. Without it, treasury is reconstructing the present from the past.

The messaging layer already exists. ISO 20022's camt.052 intraday report carries near-real-time balance and account movement data within the business day, with each transaction tagged by amount and end-to-end identification back to the original instruction.

Camt.052 was built for a business day, though, which is the catch. On a rail that never closes, you need either event-driven notification or polling frequent enough that your dashboard lag is shorter than the time it takes a payment surge to drain your buffer. Fifteen-minute refresh cycles are fine at low volume and dangerous once corporate senders start using the rail for cash concentration.

Forecasting predicts changing liquidity needs

Forecasting turns historical flow data into an estimate of your net position hours ahead, which is what lets you fund before the shortfall. The inputs are payroll cycles and whatever new transaction patterns your product team just launched.

Tax season is a clean illustration of how fast a pattern can shift. The Clearing House reported that tax refund disbursements over RTP increased 78% in the first four months of 2026 compared with the same period a year earlier.

A 78% year-over-year jump in a single seasonal use case means a model trained on last year's data will underestimate this year's peak by a wide margin during exactly the weeks it matters. Retrain on rolling windows, and treat any new corporate client with concentrated disbursement runs as a forecast input on day one instead of waiting for three months of history.

Automated top-ups prevent avoidable shortfalls

Automated top-ups are rules that fire a liquidity transfer when your balance crosses a defined threshold, without waiting for a person to notice. The rule set needs a trigger level and a fallback if the transfer fails.

Controls belong in the same rule set. Per-transfer caps and daily aggregate limits keep an automation bug from moving your entire master account balance, and every action needs a timestamped audit record. The liquidity management transfer window on FedNow constrains when funds can move between accounts, so automation has to know the calendar as well as the balance.

Here's the part that trips up new implementations. An automated top-up that can't execute because the funding rail is closed is an alert with extra steps. Design the rules so a failed transfer escalates to a human with a pre-authorized alternative, and test that path during a weekend before you rely on it.

What happens when liquidity runs short?

When liquidity runs short, the outcome depends entirely on the scheme, and on the RTP network it's outright rejection. There's no queue and no partial settlement. Other schemes handle shortfalls differently, with queueing or an intraday overdraft against the master account.

The Federal Reserve flagged the overdraft scenario explicitly when designing FedNow, because a participant with unexpectedly high outgoing volume during hours when Fedwire isn't operating may incur an overnight overdraft it can't cure through a transfer from another participant.

The damage compounds beyond the failed transaction:

• A rejected payment reaches the customer as a failure with no explanation they'll accept, since the money was in their account

• Overnight overdrafts carry cost and supervisory attention, and repeated ones invite questions about your liquidity risk framework

• Emergency funding on a weekend prices worse than planned funding on a Tuesday

The reputational piece is the one that lingers. Instant payment failures are visible to the customer in seconds, which is a different exposure than a delayed ACH file nobody sees.

Integration makes automation possible

None of the automation described above works unless your systems exchange balance and transaction data fast enough to act on. The RTP gateway knows what's been sent, and the treasury platform holds the funding logic. If any of those talk in batch files, your control loop runs at the speed of the slowest hop.

APIs replacing batch processing give instant access to balances and transaction status, according to HSBC's research on real-time treasury, which is the difference between an event-driven position and a periodic snapshot.

What that means practically is that integration architecture determines your minimum viable buffer. A bank whose treasury system learns about settlement drawdown ninety minutes late has to hold ninety minutes of peak outflow as extra cushion, permanently. Cutting that lag to seconds releases real money from the joint account, which is how an integration project pays for itself on the balance sheet.

How should banks design liquidity controls?

Design liquidity controls as a written policy with named owners before you write any code, because the technical build implements decisions that treasury has already made. Every item below needs a specific number and a person accountable for it.

1. Minimum balance floor and target balance, sized on peak outflow across your longest non-funding window rather than daily averages

2. Named owner for the forecast model, with a defined retraining cadence and a rule for onboarding new high-volume senders

3. Top-up authority thresholds, showing what the system executes alone and what needs sign-off

4. Weekend and holiday coverage roster with escalation contacts who can actually authorize a transfer

5. Stress scenarios and documented failover for gateway, treasury platform, and funding rail outages

The Basel Committee left stress scenario design to institutions themselves, which has produced no direct methodology for intraday stress testing despite supervisors regularly requiring it during review.

That absence is an opening. Since no standard method exists, a bank that documents its own scenario logic clearly defines the terms of the supervisory conversation.

Build always-on payment infrastructure with EGS

If your liquidity controls depend on systems that were designed for a business day, the fix is an integration and architecture project. Energize Global Services (EGS) is a technology company founded in 2007 and headquartered in Yerevan, Armenia, with offices in the United States and Bulgaria. It builds software for banking and fintech clients.

EGS engineers work on core banking systems and payment platforms. Their work includes the company's own remote banking product, Doocat. That's the same set of components a real-time payments liquidity framework runs on.

Book a call with the EGS engineering team to walk through your current settlement architecture and where the data lags sit.