Instant Payments 24/7: Liquidity and Settlement-Risk Operations When the Batch Window Disappears

The Instant Payments Regulation is discussed as a payments-speed problem. It is a liquidity problem wearing a payments badge, and the part of the estate that feels it first is treasury, not the payment gateway.

Most coverage of the Instant Payments Regulation (Regulation (EU) 2024/886, amending the SEPA Regulation and in force since 8 April 2024) treats it as a race to hit ten seconds. Euro-area banks had to be able to receive SEPA instant credit transfers from 9 January 2025 and to send them, with verification of payee, from 9 October 2025. The engineering attention has gone where the deadline points: the rails, the sanctions screening, the name-matching service. That is the visible work. The quieter consequence is that a payment which used to settle inside a controlled batch window now settles at 03:00 on a Sunday, irrevocably, and the funds have to be there. Nobody is at the treasury desk to make sure they are.

The buffer that quietly disappeared

Batch settlement gave you an end-of-day window. Positions accumulated during the day, you netted them, and you trued up overnight against your central-bank account before the next cycle. That window was a liquidity buffer nobody wrote down as one. It absorbed forecasting error, it gave operations time to spot a shortfall, and it meant funding decisions were made a handful of times a day by people who were awake.

Instant settlement removes it. A SEPA instant credit transfer must make funds available to the payee within ten seconds, on all calendar days of the year, around the clock. There is no end-of-day, because there is no end of day. Every outbound payment draws down settlement liquidity at the moment it is sent, and once it is sent it cannot be recalled. The account has to be funded continuously, not periodically, and the scheme-level cap that used to bound a single instant transfer has been removed, so the size of the largest payment you must be able to settle at any second is now a business decision rather than a scheme limit.

Why nights and weekends are the hard part

Here is the mechanical trap, and it is specific. In the euro area, instant payments settle across TARGET Instant Payment Settlement (TIPS), which runs continuously. But the central-bank money that funds a TIPS dedicated cash account sits in the RTGS component of T2, which does not. RTGS operates on business days, within defined hours, and is closed at night, at weekends and on TARGET holidays. During those closures there is no real-time path to move fresh central-bank liquidity into your TIPS account.

So the liquidity you pre-position in that account before RTGS closes on Friday evening is, in practice, the liquidity you have until it reopens on Monday. If a weekend of payment demand exceeds what you parked, outbound instant payments start to fail, or you are forced to hold buffers so large that the forgone return becomes a real cost. This is the operational shape of the problem: a continuous outflow funded from a source that is only open part of the time. It is the same class of resilience issue as any always-on system fed by a batch-era dependency, and it wants the same treatment — the core ledger has to record these postings in real time and treat them as irrevocable, and the funding position has to be visible against them second by second.

What the systems now have to do

Three capabilities move from nice-to-have to load-bearing, and none of them existed in a batch operation because the batch operation did not need them.

Intraday liquidity monitoring, in real time. A daily liquidity report is a rear-view mirror when positions change every second. You need a live view of the settlement-account balance against committed and projected outflows, refreshed continuously, that a system can act on rather than a report a human reads the next morning. The relevant unit of time is now the second, not the day.

Automated funding triggers. Where a real-time funding path exists — during RTGS hours, or through a standing floor-and-ceiling arrangement that tops up the settlement account automatically when it drops below a threshold — the top-up has to be automatic. A treasury team cannot manually fund an account that drains at machine speed, and it certainly cannot do so at 03:00 on a Sunday. The trigger logic, the thresholds and the fallback when the primary path is closed all have to be designed, tested and owned.

Prefunding as a forecast, not a guess. Because you cannot replenish from central-bank money at weekends, the Friday pre-position has to cover the weekend’s demand with a real margin. That is a forecasting problem — historic weekend volumes, known large payments, seasonal peaks — and getting it wrong is expensive in both directions: too little and payments fail, too much and idle balances earn nothing. This is where capacity and demand planning stops being a throughput exercise and becomes a liquidity one.

Who this catches, and when

Euro-area banks are already inside the send-side obligation, so for them this is a live operational reality, not a future one. Payment and electronic-money institutions have longer — their send and receive obligations run to 9 April 2027 — but they are also the firms most likely to reach TIPS indirectly, through a settlement agent, which changes the liquidity question rather than removing it: you are now dependent on your agent’s funding arrangements and cut-off behaviour as well as your own. Non-euro member states run on a later timetable into 2027 and 2028, which is time to design the liquidity operation properly rather than bolt it on after the rails go live.

The firms that will get caught are the ones that treated the regulation as a payments-rail project and closed it when the ten-second SLA was met. The rail was the part with a demo. The liquidity operation is the part with a 03:00 failure mode, no batch window to true up in, and a treasury desk that has gone home.