Every few years, a new standard promises to unify cross-border payments. Each time, the world ends up with one more standard instead of one fewer. That is not a failure of ambition; it is a signal about which strategy actually holds up when the world refuses to converge.

The case for a single standard

Standardisation is appealing: one format, one protocol, one set of rules, and everything interoperates by definition. The difficulty is adoption. Rails are built by different entities with different incentives and jurisdictions, and incumbents rarely migrate off infrastructure that already works. The cost of switching falls on one party while the benefit is shared, which is a strong reason to stay put.

Why interoperability ages better

Interoperability takes the opposite bet. Instead of requiring everyone to converge, it adapts to what already exists. Card networks, local instant schemes, SWIFT, stablecoins and agent protocols each keep their own logic; adapters translate between them. When a new rail appears, it becomes another adapter rather than a rival standard to be defeated.

For anyone building payment infrastructure, that changes the design goal. The question is not "which standard will win" but "how easily can I plug into the next one". An architecture that answers the second question survives the first being answered differently than expected.

What this implies for builders

A protocol layer should expose clean interfaces — API, OpenAPI and MCP for agents, ISO 20022 for institutions — and treat every rail as a path behind a common boundary. Routing then weighs cost, settlement time, reliability and regulatory fit across whichever paths are available, without the core needing to know how each rail works internally.

SUPA is designed this way: a neutral settlement layer with rail adapters, so no single standard has to carry the whole world.

In short

  • Standardisation aims for convergence; interoperability adapts to variety.
  • Rails rarely migrate off what already works.
  • Adapters let a new rail join without replacing the others.
  • For builders, the goal is plug-in ability, not picking a winner.

Build against the interfaces at /developers/.