How to Design a CBDC for Cross-Border Payments

A cross-border CBDC is not a single currency but a system of systems connecting domestic central bank infrastructures. The primary design challenge is enabling seamless value transfer between potentially incompatible national ledgers while preserving monetary sovereignty and regulatory compliance. Key architectural models include: a common multi-CBDC platform (mCBDC), interlinked domestic systems, and a single global CBDC. The Bank for International Settlements (BIS) categorizes these as mCBDC Bridge, Interlinking, and Single Rulebook models, each with distinct governance and technical trade-offs.

The mCBDC Bridge model, exemplified by projects like Project mBridge, uses a common distributed ledger platform shared by participating central banks. This platform acts as a corridor network for cross-border transactions, settling payments in wholesale CBDC. Smart contracts automate compliance checks like anti-money laundering (AML) and capital flow management. A critical technical component is an Atomic Cross-Chain Swap protocol, ensuring that a payment on one domestic ledger is finalized only when the corresponding credit on the foreign ledger is confirmed, eliminating settlement risk.

Implementing atomicity often involves Hash Time-Locked Contracts (HTLCs) or more advanced cryptographic protocols like Adaptor Signatures. In an HTLC-based bridge, the payer locks funds with a cryptographic hash. The payee must present the preimage (the data that generates that hash) to claim the funds within a set time window. This creates a conditional payment that is either completed atomically or refunded. Code for a simplified HTLC condition in a smart contract might check: require(sha256(preimage) == hashLock && block.timestamp < timeout, "Claim failed");.

Interoperability requires standardized APIs and data formats. The ISO 20022 messaging standard is becoming the common language for cross-border payments, defining structured data fields for payer, payee, amount, and purpose of payment. A cross-border CBDC system must translate domestic ledger transactions into ISO 20022-compliant messages for the corridor network. This layer also handles currency conversion, which can be managed by a decentralized foreign exchange market built into the platform or through predefined central bank arrangements.

Governance and legal frameworks are as critical as the technology. A cross-border system must define rules for dispute resolution, transaction finality, and liability in case of technical failure. The architecture must support privacy-enhancing techniques like zero-knowledge proofs for regulatory reporting, allowing authorities to verify compliance without exposing all transaction details to all parties. This balances the need for transparency with data protection, a key concern for both individuals and sovereign states.

For developers, building prototypes involves selecting a ledger platform (e.g., Corda, Hyperledger Fabric, or a permissioned Ethereum variant), designing token and smart contract standards, and integrating with existing national payment systems (RTGS). Testing must simulate network partitions, oracle failures for forex rates, and adversarial scenarios to ensure resilience. The end goal is a system that reduces settlement times from days to seconds, lowers costs, and increases transparency in the global financial system.

A foundational prerequisite is selecting the appropriate distributed ledger technology (DLT) architecture. For cross-border functionality, the system must support interoperability with other ledgers and CBDC networks. Options include permissioned blockchains like Hyperledger Fabric or Corda for controlled access, or a hybrid model combining a private settlement layer with public blockchain bridges for transparency. The choice impacts scalability, finality, and the ability to integrate with existing real-time gross settlement (RTGS) systems. Key technical considerations include transaction throughput (targeting 1,000-10,000 TPS), sub-second finality for settlement, and robust digital identity frameworks for participant verification.

Understanding monetary policy and regulatory compliance is non-negotiable. A cross-border CBDC must be designed with embedded regulatory controls, often called a "two-tier" or "hybrid CBDC" model, where the central bank issues the digital currency but intermediaries handle customer-facing services. This requires programmable features for enforcing jurisdictional rules, such as transaction limits, wallet tiers, and automated compliance checks for Anti-Money Laundering (AML) and Counter-Financing of Terrorism (CFT). Designers must model how the CBDC interacts with domestic monetary policy tools like interest rates and reserve requirements in a multi-currency context.

The core of cross-border functionality lies in interoperability protocols. This involves designing or adopting standards for atomic cross-chain settlement to eliminate Herstatt risk. Key models include: 1) Single ledger with multi-currency capabilities, like the Bank for International Settlements' (BIS) Project mBridge prototype. 2) Interlinked domestic CBDC systems using bridges and hash-time-locked contracts (HTLCs). 3) A common settlement layer acting as a "network of networks". Each model has trade-offs between centralization, liquidity fragmentation, and governance complexity that must be evaluated against policy goals.

Security and resilience are paramount. The system must be resilient to double-spending attacks, consensus failures, and cyber attacks. This involves implementing robust cryptographic key management (often using Hardware Security Modules - HSMs), designing for business continuity and disaster recovery, and establishing clear liability frameworks for operational failures. For cross-border payments, data privacy becomes complex, requiring designs that can reconcile transparency for regulators with confidentiality for users, potentially using zero-knowledge proofs or other privacy-enhancing technologies (PETs).

Finally, successful design requires active collaboration through international standard-setting bodies. Engagement with the Financial Stability Board (FSB), the Committee on Payments and Market Infrastructures (CPMI), and the International Organization for Standardization (ISO) is crucial for developing common messaging formats (like ISO 20022), technical interfaces, and legal frameworks. Piloting through sandbox environments and proof-of-concepts (e.g., Project Dunbar, Project Jura) is the essential final step to test design assumptions regarding liquidity management, foreign exchange conversion, and 24/7 operational readiness before any production launch.

