Interoperability aspects of CBDC across ecosystems and borders

Introduction

The vast majority of central banks around the world are investigating or piloting a Central Bank Digital Currency (CBDC), with a select few already running live systems. Although there is no single universal definition of CBDC as of writing, it is commonly understood to be:

• a digital representation of a country’s or region’s existing currency: this means that the CBDC will be denoted in the same currency and be 1:1 exchangeable for other types of money, such as deposit money, in a way that resembles cash;

• issued directly by the central bank: unlike deposit money and e-money, which is issued by private entities, CBDC represents a direct claim on the issuing central bank and therefore, the central bank has full control over its supply;

• usable in electronic payments: unlike cash, which can only be used for payments in physical proximity, CBDC as digital money can be used both offline and online; and

• legal tender: the ability to use CBDC for any purpose and to discharge monetary obligations.

The Bank for International Settlements (BIS), an international financial body whose membership comprises over 60 central banks, succinctly defines CBDC as a “digital payment instrument, denominated in the national unit of account, which is a direct liability of the central bank” [1]. For a comparison to other common payment instruments and digital assets, refer to the table below (excluding commodity-backed instruments).

While not strictly necessary according to the above definitions, CBDC payments are usually expected to be settled instantly. In terms of accessibility, we can distinguish two types of CBDC. Retail CBDC (rCBDC) can be used by anyone in the country, whereas Wholesale CBDC (wCBDC) is only available for regulated financial intermediaries [2]. The name refers to the idea that the former allows for retail payments, whereas the latter would be used by financial institutions.

BIS’ latest survey report about central banks’ engagement in CBDC and other digital assets found that in 2022, 93% of central banks are conducting work on “some form of CBDC” [1]. Of those, about three quarters are focusing both on retail and wholesale CBDC. This suggests that both types have distinct use cases that cannot be easily achieved within a single framework.

Concretely, the survey suggests that “work on wholesale CBDC is driven mainly by the desire to enhance cross-border payments” [1]. Awareness of this topic reaches back at least four years: In 2019, Bank of Canada and the Monetary Authority of Singapore published a design paper of “Project Jasper–Ubin”, in which both banks investigated cross-border payments between their jurisdictions [3]. Additionally, in 2020, the Financial Stability Board (FSB) has identified the need of “factoring an international dimension into CBDC design” as a building block towards enhancing cross-border payments [4].

From these developments, it becomes clear that any CBDC implementation will not realize its full potential in isolation, but in combination with other types of domestic or cross-border CBDC. More broadly, it means that CBDCs must be interoperable with other payment systems. According to the BIS definition, participating institutions, for example from different jurisdictions, should be able to “conduct, clear and settle payments across systems without participating in multiple systems” [5].

Unique challenges and opportunities with CBDC

In the broader context of payments, interoperability is not a novel topic. This year, the BIS and Bank of England have published a report on “Project Meridian,” linking the Bank’s real-time gross settlement system (RTGS) to a digitized land registry through a synchronisation operator. The purpose of the project was to demonstrate how to facilitate a delivery-vs-payment approach for housing transactions, essentially reducing the settlement risk by synchronising the multiple fund and asset transfers involved in a real estate transaction. The key ideas are to represent the real estate deed digitally on a ledger and to earmark funds in the RTGS before the transaction is completed, thereby preventing them from being misused [6].

There has also been work conducted regarding synchronisation of instant payment solutions across countries to facilitate cross-border payments. A report from last year describes a prototype to synchronise USD and EUR instant payment systems, where “settlement in one system is made conditional to the settlement in the next system”, therefore providing strong guarantees about the progress of a transaction [7]. A similar project has been undertaken by BIS, linking the Eurozone’s, Malaysia’s, and Singapore’s instant payment systems [8].

