The Rails Keep Multiplying. The Question Before You Send Doesn't.

If you work in payments, you've learned to be skeptical of anything announced as “transformational.” Most of it turns out to be a new message format or a standard that takes five years to change anything day to day.

This month's tokenised-deposit news is not one of those.

In early September, DBS and Citi completed a cross-border US-dollar payment between Singapore and New York. Settled in minutes on Swift's new blockchain-based ledger, on a weekend that would normally have pushed settlement out to two business days once the time-zone gap and the closed banking week lined up against it. Days earlier, UOB and HSBC ran the same play in Hong Kong dollars. Seventeen banks across six continents are lined up to pilot the same infrastructure. Swift's own framing is that tokenised deposits, regulated stablecoins, and CBDCs are heading toward an interoperable stack, not a single winner-take-all rail.

A new rail, not a new answer

It's tempting to read this as the start of a different conversation - blockchain settlement instead of Swift messages, programmable money instead of correspondent banking. But strip away the rail and the operational question underneath is exactly the one banks have always had to answer before a payment leaves: is this the right account, and is it actually going to the person it's supposed to?

That question doesn't retire when settlement gets faster, if anything it gets sharper. A payment that used to take two days left a window to catch a mistake. A payment that settles in minutes, on a rail explicitly built to be instant and hard to reverse, doesn't.

No bank gets to wait this one out

The practical implication of an “interoperable stack” is that no bank gets to wait and see which rail wins before it invests. Customers and corporates will move value across whichever combination of Swift, instant schemes, and tokenised settlement fulfills their needs, whether it is speed or something else, without perhaps knowing or caring which one they use. The verification layer sitting underneath all of it has to work the same way regardless, or it becomes the weak link nobody notices until a payment goes to the wrong place at machine speed.

Built for whichever rail wins

This is exactly why we've built Global Payee Verification to be payment-rails agnostic from the ground up - one API, whichever scheme or rail the payment ultimately travels on. It's also why we've stayed close to where Swift's own roadmap is heading rather than watching from the sidelines, as one of four global fintech partners in Swift's Payment Experience Proof-of-Value since a couple of years ago. Industry estimates put the annual cost of cross-border payment friction and errors at $250 billion. Most of that isn't a settlement-speed problem. It's a “was this the right account” problem - and that problem doesn't go away because the rail underneath it got a rebrand.

We'll be on stage at Nordic Fintech Week later this month talking through exactly this: what “the future of money” actually changes, and what it doesn't.

Before you hit send

So the sharper question for 2026 isn't “which settlement rail will we be on”. Most banks will end up on several. It's this: whichever one a payment travels on, can you still say with certainty that it's going to the right place - before it's too late to check?