Privacy, Ledger Architecture, and Cross-border Integrations in Central Bank Digital Currency

July 2, 2023 | 13 minute read
Mark Rakhmilevich
Vice President, Blockchain Product Management
Text Size 100%:


114 countries, representing over 95 percent of global GDP are exploring a CBDC, according to the CBDC tracker published by the Atlantic Council, with about half of them in advanced stages (development, pilot, or launch). Oracle has been involved with some of these explorations in various forms, including participation in the Bank of England CBDC Technology Forum and in the ECB technical talks to explore options for the design of a central bank digital currency. We’ve also engaged with Central Banks in Europe, Middle East, Africa, and Asia to discuss our CBDC sandbox to help accelerate the exploration of various facets of CBDC through POCs and pilots. And we’ve been exploring the OpenCBDC – an MIT open source project released by Project Hamilton - a collaboration between the Federal Reserve Bank of Boston (Boston Fed) and the MIT's Digital Currency Initiative (MIT DCI)

Privacy Considerations and Privacy-Enhancing Technologies in Retail CBDC

Recently I’ve had an opportunity to join experts from financial sector, technology companies, and academia at the Digital Dollar Project’s roundtable discussions on privacy requirements for a U.S. CBDC held at the UC Berkeley’s Haas School of Business. This series of 3 roundtables (held at MIT Connection Science and Engineering, UC Berkeley's Center for Responsible, Decentralized Intelligence, and the Georgetown University Law Center's Institute of International Economic Law) brought together academics and subject matter experts from the public sector, technology companies, and leading financial and payment institutions. The roundtables were focused on the technical and regulatory implications of privacy in the context of exploring digital dollar as a possible U.S. retail CBDC – an additional form of electronic payment, which is a liability claim on U.S. Federal Reserve that similarly to cash would be widely available to the general public for individual and merchant payments. The results have been published recently as a summary report on Privacy in the Age of Digital Money: Defining the Requirements for CBDCs.

There are many considerations involved in retail CBDC, not least of which is introducing it without disrupting the existing banking system and ensuring broad adoption in retail payments, but perhaps the most talked about is privacy. When you exchange a $10 bill for some strawberries at a roadside fruit stand, which I recently did on a drive through Central California, the privacy and anonymity of the exchange is assured (though the possibility that the fruit stand has a web cam to record all visitors cannot be discounted.) When it comes to larger payments, banks do impose some traceability today when you deposit or withdraw very large amounts of cash, but any cash transactions under those limits are usually untraceable (leaving aside a possibility of marked bills that we’ve all seen in movies about hostage ransoms.) Why not the same anonymity for digital dollars under some threshold amount? With digital currency, automating a few thousand individual transactions of $10 is fairly trivial, but the total amount could certainly merit the attention of regulators who need to enforce Anti-Money Laundering laws, sanctions violations, comply with valid law enforcement requests, etc. It was made pretty clear at the DDP’s roundtable that tying privacy rules to the threshold amounts of a transaction is not viable in digital currency.

What then?  How do we square the need for privacy (which is crucial for any widespread adoption of retail CBDC) and the need for regulatability, which is a requirement for any country adhering to the rule of law? The roundtable participants discussed a number of Privacy-Enhancing Technologies (PETs), including techniques for ensuring accountability for any de-anonymization, and nuances of real-time interdiction of payments that violate regulations vs. after-the-fact detection of such violations in an audit process. PET’s can include a wide range of approaches, such as:

  • Anonymization and pseudoanonymization
  • Differential privacy
  • Secret computation (e.g., homomorphic encryption, multi-party computation)
  • Trusted Execution Environments (TEEs)
  • Federated and Swarm Learning in AI
  • Accountable de-anonymization measures

For more detailed overview of PETs I recommend Bank of Japan’s Privacy Enhancing Technologies: Payments and Financial Services in a Digital Society and OECD’s Emerging Privacy Enhancing Technologies: Current Regulatory and Policy Approaches.

Also important to note that ISO 27000 standards family, which is a primary guide on information systems security for financial institutions, continues to evolve, with ISO 27701 focus on privacy in response to EU strengthening GDPR, which is going to impact CBDC handling of Personally Identifiable Information (PII). This will interact with regulatability requirements (KYC, AML/CFT), which are heavily dependent on access to PII of the parties involved in a payment. While the CBDC ledger can handle transactions using anonymous or pseudonymous identities, the payment interface providers must manage the KYC requirements as part of user onboarding, to handle transfers between CBDC and current (fiat) accounts, and to enforce AML/CFT regulations.  All of these processes involve PII, and therefore GDPR considerations will have to be addressed.

Ledger Architecture: Centralized or Distributed

