Skip to content
Komposite News
Markets · Technology · Capital
Thursday, September 10, 2026Global EditionGot a tip?
Payments

Treasury was built on float

The instant rails work, clear large sums, and run continuously. Corporate finance departments were designed around the delay they remove.

Elena Vasquez · Fintech Correspondent
August 24, 20262 min read
A paper planner open on a deskNORTHFOLK via Unsplash
The rails settle in seconds. The finance function around them still runs on batch.NORTHFOLK via Unsplash

The technical argument about instant payments is finished. Both American networks clear continuously, both accept transfers large enough for ordinary corporate use, and the participating institution list is no longer a limitation for most companies.

The rails are also being used. Network operators and bank advisers describe volumes and per-transaction limits that now accommodate mainstream business payments rather than only the small, urgent transfers the systems launched with.

What has not moved at the same pace is the finance function. A treasury department is an apparatus for managing known delay: cash forecasts assume settlement takes a predictable number of days, sweep rules run on a schedule, and reconciliation happens in batches because payments arrive in batches.

Remove the delay and none of that breaks, which is the problem. Nothing fails loudly enough to force a change, so instant capability sits alongside a process that does not use it, available to any treasurer who wants to rebuild a working system for a benefit measured in days of float.

Float is also worth something again. When money earned nothing, accelerating a receipt was close to free. At current short rates the interest on funds in transit is a real number, and it appears on the side of the ledger that resists change.

The adoption pattern reflects that arithmetic precisely. The use cases moving first are the ones where delay causes a business problem rather than a treasury inefficiency: payouts to people waiting on money, refunds that would otherwise generate a support call, and settlement at closing where the alternative is a wire and a phone call.

Practitioners advising corporates describe the barriers as less about the rails than about integration and internal readiness, which is a polite way of saying the work sits inside the customer rather than at the bank.

Irreversibility is the operational objection that comes up first and matters most. An instant credit push cannot be recalled the way a mistaken batch file can be pulled before it settles, so the control that used to live in the delay has to be rebuilt before the payment leaves.

That relocates fraud prevention rather than eliminating it. Confirmation of the payee before sending, limits calibrated by counterparty, and approval steps that complete in seconds are the substitute for a window in which somebody could notice.

Continuous settlement also removes a boundary the finance calendar depends on. A treasurer who could previously reason about a closing position now manages an account that moves at three in the morning on a Sunday, and the forecasting tools were not built for that.

None of this argues against the rails. It explains why capability and adoption diverge for years in payments, and why the constraint is a finance department's operating model rather than anything a network operator can ship.

More On This Story