Launching a Cross-Border CBDC Pilot with Partner Jurisdictions

A cross-border CBDC pilot is a structured test of a digital currency system involving two or more central banks. Its primary goal is to evaluate the technical feasibility, regulatory compliance, and operational resilience of transferring value across jurisdictions using a common digital token. Unlike domestic pilots, these projects must reconcile different legal frameworks, payment systems, and supervisory requirements. Key motivations include reducing settlement times from days to seconds, lowering transaction costs for remittances and trade finance, and exploring new models for interoperability between future monetary systems. Projects like Project mBridge (involving the BIS and central banks of China, Hong Kong, Thailand, and the UAE) and the Jura Project (Swiss National Bank and Banque de France) serve as critical real-world testbeds.

The foundation of any pilot is a clear project blueprint. This document must define the pilot's scope: the specific use case (e.g., cross-border trade settlement, remittances), the participating financial institutions, the volume and value limits for test transactions, and the legal basis for the experiment, often requiring a sandbox or specific regulatory exemption. A governance framework is essential, establishing roles, decision-making processes, and communication channels between the partner central banks and any private sector participants. The technical architecture must also be scoped, deciding between a common platform (like mBridge's multi-CBDC platform), interlinked domestic systems, or a hybrid model.

Selecting the right technological infrastructure is the core technical challenge. The chosen platform must ensure atomic settlement (Delivery vs. Payment or Payment vs. Payment) to eliminate principal risk. Many pilots utilize Distributed Ledger Technology (DLT) for its ability to provide a single, shared source of truth across borders, though some explore enhanced traditional systems. Key design decisions include the ledger type (permissioned vs. permissionless, often using frameworks like Hyperledger Besu or Corda), the token model (wholesale CBDC tokens vs. tokenized commercial bank deposits), and the interoperability protocol for connecting to domestic Real-Time Gross Settlement (RTGS) systems. Smart contracts are typically employed to automate compliance checks and settlement logic.

Operational execution involves a phased approach. The development and testing phase includes building and integrating the platform components, followed by rigorous internal and closed-loop testing. The limited live pilot phase then commences with a small group of pre-selected commercial banks and corporate entities conducting real, but constrained, transactions. Throughout this phase, participants monitor key performance indicators (KPIs) such as transaction finality time, system throughput, uptime, and the effectiveness of anti-money laundering (AML) and sanctions screening tools. A dedicated project management office coordinates issue resolution and ensures all parties adhere to the agreed protocols.

The final and most critical phase is evaluation and reporting. Teams must analyze the collected data against the pilot's original objectives. The assessment should cover technical performance, economic impact, user experience, and, crucially, legal and regulatory findings. This analysis informs a public report or whitepaper that shares lessons learned, identifies persistent challenges (like legal harmonization and data privacy), and provides recommendations for any future phases or potential production systems. The ultimate output is not a live system, but a validated body of evidence to guide policy and long-term CBDC design decisions on the international stage.

The first prerequisite is establishing a clear legal and regulatory framework. This involves formal agreements, often called Memoranda of Understanding (MoUs), that define the roles, responsibilities, and liabilities of each participating jurisdiction. Key clauses must address governance (decision-making processes), data privacy (adherence to GDPR or similar regulations), dispute resolution, and the legal status of the pilot's digital currency. Without this foundation, technical development cannot proceed with certainty.

Technical interoperability is the next critical agreement. All parties must decide on a common protocol stack. Will the pilot use a permissioned blockchain like Hyperledger Besu or Corda, a custom distributed ledger, or a hybrid model? Consensus must be reached on core technical specifications: the token standard (e.g., a modified ERC-20 for fungibility), transaction finality rules, API standards for participant interfaces, and the cryptographic primitives for digital signatures and key management. This ensures all systems can communicate seamlessly.

Operational and economic parameters must be explicitly defined. This includes setting the pilot's scope and limits: which financial institutions will act as direct participants (nodes), the total value of CBDC to be issued for the test, transaction limits per user, and the geographic and use case boundaries (e.g., cross-border trade invoices only). Additionally, parties must agree on foreign exchange (FX) conversion mechanisms, whether using a real-time oracle for live rates or a pre-agreed fixed rate for the pilot's duration.