Another consideration that’s often raised in retail CBDC discussions is whether the technology foundation for the underlying ledger should use DLTs or centrally governed, distributed database technologies, which Bank of England recently said “might be a more efficient and appropriate approach” in its technology working paper on “The digital pound.” The paper also raises a concern about decentralized governance (in case of DLT) increasing system attack surface, which in turn requires implementation of security controls to minimize these access control risks. And this could impact system performance as well as its usability and adoption. The paper doesn’t present a conclusion on this topic, but recommends further analysis of the foundational technologies used for the core ledger.

According to Bank of International Settlements, which keeps data on CBDC projects around the world, in the latest available dataset from January of 2023 10 countries used conventional (database) ledgers in their implementations, 8 countries used DLTs, and 15 countries a combination of conventional and DLT technologies. This is influenced by many factors, some objective, such as security, resilience, scalability needs (based on country’s population), and skill set of the implementation teams, as well potential bias for or against specific technologies.   

Recognizing that Central Banks have used both centralized and decentralized ledgers in CBDC pilots and even in live CBDC implementations based on a number of factors, Oracle incorporates both in our CBDC sandbox. Fungible token implementation using a permissioned DLT provided by Oracle Blockchain Platform (OBP) based on open source Hyperledger Fabric simplifies the decentralized governance problem by providing a role-based governance layer for a decentralized network including Central Bank and an authorized set of other participating financial and regulatory entities. And a similar tokenization implementation using Blockchain Tables in Oracle’s Autonomous Transaction Processing (ATP) database leverages a mature centrally-governed distributed database with immutability advantages of cryptographic hash-linked table rows,  row signing and counter-signing, and strong integrity verification capabilities including signed table digests.

The DLT and database ledgers can also be integrated in a two-tier hybrid or intermediated CBDC implementation, based on the concepts described in the seminal paper on CBDC architectures, “The technology of retail central bank digital currency” by Raphael Auer and Rainer Böhme and illustrated in the top and bottom section of the diagram below. 

Source: Auer and R Böhme, “Central bank digital currency: the quest for minimally invasive technology”, BIS Working Papers, no 948, June 2021.

In the Indirect CBDC the wholesale network involving Central Bank (CB) and participating banks X and Y would use blockchain nodes, such as Oracle Blockchain Platform, to run a permissioned blockchain network with CB in a minter and burner role, and other participants able to execute interbank transactions. Each participating bank would also run its independent retail ledger using a database with immutability features, such as ATP’s Blockchain Table. Transactions between parties A and B would be handled directly in the bank X retail ledger, while transactions between A and C (who’s account is at bank Y), would in addition to local ledgers reflect transfers between banks X and Y through the wholesale CBDC using permissioned DLT-based network and visible at the Central Bank’s node(s). 

Hybrid CBDC architecture (in the bottom section of the diagram) would also use a local ATP-based ledger at each Payment System Provider (PSP), which can be a regulated narrow bank or a payments-only entity, and participate as a distributed node in a wholesale permissioned OBP-based ledger connecting CBs and PSPs. However, transactions between parties A and B through accounts at the same PSP would now also be reflected on the wholesale ledger, but with some delay. The asynchronous nature of updating the wholesale ledger in the hybrid CBDC allows for batching transactions, which enables it to scale to much higher payment volumes than if each payment required an independent transaction commit. This is akin to widely used roll-ups in Layer 2 DLT scaling solutions, where Layer 2 chains achieve scalability by batching multiple transactions and committing these via a single transaction on the Layer 1 chain.

However, there’s really no benefits to decentralizing PSP’s local ledger maintaining their local user’s transactions. As long as a conventional database can deliver resilience, high performance and cost-effective scalability, with immutability and cryptographic verification of transactions to protect against external hackers or insider threats, it would significantly simplify CBDC implementation for large numbers of PSPs. Oracle in-database blockchain tables provide the required immutability and verification methods, along with user signing and database countersigning options. As a Level 2 ledger connected to the wholesale Layer 1 ledger based on permissioned DLT, it can provide asynchronous roll-ups or batch updates along with relevant cryptographic digests of the PSPs ledger into the wholesale Layer 1 permissioned DLT network comprising the Central Bank and other wholesale network participants.

Multi-currency Payments and Cross-border CBDC

Beyond these architectures for scaling retail CBDC, there’s also interesting work going on in linking multiple countries CBDC systems to enable multi-currency interbank payment channels.  One of the more advanced is the mBridge project sponsored by the Bank for International Settlements (BIS) with participation of 20 commercial banks from Hong Kong SAR, Mainland China, the UAE and Thailand with participation of their four Central Banks. They experimented with foreign exchange and payment vs. payment (PvP) transactions on behalf of corporate clients. This multi-CBDC platform was implemented as a single ledger, direct-access CBDC model with a common technical infrastructure for hosting multiple CBDC currencies, thus enabling domestic issuance by each CB as well as cross-border multi-currency payments. The traditional model for settling cross-border payments is a correspondent banking – and it’s estimated to handle nearly $23.5 trillion globally, with transaction charges of around 0.5%, or approximately $120 billion, not to mention significant settlement delays and associated risks.

