Treasury Without the Buffer: Vladyslav Kolodistyi on Funding Instant Payouts at Scale

Treasury teams have spent decades building around a single assumption: that money leaves on a schedule they control. Instant payouts remove the schedule, and the funding model has to be rebuilt around a calendar that includes Saturday at midnight.

The infrastructure challenge has been well documented. Banks and payments firms facing the EU regulation had to address liquidity management, verification of payee and bulk payments simultaneously, as EY set out in its analysis of the transition. Platforms building on those rails inherited the same instant payouts problems one layer up.

Vladyslav Kolodistyi, who works on payments infrastructure at PayAdmit, describes the float as the thing nobody realised they were using.

"Settlement delay was working capital that nobody put on a balance sheet," says Vladyslav Kolodistyi. "Real-time payments take it away, and suddenly treasury has to fund positions it never had to fund before. That is not a payments engineering problem. It is a cash problem with a payments trigger."

Real-time payments remove the float treasury quietly relied on

Under batch settlement, a payment authorised on Friday afternoon left the account on Monday morning. Those three days were not idle; they were liquidity. The obligation existed and the cash had not moved, and treasury planning was built on that predictable lag.

Real-time payments collapse it to ten seconds, and the regulation makes the timing non-negotiable, with funds required to reach the payee inside that window at any hour on any calendar day.

That produces three instant payouts funding pressures at once. Instant payouts have to be funded outside banking hours, when wholesale funding markets are closed. Forecasting must be accurate enough to avoid both a shortfall and an expensive idle balance. And the instant payouts peaks are less predictable, because real-time payments concentrate outflows into moments rather than spreading them across a settlement batch.

Vladyslav Kolodistyi sees the weekend as the sharpest constraint. "A platform paying thousands of recipients on a Saturday needs the liquidity in place on Friday," he says. "There is no intraday correction available. Real-time payments mean your Friday forecast is your Saturday reality, and if it was wrong the instant payouts simply fail."

Failed instant payouts carry a reputational cost a delayed batch never did. A batch payment running late is an operational inconvenience. Failed instant payouts are a broken promise the recipient sees immediately.

The regulation removes a mitigation that firms might otherwise have used. Because charges for instant credit transfers cannot exceed those for standard transfers, a provider cannot price the instant payouts funding cost into a premium tier. The payments cost has to be absorbed or engineered away.

Concentration risk is the second treasury problem and the less obvious one. Batch settlement spread outflows across a scheduled run, which smoothed the funding requirement. Real-time payments do the opposite: instant payouts leave when recipients ask for them, and recipients ask at similar times.

Vladyslav Kolodistyi has seen the pattern catch teams out. "Your instant payouts peak is not your volume divided by twenty-four," he says. "It clusters around shift ends and paydays. Real-time payments turn a smooth funding curve into a spiky one, and treasury planning built on averages will be short at exactly the wrong hour."

Currency adds another layer. Instant payouts inside the euro area run on one regulated rail with predictable settlement behaviour. Cross-border instant payouts touch several real-time payments rails with different cut-offs, different limits and uneven real-time payments coverage, and each of those real-time payments corridors has its own funding profile.

Instant payout API design and the operational discipline funding requires

The funding problem and the technical design are more connected than most teams expect, and Vladyslav Kolodistyi argues that the instant payout API is where treasury discipline either gets enforced or lost.

"Your instant payout API should know your funding position," he says. "If it does not, you will submit payments you cannot fund and discover it at settlement. A payments platform that cannot express a funding limit in the request path is not ready for real-time payments at scale."

That has concrete implications. Funding limits belong in the payments platform rather than in a spreadsheet. Queueing behaviour for instant payouts must be defined for the case where funding is temporarily insufficient. Payments status modelling has to distinguish a payout held for funding from one held for screening, because the two need very different responses.

Five practices Vladyslav Kolodistyi recommends for platforms funding instant payouts at scale:

1. Forecast on a rolling basis rather than a daily cut, because settlement is now continuous
2. Express funding limits inside the payments platform so they apply automatically in the request path
3. Model weekend and holiday peaks separately, since real-time payments concentrate outflows unpredictably
4. Define queue behaviour explicitly for funding shortfalls rather than letting instant payouts fail opaquely
5. Reconcile continuously, because a moving settlement position cannot be checked once a day

The fifth is where most payments and finance teams struggle. Batch runs produced tidy daily files and a closing position. Real-time payments produce a continuous stream, and a ledger built around a daily cut will generate reconciliation breaks that nobody can explain afterwards.

"Nobody budgets for the accounting change," says Vladyslav Kolodistyi. "Real-time payments make the settlement position move all weekend. That is a reporting rebuild, and it usually arrives as a surprise three months after launch."

There is a scale threshold worth naming. A platform handling a few hundred instant payouts a day can manage funding manually. At tens of thousands, every funding decision has to be automated, because the queue never drains overnight and there is no overnight.

Buffer sizing is the practical question everyone asks. Vladyslav Kolodistyi declines to give a universal number and gives a method instead: model the largest plausible weekend of real-time payments volume, add the screening holds, and fund to that rather than to an average. Real-time payments punish planning by averages.

"Your buffer is not a percentage of monthly payments volume," he says. "It is a function of your worst realistic weekend. Instant payouts do not care what your monthly average was."

Vendor selection follows from the same logic. A payments provider that supports instant payouts but cannot expose payout and settlement status in real time forces the platform to rebuild visibility elsewhere, and treasury forecasting depends on that visibility entirely. Vladyslav Kolodistyi treats settlement transparency as a procurement requirement rather than a preference.

His sequencing advice mirrors what he says about every real-time payments programme. Build payments reconciliation and exception handling before the fast path. The fast path is a week of engineering; the exceptions and the funding model are the product, and every payments team that inverted that order rebuilt it under pressure later.

Fraud interacts with funding more directly than most teams expect. Under real-time payments there is no recovery window after settlement, so a fraudulent payout is a realised loss rather than a reversible error. That changes the payments provisioning conversation, because instant payouts convert a recoverable exposure into a permanent one.

"Treasury and fraud have to plan together once instant payouts are live," says Vladyslav Kolodistyi. "Under batch settlement, fraud was a recovery cost. Under real-time payments it is a funded loss, and the number belongs in the same forecast as the liquidity."

Staffing follows. Real-time payments are a continuous obligation and the funding decisions cannot wait for European business hours, so either the decisioning becomes automated or the rota extends. Most payments teams find this out after their first weekend of instant payouts.

Stress testing belongs in the plan too. Vladyslav Kolodistyi advises running a funding scenario in which instant payouts spike well above forecast on a Sunday with a rail slow to confirm settlement, then checking whether the payments platform queues, fails or overdraws. Real-time payments make that scenario ordinary rather than exceptional.

"Model the bad weekend before it happens," he says. "Instant payouts at scale are a liquidity product wearing a payments interface, and real-time payments do not wait for your treasury meeting."

Instant payouts are a genuine improvement for recipients and a genuine burden for treasury. Both are true, and the firms handling it well are the ones that planned the funding model with as much care as the integration. Further commentary from Vladyslav Kolodistyi on payments treasury and settlement is published through his LinkedIn profile.