As the BIS notes, a “retail CBDC differs from existing forms of cashless payment instruments [...], as it represents a direct claim on a central bank rather than the liability of a private financial institution” [1]. This presents a unique opportunity for interoperability, because much friction in payment processes is introduced due to the need of converting between different private instruments with counterparty risk. Even more so, the literature around CBDC suggests designing it as a bearer instrument, which gives yet higher flexibility in terms of storage and transmission of monetary value; an advantage that also applies to wCBDC as compared to traditional RTGS. For example, transfer of CBDC tokens can be facilitated in a peer-to-peer fashion, which possibly makes it more efficient than using existing payment networks. This represents a unique opportunity to ease fragmentation in the payments ecosystem: CBDC infrastructure would be a standard right from the start.

This flexibility also introduces a challenge: lack of standardisation. While many (international) standardisation bodies are currently engaged in work on CBDC and/or digital assets, there is no clear picture yet in critical areas, such as wallet and message formats. Also, there is no consensus yet about which existing standards apply or can be repurposed for CBDC, for example ISO 20022 (message formats) or ISO 9362 (business identifier codes). It is not hard to imagine that this situation could cause widespread fragmentation.

Interoperability domains

In this paper, we focus on connection points between (retail and wholesale) CBDC vis-à-vis other systems, be they existing or emerging infrastructure. We discuss those different domains based on a classification according to the following key criteria:

• The unit is the currency symbol, such as EUR or USD, or alternatively another asset identifier, such as an International Securities Identification Number (ISIN) for securities. For the purpose of this section, we assume that the asset is fungible and divisible (up to a certain extent) and exclude non-fungible tokens (NFTs).

• The issuer is the entity that manages the supply of the digital currency; this responsibility includes increasing (or reducing) currency supply in the economy. For CBDC, the issuer is the central bank, and the unit would be their jurisdiction’s currency. Other combinations are possible, e.g., stablecoins that are privately issued but denominated in a national currency unit.

• The platform is the technical infrastructure that may or may not be operated by the issuer of the currency. Most rCBDC platforms will be sovereign national infrastructure, whereas cross-border CBDCs may be under joint operation by multiple countries. On the other hand, stablecoins are typically implemented on top of public blockchains.

Interoperability becomes more challenging, the more of those key criteria differ. We can now analyse different interoperability domains based on the key criteria.

Existing instant payment systems

According to data from this year, 52% of “central banks regulate or operate an instant payments system” (IPS) [9]. Consequently, at least the connection of a domestic IPS with a domestic CBDC will be a high priority for central banks. While the currency unit will definitely be the same and the platform will most likely be different, the situation for the issuer may be unclear. For example, some countries may choose to delegate CBDC wallet funding and defunding transactions – effectively an instant payment between (private) deposit money and central bank money – to the private sector, therefore letting commercial banks implement individual integrations.

Domestic retail and wholesale CBDC

Should a central bank decide to implement multiple domestic CBDCs, then unit and issuer will be identical, but their platforms will most likely differ. To prevent high participants’ costs because of liquidity requirements on both platforms, central banks should allow for 24/7 seamless funds transfer between systems.

Foreign CBDC

Considering foreign CBDCs, all key criteria differ. A defining issue for connecting multiple CBDCs across countries is multi-laterality. In the classical approach, each pair of currencies needs a dedicated connection. Mathematically, with 10 different currencies, 45 pairs would be required. (There are 45 unique pairings in a set of 10 subjects, calculated using the formula $n \times (n - 1) \div 2$.) Worse, since a central bank typically cannot manage the foreign-exchange liquidity alone, the private sector must offer exchange services. (There are exceptions to this, for example in the case of pegged currencies.) Another model could improve the situation, with a setup where individual domestic CBDCs connect to a common cross-border CBDC in a hub-and-spoke fashion (see figure below for a comparison). Examples for this approach are “Project Mariana” [10] and “Project mBridge” [11]. In particular, Mariana sought to not only solve multi-laterality on the technical level, but also the liquidity level.

Stablecoins

Even though the major stablecoins retain a 1:1 peg to their backing currency unit, they cannot always guarantee full at-par convertibility. This means that (often centralized) exchanges are necessary to convert CBDC to stablecoins, even though their platform might be the same, for example, if a wCBDC were to be issued on the ERC-20 standard. We therefore assume that the key criteria unit and issuer will differ to a domestic CBDC.

Technical interoperability options