Finally, a comprehensive risk management and contingency plan is non-negotiable. The foundational agreement must outline procedures for handling technical failures (e.g., node downtime, consensus halts), cybersecurity incidents, and the process for orderly wind-down of the pilot. This includes defining clear escalation paths, communication protocols for stakeholders, and a rollback strategy. Establishing these 'circuit breakers' upfront builds trust and ensures the pilot can be conducted safely within a controlled sandbox environment.

The technical design phase establishes the foundational architecture for a cross-border CBDC pilot. This involves selecting a distributed ledger technology (DLT) platform—such as Hyperledger Besu, Corda, or a custom blockchain—that meets the requirements for privacy, scalability, and finality agreed upon by all partner central banks. A critical early decision is the interoperability model: will the pilot use a common, shared ledger (a "single system" approach), interconnected national ledgers (a "bridge" model), or a hybrid architecture? Each model carries distinct implications for sovereignty, transaction settlement, and technical complexity.

Defining the technical governance framework is paramount. This includes establishing protocols for smart contract upgrades, node operator permissions, and consensus mechanism adjustments. For a pilot involving multiple sovereign entities, a multi-signature or decentralized autonomous organization (DAO)-like structure is often proposed for key administrative functions. The architecture must also specify data privacy and visibility rules, determining what transaction details are shared on a common ledger versus kept private on national subsystems, potentially using zero-knowledge proofs or other cryptographic techniques.

The architecture must detail the settlement model. Will it be real-time gross settlement (RTGS) or deferred net settlement? For cross-border payments, a common solution is to use a wholesale CBDC (wCBDC) held by commercial banks in each jurisdiction, which settle on the shared ledger, while retail users interact with their domestic systems. The technical design must specify the messaging formats (like ISO 20022), APIs for bank integration, and the atomic settlement mechanism to ensure a payment in one currency is irrevocably settled only when the corresponding receipt in another currency is confirmed, preventing settlement risk.

Security and resilience are designed into every layer. This involves specifying node infrastructure (cloud, on-premise, or hybrid), network topology, and key management systems for participant banks and the central banks themselves. The design must plan for regulatory compliance tooling, such as transaction monitoring for anti-money laundering (AML) and programmable features for enforcing jurisdiction-specific rules. A comprehensive testing strategy for smart contracts, integration points, and disaster recovery scenarios is also a core deliverable of this phase.

Finally, the technical design document serves as the blueprint for the subsequent development phase. It should include detailed API specifications, data models, and sequence diagrams for key flows like cross-border payment initiation, foreign exchange conversion, and end-of-day reconciliation. Successful pilots, like Project mBridge led by the BIS Innovation Hub, demonstrate that rigorous technical design focusing on interoperability standards, clear governance, and layered security is critical for moving from concept to a functional, multi-jurisdiction proof-of-concept.

Launching a cross-border CBDC pilot requires establishing a robust governance framework before any technical development begins. This framework defines the rules of engagement between participating central banks and financial institutions. Key components include a Memorandum of Understanding (MoU) outlining objectives, roles, and data-sharing protocols, and a technical governance committee with representatives from each jurisdiction to oversee protocol design and dispute resolution. This committee is responsible for approving changes to the shared ledger rules, transaction formats, and participant onboarding criteria, ensuring no single entity has unilateral control.

The core technical challenge is achieving interoperability between potentially heterogeneous CBDC systems. Pilots often employ a hub-and-spoke model or a common multi-currency ledger. For instance, the Project mBridge ledger, built on a permissioned blockchain, allows direct peer-to-peer transactions across jurisdictions. Technically, this involves defining a common transaction message standard (like ISO 20022 adaptations), implementing atomic cross-chain settlement using Hashed TimeLock Contracts (HTLCs), and agreeing on a foreign exchange pricing oracle mechanism. Smart contracts on the shared ledger enforce settlement finality and compliance rules programmed by the governance committee.

Operational models must address legal compliance and risk management across borders. This involves mapping transaction flows to respective jurisdictional regulations for Anti-Money Laundering (AML), Counter-Financing of Terrorism (CFT), and data privacy (e.g., GDPR). A practical approach is to implement regulatory nodes operated by each central bank, which validate transactions against their local rulebooks without exposing raw data. For example, a transaction from Jurisdiction A to B would require cryptographic proofs of AML compliance from A's node before B's node permits settlement. This Regulatory Technology (RegTech) layer is critical for operational legitimacy.

