Cases for Wholesale CBDCs

In the sweet spot of central banks (unlike retail)

There are over 100 central banks around the world exploring, building and testing central bank digital currencies (CBDCs)¹. Most projects are for retail CBDCs for direct use by consumers, but there is increasing focus on wholesale CBDCs.

Wholesale CBDCs, or wCBDC have great potential in enabling retail payment systems rather than being a retail payment system itself (as with a retail CBDC) and are much more in the sweet-spot of what central banks do.

wCBDCs are still at an early stage, with around 60 central banks experimenting with them. Much of this work appears to be theoretical and shaped from a central bank perspective and for conventional central bank operations. I sense input to this work is missing - from the retail market and from those innovating retail payments who could benefit from a wCBDC.

In this article I outline three uses for wCBDC in enabling retail payment networks and systems, covering:

1.     Custodied funds for d-money with real-time proof of reserves

2.     Custodied funds for e-money

3.     Continuous settlement for retail clearing systems

There are other uses for wCBDC such as for backing stablecoins and facilitating cross-border FX payments which I also touch on below.

Key points on wCBDC design for use by retail payment systems are:

1.     Retail payment systems can settle outside a central bank using a tokenised wCBDC anchored in wCBDC within a central bank. This allows the central bank to achieve control and stability objectives, while giving flexibility to the retail payment system design and operation

2.     wCBDC can be on a blockchain, but there are other suitable technologies such as OLTP databases

3.     There is no need to embed programmability into wCBDC other than programmability (e.g. through an API) that allows other digital forms of money to be anchored rigidly in wCBDC. This anchoring feature is essential to an effective wCBDC. It eliminates backing risk and the need for periodic attestations by third parties to verify backing.

These perspectives are informed by my own work with Fourdotzero, a micropayment network I have co-founded and through my experience working with retail payment systems and payment providers.

If you have comments, suggestions or disagree with the models, please share them.

1.     Custodied funds for d-money with real-time proof of reserves

In this model, consumers and businesses have digital wallets containing digital money, d-money, used to buy and sell goods and services with others who have the same digital wallets. This model is a new way of operating a payments network, with huge global potential. Fourdotzero is designed on this model, but currently is based on normal commercial bank deposits and HQLA (high quality liquid assets such as short term government bonds), which wCBDC could replace.

Using digital technology outside of the bank infrastructure and card networks, these digital wallets are very cheap to operate and versatile in supporting in-person, wallet-to-wallet payments as well as remote payments embedded in digital businesses. They are designed to enable business models in the digital economy, for example very high volume, low value micropayments, AI-driven payments and automated machine-to-machine payments.

d-Money and Tokenised wCBDC

d-Money in digital wallets is backed by tokenised wCBDC which in turn is backed by wCBDC held at a central bank. See Figure 1. By tokenising wCBDC, the d-money network has full flexibility to design how its network operates, independent of the wCBDC but anchored in it.

Figure 1 – d-money backed by tokenised wCBDC backed by wCBDC

At all times, the sum of tokenised wCBDC held by wallet providers equals the amount of wCBDC held by the digital payment network at the central bank. In turn, the sum of d-money held across all a wallet provider’s wallets equals the amount of tokenised wCBDC held by the wallet provider (and the sum of d-money held in all wallets across all wallet providers equals the wCBDC held at the central bank).

In effect, d-money held in a digital wallet is a claim on tokenised wCBDC which is a claim on the wCBDC held at the central bank.

Funding and De-Funding

Wallet holders may fund their digital wallets from their bank accounts and withdraw funds back to them. When funding their digital wallet:

-       The digital wallet holder sends money from their bank account to the network’s client custody bank account

-       Using these funds, the network purchases wCBDC from the central bank, mints the same value of tokenised wCBDC and allocates it to the holder’s wallet provider who issues the same value of d-money to the holder’s wallet.

When withdrawing from a digital wallet to a bank account:

-       The digital wallet holder requests to withdraw from their digital wallet to their bank account

-       The digital wallet provider withdraws the d-money from the digital wallet, the network burns the same amount of tokenised wCBDC, withdraws wCBDC held at the central bank to its bank account and transfers the funds to the holder’s bank account.

Proof of Reserves

The network provider’s systems ensure that the sum of d-money in its wallet providers wallets always equals the sum of tokenised wCBDC, in real-time for every payment made between wallets and for every funding addition and withdrawal.

The central bank needs to provide an API so that the network provider can always check and demonstrate publicly in real-time that its wCBDC reserves equal the sum of tokenised wCBDC in its network. This proof-of-reserves API is a key benefit of the wCBDC.

Considerations

1.     Settlement between wallet providers occurs real-time using tokenised wCBDC for every payment, there is no settlement at the central bank

2.     Use of wCBDC could be replaced by tokenised deposits held at a commercial bank – if so, the commercial bank would need a similar proof-of-reserves API

