Most coverage of central bank digital currencies stops at the policy layer: who issues one, who’s piloting one, what it means for monetary sovereignty. That framing misses the actual engineering question, which is whether a payment denominated in a digital yuan, digital dirham, or digital pound can move into another country’s ledger and settle there as finality, not as a promise. That’s a different problem from domestic CBDC design, and it’s a different problem from the general cross-chain interoperability debates this Hub has covered elsewhere. It has its own stack of standards, and most of that stack is still being written in real time by central banks that don’t fully agree with each other yet.
Why a domestic CBDC and a cross-border CBDC payment are different engineering problems
A domestic CBDC is, at the architecture level, a closed system. One central bank controls the ledger, sets the rules for who can hold an account or wallet, and defines finality on its own terms. The hard problems are things like offline functionality, privacy against surveillance, and throughput at retail scale. None of that requires any other jurisdiction’s cooperation.
Cross-border movement requires two sovereign ledgers, each with its own finality rules, its own compliance regime, and its own idea of what “settled” means, to agree on a shared protocol without either side ceding control of its own currency. A domestic CBDC payment is a database update inside one institution’s infrastructure. A cross-border CBDC payment is a negotiation between two institutions that don’t report to the same regulator, don’t run the same software, and in some cases don’t trust each other’s AML controls.
This is why the interesting work in cross-border CBDC design isn’t happening at the application layer. It’s happening in messaging standards, settlement protocols, and legal frameworks that have to function across a trust boundary that domestic systems never have to cross.
ISO 20022 as the shared messaging layer, and where it still falls short for CBDCs
ISO 20022 has become the default messaging standard that most cross-border CBDC projects build on, largely because it’s already the standard most correspondent banking and RTGS systems are migrating toward anyway. Using a structured, data-rich message format for a CBDC payment means the payment can carry remittance information, regulatory reporting fields, and purpose codes in a form that’s machine-readable on both ends, instead of the free-text fields that plague older SWIFT MT messages.
That part works. Where ISO 20022 falls short is that it was designed to describe a payment instruction moving through correspondent banking rails, not to describe atomic settlement on a ledger. ISO 20022 tells both systems what the payment is for and who it’s between. It says nothing about how value actually moves, what constitutes finality on a distributed ledger, or how two ledgers confirm to each other that a transfer happened simultaneously rather than sequentially. That gap is being filled by separate settlement protocols that sit underneath the ISO 20022 message layer, and those protocols are where the real interoperability problem lives. A CBDC corridor can standardize its messaging completely and still have no agreed way to guarantee settlement finality across the two legs of the transaction.
Three integration models: single-platform, hub-and-spoke corridors, and bilateral bridges
Central banks exploring cross-border CBDC interoperability have converged on roughly three architectural models, and the choice between them has consequences for every fintech that expects to connect to this rail eventually.
Single-platform models put multiple central banks’ currencies on one shared ledger, operated under a common rulebook and common technical standard. Every participating currency settles on the same infrastructure, which eliminates the cross-ledger messaging problem entirely because there’s only one ledger. The cost is political: participating central banks have to accept a shared technical standard and, to some degree, shared governance over a platform that touches their own currency.
Hub-and-spoke corridors keep each central bank’s CBDC on its own domestic ledger but route cross-border payments through a central hub that handles message translation, liquidity matching, and settlement coordination. This preserves each central bank’s sovereignty over its own system while giving payments a single point of integration. The hub becomes a dependency, though, and its rules effectively become the de facto interoperability standard for everyone who connects to it.
Bilateral bridges connect two central banks’ systems directly, with a protocol negotiated specifically for that pair. This is the most sovereignty-preserving model and the least scalable one: every new corridor requires its own negotiated technical agreement, which means the standard doesn’t generalize, and a fintech operating across multiple corridors has to integrate with each bridge separately.
Most of the live pilots are experimenting with hub-and-spoke or single-platform approaches precisely because bilateral bridges don’t scale past a handful of corridors. That’s a meaningful signal for architecture decisions: betting on bilateral bridge integration as a long-term strategy is likely to mean rebuilding that integration work repeatedly as the market consolidates toward shared platforms.
Inside mBridge and the other multi-CBDC platform pilots setting de facto standards
The most advanced single-platform project to date is mBridge, developed through the BIS Innovation Hub with central banks including the People’s Bank of China, the Hong Kong Monetary Authority, the Bank of Thailand, and the Central Bank of the United Arab Emirates, with the Saudi Central Bank joining as a participant later. mBridge runs a shared distributed ledger that lets each participating central bank issue and redeem its own CBDC on common infrastructure, so a commercial bank in one jurisdiction can hold and transfer another jurisdiction’s central bank money directly, without routing through a correspondent bank chain.
What makes mBridge worth tracking isn’t just that it works technically. It’s that the design choices baked into its settlement rules, participant onboarding requirements, and compliance architecture are becoming reference points that other projects measure themselves against, whether or not they formally adopt mBridge’s standard. That’s how de facto standards form in payments infrastructure: not through a single body publishing a spec, but through one working system becoming the thing everyone else gets compared to.
mBridge isn’t the only project worth watching. The BIS has run parallel experiments including Project Nexus, which focuses on linking domestic instant payment systems rather than CBDCs specifically but shares the same underlying interoperability questions, and Project Agora, which explores tokenizing commercial bank deposits alongside wholesale CBDCs on a shared programmable platform. Project Mariana tested cross-border FX settlement between CBDCs using automated market maker mechanics borrowed from decentralized finance. None of these projects has converged into a single global standard, and none is likely to anytime soon, but each is generating technical precedent that fintechs building toward this space need to understand on its own terms rather than assuming one model will simply win.
Atomic settlement and the payment-versus-payment problem across two sovereign ledgers
The core technical problem in any cross-border CBDC transaction is payment-versus-payment settlement, usually shortened to PvP. PvP means both legs of a currency exchange, the payment in currency A and the payment in currency B, settle simultaneously, so neither party is ever exposed to the risk that one leg completes and the other fails. This is the same principle behind delivery-versus-payment in securities settlement, applied to the specific problem of foreign exchange.
On two separate sovereign ledgers, guaranteeing simultaneity is genuinely hard. Each ledger has its own block production or settlement cycle, its own notion of what counts as final, and no shared clock. The standard technical answer is a Hashed Time-Lock Contract or a similar atomic swap mechanism: both legs are locked with a cryptographic condition, and the release of one is contingent on the release of the other, so the transaction either completes fully on both ledgers or reverts on both. mBridge and most of the bilateral bridge pilots implement some variant of this approach.
The catch is that atomic settlement mechanisms assume both ledgers can execute smart-contract-style conditional logic, which not every central bank’s CBDC architecture supports, and they assume both central banks are comfortable with a settlement mechanism that isn’t directly under either one’s sole control during the lock period. That second point is as much a governance question as a technical one, and it’s part of why PvP across sovereign CBDC ledgers remains the single hardest unsolved piece of this stack, even on the platforms furthest along in production testing.
Where FX conversion and liquidity actually happen in a cross-border CBDC transaction
A detail that gets skipped in most CBDC coverage: FX conversion in these systems doesn’t happen inside the central banks’ own ledgers. Central banks issue and redeem their own currency; they generally don’t want to be in the business of running a foreign exchange market. Conversion happens through liquidity providers, typically commercial banks or licensed market makers, who hold inventory in both currencies on the shared platform and quote exchange rates for the swap leg of a PvP transaction.
This means the liquidity layer of cross-border CBDC settlement looks structurally similar to the correspondent banking liquidity model it’s meant to replace, just compressed into a single atomic transaction instead of a multi-day correspondent chain. The improvement is in settlement speed and counterparty risk, not in the basic economics of who provides FX liquidity. A fintech building on top of these rails still needs to understand who the liquidity providers on a given corridor are, how deep their quoted markets are, and what happens to pricing when a payment is large enough to move the quote before the atomic swap executes. None of the current pilots have published deep, continuous liquidity at scale; most are still operating with a limited set of liquidity providers under pilot conditions, which matters for anyone assuming these rails are production-ready for high-volume commercial flows today.
The governance and legal standards nobody has finished writing yet
The technical layer is advancing faster than the legal and governance layer underneath it. A handful of open questions still don’t have settled answers across the active pilots:
- Legal finality: when does a cross-border CBDC transfer become legally irrevocable, and under which jurisdiction’s law, when the transaction touches two legal systems simultaneously?
- Liability allocation: if an atomic swap fails partway through due to a technical fault, which central bank or platform operator bears responsibility, and under what contractual framework?
- AML and sanctions screening: each jurisdiction has its own screening requirements, and a shared platform has to decide whether screening happens once, centrally, or redundantly at each participant’s edge, without creating gaps either way.
- Data sovereignty: transaction data on a shared multi-CBDC platform may be subject to competing data residency and privacy rules depending on which participants’ data protection regimes apply.
None of these is a purely technical problem, but all of them constrain what the technical architecture is allowed to do. A platform can have elegant atomic settlement logic and still be unusable in production until participating central banks agree on the legal status of what that logic produces.
What fintechs building toward cross-border CBDC rails should be tracking now
For teams evaluating where to put engineering effort, a few things are worth monitoring rather than building against prematurely. Watch which messaging extensions to ISO 20022 get formal adoption for CBDC-specific fields, since that will determine how much custom translation logic a connecting system needs to maintain. Watch which of the hub-and-spoke or single-platform projects move from pilot to limited production, since that’s a stronger signal of where de facto standards will settle than any single central bank’s public statements. And watch the liquidity provider lists on active corridors, since the practical usability of any cross-border CBDC rail depends on who’s willing to quote FX on it and at what depth.
This is still infrastructure in formation, not a settled standard a fintech can build a stable integration against today. Treating it that way, tracking the pilots and the protocols rather than committing engineering resources to a single bridge’s current spec, is the more defensible position until the governance and legal layer catches up to what the settlement layer can already do.
For related ground on this Hub, the stablecoins vs CBDCs breakdown covers who actually controls digital money issued under each model, and the cross-chain interoperability piece goes deeper on the adjacent technical debates around connecting separate ledgers more generally.