The pilot's technical architecture typically involves a permissioned Distributed Ledger Technology (DLT) network like Hyperledger Besu or Corda, chosen for its privacy features and governance controls. Participants operate validator nodes, and smart contracts automate key functions: a Cross-Border Payment Contract handles atomic swaps, a Netting Contract aggregates transactions for liquidity efficiency, and a Compliance Attestation Contract records regulatory approvals. Code audits and formal verification of these contracts are mandatory, as bugs could impact monetary sovereignty. Testing occurs in a sandbox environment with synthetic data before live currency trials.

Finally, defining clear success metrics and an exit strategy is crucial for a pilot. Metrics should be technical (e.g., transaction finality under 3 seconds, 99.9% system uptime), economic (e.g., cost reduction versus correspondent banking), and policy-oriented (e.g., monitoring capital flow patterns). The exit strategy must detail the process for winding down the pilot, including the orderly settlement of all outstanding obligations and the secure archival or destruction of test data. Post-pilot analysis feeds into policy discussions on the future of multi-CBDC arrangements, informing decisions on permanent system deployment.

The execution phase begins with the technical integration of the pilot systems between partner jurisdictions. This involves connecting the participating central banks' CBDC ledgers or payment systems via a cross-border interoperability layer, such as a common settlement platform or a purpose-built bridge. Key technical tasks include establishing secure API endpoints, configuring atomic swap smart contracts for foreign exchange, and implementing the agreed-upon legal and regulatory frameworks (like the "jurisdictional nexus" principle) into the system's rulebook. A phased rollout, starting with a closed user group of commercial banks, allows for controlled testing of core functionalities like real-time gross settlement and multi-currency transactions.

Continuous real-time monitoring is critical for operational stability and security. Teams should deploy dashboards tracking key performance indicators (KPIs) such as transaction throughput (e.g., transactions per second), settlement finality latency, system uptime, and the volume/value of cross-border flows. Monitoring must also cover the smart contract layer for any anomalous activity and the health of the cryptographic key management systems. Tools like Prometheus for metrics and Grafana for visualization, combined with on-chain analytics from the ledger, provide a comprehensive view. This enables operators to detect and respond to issues like network congestion or failed settlements immediately.

A formal evaluation framework should be established upfront to measure the pilot's success against its stated policy and technical objectives. This involves analyzing both quantitative data from the monitoring systems and qualitative feedback from participants. Key evaluation areas include: Efficiency gains (reduction in settlement time and cost compared to traditional correspondent banking), resilience and security (incident reports, penetration test results), user experience for financial institutions, and compliance adherence. The final evaluation report should provide actionable insights for a potential production rollout, detailing necessary technical refinements, regulatory adjustments, and scalability assessments for the interoperability model.

The pilot's success hinges on a clear, phased rollout. Begin with a closed-loop test involving a small group of pre-vetted financial institutions from each partner jurisdiction. This initial phase focuses on core functionality: executing atomic cross-border payments using the chosen interoperability model—be it a common platform like Project mBridge, a dedicated bridge, or atomic swaps. Rigorously test settlement finality, transaction privacy, and the handling of failed transactions. Document all findings and establish a clear governance framework for dispute resolution and liquidity management between central banks.

Following a successful closed test, the pilot should expand to a live, limited-scale environment. This involves onboarding a broader set of participant banks and potentially licensed non-bank payment providers. Key activities here include stress-testing the system under realistic load, integrating with existing domestic Real-Time Gross Settlement (RTGS) systems via APIs, and conducting end-to-end compliance checks for Anti-Money Laundering (AML) and Counter-Financing of Terrorism (CFT). Tools like smart contracts can be programmed to automate compliance rules, a concept explored in projects like the Bank for International Settlements' (BIS) Project Dunbar.

The final preparatory step is comprehensive risk and impact analysis. Quantify the pilot's effects on domestic monetary policy transmission and financial stability. Develop contingency plans for operational failures, cyber-attacks, and market volatility. Concurrently, engage in public communication to manage expectations and educate potential end-users. The goal is to create a robust evidence base for a policy decision on whether to proceed to a full public launch.

Looking beyond the pilot, the long-term vision involves scaling the network. This requires standardizing technical protocols and legal frameworks to enable new jurisdictions to join seamlessly. Ongoing research into programmable money for trade finance and the integration with tokenized asset markets will be crucial. Continuous collaboration through forums like the BIS Innovation Hub is essential to avoid fragmentation and build a future-proof system for cross-border payments.