Is DLT necessary to build a CBDC? Part 4

How does CBDC differ from other electronic payments?

Reading time: 11 minutes. Published on .

Much has been written about different technical implementation options of central bank digital currencies. Often, the use of DLT is proposed. It appears that the choice in favour or against DLT is so fundamental, that the CBDC Tracker even has it as a dedicated category. Yet, I often observe a lack of clarity about what DLTs are, what they can provide, and how that relates to the desired characteristics of a CBDC. In this series, I want to examine these topics in more detail. Part 4 explains what how CBDC is defined and compares it with other electronic payment systems.

Series navigation
  1. Introduction
  2. Smart contracts & programmability
  3. Cryptocurrencies
  4. How does CBDC differ from other electronic payments?

Central Bank Digital Currency in a nutshell

The vast majority of central banks around the world are investigating or piloting a Central Bank Digital Currency, or CBDC for short, 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

While not strictly speaking necessary according to the above definition, CBDC payments are usually expected to be settled instantly. In terms of accessibility, there are two types of CBDC that need to be distinguished. Retail CBDC can be used by anyone in the country, whereas Wholesale CBDC is only available for regulated financial intermediaries. The name refers to the idea that the former allows for retail payments, whereas the latter would be used mainly by financial institutions.

Let us now compare CBDC to existing instruments. Note that due to the lack of widespread experience with CBDC, many of its properties are currently only technically proven, but not necessarily economically.

CBDC Cash Reserve account Deposit money Stablecoin Cryptocurrency
Issuer central bank central bank central bank financial intermediary private company anonymous network
Embodiment digital physical digital digital digital digital
Currency sovereign sovereign sovereign private, denoted in sovereign currency private, backed by various assets, denoted in sovereign currency built-in, not backed
Accessibility Retail CBDC: universal
Wholesale CBDC: only for intermediaries		 universal only for intermediaries universal (in principle) universal (in principle) universal (in principle)
Legal tender yes yes yes no no no
Comparison between different payment instruments/assets (author’s elaboration)

As it becomes obvious from this comparison, one of the reasons central banks attempt to design retail CBDC is to combine advantages of the other instruments. (Note that I have omitted some instruments such as mobile wallets from the table for brevity.) For the remainder of this essay, I will focus on retail CBDC.

Technical requirements for CBDC

Based on the above characteristics, many different technical implementations are possible; however, it is clear that a system that is poised to process a significant share of a country’s payment volume, needs to meet high security and resilience criteria (among others).

Bank of England staffers have already proposed such criteria in 2017 (quoted verbatim):

Those criteria are still present – and further elaborated upon – in the Bank of England’s 2023 technology working paper on the digital pound. Most notably, the bank now “estimates that approximately 30,000 transactions per second may be the necessary level of performance needed”, with further explorations towards “more ambitious capabilities of […] 100,000 transactions per second”.

While details, e.g. concrete figures, differ across the working or design papers of various central banks, by and large, they are similar. However, there are stark differences regarding the issuance model which deserve some further explanation.

How is CBDC issued?

The Bank for International Settlements (BIS) distinguishes between three different issuance models:

  1. Direct CBDC. The digital money is issued by the central banks, which also manages user holdings and retail payments. The role of intermediaries is limited.
  2. Hybrid CBDC. As in the direct model, digital money is issued by the central banks, but most other responsibilities are delegated to intermediaries, such as onboarding and user interaction.
  3. Indirect (or synthetic) CBDC. As opposed to the other two models, digital money held by users is a claim on the intermediary. Issuance is still controlled by the central bank, because any intermediary wishing to distribute digital money to their customers must submit sufficiently much reserve balance.

These models are ordered by decreasing involvement of the central bank, and closely related, increasing need for supervision of intermediaries.

Roles & responsibilities across a CBDC ecosystem

In a later publication, BIS further differentiates the second model in terms of whether retail payments are processed by the central bank or by intermediaries. In the latter case, the central bank only “sees” wholesale payments, exhibiting similarity to a wholesale CBDC. Perhaps more interesting is that Auer and Böhme no longer classify the indirect model as a retail CBDC, but rather as “fully backed payment accounts or stablecoins”.

Image description see below
Roles and responsibilities of the broader ecosystem players in a hybrid CBCD model (author’s elaboration)
Image description

Three players: Central Bank, Public Sector, Private Sector

  • Central Bank:
    • Issuance & Management of CBDC
    • Financial stability
    • Payment efficiency & integrity
  • Public Sector:
    • Ensure financial inclusion
    • Regulatory oversight
    • Fraud detection & investigation
  • Private Sector:
    • Distribution & custody of CBDC
    • Providing additional innovative services

If we give up the notion of clear technical separation between the different issuance models, and instead consider them on a spectrum, we can focus on common themes of governance, before moving on to assessing DLT’s appropriateness for implementing CBDC.

