CBDC Operating Model: One- versus Multi-Tier

One of the first big retail central bank digital currency (CBDC) design decisions is the operating model. In a single-tier model the central bank performs all the tasks involved, from issuing and distributing the CBDC to running user wallets. In multi-tier models, the central bank issues and redeems CBDC, but distribution and payment services would be delegated to the private sector. Which model to adopt will depend on country-specific circumstances, such as financial sector breadth and depth, financial integrity standards compliance, and financial market infrastructure availability and supervision capacity.

Single-tier models

In a single-tier model, CBDC transactions resemble transactions with commercial banks, except accounts would be held with the central bank. A payer would log in to an account at the central bank through a web or mobile application and request a transfer of funds to a recipient’s account, also at the central bank. The central bank would ensure settlement by updating a master ledger, but only after verification of the payer’s authority to use the account, enough funds, and authenticity of the payee’s account. This mode gives central banks more control over the product design and implementation process.

However, the single-tier model requires the central bank to assume an active role in distribution and payment services that may exceed the scope of its core mandate and capacity. Moreover, central banks would directly compete with existing digital payment service providers creating disintermediation risk. Conceptually, the single-tier model may be appropriate for a country with a well-resourced central bank in which the financial sector is extremely underdeveloped, so that there are no institutions to assume distribution and provision of payment services, as may be the case in some low-income countries.

Multi-tier models

In multi-tier models, the central bank issues CBDC but outsources some or all the work of administering the accounts and payment services. However, CBDC remains the liability of the central bank and thus CBDC holders would not be exposed to default risk of the engaged payment service providers (PSPs).

The multi-tier model has been the overwhelmingly preferred solution in CBDC pilots and the only launch so far. Running currency distribution is not something the central bank is well-suited to perform, requiring customer-facing activities that may be beyond their capacity. Also, the multi-tier model is less disruptive than the single-tier one as financial institutions play their traditional roles in distribution and payment services. In addition, this layered approach facilitates the integration of new types of consumer electronic devices without the need to alter the core of the system, and it supports the ability for third parties to build on top of the core (Shah and others, 2020; Armelius et al, 2021).

Different Flavors of Multi-Tier

Auer and Boehme (2021) discuss two different multi-tier models that differ in terms of the records kept by the central bank. In a “hybrid” architecture the central bank records all retail CBDC holdings and the CBDC is never on PSP balance sheets so that user holdings are not exposed to claims by PSP creditors in the event of PSP insolvency (first panel below).

In an “intermediated” architecture the central bank only runs a ledger of PSP wholesale CBDC holdings (second panel). Central banks may prefer this architecture due to privacy and data security concerns. However, the central bank still must honor CBDC holder claims in the event of PSP insolvency or data breaches, relying on the integrity and availability of the PSP’s records. This will require close supervision to ensure that the wholesale holdings add up to the sum of all retail accounts at all times.

Auer and Böhme (2020) suggest that, in an intermediated architecture, there be a legal framework that keeps user CBDC holdings segregated from PSP balance sheets so that the holdings are not considered part of a failed PSP’s estate available to creditors. They also suggest that the legal framework could give the central bank the power to switch user accounts in bulk from a failed PSP to a functional one. To do this expeditiously, the central bank would likely have to retain a copy of all retail CBDC holdings.

Bank of England (2020) proposes running a hybrid architecture on a “platform” in which the central bank provides a fast, highly secure and resilient technology infrastructure to provide the minimum necessary functionality for CBDC payments (the “core ledger” below). Payment interface providers would connect to it via an application programming interface (API) to provide customer facing CBDC payment services. This model effectively “combines indirect connection to the central bank with direct access to the central bank balance sheet and the CBDCs.” (Prates, 2020)

Overarching Multi-Tier Model Considerations

The multi-tier CBDC ecosystem should be designed to create economic incentives for PSPs to participate in ways that serve central bank interests (making the CBDC broadly available to the public, across regions, etc.). There should be a cost-effective business model for such PSPs with enough revenues from interest spreads, fees, and cross-subsidization, as well as controllable fixed and variable costs. Also, regulations should leave room for enough users to reach critical mass and incentivize network buildup while promoting PSP market competition.

For example, regulations that encourage interoperability of competing payment systems to encourage new entrants and reduce concentration risk should take care not to adversely impact network build-up. (For a new PSP, interoperability across PSPs could diminish the incentive of a startup to innovate since it could lower the value of a privately developed network. It could also restrict competition by excluding certain technical innovations or restricting new business models and reduce the value and increase the costs to PSPs. In addition, interoperability might increase overall risks if an innovative service provider has a higher risk profile.)

Retail Central Bank Digital Currency (CBDC) Technical Platform Criteria

Central banks that have made the decision to explore retail central bank digital currency (CBDC) issuance are focusing on a common set of key design choices. These include the operating model, the technology platform (centralized versus decentralized database technology, or token-based), degree of anonymity/privacy, availability/limitations, and whether to pay interest. These design decisions are driven by country-specific factors and balance the need to achieve the policy objectives that launched the exploration process and be attractive to users and merchants. (For more detail on these factors and considerations see the 2020 IMF working paper on CBDC operational considerations.)

In this blog I want to talk about the technology platform decision, broadly speaking breaking down into those with centralized or decentralized ledger architectures, and ledger-less offline peer-to-peer stored value platforms. In a traditional centralized ledger (client-server model with no distributed components) transaction processing would entail the payor connecting to the central ledger keeper and initiating a funds transfer to the recipient’s account. The ledger would be updated after the payor has been confirmed as the account holder who has enough funds to carry out the transaction.