Due to the heterogenous interoperability domains, there is no one-size-fits-all solution. We have identified three technical interoperability options whose suitability for a given domain depends on the similarities and differences across the key criteria explained above:

1. A bridge is a deep, bidirectional connection between two (or more) systems, where participants can seamlessly transfer value. For example, a bank could request conversion of a particular amount $x$ of rCBDC into the equivalent amount of wCBDC, therefore reducing the supply of retail CBDC ($M_R^{\prime }=M_R-x$) and increasing the supply of wCBDC ($M_W^{\prime }=M_W+x$). However, the total circulating CBDC supply stays constant ($M_R+M_W=M_R^{\prime }+M_W^{\prime }$). This option works especially well if both unit and issuer are the same, or alternatively if the units have a fixed exchange rate. Of course, both platforms need to support this kind of value transfer on a technical level.

   Such a connection can be easily operated on a 24/7 basis. But it should not be considered if the central bank is not in control of the other system, due to a substantial risk that vulnerabilities in third-party systems could propagate across bridges [12].

   We assume that this option is suitable for the interoperability with IPS and across domestic CBDC. This could aid commercial banks in their liquidity management, since they would not need to retain balances or tokens in two distinct systems, and can exchange monetary value on demand. For example, if a bank’s customers withdraw more retail CBDC from their deposit accounts than is currently available in that bank’s digital vault, it could request an instant conversion from its RTGS balance.

2. An exchange is an entity that controls liquidity of two or more assets that may differ on unit, issuer, and platform, providing a service that allows participants to trade one asset for another. In this option, a payment across systems would comprise at least two transactions: A payer $A$ pays an amount $x$ to the exchange $E$. Subsequently, the exchange triggers a payment of an amount $y$ based on a pre-determined rate to the payee $B$. Depending on the precise technical design, more parties might be involved. Independent of that, the total monetary supply on each individual system stays constant for each transaction.

   There are technical measures to make the orchestration more reliable. Most importantly, the individual transactions should not diverge, i.e., one transaction should complete if and only if the other one completes (so called atomic settlement or atomic swap). This can be achieved through Hash-Time Lock Contracts (HTLC), a type of smart contract that can work across platforms. Though if both systems use the same platform, Automated Market Makers (AMMs), another type of smart contract, can prevent divergence and manage liquidity and pricing automatically.

   An automated, standardized exchange mechanism could solve multi-laterality. But we note that the foreign-exchange market is currently highly decentralised, therefore consistent pricing through smart contracts is not yet achievable. There is active work conducted on AMM research [13]. Using AMMs, a hub-and-spoke model can be easily implemented, because there is a unified liquidity pool across multiple currencies.

   This option naturally lends itself to interoperability with foreign CBDC. It can also be employed for IPS (where no currency conversion is required) and stablecoins.

3. A wrapper is a technical facility where the central bank or an authorized intermediary would provide a representation of the CBDC in another system, sharing the same unit. A conversion request would therefore entail locking or earmarking CBDC into a dedicated wallet and issuing the same amount on the other system. Effectively, this would increase the monetary supply since the same value is now present in two systems. By construction, wrapper solutions cannot easily work in a hub-and-spoke model.

   The challenge with wrappers is that each participant must trust that the funds are actually locked and can be converted back at any time, should they so request. Note that stablecoin issuers follow this approach, but typically, they do not have access to central bank money to use as collateral.

   We foresee that the wrapper option could be used in jurisdictions where cash issuance is devolved to commercial banks based on strict reserve criteria imposed by the central bank. Additionally, Project Mariana, in implementing a multilateral cross-border CBDC, combines an AMM exchange with domestic rCBDC wrappers (unfortunately also named “bridge”) [10].

Based on these considerations, it becomes clear that any CBDC design should take each of those options into account. Fortunately, there is overlap and technical requirements can be easily incorporated depending on the use cases.

Case study: Equipping an IPS with offline capability

Banco Central do Brasil (BCB) has created the instant payment system Pix in 2020, enabling “enables its users — people, companies and governmental entities — to send or receive payment transfers in few seconds at any time, including non-business days.” According to recent statistics, Pix enjoys popularity within Brazil’s population; with about 3 billion transactions per month. Since its inception, “the Pix system has been used by more than 140 million individuals,” which corresponds to “about 80 percent of the adult population,” as well as 13 million firms [14].