mBridge is an attempt to re-envision global payments and explore technical, legal, financial, and regulatory issues that arise in this context. On the technical side the project explored integration with each country’s interbank payment system through RTGS on- and off-ramps as well as connectivity to domestic CBDC systems. The platform provided support for commercial banks to request issuance and redemption of CBDCs from their Central Bank, and to initiate and respond to peer-to-peer push payments in any of the four currencies with any other commercial bank counterparty on the platform. mBridge demonstrated the potential to settle transactions instantly, which reduces settlement risk compared with the correspondent banking model, where a three-to-five day delay between payment and settlement is commonplace.

Similar to mBridge approach, Oracle's CBDC sandbox provides a single platform direct access approach for multi-currency payments with liquidity pools for foreign exchange. These built-in exchange facilities, created as part of the tokenization system on Oracle Blockchain Platform, contain exchange pool accounts for various currencies that can be funded based on a percentage of minted currency or through direct transfers from liquidity-providing banks. The bi-lateral exchange rates can be set from any external system via the provided APIs, and are then applied when a cross-currency transfer is submitted. OBP atomic transaction capability is used to handle all credits and debits to liquidity pool currency-specific accounts and originator and counterparty accounts with a single ledger commit, ensuring that either all occur, or nothing occurs.

A key requirement of any cross-border CBDC approach is integration with domestic payment rails, including Real Time Gross Settlement (RTGS) systems or other CBDCs deployed domestically. Oracle's CBDC Sandbox enables integration with both. The ISO20022 payment messages integration can be leveraged for seamlessly connecting into many RTGS systems. For integration with other CBDC systems, Oracle Blockchain Platform provides built-in atomic transaction orchestration with Ethereum, Hyperledger Besu, and other EVM based DLTs. Additional DLTs can be integrated via open source Hyperledger Firefly and Hyperledger Cacti projects.  

Another approach to cross-CBDC integration has been proposed by Swift – a global interbank financial messaging services provider with more than 11,000 financial institutions and corporate customers. It relies on SWIFT’s CBDC Connector Gateway built to connect diverse DLT-based CBDC solutions to the Swift platform. The gateway uses ISO20022 messaging formats for payments and Swift-managed PKI-based identity. By connecting various CBDCs to the Swift platform, this approach simplifies the connectivity requirements and identity management compared to a decentralized platform, and enables an array of value-added services, such as KYC, AML, sanctions screening, etc.

Oracle’s Applications Drive Large Volumes of Payments

Oracle’s interest in the emergent CBDC space goes beyond the technologies and capabilities provided by the CBDC sandbox for wholesale or retail CBDC schemes. It also stems from RTGS integration capabilities in Oracle Banking Payments, which connects CBDC technologies with the broader banking and financial markets ecosystem. In addition hundreds of thousands of Oracle customers use Oracle applications to initiate large volumes of payments through our MICROS PoS systems for restaurants and hotels, B2B payments through Fusion and Netsuite ERPs, construction-related payments through Textura and a number of other commerce applications in Retail, Healthcare, and other industries. The adoption of future CBDC “payment rails” in these applications is an important factor in CBDC acceptance.

The impact of the privacy considerations, ledger design, and cross-border integration approaches discussed in this post on ease of adoption at interbank and retail level, as well as security, scalability, resilience, and ability to meet regulatability requirements is being explored in CBDC projects around the world. Oracle is contributing to these efforts through our CBDC sandbox and deep history of supporting core banking, RTGS systems, large-scale payments implementations, and other financial systems. Ongoing focus on privacy and confidentiality of CBDC payments, scalability to tackle retail transactions, cross-border multi-currency payments, and interoperability between CBDC and existing payment ecosystems is critical to ensure not only successful implementation of CBDC projects but their adoption across the wholesale and retail spheres in many countries.

Mark Rakhmilevich

Vice President, Blockchain Product Management

Mark is responsible for Blockchain strategy and products. He focuses on evolving Oracle Blockchain Platform and Oracle Database Blockchain Tables in the cloud and on-premises to meet the needs of customers and partners for scalable, secure, production-ready platform to support blockchain solutions. He helps to guide customers and partners around the world in applying blockchain technology to deliver on key business outcomes – accelerating growth, reducing costs and friction in business ecosystems, reducing risk and fraud, and bringing to market innovative solutions that solve real-world societal challenges. Mark facilitates customers’ journey from rapid experimentation to live production through discovery, sharing industry use cases and best practices, and advising on solution architecture.

Previous Post

Latest OCI Blockchain Platform update enables blockchain interoperability and brings Web3 capabilities to OCI

Mark Rakhmilevich | 13 min read

Next Post

Enhance enterprise data security and trust: Must see Blockchain Technology sessions at Oracle CloudWorld 2023

Kiran Makarla | 3 min read