Technology & Innovation Lab INTEROPERABILITY BETWEEN CENTRAL BANK DIGITAL CURRENCY SYSTEMS AND FAST PAYMENT SYSTEMS A TECHNICAL PERSPECTIVE ACKNOWLEDGEMENTS This knowledge brief has been prepared by a World Bank team comprised of Raunak Mittal, Mert Ozdag, Mahesh Karajgi, and Emmanuel Crown (Information Technology Solutions, Technology & Innovation Lab (ITSTI)), in collaboration with Ahmed Faragallah (Finance Competitiveness and Innovation (FCI) Global Practice), under the guidance of Harish Natarajan (Lead Financial Sector Specialist, FCI), and Stela Mocan (Manager, ITSTI). © 2024 The World Bank 1818 H Street NW Washington DC 20433 Telephone: 202-473-1000 Internet: www.worldbank.org This work is a product of the staff of The World Bank with external contributions. The findings, interpretations, and conclusions expressed in this work do not necessarily reflect the views of The World Bank, its Board of Executive Directors, or the governments they represent. The World Bank does not guarantee the accuracy of the data included in this work. The boundaries, colors, denominations, and other information shown on any map in this work do not imply any judgment on the part of The World Bank concerning the legal status of any territory or the endorsement or acceptance of such boundaries. Rights and Permissions The material in this work is subject to copyright. Because The World Bank encourages dissemination of its knowledge, this work may be reproduced, in whole or in part, for noncommercial purposes as long as full attribution to this work is given. Any queries on rights and licenses, including subsidiary rights, should be addressed to World Bank Publications, The World Bank Group, 1818 H Street NW, Washington, DC 20433, USA; fax: 202- 522-2625; e-mail: pubrights@worldbank.org. Technology & Innovation Lab INTEROPERABILITY BETWEEN CENTRAL BANK DIGITAL CURRENCY SYSTEMS AND FAST PAYMENT SYSTEMS A TECHNICAL PERSPECTIVE Acronyms API application programming interface BIS Bureau of International Settlements CBDC Central Bank Digital Currencies rCBDC retail CBDC wCBDC wholesale CBDC DLT Distributed Ledger Technology FCI Finance Competitiveness and Innovation FPS Fast Payment System ISO International Organization for Standardization ITS Information Technology Solutions ITSTI ITS Technology and Innovation Lab JSON JavaScript Object Notation NPS National Payment System PSP Payment Service Provider PvP Payment vs Payment REST Representational State Transfer RPC Remote Procedure Call RPS Retail Payment System RTGS Real Time Gross Settlement  5 BACKGROUND The World Bank Group’s ITS Technology and Innovation lab (ITSTI) has been actively conducting hands-on technological experimentation, and building internal knowledge and expertise about emerging technologies and innovations related to central bank digital currencies (CBDCs) along with other payment system innovations. As part of this effort the technology team has identified various pillars: for example, programmable money, privacy enhancing techniques, the interoperability of networks and systems, and offline payments. ITSTI Lab has worked closely with the World Bank Finance, Competitiveness and Innovation Global Practice and other ITS teams to cocreate and share knowledge on emerging technology designs in CBDC with partners in both the public and private sectors. This Knowledge Brief outlines some of our learnings and insights from internal exploration and experimentation on CBDC interop- erability with existing payment systems like fast payment systems (FPS). 6 Technology Design for Interoperability Between Central Bank Digital Currency Systems and Fast Payment Systems EXECUTIVE SUMMARY Central banks around the world are actively researching and investigating the benefits, challenges, and design options of wholesale and retail central bank digital currencies (CBDCs). Since CBDCs are one of the most critical components of a national payment system (NPS), it is important that their interoperability with other payment systems is one of the key consid- erations in the design process. The ITS Technology & Innovation (ITSI) team, in collaboration with the World Banks’s Finance Competitiveness and Innovation (FCI) Global Practice, has conducted technology design experiments on two specific scenarios regarding CBDC system interoperability with fast payment systems (FPS). In the first scenario, the experiment investigated the option of settling FPS obligations in a wholesale CBDC system, including the option to reserve funds to guarantee the settlement of FPS net obligations. In the second scenario, the team investigated the interoperability between users within the FPS and retail CBDC users, including the transfer of funds among both types of users, using common services such as address resolution services. This experiment illustrated how CBDC systems could interoperate with retail payment systems through an interlinking bridge that was used to route messages and application programming interface (API) calls among different systems. The programmability features of Distributed Ledge Technology (DLT) were used to link the settlement in CBDC to the transfer of funds in the FPS. The technical applicability for this type of interoperability was demonstrated through the experiments, with the caveat that these experiments do not take into account complexities that may be involved with live systems. CBDC AND PAYMENT SYSTEM INTEROPERABILITY The interoperability between CBDC systems and other payment systems is essential in order to avoid fragmentation in the national payment system. For the CBDC to be used in any jurisdictions at all it should have the rails to be exchanged with existing payment instruments; otherwise it would have limited practical value. Interoperability allows the CBDC to enhance overall payment system efficiency within the jurisdiction, because the CBDC can provide instant settlement and extended access to excluded segments of the community, or even to nontraditional payment service providers (PSPs). CBDC interoperability allows a seamless flow of value across various forms of money and different types of accounts. Domestic payment system interoperability with other domestic payment infrastructures is a key challenge in CBDC design. CBDC interoperability with payment systems such as the Real Time Gross Settlement (RTGS) system or a fast/instant payment system--and the exchangeability with other forms of money such as e-money, commercial bank money, or cash-- are essential for smooth end-to-end payment flow. Even if the CBDC assumes the same value of unit of money in the jurisdiction, it would need to be booked in distinct systems at the central bank, or even by payment service providers; therefore CBDCs need to have special accounts, or stores of value, from other forms of money.1 CBDC Infrastructure Platform Connectivity and Interoperability Foreign CBDC Existing Payment Infrastructure Infrastructure Domestic Cross Border Positioning the CBDC system correctly within an NPS is crucial for its successful imple- mentation. We have identified three high-level scenarios for the interoperability of CBDC systems with other domestic payment systems. 1. Interoperability between a wholesale CBDC system and an RTGS system. This would be used mainly to buy and sell CBDC to payment service providers. In this case, wCBDC participants would need to have direct or indirect access to RTGS in order to exchange the CBDC with funds in the RTGS, and vice versa. We have not tackled this case within this note. 2. Interoperability between retail payment systems (RPS) and wCBDC, where the retail payment systems (FPS, ACH, card switches, etc.) settle the net results in 1 “Under this construction, a CBDC therefore has intrinsically different properties to other forms of money; principally, its legal construct is that it is a liability of the central bank and not a private company. This could require its segregation from other forms of money throughout its lifecycle. Any transfer into other forms of money would require the exchange of a CBDC instrument with other money instruments between the originating firm and the Bank or another third party. Therefore, CBDCs must always, and at every point in a payment journey, remain distinct and distinguishable from other forms of money.” – DESIGNING INTEROPERABILITY FOR A POTENTIAL UK CBDC- UK Finance – July 2022 CBDC andPaymentSystem Interoperability 9 the wCBDC. This case would require sending transactions from the FPS to the wCBDC for settlement. Further requirements would include reserving funds in the wCDBC system to limit the credit risk and guarantee the settlement of the FPS transactions. This case is described in Scenario 1 below. 3. Interoperability between RPS (mainly with FPS systems) and retail CBDC systems, where users connected to the FPS through their PSPs, would be able to transfer value to rCBDC users, with real-time settlement at the beneficiary account/wallet. This case would require real-time transfer of funds between the two systems, where the assumption is that the transfer would take place through a bridge that links both systems. This scenario requires an address or an alias service that will resolve the mobile number of the beneficiary to a specific PSP and a certain account/wallet. This case is described in Scenario 2 below. BOX 1: CROSS-BORDER PAYMENT SYSTEM INTEROPERABILITY When selecting the design options of CBDC systems, it is important to consider the possible integration with other CBDCs or payment systems at the cross-border level. The BIS, along with other developing partners including the World Bank, under the G20 cross-border payments roadmap, has published two reports on cross-border CBDCs. The possible scenarios for integrating cross-border CBDC systems have been explained under the BIS report to the G20, titled “Options for Access to and Interop- erability of CBDCs for Cross-Border Payments” and published in July 2022. This report identifies three interlinked models for interoperability, including a single-access point, a bilateral link, and a hub-and-spoke solution. The report also identifies the single system model, which involves CBDCs that use a single common technical infrastructure, and potentially also a common rulebook, to connect PSPs from different jurisdictions. 10 Technology Design for Interoperability Between Central Bank Digital Currency Systems and Fast Payment Systems DOMESTIC CBDC INTEROPERABILITY SCENARIOS Domestic CBDC Interoperability Scenarios 11 Challenge Statement • Positioning a wholesale or retail CBDC system within the existing payment system in order to ensure the smooth flow of funds among different payment systems. Exploration Objectives • Outline models for interoperability scenarios of CBDC and FPS, and prototypes for technical interoperability for the stylized models. Interoperability Scenarios for FPS and CBDC systems Use Case Scenario 1: End users make payment transactions using an FPS enabled by their respective payment service providers (PSPs). The PSPs settle these net obligations of the FPS through the wholesale CBDC. Step 1: Participants in the FPS need to reserve funds in the wholesale CBDC system, to guarantee the settlement of their net obligations in the FPS. These reserves are held in the wCBDC system and can be used only to settle FPS net results. Step 2: The payer initiates the transaction through its PSP, using a payee payment address alias. Step 3: The payer PSP locates the payee PSP through the account look-up service in the FPS. Step 4: The transaction fee is communicated to the payer, and the payer confirms the transaction. Step 5: The payer PSP executes the transfer transaction to the payee PSP through the FPS. Step 6: Notification is sent to both payer and payee by their respective PSPs. Step 7: The PSP obligations are recorded in the FPS for netting, and are batched together in the settlement window. Step 8: Settlement instruction is sent from the FPS to the wholesale CBDC so that the settlement among the PSPs can take place in central bank money in their prefunded accounts. Within this scenario, the operation of the FPS will not change, with the exception of settling in a wCBDC system, instead of in an RTGS. Settlement of the FPS in a wCBDC system could happen with minimum interruption to the typical operations of the FPS. This scenario could be very useful, since the wCBDC system will operate 24/7; hence it will secure settlement for the FPS even during weekends and long holidays. The wCBDC system could secure settlement to the FPS based on net arrangement, or continuously, based on real-time settlement. If the FPS settles its transactions in the wCBDC system on a gross basis, no reserves will be required in the wCBDC system to guarantee the FPS settlement; therefore, the overall settlement will be cheaper for the PSPs, as they will not bear financing costs. Within this scenario, we assume the settlement to be on a net basis. This scenario would require multiple arrangements between the FPS and the wCBDC system, including the following: • The wCBDC system should be able to hold reserves to guarantee the settlement of the FPS net obligations; therefore, reserve accounts and requests to reserve funds should be available within the wCBDC system. 12 Technology Design for Interoperability Between Central Bank Digital Currency Systems and Fast Payment Systems • The wCBDC system should be able to receive a batch of transactions and settle them on an all-or-none basis. • The FPS should be able to send inquiry messages to the wCBDC system to check the balance of reserve accounts, and should receive a response with the reserved balance per the PSP. • An increase in the reserved balance in the wCBDC system should be reflected at the FPS reserves, in order to increase the limits of FPS participants’ accounts. • We have assumed in this scenario that all of the transactions between the CBDC systems and other payment systems would pass through a bridge component. The bridge will be explained in more detail under Scenario 2. SCENARIO 1: RETAIL FAST PAYMENT SYSTEM WITH SETTLEMENT IN WHOLESALE CBDC FPS Scheme Debit Credits Alice wallet Bob wallet Transmission Notification PSP A PSP B of txn details to Payer (FPS Scheme) (FPS Scheme) for clearing and Payee Payment request from Alice Netting of PSP Obligations Settlement Instruction Alice Bob Translate the message Bridge (e-money (e-money wallet) wallet) Communicate the Settlement Message CBDC Network PSP A Settlement through PSP B (CBDC network) Wholesale CBDC System (CBDC network) Use Case Scenario 2: In this scenario, retail users in payment systems such as retail CBDCs and FPS’s transact with each other. This scenario will discuss the option of a user who is connected to an rCBDC system through its PSP to send funds to an FPS user through a link between the rCBDC and FPS systems. This scenario could play out in three different ways: (i) The PSP of the payer is in both of the payment systems, so the PSP of the payer will debit the rCBDC account of the payer, and send the transaction directly to the FPS system, debiting the PSP and crediting the PSP of the payee. This will therefore credit the payee, with the PSP of the payer acting as intermediary between the two payment systems; (ii) The PSP of the payee is in both of the systems, and the PSP of the payee will receive the funds in the rCBDC system from the payer directly or Domestic CBDC Interoperability Scenarios 13 from the PSP of the payer, and will credit the e-money or bank account of the payee. In this case, the PSP of the payee will be the intermediary; (iii) A third party, neither the payer PSP nor the payee PSP (most probably the central bank) acts as the intermediary between the two systems. The central bank receives the funds from the PSP payer in the rCBDC system, and credits the PSP of the payee in the FPS. In our interoperability experiment we deployed the third option. In reality, it could be very helpful for the central bank to act as the intermediary among financial institutions for the transfer of funds from and to the CBDC systems. This is mostly because the central bank would have infinite liquidity in the domestic currency in any payment system; thus there is no credit risk when the central bank performs the intermediary role, since the central bank will never be insolvent in the domestic currency. These are the steps in such a scenario: Step 1: Participants in the FPS need to reserve funds in the Real Time Gross Settlement (RTGS) system, to guarantee the settlement of their net obligations in the FPS. These reserves are held in the RTGS system, and can be used only to settle FPS net results. Step 2: The payer initiates the transaction through its payment service provider (PSP) from the payer’s rCBDC account, using the payee’s payment address alias. Step 3: The payer PSP locates the payee PSP through the account look-up service in the rCDBC system. Step 4: The transaction fee is communicated to the payer, and the payer confirms the transaction. Step 5: The payer PSP identifies the payee as a non-rCBDC account, thus executes the transfer transaction to the payee’s PSP through the bridge that is managed by the central bank. Step 6: The payer PSP pays the transfer value to the central bank in the rCBDC system, usually? through the bridge component. Step 7: The central bank initiates a transaction to the payee PSP within the FPS. Step 8: The payee PSP transfers funds through the FPS to the payee. Step 9: Notification is sent to both payer and payee by their respective PSPs. Step 10: The central bank and the payee PSP obligations are recorded in the FPS for netting, and batched together in the settlement window. Step 11: Settlement instruction is sent from the FPS to the RTGS so that the settlement from the central bank to the payee PSP will take place in central bank money from their prefunded accounts. This scenario would require multiple arrangements between the FPS and the wCBDC system, as follows: • In the case of using an alias to refer to the payee account (such as a mobile number or email address), the payer PSP would need to resolve the alias in order to confirm the payee PSP and the account number. There could be various scenarios for this resolution process. For example: 14 Technology Design for Interoperability Between Central Bank Digital Currency Systems and Fast Payment Systems • Use of a common address resolution service between the FPS and the rCBDC systems, or using separate resolution services for each of the FPS and rCBDC systems. A resolution service among different systems would need an additional identifier to identify the system that the payee’s account belongs to (FPS or rCBDC). • Use of a direct resolution service, in which the payee’s PSP and account number are both provided by the alias resolution service; or indirect resolution, in which only the payee’s PSP is identified, and it is the responsibility of the payee’s PSP to identify the account number of the payee. This option is more acceptable in terms of maintaining the privacy of individuals. • The bridge component can be critical for interoperability between different CBDC systems (for example, rCBDC and wCBDC, or online and offline rCBDC); or between CBDC and other payment systems such as RTGS and FPS. Within the bridge, the central bank receives the funds from a PSP in one system and transfers the funds to the other system for the recipient PSP. The bridge keeps a list of PSP identifiers in the different systems, in order to use the interoperability function. • Despite it being technically possible to do a transfer from the central bank to an end user in the rCBDC system, we are reluctant to consider this as a possible scenario; we would rather consider a direct relationship between the end user and his or her own PSP, but not directly with the central bank. However, this is technically a design option and could be dependent on the CBDC and the roles played by the central bank and the PSPs. • The transfer from payer to payee should be complete end-to-end, or should be reversed. Possible error cases could include a case where the payer would be debited by the payer’s PSP, but the PSP could not resolve the alias of the payee; or the PSP might resolve the alias of the PSP but there could be a mismatch in the payee’s name. For all of the previous cases, the transfer should be reversed until the funds are credited back to the payer. Smart contracts could be a suitable technical solution for managing these cases. Domestic CBDC Interoperability Scenarios 15 SCENARIO 2: DOMESTIC PAYMENTS BETWEEN RETAIL CBDCS AND BANK ACCOUNTS CONNECTED TO FPS’S Debit Alice wallet and credit PSP A CBDC wallet PSP A (CBDC network) PSP B Credits Bob account PSP B Payment request PSP B Payment (FPS Scheme) (FPS Scheme) via FSP request from Alice Settlement Option 1 through RTGS PSP A PSP B Debit (CBDC network) Payment request (CBDC network) Alice via CBDC network wallet (Settle in CBDC) PSP B Credits Alice and credit PSP B Bob account (CBDC PSP A (FPS Scheme) wallet) CBDC Option 2 wallet Bob (e-money Debit PSP A 1. Debit CB wallet) CBDC Wallet Central Bank Credit Central Bank (CBDC network) PSP B FPS (FPS Scheme) 2. Settlement in RTGS PSP B Credits PSP A PSP B Bob account (CBDC network) Bridge Debit Alice wallet (FPS Scheme) and credit PSP A CBDC wallet Option 3 16 Technology Design for Interoperability Between Central Bank Digital Currency Systems and Fast Payment Systems EXPERIMENT SET-UP AND DESIGN ExperimentSet-up and Design 17 CBDC SYSTEM The team experimented with a DLT-based CBDC system to explore how such a system would interoperate with an FPS. A private Ethereum implementation was used for the DLT, and an ERC-20-based smart contract for CBDC representation. The experiment does not suggest that DLT is required, or even needed, for CBDC system design; but if DLT is chosen for the CBDC, then it might interoperate with non-DLT fast payment systems. FAST PAYMENT SYSTEM To simulate an FPS environment, the project team leveraged the Mojaloop Foundation’s open-source software, Mojaloop, which is designed for inclusive fast payment systems. The team did not investigate the merits of Mojaloop, but used its open-source code to simulate components of the existing payment system. The team leveraged Docker--an open-source platform that enables developers to encapsulate, distribute, and execute applications in containerized environments--to package the Mojaloop microservices and middleware. To simulate payment transfers between users from two PSPs, the team used the Mojaloop simulator, an open tool developed by the Mojaloop team. Along with this, various Mojaloop open-source APIs (account look-up, transfer request, settlement, etc.) were used. BOX 2: SCENARIO, DESIGN AND TECHNICAL INTEROPERABILITY COMPONENTS SCENARIO 1, SETTLEMENT OF FPS TRANSACTIONS IN A WHOLESALE CBDC SYSTEM Mojoloop Scheme PSP A PSP B Mojaloop Hub Fund PSP A Mojoloop Update Settlement & Position Accounts, settlement account Close settlement window Calls Mojoloop API to Fund Calls Mojoloop Settlement APIs Moja Settlement account Interoperability Bridge Call smart contract to settle Listens to funding event and send settlement message Pre-fund Settlement PSP A Reserve Smart Contract PSP B (CBDC Wallet) with CBDC with CBDC (CBDC Wallet) CBDC Smart Contract DLT base Wholesale CBDC Network TECHNICAL INTEROPERABILITY DESIGN COMPONENTS Interoperability Flow Bridge between Mojaloop<>Wholesale CBDC • PSPs prefund their accounts on a system wholesale CBDC system through smart contracts in order to execute retail Reserve smart contract on CBDC system transactions on Mojaloop; • The interoperability bridge listens to this event and informs the Mojaloop APIs (CBDC System and Mojaloop) network; • The end-user retail transaction is facilitated by the PSPs; • Based on predefined settlement windows, the settlement instruction is triggered from Mojaloop, and is executed by the bridge by calling the CBDC system; • The settlement is executed on the CBDC system, after which the same is communicated to the Mojaloop system to update its database records. SCENARIO 2, SETTLEMENT OF FPS TRANSACTIONS IN A WHOLESALE CBDC SYSTEM TEROPERABILITY TECHNOLOGICAL COMPONENTS CBDC Network Interoperability FPS Alice Components Central PSP A Bank Global Address Lookup Bob CBDC Wallet CBDC PSP B Transfer Lock Contract CBDC Adapter (Bridge) RTGS Platform Central Bank Central Bank PSP B Money Flow Debit Central Bank RTGS Messages Flow Credit PSP B RTGS Account CBDC Ledger Debit Alice CBDC Credit Card Bank CBDC ExperimentSet-up and Design 19 TECHNICAL INTEROPERABILITY DESIGN COMPONENTS Interoperability Flow CBDC Bridge (+Adapter) • CBDC payer requests the PSP to send money to a payee account accessible Global Lookup Address through the FPS; • PSP checks in the global lookup address to see which payment system Reserve smart contract on CBDC system and PSP is serving the payee; • Since the payee PSP is operating in the APIs (CBDC System and Mojaloop) Mojaloop system, the bridge operator (the central bank) is requested to reach the payee PSP and process the payment; • CBDCs reserved through smart contracts would debit the payer’s CBDC wallet, credit the central bank wallet, and send to the bridge to make the call to Mojaloop; • The central bank and the payee PSP execute the payment on Mojaloop, after which the payee PSP informs the payee that money has been received from the payer; • The central bank and the payee PSP settle the FPS transaction leg through the RTGS. 20 Technology Design for Interoperability Between Central Bank Digital Currency Systems and Fast Payment Systems INTEROPERABILITY TECHNOLOGICAL COMPONENTS Interoperability Technological Components 21 The experimentation proof of concepts on CBDC and Mojaloop interoperability had the following key technical components: INTEROPERABILITY BRIDGE The interoperability bridge is a component that facilitates the communication and exchange of information between Mojaloop and the DLT-based CBDC. Since Mojaloop does not natively support communication with DLT systems, the bridge was created to bridge the gap and enable the exchange of information between the two systems, thus facilitating the seamless transfer of funds between Mojaloop (an FPS) and the CBDC system. The bridge application was developed using Node.js, a popular JavaScript framework. The diagram above illustrates the placement of the bridge between the CBDC and Mojaloop systems. The bridge is responsible for monitoring the base CBDC contract, using the remote procedure call (RPC) protocol to detect events. An event is a way for a smart contract to notify the outside world of a specific occurrence or state change that has taken place within the contract. Once an event occurs, for example a fund transfer between addresses, the bridge retrieves this information and identifies the relevant PSP involved in the transaction using its internal mapping of addresses and entities. The bridge then relays this information to Mojaloop via Mojaloop’s REST API, along with the relevant metadata. This approach is used to automate actions such as prefunding PSP accounts. In addition, the bridge period- ically queries Mojaloop for settlement and position account balances and, using the RPC protocol, triggers a transfer from the reserve smart contract to the relevant PSP wallet, to handle settlements. The bridge can also tackle exception handling to ensure that either all parts of the transaction go through, or none (in the event of an exception). When an exception occurs during a payment transaction, the system generating the exception sends the error message to the bridge; this includes an error code, and information about the error. The bridge system can then take appropriate action to resolve the issue, or can communicate with the other payment systems regarding proper action. The bridge is actually a module that serves as a link between different payment systems, for example, the FPS and the rCBDC. The bridge has the business logic required to implement the rules aimed at mitigating credit risk by ensuring that there are enough reserves in the CBDC systems to guarantee settlement of the FPS batch. Since the central bank is mostly acting as the intermediary among participants within the bridge, there might not be a need to settle based on PvP among these systems, because the central bank would have an infinite amount of funds in its own issued currency. The central bank can therefore cover liquidity drainage in one system, and can set the rules for using the liquidity of one participant in transferring? from one system to another. SMART CONTRACT ON A CBDC SYSTEM A smart contract is a self-executing program that runs on a blockchain and manages the transfer of assets. It executes the transaction according to a predefined set of conditions, 22 Technology Design for Interoperability Between Central Bank Digital Currency Systems and Fast Payment Systems such as the conditions allowing a transfer to be done in full, or to be reversed. It also ensures that transactions are processed automatically and securely. Our experiment used an ERC20-based smart contract to power the native CBDC. This smart contract applied the rules for transferring CBDC assets on the blockchain network. In addition to the ERC20 smart contract, an additional smart contract, a transfer contract was written, which played the role of an intermediary between the PSPs and acted as a reserve account to hold settlement funds. The contract facilitated automated reconciliation of accounts through the interoperability bridge, without the need for manual human intervention. USE OF APIS MOJA LOOP RPC API ge I AP an ST ch 1. Observing for events RE ex ta Da 2. CBDC Network Bridge 3. Injection of responses RPC API APIs are a set of protocols that allow different systems to communicate with each other. Mojaloop has a set of predefined REST APIs that allow external systems to communicate with it. The interoperability bridge leveraged these APIs to trigger certain actions within Mojaloop when smart contract events2 occurred on the CBDC system by connecting directly to the CBDC smart contracts through an RPC. This allowed the bridge to directly invoke the functions defined in the smart contracts and to monitor the events generated by these contracts in real time. By leveraging both REST APIs and RPC, the interoperability bridge was able to provide seamless connectivity between the CBDC system and Mojaloop. The use of APIs ensured that the interoperability bridge was able to seamlessly integrate with Mojaloop and take advantage of its existing functionality, without the need for extensive custom development and changes to the core codebase of Mojaloop. 2 In Ethereum smart contracts, an event is a way for a smart contract to notify the outside world of a specific occurrence or state change that has taken place within the contract. Events are defined as part of a contract’s code, and they can be emitted by the contract when certain conditions are met. Interoperability ExperimentSet-up Technological Components and Design 23 API DATA FORMAT AND FINANCIAL MESSAGE FORMAT API data formats are standardized structures for organizing and representing information that is being transmitted between computer systems. They define the format of data being exchanged, including the types of data and the structure in which they are presented. Both Mojaloop and Ethereum support JSON (JavaScript Object Notation) as a data exchange format. JSON is a lightweight data interchange format that is widely used for data exchange between different systems. It is a text-based format that is easy for humans to read and write, and easy for machines to parse and generate. Financial Messaging Data Standard: When different payment systems use different financial messaging standards, it can make communication between two different systems complex. In such a case, the interlinking system is also responsible for translating the messages so that the two systems can understand each other. While this is possible, errors and unnecessary delays can result due to issues such as a lack of the required information, or bespoke custom- ization of message translation across payment systems. ISO20022, the ISO standard for electronic data exchange between financial institutions, was not leveraged in this experiment; however, if the CBDC and fast payment systems use the ISO20022 standard, it would simplify the interoperability challenge, thereby reducing the burden of translating messages across systems. Mojaloop uses a proprietary message format and does not follow ISO20022, although it intends to provide support for it in the future. On the other hand, an experiment that used Ethereum smart contracts for the CBDC system simulation would need to be designed to parse the message and extract the relevant information in order to handle the ISO20022 messages. The smart contract would then execute the appropriate actions based on the message content. This would be handled by the oracle service of the interoperability bridge. However, in our experiment this was handled using the Mojaloop message format rather than ISO20022. Open Questions Various technological and operational questions require additional attention in order to enable seamless integration and interoperability of future CBDC infrastructures with non-CBDC payment systems. Some of them are outlined below. In our experiments, we sometimes tended to use simplifications that wouldn’t be feasible? [or practical?] in a live system; for example, we didn’t integrate the FPS with a complete RTGS system, and we didn’t use a full version of an alias resolution system. Such simplifications are acceptable in an experimental situation; however, in a live environment they could impact the efficiency of the whole solution. While we examined a few of these technical questions in our experiment, more research and further discussions are required in order to fully prove the proposed solutions. TECHNICAL QUESTIONS • Tech Design: What technology components are needed to achieve interop- erability between DLT or non-DLT-based CBDC systems and FPS systems? The development of standardized protocols is crucial for achieving interoperability 24 Technology Design for Interoperability Between Central Bank Digital Currency Systems and Fast Payment Systems between different CBDC and FPS systems. These protocols would define how different systems communicate with each other, and how they exchange data. In addition to this, APIs provide a way for different systems to interact with each other. In the case of CBDC and FPS systems, APIs can enable the seamless transfer of funds and data between different systems. • Message Standard: Communication and exchange of payment messages will be a key part for CBDC systems and FPS systems to interoperate. How could this communication take place? In our experiment, we didn’t apply the ISO20022 message format. This could be a limitation of the experiment, since most of the FPS or CBDC systems might need to exchange information based on a standard message format such as ISO20022 or SWIFT MT. • Scalability: Our experiment explored a bilateral link between two domestic payment systems, a CBDC and a fast payment system, via an interoperability bridge which can potentially be standardized to achieve a scalable design. The experiment did not test for scalability and the capacity to handle a high transaction load. To handle high throughput, future work should consider designing for horizontal scalability, which would involve adding more computing resources, such as servers, to handle the transaction load. Higher throughput would also depend on the capacity of the CBDC system and the FPS under consid- eration, and the efficiency of the interlinking components, such as the bridge. OPERATIONAL QUESTIONS • How can indirect participants in a wholesale CBDC system, such as nonbank e-money issuers, or payment service providers, settle their transactions in the FPS? Possibly there could be a more sophisticated settlement structure in the CBDC system to allow direct participants in the FPS to settle their transactions indirectly in the CBDC system through a direct participant in the system such as a commercial bank. Such arrangements will need to identify limits for the indirect participants within the CBDC, defined by the direct participants in order to mitigate credit risk. • How could differences in operational and governance rules between market infrastructures such as FPS and CBDC systems affect the performance of these systems? The main issue could be the differences in roles and access models among participants in the FPS and CBDC systems. Direct versus indirect partic- ipation models would need special clearing and settlement arrangements. The governance of each system, including the roles of participants and their say in scheme rules might impact the ability of participants to settle and clear transac- tions smoothly. All such arrangements would need detailed studies to address the impact of governance aspects on the performance of the various systems, and how to adequately develop such a governance structure. • What is the vision of the central bank and the role of payment service providers in enabling CBDC interoperability with other payment systems? Actually, the positioning of the wholesale or retail CBDC systems within the Interoperability ExperimentSet-up Technological Components and Design 25 national payment system would determine the required interoperability for CBDC and other payment systems. The objectives of the central bank for developing a CBDC system, and whether it acts as a backup for the existing payment infra- structure, might increase the level of interoperability, since the CBDC system might be connected to more systems. An rCBDC system that targets financial inclusion would need to be tightly connected with other retail payment systems to enable the seamless flow of funds among different systems. PSPs might prefer to keep their liquidity in one system, such as the RTGS or the CBDC, to minimize the liquidity requirements; however, this would require strong links with other payment systems. 26 Technology Design for Interoperability Between Central Bank Digital Currency Systems and Fast Payment Systems LESSONS LEARNED LessonsLearned 27 • Interoperability between FPS and CBDC systems may require using common components such as address resolution services. While the address resolution is a typical component of the FPS, it has not been sufficiently explored with retail CBDC systems. A common module to serve both systems could be an option, but privacy requirements might enforce the use of specific address resolution models (like indirect resolution) when the central bank doesn’t have access to information about individual retail CBDC users. • The use of a bridge component to avail links among different payment systems could be very useful in isolating the logic of the transfer and the message format from individual systems, and shifting these functionalities to a dedicated module. The bridge could position the central bank as the optimum intermediator among financial institutions participating in different systems, including retail and wholesale CBDC, or online and offline CBDC. The central bank is well positioned to provide such a role, due to its infinite liquidity in all systems, and the exemption from being subject to insolvency risk in the domestic currency. • Differing technical standards for payment message standards, API designs, etc., can lead to complexities in the services of the interlinking bridge. • The open-source real-time payment system Mojaloop provides an effective way to simulate traditional retail payment systems. However, it can involve a steep learning curve to understand the infrastructure and run the set-up. • If the CBDC system leverages programmability, it might enable interesting features on locking the funds and triggering settlement of successful funds transfer in traditional systems. While this approach has benefits in reducing counterparty risk, it could also introduce complexity and security tradeoffs. • Smart contract-based CBDC designs can interoperate with traditional external systems through bridging oracle services, and by communicating messages and actions across different systems. • While the interoperability bridge is technically feasible, it may introduce certain trust assumptions and require trusted third parties to operate the bridge connecting PSPs and users in two different payment systems. The central bank could best fit this position. 28 Technology Design for Interoperability Between Central Bank Digital Currency Systems and Fast Payment Systems LOOKING AHEAD LookingAhead 29 CBDCs, if and when they are introduced, will become a critical component not just in the context of national payment systems but may also have significant importance in the context of cross-border payment infrastructures. The jury is still out with regard to what form and shape the CBDC systems will have; however, it is fair to state that CBDC interoperability with legacy and new payment systems will be essential in order to avoid furthering payment system fragmentation. Through this note, we hope to share the knowledge we have acquired from our practical experiments on FPS interoperability with CBDC systems, and to foster further research into and investigation on this topic. Engaging with the relevant stakeholders, such as the operators of payment market infrastructures, central banks, financial institutions, technology providers, and researchers will be crucial in order to build further on this work concerning domestic and cross-border interoperability of CBDC systems with other payment systems. 30 Technology Design for Interoperability Between Central Bank Digital Currency Systems and Fast Payment Systems LookingAhead 31