According to the International Monetary Fund (IMF), some of the factors contributing to Pix’ success are instant settlement, low transaction costs, and the central bank acting as infrastructure provider and regulator [14]. Those success factors are shared with the design criteria of an rCBDC. Therefore, a natural question arises: What could an rCBDC bring to the table, if a domestic IPS is already popular?

A possible answer is given by examining a shortcoming of Pix: It is not possible to conduct a transaction without a smartphone or network connectivity, since Pix only supports online payment processing. This poses a challenge to resilience, but also to financial inclusion.

To reimagine instant payments with offline capability, Giesecke+Devrient submitted a proposal to BCB’s “LIFT challenge”, a broad initiative to further the central bank’s innovation agenda [15].

Filia^® is a token-based CBDC that focuses on retail use cases, such as offline payments, but supports other types of digital currency as well. It is designed for, but not limited to, a multi-tier distribution model where:

• the issuing central bank provides the core infrastructure, such as the underlying protocol, the backend to assure the integrity of currency in circulation, as well as mechanisms to govern the CBDC ecosystem; and

• private sector intermediaries, such as financial service providers, to provision end user wallets and build innovative services based on the core technology and regulatory framework provided by the central bank.

The offline functionality supports payments where both payer and payee use devices without online connectivity, coined “dual offline” by BCB. The underlying security model relies on, broadly speaking, secure hardware, end-to-end encrypted communication channels, and an industrial-strength public key infrastructure.

In our proposal, we explore how Brazil’s instant payments could be augmented with Filia^® offline technology. Users would be equipped with a secure hardware wallet that is bound to their existing bank account, and that can manage tokenized offline-transferable money. We then describe the following scenario, conducted by and end-user through a mobile app:

1. a user transfers bank account money to their offline wallet

2. they use their secure hardware wallet to conduct offline transactions

3. they transfer back their offline value to their bank account

This corresponds to an exchange between account-based bank deposit money and a tokenized rCBDC that is specialized to offline payments. Notably, there is no need to reflect offline transactions in a bank’s general ledger, since the tokenized offline money more closely resembles physical cash, with the mobile app being an “ATM” that supports withdrawing and depositing tokens. This resemblance also provides a considerable opportunity: Only the conversion between deposit money and cash requires a bank account and connectivity, but intermediate transactions can occur also between individuals without bank accounts. Most importantly, funds received offline can be immediately respent, which provides benefits over existing store-value card systems.

The Filia^® Mobile SDK and backend components are modular and allow a custom integration into a commercial bank’s (or central bank’s) system landscape. With them, a bank can implement the onboarding, (de)funding, and payment flows for secure hardware wallets in existing mobile apps. Alternatively to an exchange model operated by commercial banks, our proposal could also be implemented on a central bank level as a bridge.

Our report concludes that adding offline payments to an IPS “emphasize[s] the unique value proposition of CBDC [...], such as ease of use, convenience, enhanced privacy and lower overall costs.” Therefore, these benefits would “significantly translate to broad user adoption of a Digital Real in real life payment scenarios.” Finally, from a user perspective, these “design features could effectively extend accessibility of digital payments to the 10% of unbanked Brazilians as well as 11% of those who are underbanked,” providing a real benefit to economy and society [15].

Case study: Cross-border payments using an international payments network

As a case study, we will consider a proof of concept implemented in a joint project by Giesecke+Devrient and the UDPN Alliance [16]. The solution connects two products: the Universal Digital Payments Network (UDPN) platform as the multilateral cross-border infrastructure and Filia^® as one example of a domestic rCBDC platform (see previous section for details).