3.     wCBDC, tokenised wCBDC and d-money can be held on any suitable technology, including blockchain

4.     Since the d-money, tokenised wCBDC and wCBDC are always in lock-step, enforced programmatically and visible to the central bank, there is no risk of loss of customer funds. It is impossible to mint more tokenised wCBDC than wCBDC and to have more d-money in issue than tokenised wCBDC. Consequently, capital requirements on the network provider and wallet providers should be minimal, even eliminated.

5.     A stablecoin could be backed in a similar fashion by wCBDC, but instead of d-money in a digital wallet as shown in Figure 1, the stablecoin would be available for use by consumers and businesses directly as a tokenised wCBDC.

2. Custodied funds for e-money

e-Money is an established business, proven over the past two decades. e-Money issuers are required by regulation to keep customer funds separate from their operational funds and to ensure their issued e-money is matched 1:1 with their customer funds. This 1:1 matching is a point of risk with e-money issuers, managed through regular reporting, auditing and regulator scrutiny.

Without changing the business model or technical architecture of the e-money industry, e-money issuers could park their customer funds at a central bank as wCBDC and use a proof-of-reserves API to improve the management and attestation of customer funds and e-money. See Figure 2.

Alternatively, e-money issuer customer funds could be held as tokenised deposits at a commercial bank with a proof-of-reserves API, instead of as a wCBDC at a central bank.

Figure 2 – e-money backed by wCBDC

3. Continuous settlement for retail clearing systems

Retail clearing systems use typically deferred net settlement using a RTGS at the central bank for banks to settle with each other across their reserve accounts. For example, in the UK the Faster Payments System has three daily settlement cycles during business days – at the end of each cycle, the banks square up with each other and each bank then accrues a net debt or surplus until the next cycle. Since FPS is 24x7, large imbalances can build up between cycles, including overnight and at weekends – especially when there is a bank holiday either side of a weekend and at peak periods. This creates liquidity risk and credit risk, requiring rules, limits, active monitoring and management.

Figure 3 – continuous settlement using wCBDC

A wCBDC could be used to reduce these risks and manage liquidity more efficiently, through continuous settlement, as shown in Figure 3. Each bank holds wCBDC on a shared ledger at the central bank in sufficient quantities to cover any net short positions they anticipate. As clearing proceeds, instead of accumulating debts or surpluses, the wCBDC ledger is updated continuously so that at any moment in time each bank’s wCBDC balance is accurate and up to date. If a bank has surplus wCBDC, they may withdraw the surplus to their reserve account when the RTGS is open, or they may add additional funds to the wCBDC ledger from their reserve account if their wCDBC balance is low or approaching a minimum limit.

wCBDC used in this way eliminates credit risk between banks and reduces liquidity risk. Banks still need to manage their liquidity by funding their wCBDC balance through the RTGS and to forecast and pre-fund liquidity for any periods when the RTGS is shut, but liquidity management is more flexible and efficient.

Additionally, there is no need to have indirect participants in the payments clearing system. Each participant has an account on the wCBDC ledger giving the central bank real-time visibility of all balances. Those participants that wish to, can still use the services of a sponsor bank to manage their liquidity, using the RTGS on their behalf.

This arrangement would improve both deferred net settlement payment systems and gross settlement systems which typically use tiering where large banks handle settlement on behalf of their agency banks. With wCBDC in gross settlement systems, there is no need for tiering, every participant has a wCBDC account giving visibility to the central bank. It would also allow the gross settlement system to operate extended operating hours, possibly without cut-off times, even 24x7, provided sufficient liquidity is pre-funded by each bank.

This concept is the same as an omnibus RTGS account which the Bank of England for example has in operation. However,  rather than an RTGS account, in this model the pooled bank balances are on a separate wCBDC ledger allowing clearing systems to operate independent of the RTGS, creating resilience and flexibility. Additionally, it gives the central bank visibility of all reserve balances of participants in the clearing system.

This use of a wCBDC ledger also allows faster onboarding of participants on a clearing system than onboarding them onto a RTGS. RTGSs are usually integral to monetary policy (setting of rates), thus have code freezes every time monetary policy is likely to change (typically when central bank policy committees meet monthly/bimonthly). They are also essential to the smooth running of wholesale financial transactions and as such, RTGSs are subject to very tight controls, limiting how often new participants can be onboarded and other changes are made. A wCBDC ledger would isolate clearing systems from RTGSs eliminating technical and operational dependencies, including faster onboarding and making it easier to open access to clearing systems to non-bank payment service providers.

If central banks in different countries operated a wCBDC connected to the domestic retail payment system in this way, then it would facilitate innovation in cross-border payments. It would level the playing field for non-bank cross-border payment providers to have easy access to retail payment systems to give them full domestic reach for pay-ins and payouts in each country without being dependent on local banks. 

1. CBDC tracking website: https://cbdctracker.org/