Friday at 4:55pm
A supplier invoice is due. In the old world, a treasury team could take a view on that: the payment run is Monday, the bank clears it Tuesday, and the money is gone by Wednesday. There was slack in the system, and the slack was useful. It gave people time to check, to chase receivables, and to move cash between accounts.
Instant payment systems remove much of that slack. The change is not only speed. It changes what a treasury team can rely on.
What instant means here
Instant payment rails let money move between accounts in seconds, at any hour, on any day. Nigeria's NIP is a familiar example for many of our readers, the UK has Faster Payments, and India's UPI is the best known large scale case. They differ in design and rules, but share the property that settlement to the recipient is fast and, typically, final.
Final is the word that matters. A card payment can be disputed, and a cheque can bounce. An instant credit transfer, once sent, is usually very hard to pull back.
Four things that shift
The float disappears. Delay between sending and receiving used to be a quiet source of working capital. Pay on Friday, funds leave on Tuesday. When the money leaves immediately, that buffer is gone, and forecasts built on settlement lags become wrong in a way nobody announced.
Cash moves outside office hours. Receipts can land on Saturday night. Payments can leave at 3am. A treasury process that assumes a daily cut off, a morning balance and an end of day position is describing a world that no longer matches the account.
Mistakes become permanent faster. A wrong account number in a batch used to leave a window to catch it. Now the window may be a few seconds. Controls such as beneficiary name checks, limits and approvals matter more, and they have to work before the payment, not after.
Fraud has less time to be noticed. Fast, final payments suit fraudsters as much as anyone. Business email compromise and fake supplier detail changes are more damaging when the money is gone before anyone reads the email twice.
What treasury teams can do about it
Treat visibility as the first problem. If you cannot see balances across accounts and banks during the day, you cannot manage cash that moves during the day. Intraday balance reporting, from every bank you use, becomes a basic requirement and not a refinement.
Tighten the approval path for outgoing payments. Dual authorisation, sensible limits by amount and beneficiary, and a hold on any change to payee details until it is confirmed by a second route, such as a call to a known number. These controls cost minutes and save very large mistakes.
Rebuild the forecast. Replace assumptions about settlement lags with actual timing data, and be honest where you do not have it. A shorter, more frequent forecast cycle suits a faster world.
Use the speed on the receiving side. Faster collections are a real benefit. Customers who can pay instantly will often do so, and reconciliation can match the payment to the invoice on the same day if you give each customer a unique reference or virtual account to pay into.
The other side of the ledger
Instant rails are not a problem to be survived. For many companies they bring faster collection, lower cost of paying out to suppliers and staff, and fewer manual steps. Paying a contractor on the day the work is approved is a better experience for everyone.
But the benefits go to teams whose systems and controls match the rails. Those that keep running batch processes designed for next day settlement will gain little and carry the new risks.
Note, too, that availability differs. Not every bank, country or corridor offers the same speed, and cross border payments are still mostly slower. A treasury team often operates both worlds at once.
A short note on cross border
Everything above applies most clearly to domestic transfers. Cross border payments remain slower and more varied, with intermediaries, cut off times and compliance checks. Treat them as a separate flow in your forecast and do not assume the speed of the local rail extends to them.
One thing to do this month
Choose a weekend. Look at what your accounts did over it, and whether anyone on your team knew. If the answer is "nothing happened, or we do not know", that is your starting point, because the rails already run when your team does not.