CBDC vs. stablecoins

There is common understanding across central banks that governance and operation of CBDC falls purely within a limited set of regulated entities. As opposed to traditional deposits, many non-banks can hold CBDC, to increase competition within the payment landscape for the benefit of end users.

This is comparable to stablecoins. The major stablecoin issuers Tether (USDT), Circle (USDC), and others, follow a centralized governance approach. The issuer is responsible for cash-in and cash-out transactions, as well as ensuring that there are always sufficiently much backing assets (collateral) to match the circulating supply of the stablecoin.

However, since USDT, USDC, and others are issued as smart contracts on Ethereum (and other smart contract-capable blockchains), stablecoin holders can transact in a decentral manner without intermediaries. They are also integrated into AMMs (automated market makers, see previous part) and can be therefore traded for other types of assets. Any interested user can also build their own smart contract logic to transact with stablecoins, such as implementing recurring payments.

This gives rise to an interesting combination of centralization and decentralization: a fully centralized instrument that uses a fully decentralized platform. A hypothetical CBDC that is issued in a similar way would therefore satisfy certain (centralized) governance requirements.

But the decentralized aspect of the underlying distributed ledger still poses a problem. The central bank would have no control over the evolution of the protocol, potential forks, or double-spending attacks. For example, consider a hypothetical protocol change that would negatively impact a particular token but is accepted by the majority of miners. The token-issuing entity has no way of vetoing that change, effectively yielding control over the token to an anonymous set of stakeholders.

This also leads us to the second point: this plurality of anonymous blockchain participants that together form a consensus about whether or not a transaction is valid. In offline scenarios, there is by definition no connectivity to the ledger, therefore rendering consensus impossible. Offline payments only work if we can assume a basic level of trust between participants, where the trust may be established through hardware security. This goes counter to the idea of public distributed ledgers.

From this, we can conclude that public blockchains, like those employed by stablecoins, are not desirable for CBDCs.

CBDC vs. deposits

As of today, deposit money is already electronic. It can be used for online payments, and to a limited extent, also offline (for example with contactless cards). But unlike central bank money, deposit money is issued by individual banks. That means that transfers from an account at bank A to a bank account at bank B may involve an additional settlement step, where bank A pays bank B the equivalent amount in central bank reserves. Conversely, if a payment happens between accounts in the same bank, it can be settled inside the bank (referred to as on-us transactions).

Some banks have investigated tokenizing deposits, i.e., defining a common standard for a digital representation of their privately-issued money. Such a solution would entail:

The precise mechanics differ. In the Regulated Liabilities Network (RLN) proposal, there is a wholesale token that represents central bank reserves, closely mirroring the working of current inter-bank settlement systems. In another proposal, the German Banking Industry Committee (Die Deutsche Kreditwirtschaft) has sketched exchange algorithms based on atomic swaps of each other’s tokens, possibly across different ledgers.

Yet, the same questions about stablecoins remain for tokenized deposits. Governance would need to be decentralized; otherwise, where is the material difference to traditional reserve accounts? But then, would a central bank be willing to participate in such a system? Also, since the tokens are issued from multiple entities, they are not truly interoperable, therefore restricting flexibility and preventing offline payment use cases.

Based on these considerations, the design space for CBDC is restricted further. Even a permissioned distributed ledger where multiple banks are members and can exert control over settlement will not be appropriate for a CBDC.

Conclusion

CBDC shares some aspects with other electronic payment systems, stablecoins, and deposits. However, the combination is unique: issued by the central bank, directly accessible for users, and offline-capable. To some extent, this simplifies matters, because today’s typical settlement routines often involve multiple intermediaries and therefore multiple kinds of money. But on the other hand, it also restricts the design decisions: decentralized governance, key feature of DLTs (as argued in earlier parts of this series), is detrimental to a CBDC. Is there anything left? What about programmability, privacy, performance? I will explore that in the next and final part of this series.

Notes & References

CBDC definition. There are plenty of references on the definition of CBDC. For example, consider the high-level introductions by McKinsey and Investopedia. There is ongoing debate in the literature whether the concept of wholesale CBDC is novel, e.g., with Fabio Panetta likening it to central bank reserve accounts.

Legal tender. While retail CBDC is typically expected to become legal tender, it is important to clarify what that means. Legal tender can increase trust in currency, but does not relate to general payments. For example, merchants could refuse cash payments, even though it is legal tender.

Privacy and anonymity. There are varying levels of privacy in cryptocurrencies, typically ranging from pseudonymity to anonymity. For technical explanations, see also “Anonymous and pseudonymous data: Are they actually important?” and “Anonymity vs Pseudonymity”.

Thanks to my colleagues Daniel Nagy, Severino Sequeira, and Martin Rönnebeck for their comments on early drafts of this article.

This post has also been published on LinkedIn.