The UDPN is a global messaging network supporting government-regulated digital currency systems, including regulated stablecoins and CBDCs. It allows any entity to transfer and swap digital currencies across borders, currencies, and systems in a low-cost and convenient manner. Technically, it comprises a DLT-based application layer where smart contracts can be deployed and called for core UDPN functions (e.g., transfer, swap) and also allows third parties to innovate and deploy their own smart contract-based value-added services for functions such as Know Your Customer checks (KYC) or foreign currency exchange (FX). Within UDPN, the DLT nodes validating transactions are operated in a decentralized governance structure by an industrial consortium of multiple entities. This enables a hub-and-spoke model where new systems and participants can be onboarded easily. UDPN relies on the open Decentralised Identifiers (DID) standard [17] to establish relationships between entities across different systems.

The goal of the joint project is to connect both systems and enable bidirectional, peer-to-peer payments across currencies. As a showcase, we implemented payments from hypothetical EUR (running on Filia^®) to INR (running on UDPN) rCBDCs. This included transfers between end-user wallets, currency conversion, liquidity management, CBDC issuance, identity, and wallet management.

For the purpose of the prototype, it was decided to employ two different CBDC issuance models: the hypothetical Digital Euro is issued in a two-tier model on the Filia^® platform, and the Digital Rupee in a synthetic model natively on UDPN. In terms of the above classification, the prototype is an exchange between two systems with different units, issuers, and platforms.

The high-level transaction flow for a EUR-to-INR transaction can be described as follows (figure above):

1. In the Filia^® app, the first user initiates a cross-remittance transaction to the second user with the cross-remittance transaction information: beneficiary unique identifier (such as registered e-mail ID, phone number, etc.), beneficiary bank, amount (EUR), etc. The system queries and displays the best FX rate applicable and receivable in local currency (INR) to the sender to confirm the cross-border transactions.

2. After the first user confirms the transaction, their bank initiates the EUR transfer from their EUR wallet to the FX Settlement Bank’s EUR wallet (EUR liquidity pool). The Filia^® system will process the payment and return the result to the first user’s bank.

3. The first user’s bank initiates a swap request from EUR to INR by calling the “Transfer and Swap” smart contract deployed by the FX Settlement Bank on the UDPN.

4. The FX Settlement Bank confirms the status of EUR transaction result from the Filia^® payment processor.

5. After confirming the transfer, the FX Settlement Bank will initiate an INR transfer and send the INR from its INR liquidity pool to the second user’s INR wallet by calling the “eINR Wallet” smart contract.

6. Once the INR transfer is complete, the transaction result will be synchronized to the participating banks and the “Transfer & Swap” contract.

7. Both users can retrieve the result of the swap transaction from their respective banking apps with transaction logs, including timestamps, FX rates, and transaction/service fees (if applicable).

Key benefits presented by this solution are lower transactions costs, faster transaction times with 24/7 availability (end-to-end in less than one minute), settlement in national currencies, improved data sharing and transparency for all participants (including end-users), and regulatory compliance. Due to the modular architecture, the prototype addresses some key hurdles in today’s cross-border transactions. Since any FX provider can connect to the system, the need for intermediary credit is eliminated. Furthermore, this reduces the dependence on intermediaries and correspondent banking, which also increases transfer speed.

Conclusion

We have presented several interoperability aspects that any (retail or wholesale) CBDC design must take into account. Even though CBDC is an instantly settled liability of the central bank, and even though a token-based CBDC would allow for great flexibility regarding wallets and transactions, there are some challenges to prevent it becoming an insular system. In particular, connection points exist to instant payment systems, other domestic CBDC, cross-border CBDC, and stablecoins. There is no single technological means to address all those connections uniformly. In this paper, we have discussed three broad options: bridges, exchanges, and wrappers, that each have different use cases. Given that cross-border payment is currently among the most severe pain points in the payments ecosystem, we have implemented a prototype that enables multilateral, peer-to-peer transactions between countries across currencies. Among the most effective measures to address the FSB’s goal to enhance cross-border payments, we suggest to further investigate standardisation and a hub-and-spokes model, both of which reduce the total complexity of the system.

Acknowledgments

This work has been partially supported by the Federal Ministry of Education and Research (BMBF), Verbundprojekt CONTAIN (13N16582). The author wishes to thank their colleagues Polly Bäumler, Vratul Kapur, Daniel Nagy, as well as the anonymous referees from Journal of Payment Strategy & Systems for their numerous suggestions to improve this manuscript.