Forging a framework for central bank digital currencies and tokenization of other financial assets

Since the COVID-19 pandemic, cash use has declined worldwide and digital payments based on cryptocurrencies or outdated digital payment systems have prevailed. As a result, new forms of centrally managed digital currencies are emerging alongside cryptocurrencies such as Bitcoin, whose notorious volatility has challenged their adoption worldwide. More prominently, central bank digital currencies (CBDCs) have come to offer digital forms of central bank money, while signed deposits mark the lifecycle of commercial bank money in both the retail and wholesale contexts.

Under such centrally controlled systems, accountability must coexist with privacy, while both must respect the need for authorized audits. At the same time, due to the system’s critical nature, achieving resilience is crucial, while its definition extends beyond collision fault tolerance in legacy critical infrastructure systems. The system must be resistant to a Byzantine fault, so that it can continue to function even if parts of the system are compromised.

Decentralized transaction processing systems, such as distributed ledger technology (DLT), are relevant platforms, but current DLT implementations are generally not scalable enough. That ceiling has been shattered by recent work done by IBM Research®, which delivers a high-performance framework for CBDCs that combines privacy, regulatory compliance and advanced resiliency.

What are central bank digital currencies?

Central bank digital currencies are digital currencies controlled by the central banks of countries. Like cash, they are designed to store value, act as mediums of exchange and represent a unit of account. CBDCs are used for both wholesale settlements between commercial banks or central banks and retail payment transactions, such as transactions by individuals. In recent years, CBDCs have been positioned as a viable solution to current inefficiencies in financial markets, as they can promote innovation, more effectively aid inclusion in payment systems and reduce settlement delays, costs and counterparty risks.

Today, more than 130 central banks are actively exploring CBDCs and publish periodic reports on the functional and non-functional requirements of CBDC platforms, including the evolving architectural considerations and the outcomes of their various CBDC experiments. A handful of national central banks have even started CBDC pilots, while the European Central Bank recently initiated a legislative proposal for the adoption of a digital euro.

CBDC requirements and challenges

Although the regulation of CBDC systems depends on local jurisdiction, systems share many of the same functional and non-functional requirements. For example, the critical impact of CBDC infrastructure on the monetary supply implies that it should be controlled by central banks. However, the robustness and resilience requirements associated with the critical nature of a CBDC system require a decentralized management, geographically distributed deployment of the system and independent operation of the different parts of the system.

Regulatory compliance and effective dispute resolution capabilities require transparency, auditability and non-repudiation. Regulations such as the Anti-Money Laundering Directive (AML) or efforts focused on combating the financing of terrorism (CFT) require that suspicious payment transactions be detected, attributed to their origin and reported to the relevant authorities. Alternatively, the EU’s Revised Payment Services Directive (PSD2) emphasizes the importance of fraud detection and dispute resolution. In addition, a CBDC system must interoperate with existing payment, settlement and liquidity infrastructure along with other CBDC systems and emerging digital asset systems.

The performance and scalability of the system is crucial for its adoption and use. This is important for a wholesale CBDC platform that seeks to expand its use for other applications beyond settlement. Retail CBDC systems should be able to compete with existing payment services and accommodate millions of user transactions. This means being able to process tens of thousands of transactions per second (TPS) at peak times.

Payment transaction privacy is also important. Privacy refers to the right of data owners to control who accesses their transactional information. For example, PSD2 states that the processing of personal information must comply with the GDPR and its principles of data minimization, which limits the collection of personal information to what is necessary for transaction processing. This can be interpreted in several ways. A conservative approach to data minimization ensures that payment transactions are processed without leaking any information about the transaction parties or the values ​​of the transactions. This makes transaction monitoring and auditing more difficult. A permissive approach reveals the value of the payments and possibly the identity of the payer and payee.

A progressive CBDC system must accommodate different interpretations of privacy, along with all other requirements, including performance and auditability. As technology evolves, so do privacy regulations and requirements—and agility must be built in.

How does the IBM Research platform address these challenges?

At IBM Research, we have developed a transaction processing framework for variable financial asset management (mainly for CBDCs) that addresses all the previously mentioned challenges. Permissioned DLTs offer multiple advantages over other technologies, including their ability to address privacy, transparency, and resilience to compromised nodes, even with a centralized governance model. They also meet and exceed CBDC performance and scalability requirements. We have further validated these claims by introducing a system architecture and protocols, which exhibit:

Transparent transaction processing with strong accountability through a shared ledger that records all transactions processed by the system. Resilience against compromised nodes by using DLTs to use decentralization in every phase of the transaction processing and shared ledger evolution. High-throughput and low-latency transaction processing that outperforms retail CBDC requirements through the optimal combination of the export-order-validate transaction processing model introduced by Hyperledger Fabric 1.0, a modern Byzantine fault-tolerant consensus protocol (tolerant of compromised nodes), and two-phase commit principles for high degree of parallelism in transaction processing, principles for high degree of parallelism in transaction processing. Horizontal scalability of all application layer logic implemented in transaction processing. This is important for applications that use computationally heavy zero-knowledge proofs to provide privacy.

In this work, we include a prototype implementation of our framework as an evolved version of Hyperledger Fabric, together with the four CBDC privacy models: Standard unspent transaction output (UTXO) support using standard public key infrastructure (PKI ) with no privacy in place; standard UTXO support with accountable pseudonym/anonymity for transactors using self-sovereign identity principles and privacy standards; UTXO support improves with anonymity and exchanged amount confidentiality using zero-knowledge proof-based extensions; and untraceable UTXO using the cryptographic means introduced by IBM Research for full transactor (accountable) privacy. We further evaluated our system’s performance using three consensus protocols: a collision fault-tolerant consensus protocol, Raft; A Byzantine fault-tolerant consensus protocol in the wild, SmartBFT; and a new Byzantine fault-tolerant architecture inspired by the Narwhal and Tusk consensus algorithm, which demonstrates state-of-the-art performance and scalability.

Our results show that our prototype implementation for the standard UTXO pseudonymity model can process up to 80,000 TPS in the case of Raft and SmartBFT and more than 150,000 TPS in the case of emerging consensus algorithms. Our results further demonstrate the horizontal scalability of transaction processing computation. In fact, we show that the same numbers can be achieved in stronger privacy scenarios where the exchanged amounts and the activity of individual users are hidden at the expense of more powerful equipment. The obtained performance numbers are consistent with a CBDC system that provides privacy for end users while allowing authorized auditors to inspect transactional information and settlement components to properly process transactions.

How is this framework relevant or applicable to other forms of signed financial assets?

Tokenization is a term that expands on different forms of financial assets. This refers to the digitization of a business asset, but assuming a digital system that first supports some kind of requirement around transparency, interoperability, resilience and programmability beyond what legacy systems can accommodate. Central bank digital currencies are examples of the tokenization of central bank money, but we see tokenization expanding on deposits to commercial banks or commercial bank money (also known as tokenized deposits), various forms of securities (tokenized securities) and many more.

All of these systems, while distinct in terms of the use cases they address, boil down to a similar set of requirements in terms of accountability, privacy, regulatory compliance, resilience, and programmability. Indeed, although each use case needs to be explored in depth to conclude, the framework proposed by IBM Research is generic enough to directly accommodate a wider range of applications of signed assets.

Learn more about the IBM Research CBDC platform