Banks and FIs don't want a new financial system. They want a faster one.
There's a popular story in crypto that goes something like this: one day, banks and crypto networks will merge into one big, elegant system, and the old rails will simply disappear.
It's a nice story. It's also not what we're seeing from where we sit.
At Saber, we move money for institutions and fintechs in the West to the Middle East and South East Asia. We talk to banks, PSPs, and fintechs every week about why they're interested in stablecoins. And the honest pattern is this: none of them are asking to join an open, permissionless system. They're asking us to help them settle faster, reconcile less, and move money with fewer intermediaries, using blockchain as the plumbing.
What they're actually buying
Enterprises don't evaluate this technology the way early crypto users do. They're not weighing decentralization or censorship-resistance. They're running it through the same checklist they run every vendor through: does this reduce cost, reduce risk, and fit inside our compliance and operational controls?
That's why the parts of blockchain infrastructure getting real adoption right now are narrow and specific:
Settlement that closes instantly, so capital isn't locked up waiting for a trade or transfer to finalize.
A single shared record, so reconciliation between counterparties stops being a manual, error-prone back-office job.
Money that can carry logic, so payouts, margin calls, or scheduled payments execute automatically instead of through a chain of emails and approvals.
What they consistently don't want is the open-access, pseudonymous, irreversible version of any of this. They want the ability to freeze a transaction, know exactly who they're transacting with, and produce a clean audit trail on demand. Ask any bank or payment company whether they'd trade regulatory reporting and reversibility for permissionless access, and the answer is no, every time.
The design implication for anyone building this infrastructure
If you're building products or APIs for this segment (as we are) the lesson isn't "make it more decentralized" or "make it more open." It's closer to the opposite: build the settlement speed and programmability first, and treat compliance, identity, and control as core product features rather than bolt-ons.
Concretely, that means:
KYC, sanctions screening, and transaction monitoring belong in the API, not around it. If a partner has to build their own compliance layer on top of your rails, you've made your product harder to buy, not easier. Same with if they can’t use their existing KYC systems.
Give operators the controls they already expect like the ability to pause, reverse, or flag a transaction, and to identify who's on the other side of it. Removing these isn't a simplification, it's actually a disqualifier.
Offer the outcome, not the architecture. Faster settlement, fewer reconciliation hours, lower cost per transfer, that's what gets the budget approved. Nobody in a procurement meeting is buying "programmability" for its own sake.
Design for integration into existing workflows, not for replacing them. The institutions we work with want this to sit inside their current treasury, compliance, and reporting stack, not require them to rebuild it.
Two different products, not one
It's worth being clear-eyed that this is a genuinely different product than the open, composable systems crypto-native builders are still pushing forward and that's a good thing.
Open networks are where a lot of the underlying innovation (new settlement models, new primitives) gets tested first. The compliant, enterprise-ready version of that infrastructure which is where we've chosen to focus is what makes that innovation usable by the institutions actually moving global payment volume today.
That's the opportunity as we see it: not recreating an open financial system inside a bank, but taking the parts of blockchain that make money move better and packaging them in a way institutions can actually say yes to.