Alternatively, the ledger could be run on a distributed ledger technology (DLT) platform, in which the ledger is replicated and shared across several participants. With a DLT platform the central bank could have a centralized, decentralized or partially-decentralized authority for verifying and/or committing transactions. DLT platforms can be “public” (accessible by anyone) or restricted to a group of selected participants (“consortium” or “private”). Ledger integrity can be managed by a selected group of users (“permissioned”) or by all network participants (“permissionless”).

So far, central banks that have reached the proof of concept (PoC) and pilot stages of CBDC explorations have opted platforms that allow for control over platform access and participants, and role-based oversight and visibility of transactions (see table). Such platforms also ensure that the central bank retains full control over money issuance and monetary policy. They include centralized ledger and DLT private permissioned platforms, and digital bearer instrument platforms. Permissionless (decentralized authority) platforms have tended to fall short on scalability, and settlement finality, and financial integrity risk management.

Digital CurrencyPartner FirmPlatform TechnologyPlatform Type
Bahamas Sand DollarNZIANZIA Cortex DLTDLT private permissioned
China e-CNYn/an/aCentralized ledger
ECCB DCash and
Nigeria eNaira
BittHyperledger FabricDLT private permissioned
Uruguay e-PesoRoberto GioriGSMTCentralized ledger
JamaicaeCurrencyDSC3Digital bearer instrument
Sweden e-KronaAccentureR3 CordaDLT private permissioned
Ukraine E-HryvniaStellarStellarDLT private permissioned
Ecuador dinero electrónicon/aMobile moneyCentralized ledger

It has been generally believed that centralized platforms process transactions more quickly. VISA says their network can handle up to 65,000 transactions per second (TPS), while private DLT platforms have tended to be way slower (e.g., 10,000+ TPS).  There is also the issue of “finality” – the point at which transferred funds become irrevocable. Some networks, like Bitcoin and R3 Corda, offer only what is called “probabilistic finality” which won’t cut it for a retail payment system.

Although all the pros and cons of DLT-based versus centralized ledger-based retail payment systems are out of scope of this post, it’s worth mentioning that DLT-based platforms may offer enhanced resiliency by reducing single points of failure. Also, potential data loss at one node can be recovered through replication of the ledger from other nodes when the network comes back online. But DLT-based platforms may experience attacks against the network layer, which includes the consensus mechanism by which database updates are approved, or smart contract exploits. (For more on such pros and cons, see Raphael Auer and Rainer Böhme’s Technology of Retail Central Bank Digital Currency article)

In the table below, I’ve listed what I believe to be the main players in the retail CBDC platform space. My main criterion for inclusion is that the platform has been used in a CBDC or sovereign digital currency pilot or proof of concept or has published something substantive to back up the claim that it offers a viable CBDC platform. I’ve tried to categorize them by whether they’re ledger- or token-based, and if they’re ledger-based, whether the ledger management is centralized or distributed. My plan is to make this a “live” table, and possibly add more columns based on your comments and suggestions. If you have platform suggestions that I’ve missed, please provide links to written material that supports the claim.

NZIAPlatform used for Bahamas Sand Dollar
HyperLedger FabricPlatform used by Bitt in ECCB DCash and Nigerian eNaira pilots
R3 CordaPlatform used for e-Krona proof of concept and also see R3 landing page
StellarPlatform used for Ukraine E-Hryvnia CBDC proof of concept
Hedera Hashgraphhttps://futuremtech.com/central-bank-digital-cash/
Centralized Ledger: 
Roberto GioriPlatform used in Uruguay e-Peso CBDC pilot
Gnu Talerhttps://www.snb.ch/en/mmr/papers/id/working_paper_2021_03
eCurrency Platform used for Jamaica pilot and also see white paper
G&D FiliaWorking on Ghana’s e-Cedi pilot and Thailand’s CBDC proof of concept.

What Is and Isn’t a *Wholesale* Central Bank Digital Currency?

In a previous post I discussed what is and isn’t a retail central bank digital currency (rCBDC): A broadly available general purpose digital payment instrument, denominated in the jurisdiction’s unit of account, that is a direct liability of the jurisdiction’s monetary authority, and subject to the same rules and regulations as imposed on the jurisdiction’s other units of account. The gist of this is summarized in the following table.

I then went on to describe wholesale central bank digital currency (wCBDC) as being like an rCBDC, but being restricted to wholesale, financial market payments. But some will notice that I never mentioned the technology platform – whether it runs on a centralized or decentralized ledger, or whether there is even a ledger at all (i.e., “token” based). And that’s because discussions around rCBDC are generally agnostic about the platform type. However, it’s my sense that that is not the case for wCBDC.

And that may be because wCBDC is not really anything new. For example, a 2018 IMF staff discussion note characterized central bank reserves as a “wholesale form of CBDC used exclusively for interbank payments” which has been around for ages. And in 2020, ECB legal staff noted that “the issuance by central banks of digital liabilities and the corresponding holding, by third parties, of intangible money claims against the balance sheet of the digital liability-issuing central bank would not represent a genuine novelty.”

And a 2020 paper that surveyed wCBDC research found that “the overarching motivation for CBDC research by CBs is to assess the impact of distributed ledger technology (DLT) on financial market infrastructures (FMIs). Which all implies to me that when people say “wholesale CBDC” they really mean to say is “distributed ledger technology (DLT) based wholesale CBDC. This may be a trivial discussion but when we say “retail CBDC” we encompass all platforms (centralized, distributed and token-based) and as everyone knows I’m a stickler on definitions!

And although I don’t follow wholesale CBDC developments closely, I’ve tabulated below the experiments that have popped up in my Daily Digest. If I’ve missed any, please let me know in the comments! FYI I plan to keep the table updated on my Kiffmeister Chronicles blog. That’s also the best version of the table to use if you want to follow the live links in the “references” section.