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

Ever since the COVID-19 pandemic, cash usage has been decreasing worldwide and digital payments based on cryptocurrencies or legacy digital payment systems have prevailed. As a result, new forms of centrally managed digital currencies are emerging alongside cryptocurrencies like Bitcoin, the notorious volatility of which has challenged their acceptance worldwide. More prominently, central bank digital currencies (CBDCs) have come to offer digital forms of central bank money, while tokenized deposits tokenize the lifecycle of commercial bank money in both the retail and wholesale context.

Under such centrally governed systems, accountability needs to co-exist with privacy, while both need to respect the need for authorized audits. At the same time, because of the system’s critical nature, achieving resilience is crucial while its definition extends beyond the crash fault tolerance in legacy critical infrastructure systems. The system must be resilient to a Byzantine fault, so that it can continue to operate even if parts of the system have been 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 performing framework for CBDCs that combines privacy, regulation compliance and advanced resilience.

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, serve 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 remedy 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 publishing periodic reports on the functional and non-functional requirements of CBDC platforms, including the evolving architectural considerations and the outcomes of their various CBDC experimentations. A handful of national central banks have even started CBDC pilots, while the European Central Bank recently initiated a legislation 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 governed by central banks. However, the robustness and resilience requirements associated with the critical nature of a CBDC system impose a decentralized governance, geographically distributed deployment of the system and independent operation of the different parts of the system.

Regulatory compliance and efficient dispute resolution capabilities require transparency, auditability, and non-repudiation. Regulations such as the anti-money-laundering directive (AML) or efforts that focus on combating the financing of terrorism (CFT) stipulate 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. Additionally, a CBDC system should interoperate with existing payment, settlement, and liquidity infrastructures alongside other CBDC systems and emerging digital asset systems.

The performance and scalability of the system are crucial for its acceptance and use. This is important for a wholesale CBDC platform that seeks to extend 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 restricts the collection of personal information to what is necessary for transaction processing. This can be interpreted in various ways. A conservative approach to data minimization makes sure that payment transactions are processed without leaking any information about the transacting parties or the values of the transactions. This renders transaction monitoring and audit more difficult. A permissive approach reveals the value of the payments and potentially the identities of the payer and payee.

A progressive CBDC system should 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 should be built in.

How does the IBM Research platform cope with these challenges?

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

• Transparent transaction processing with strong accountability through a shared ledger that records all transactions processed by the system.
• Resilience to compromised nodes by using DLTs to employ decentralization in each 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 execute-order-validate transaction processing model introduced by Hyperledger Fabric 1.0, a state-of-the-art Byzantine fault-tolerant consensus protocol (tolerating 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 introduced in transaction processing. This is important for applications that employ computationally heavy zero knowledge proofs to offer privacy.

In this work, we feature a prototype implementation of our framework as an evolved version of Hyperledger Fabric, coupled 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 pseudonymity/anonymity for transactors using self-sovereign identity principles and privacy standards; UTXO support enhanced 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 crash 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, exhibiting state-of-the-art performance and scalability.

Our results show that for the standard UTXO pseudonymity model, our prototype implementation 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 compute. In fact, we show that the same numbers can be attained in stronger privacy scenarios where the exchanged amounts and the activity of individual users are concealed at the cost of more powerful equipment. The obtained performance numbers correspond to a CBDC system that offers 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 tokenized financial assets?

Tokenization is a term that expands on different forms of financial assets. It refers to the digitalization of a business asset, but assuming a digital system that supports first of a kind requirement around transparency, interoperation, 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 these systems, while distinct in terms of the use-cases they address, come down to a similar set of requirements in terms of accountability, privacy, regulation compliance, resilience and programmability. Indeed, while each use-case needs to be investigated in depth to conclude, the framework proposed by IBM Research is generic enough to directly accommodate a wider scope of applications of tokenized assets.

Learn more about the IBM Research CBDC platform