If you work in payments, you’ve learned to be skeptical of anything announced with the word “transformational.” Most initiatives turn out to be a new message format, a new acronym, or a standard that takes five years to adopt and changes very little day to day.
Swift’s move toward operating a scheme is not one of those.
It’s easy to file it alongside everything else on the roadmap; ISO 20022, instant rails, the next pre-validation API. But that framing misses what’s actually happening. Swift is shifting from being the network that carries the message to defining the rules of the experience itself: what a cross-border payment should cost, how fast it should arrive, what the sender should know before they hit send, and what counts as “done.”
For decades, Swift’s main job was connectivity. It moved messages reliably between institutions and, sensibly, stayed out of the commercial relationship between them. A scheme is a different thing entirely. A scheme is a rulebook, a set of commitments every participant agrees to honour: predictable price, predictable speed, end-to-end transparency, confirmation of delivery.
If that sounds familiar, it should. It’s the model that made card networks feel effortless to consumers, and it’s the direction the G20 has been pushing cross-border payments toward for years: cheaper, faster, more transparent, more accessible. Swift codifying this into a scheme is the industry’s clearest signal yet that “good enough” cross-border is no longer good enough.
Here’s the part worth pausing on. A standard is something you implement. A scheme is something you commit to. And commitments come with expectations attached.
When the bar moves from “the message went through” to “the customer was told the price up front, the payment arrived when promised, and both sides got confirmation,” the work changes. It’s no longer purely about connectivity. It’s about everything that wraps around the payment: validating the payee before money moves, showing fees and timing before the customer commits, and tracking the payment after it leaves. So “where is my payment?” finally has an answer.
That’s a meaningful lift for any institution still treating cross-border as a back-office messaging function. And it’s exactly the gap that separates banks who will meet the scheme comfortably from those who’ll be scrambling to.
We think the banks that win here won’t be the ones who treat the scheme as a compliance checkbox to clear at the deadline. They’ll be the ones who recognize that Swift is, in effect, standardizing the customer experience - and who get ahead of it.
The good news: meeting a scheme like this doesn’t require rebuilding your core. The commitments live at the edges of the payment: pre-payment validation and predictability, post-payment tracking and resolution, which is precisely the layer that core banking systems were never built to handle. It can be added on top of what you already run.
That’s the work we spend our days on, and it’s why we’ve been involved in Swift’s own experience initiatives rather than watching from the sidelines. The scheme isn’t a threat to banks. It’s a roadmap and a fairly generous one, because it tells you exactly what the market will expect before the market starts demanding it.
So the question isn’t really “are we technically able to comply with the scheme?” As most institutions will be. The sharper question is: when a cross-border payment becomes something your customers can price, track, and trust the way they already do everything else - will that feel like a natural extension of what you offer, or like a project you started too late?
That gap is the whole game. And it’s the thread we’ll pull on over the next few weeks.
Next in this series: if Swift’s scheme is one answer to fragmented cross-border payments, Nexus is another - and the two are easier to understand together than apart. More soon.