A cross-border CBDC system is fundamentally a multi-currency ledger accessible to authorized financial institutions across jurisdictions. The core architecture is typically layered: a wholesale CBDC (wCBDC) layer for interbank settlements, an interoperability layer for connecting disparate national systems, and a governance layer for rule enforcement. Unlike domestic retail CBDCs, the cross-border design must prioritize atomic Delivery versus Payment (DvP) and Payment versus Payment (PvP) settlement to eliminate Herstatt risk. Key reference models include the Bank for International Settlements (BIS) Project mBridge platform and the European Central Bank's exploratory work on a digital euro for international use.

The interoperability layer is the most critical technical challenge. It must translate between different national CBDC protocols, legal frameworks, and messaging standards like ISO 20022. Two primary models exist: a common multi-CBDC platform (a shared ledger like mBridge) and bilateral linking of domestic systems via APIs and smart contracts. The common platform model, often built on distributed ledger technology (DLT) such as Hyperledger Besu or Corda, provides a single source of truth for transactions. Smart contracts on this layer automate compliance checks for Anti-Money Laundering (AML), Counter-Terrorist Financing (CTF), and foreign exchange controls, executing rules defined in the governance layer.

For the settlement layer, consider a Real-Time Gross Settlement (RTGS) system enhanced with DLT. Here, central banks issue wCBDC as digital tokens representing claims on the central bank. A Hash Time-Locked Contract (HTLC) is a foundational cryptographic primitive for cross-chain atomic swaps, which can be adapted for atomic PvP between two different CBDC ledgers. The contract locks funds in cryptographic puzzles, ensuring that either both legs of a foreign exchange trade settle simultaneously or funds are returned. This eliminates counterparty settlement risk, a major hurdle in current correspondent banking.

Identity and access management are paramount. Participants—central banks and commercial banks—require digital certificates or decentralized identifiers (DIDs) verified by a trusted root. Transactions must be pseudonymous to the network but identifiable to regulators via privacy-enhancing technologies (PETs) like zero-knowledge proofs. For example, a bank could prove it is not transacting with a sanctioned entity without revealing the counterparty's full identity to all network nodes. This balances transparency for oversight with operational privacy.

Finally, the governance layer encodes the legal and policy rules. This involves rulebooks translated into machine-executable logic. A governance smart contract could manage participant onboarding, currency inclusion, and dispute resolution. The technical design must allow for sovereign control; each central bank must retain full authority over its monetary policy and the issuance of its digital currency on the shared platform. The architecture should be protocol-agnostic where possible, allowing for upgrades and the integration of future CBDC designs without fracturing the network.

Designing a cross-border CBDC requires a multi-layered approach. The interoperability layer is the most critical, as it dictates how value moves between heterogeneous ledgers. A unified ledger model, where central banks maintain separate wholesale CBDC ledgers connected via a common settlement layer (like BIS Project mBridge), is emerging as a leading design pattern. This contrasts with direct central bank-to-central bank integrations, which create a complex web of bilateral links. The chosen model must support atomic Delivery versus Payment (DvP) and Payment versus Payment (PvP) to eliminate settlement risk.

For developers, the next step is to implement a minimum viable network (MVN). Start by setting up permissioned blockchain nodes using a framework like Hyperledger Besu or Corda, configured for your domestic wholesale CBDC ledger. The core smart contract logic should manage: - Issuance and redemption controls - Real-time gross settlement (RTGS) functionality - Transaction privacy modules (e.g., zero-knowledge proofs) - Compliance hooks for regulatory reporting. Use a sandbox environment like the BIS Innovation Hub's Project Rosalind API framework to simulate interactions with foreign central bank ledgers and test cross-border payment flows.

Testing must be rigorous and phased. Begin with unit tests for core ledger functions, then progress to integration tests simulating a corridor with one other central bank. Finally, conduct network resilience tests under high load and partial outage scenarios. Key performance indicators (KPIs) to measure include: transaction finality (target: sub-10 seconds), throughput (transactions per second), and operational costs. Engage with the ISO 20022 standards body early to ensure your payment message formats are compatible with existing financial infrastructure.

The development roadmap should be iterative. Phase 1 could be a closed-loop simulation between two central banks. Phase 2 might introduce a limited set of commercial banks as participants on each domestic ledger. Phase 3 would involve piloting with real-value transactions in a controlled environment. Throughout this process, continuous engagement with legal experts is required to navigate jurisdictional challenges and data privacy laws like GDPR, which impact how transaction data is stored and shared across borders.

To continue your research, explore the technical documentation for live projects. The Bank for International Settlements (BIS) publishes in-depth reports on Project mBridge, Project Dunbar, and Project Jura. The Digital Currency Monetary Authority (DCMA) provides specifications for its Universal Monetary Unit (UMU) reference model. Engaging with these resources and contributing to open-source financial infrastructure projects will provide the practical experience needed to advance in the field of CBDC development.