Functional consistency across retail central bank digital currency and commercial bank money

Lee Braine, Shreepad Shukla and Piyush Agarwal

Abstract

Central banks are actively exploring central bank digital currencies (CBDCs) by conducting research, proofs of concept and pilots. However, adoption of a retail CBDC can risk fragmenting both payments markets and retail deposits if the retail CBDC and commercial bank money do not have common operational characteristics. In this paper we focus on a potential UK retail CBDC – the “digital pound” – and the Bank of England’s “platform model”. We first explore how the concept of functional consistency could mitigate the risk of fragmentation. We next identify the common operational characteristics that are required to achieve functional consistency across all forms of regulated retail digital money. We identify four design options based on the provision of these common operational characteristics by the central bank, payment interface providers, technical service providers or a financial market infrastructure. We next identify architecturally significant use cases and select key capabilities that support these use cases and the common operational characteristics. We evaluate the suitability of the design options to provide these key capabilities and draw insights. We conclude that no single design option could provide functional consistency across digital pounds and commercial bank money and, instead, a complete solution would need to combine the suitable design option(s) for each key capability.

Download PDF

Introduction

1 Introduction

A central bank digital currency (CBDC) is a digital payment instrument, denominated in a national unit of account, that is a direct liability of a central bank (Bank for International Settlements 2021). Central banks are actively exploring retail CBDCs (European Central Bank 2023; Reserve Bank of India 2022; Kosse and Mattei 2023; Mu 2023) with various motivations, such as improving financial stability, implementing monetary policy, encouraging financial inclusion, improving (domestic and cross-border) payment efficiency, and enhancing payment safety and robustness (Kosse and Mattei 2023).¹¹ 1 See also the Bank of England’s web page on the digital pound: http://www.bankofengland.co.uk/the-digital-pound.

The Bank of England identified its primary motivations for a potential UK retail CBDC, the “digital pound”, as (Bank of England and HM Treasury 2023)

• •

  sustained access to central bank money as an anchor for confidence and safety in the monetary system, and

• •

  promotion of innovation and choice in domestic payments.

The Bank of England and HM Treasury established the CBDC Taskforce to coordinate the exploration of a potential digital pound, as well as two external engagement groups – the CBDC Engagement Forum and the CBDC Technology Forum – to gather input on nontechnology and technology aspects, respectively, of a potential digital pound.²² 2 See footnote 1. The Bank of England and HM Treasury (2023) consultation paper (CP) sets out their assessment of the case for a digital pound, while the Bank of England (2023) technology working paper (TWP) outlines its emerging thinking on CBDC technology. The Bank of England and HM Treasury have published responses to the CP and to the TWP, based on feedback received (Bank of England and HM Treasury 2024; Bank of England 2024).

The design of a retail CBDC and its underlying system could potentially lead to significant risks, ranging from cybersecurity risks (Bank for International Settlements 2021) to financial stability risks (Bank of Canada et al 2021). In a previous paper (Braine and Shukla 2022), where we focused on the digital pound, we identified the additional risk of fragmentation in payments markets and retail deposits if digital pounds and commercial bank money do not have common operational characteristics, and we presented an illustrative industry architecture intended to mitigate this risk by placing the digital pound and commercial bank money on a similar footing. We subsequently developed prototypes of this industry architecture as part of the Barclays CBDC Hackathon 2022 and Project Rosalind.³³ 3 The Barclays CBDC Hackathon 2022 consisted of a series of coding challenges that explored the future of money, including both the digital pound and commercial bank money. URL: http://www.creativeservices.barclays/ehome/cbdchackathon/. Project Rosalind is a joint experiment on a retail CBDC led by the Bank of England and the Innovation Hub London Centre of the Bank for International Settlements, in collaboration with the private sector. URL: http://www.bis.org/about/bisih/topics/cbdc/rosalind.htm.

In this paper we continue to focus on the digital pound and the risk of fragmentation in payments markets and retail deposits. We first explore the important concept of “functional consistency” (see Section 3) across all forms of regulated retail digital money, including existing forms of money (such as commercial bank deposits and e-money) and new forms of money (such as retail CBDCs, tokenized deposits and regulated stablecoins). Functional consistency requires several common operational characteristics and extends the concept of fungibility so that units of one form of money can be substituted for units of other forms of money (and not just for other units of the same form of money); we believe functional consistency is a desirable principle that could mitigate the risk of fragmentation in retail deposits and payments. We then present design options that are based on the Bank of England’s “platform model” (Bank of England and HM Treasury 2023) and that aim to support functional consistency and interoperability across the digital pound and commercial bank money (see Section 4). We next describe a set of architecturally significant use cases and the key capabilities they require (see Section 5). These key capabilities support some of the common operational characteristics that are needed to achieve functional consistency. We then present our preliminary evaluation of the suitability of the presented design options to support the key capabilities, and we draw some initial insights (see Section 6). Finally, we state our conclusions and identify potential next steps (see Sections 7 and 8).

Our analysis focuses on technical and functional aspects, so further work could include a comprehensive analysis of legal, operational and commercial aspects. Also, while we focus on the digital pound and commercial bank money, the principle of functional consistency and the analysis framework used in this paper should also be applicable to emerging forms of private digital money such as regulated stablecoins (Financial Conduct Authority 2023) and to other currencies.

The contributions of this paper include defining and identifying the significance of functional consistency across all forms of regulated retail digital money, and evaluating the suitability of design options to support functional consistency across the digital pound and commercial bank money. We hope the insights presented in this paper will stimulate discussion, and we look forward to ongoing industry engagement on retail CBDCs in general and the digital pound in particular.

2 The digital pound

In this section we summarize the Bank of England’s motivations, key criteria, platform model, potential functional requirements and design considerations for the digital pound, as described in the CP and the TWP.

The Bank of England’s two primary motivations for the digital pound are described in the CP (Bank of England and HM Treasury 2023, p. 24):

1. (1)

   “To sustain access to UK central bank money – ensuring its role as an anchor for confidence and safety in our monetary system, and to underpin monetary and financial stability and sovereignty”; and

2. (2)

   “To promote innovation, choice, and efficiency in domestic payments as our lifestyles and economy become ever more digital.”

Based on these primary motivations, the Bank of England identified in the CP the following key criteria for the model of provision of the digital pound (p. 51):

• •

  “To ensure that central bank money acts as the anchor of monetary and financial stability, the model should ensure access to financially risk-free central bank money, a direct end-user claim on the Bank [of England] and settlement finality for any transactions.”

• •

  “The model should be interoperable with other forms of money, in particular cash and bank deposits.”

• •

  “To support innovation, choice and efficiency, the model should be extensible and flexible reflecting the fact that the future payments landscape is innovative and dynamic.”

• •

  “The model should ensure a standard of operational resilience necessary for major national infrastructure.”

Figure 1: The Bank of England’s platform model for CBDC provision, comprising a digital pound core ledger, APIs, PIPs, ESIPs and users. Source: adapted from Bank of England and HM Treasury (2023).

The platform model proposed by the Bank of England, which we adopt in this paper (see Figure 1), comprises the Bank of England operating a digital pound core ledger and providing access via application programming interfaces (APIs) to authorized and regulated payment interface providers (PIPs) and external service interface providers (ESIPs) that provide users with access to the digital pound. The digital pound core ledger would record digital pounds issued by the Bank of England and provide the minimum necessary functionality, such as simple payments. The core ledger APIs would allow PIPs and ESIPs to connect to the digital pound core ledger and leverage its functionality to develop and offer innovative services.

In the TWP the Bank of England summarized the potential functionality and features of the digital pound under the following categories (quoted from Bank of England 2023, pp. 17–18):

Payment devices:

Smart devices and physical cards, existing online and in-store point-of-sale infrastructure, Internet of Things devices and wearables.

Wallet management:

Opening a wallet and viewing balances.

Payments:

Real-time one-off push, peer-to-peer, person-to-business (both in-store and online), cross-border, offline, scheduled, micropayments, batch payments (eg, wage) and split payments.

Interoperability:

Moving between CBDC and other forms of money, particularly cash and bank deposits

Economic design:

Ability to implement limits policy.

Identity, data and privacy:

No access to users’ personal data by the Bank [of England], PIPs undertake know your customer (KYC) checks and anti-money laundering (AML) compliance, CBDC would not be anonymous, potential for users to have privacy controls on wallets and potential for tiered wallets based on ID information.

The TWP also describes the design considerations that organize and guide the Bank of England’s work on CBDC technology.

Privacy.

The CBDC system should be designed to protect user privacy, while allowing PIPs and ESIPs the minimum necessary access to transaction data needed to provide CBDC services and to fulfill their legal and regulatory obligations.

Security.

The CBDC system should be secure by design to ensure confidence in money and promote user trust and adoption.

Resilience.

The CBDC system should be resilient to disruption, as disruptions may have far-reaching consequences for user confidence, data integrity and financial stability.

Performance.

The CBDC system should be able to handle a high number of transactions and confirm and settle these transactions as quickly as possible.

Extensibility.

The CBDC system should have an extensible design, allowing PIPs and ESIPs to implement additional functionality without affecting user services.

Energy usage.

The CBDC system should be, at the very least, as energy efficient as existing payment infrastructures and designed in a way that minimizes any impact on the environment.

3 Functional consistency

In this section we explore the concept of functional consistency for regulated retail digital money denominated in a specific national unit of account. This includes retail commercial bank money, e-money and new forms of money (such as retail CBDCs, tokenized deposits and regulated stablecoins) but excludes physical currency notes, wholesale commercial bank money and wholesale central bank money.

Bank of England and HM Treasury (2023, p. 25) defined “uniformity of money” as follows: “all forms of money – both bank deposits and cash – are valued equally (‘at par’ or ‘face value’), denominated in a common currency (sterling) and interchangeable with each other”. The CP states that “the stability of the UK economy and monetary system relies on the uniformity of money” (p. 25). Bailey (2023, p. 3) identified “singleness of money” as one of the important foundations of money and defined it as follows: “Wherever we hold our money – in bank accounts, notes and coins, etc – we can be assured that it all has the same value – the pound in my bank account equals the pound in your account. In other words, money is exchangeable at par value.” Garratt and Shin (2023) identified “singleness of money” as a cornerstone of the modern monetary system. However, neither the uniformity nor the singleness of money, as defined above, include certain operational characteristics of money that are important to users (such as ease of use and compatibility with existing payment infrastructures).

Fungibility means that any unit of a given form of money is substitutable for another (Hull and Sattath 2021); for example, one £10 note can be substituted for two £5 notes, and all pounds held in a commercial bank account are substitutable for each other. However, a different term is needed to express the substitutability of units of one form of money for units of a different form of money.

Recent developments in new forms of digital money, such as retail CBDCs and stablecoins, aim to provide users with novel functionalities, such as programmable payments, that may not be available in existing forms of money. While these novel functionalities could allow users to access innovative capabilities (such as conditional payments), there is a risk that this could lead to fragmentation in retail deposits and payments, and could therefore

• •

  negatively impact consumers (eg, through causing confusion) by requiring them to split their liquidity across various forms of money in order to obtain the unique operational characteristics each of them provides, and

• •

  make it more difficult for institutions to maintain stability and manage risk.

We define functional consistency for money as follows: “Functional consistency is the principle that different forms of money have the same operational characteristics.” We believe functional consistency is a desirable principle for the provision of all forms of retail digital money, including digital pounds and commercial bank money. Functional consistency could mitigate the risk of fragmentation and reduce the negative impacts of fragmentation on consumers, thereby facilitating both consumer and merchant adoption of new forms of retail digital money (including the digital pound). It could also support consumer choice in domestic payments by providing common operational characteristics across all forms of retail digital money. Note that we welcome and encourage the development of novel functionalities that are replicable across all forms of retail digital money.

We now identify common operational characteristics that would ensure functional consistency across all forms of regulated retail digital money. As our starting point we take the list of properties of money identified by Hull and Sattath (2021). We suggest that the following initial set of common operational characteristics are required to achieve functional consistency.

Acceptability:

the probability with which a given form of money is accepted in exchange for goods and services provided (Kiyotaki and Wright 1992).

Inclusivity:

the degree to which users can access and use a given form of money regardless of their demographics, disabilities, lack of access to technology, skills and geographic location.

Divisibility and mergeability:

the ability to divide a given form of money into smaller denominations (eg, to facilitate transactions), and the extent to which units can be merged together (Hull and Sattath 2021).

Ease of use:

the simplicity with which transactions can be conducted with a given form of money (adapted from Hull and Sattath (2021)).

Settlement time:

the time it takes to settle a transaction in a given form of money (Hull and Sattath 2021).

Transaction cost:

the pecuniary cost, in the form of a fee, imposed on the payer and/or payee when performing a transaction using a given form of money (Hull and Sattath 2021).

Reversibility:

the ability provided to a payer and/or payee to reverse a payment conducted using a given form of money, under certain circumstances.

Payment programmability:

the ability of a given form of money to support both automation and streamlining of the payments process – for example, by triggering payments based on specific events or predetermined conditions.

Transferability:

the ability of a given form of money to be transferred from one owner to another (adapted from Hull and Sattath (2021)).

Confidentiality:

the extent to which a given form of money protects users’ personal and transaction data from unauthorized access.

Integrity:

the extent to which the balance and transaction data for a given form of money is accurate, trustworthy, complete and protected from accidental or unauthorized modification.

Availability:

the ability for users to access and use a given form of money regardless of any technical or operational failures.

Identity-based:

the characteristic of requiring users of a given form of money to disclose their identities while conducting transactions (adapted from Hull and Sattath (2021)).

Fungibility:

the substitutability of any unit of a given form of money for another (Hull and Sattath 2021).

Interoperability:

the ability for users to exchange units between two forms of money.⁴⁴ 4 We use the term interoperability as an operational characteristic of a form of money and not as a technical feature describing interaction mechanisms between systems (as it is used, for example, by Bank of Canada et al (2020)).

Payment infrastructure compatibility:

the ability to use a given form of money with existing and new payment infrastructures, such as smart devices, point-of-sale (POS) infrastructure, automated teller machines (ATMs) and payment schemes.

Support for payment types:

the ability of a given form of money to support a variety of payment types, such as real-time, batch, offline, cross-border, pull, split and recurring payments.

Each of the above common operational characteristics can take on a range of values (eg, high acceptability or low transaction cost), but to achieve functional consistency all forms of regulated retail digital money should have similar values for these common operational characteristics.

Note that we have excluded the following four types of properties from the common operational characteristics needed to achieve functional consistency.

1. (1)

   Properties that are not operational characteristics from a user’s perspective, such as “throughput”, “proof of reserves” and “resource efficiency”.

2. (2)

   Properties that do not apply to regulated retail digital money, such as “untraceability”, “tax avoidability” and “scarcity”.

3. (3)

   Properties that are intrinsic to regulated retail digital money, such as “digital”, “portability” and “price stability”.

4. (4)

   Properties that are not appropriate for all forms of money, such as “interest bearing” and “user holding limits”. For example, commercial bank money can be interest bearing but it is unlikely that digital pounds will be interest bearing. Also, digital pounds may initially have user holding limits, but commercial bank money does not.

Note that, while we believe functional consistency is a desirable principle for the provision of all forms of retail digital money, not all forms of existing private digital money have the same common operational characteristics. This lack of common operational characteristics may cause fragmentation and potentially negatively impact consumers, which illustrates the importance of functional consistency for any new form of public digital money.

4 Design options to support functional consistency

In our previous paper (Braine and Shukla 2022) we presented an illustrative industry architecture that aims to place the digital pound and commercial bank money on a similar footing. We now present design options that could provide the common operational characteristics that are required to achieve functional consistency across the digital pound and commercial bank money. These design options are based on both existing payment ecosystem designs and the Bank of England’s platform model (summarized in Section 2).

4.1 Existing designs

In existing payment ecosystems some of the common operational characteristics (such as payment programmability, interoperability and payment infrastructure compatibility) are delivered using the following design options.

By the entity operating the ledger.

For example, commercial banks provide users with the ability to open accounts and operate them through various channels.

By intermediaries providing end-user access.

For example, in Open Banking,⁵⁵ 5 The UK Open Banking service allows financial data and services to be shared between banks and third-party service providers securely through the use of APIs to enable consumers and businesses to move, manage and make more of their money. URL: http://www.openbanking.org.uk/what-is-open-banking/. payment initiation service providers provide payment initiation services to end users with payment accounts held at other payment service providers.

By partners of the intermediaries providing end-user access.

For example, in card schemes, fintech firms use the services of partner banks for card issuance and transaction processing.

By common technical service providers (TSPs).

For example, in the UK domestic payment schemes, commercial banks use a common TSP to integrate with the confirmation of payee services provided by other commercial banks.⁶⁶ 6 A TSP provides technical services such as communication, technical onboarding and information processing/storage to support authorized financial services providers. It does not have a direct relationship with or provide services to end users. (Description adapted from the Financial Conduct Authority’s “AISP models under PSD2” web page. URL: http://www.fca.org.uk/firms/agency-models-under-psd2.) Another example is the Swift financial messaging system,⁷⁷ 7 URL: http://www.swift.com/our-solutions. which provides a common technical service to facilitate communication between financial institutions.

By financial market infrastructures (FMIs).

⁸⁸ 8 An FMI is a multilateral system among participating institutions, including the operator of the system, used for clearing, settling or recording payments, securities, derivatives or other financial transactions (Committee on Payment and Settlement Systems 2012).

For example, in the United Kingdom, the Faster Payments System (FPS) provides a central infrastructure that is used by participant banks to perform clearing and settlement of instant payments.⁹⁹ 9 URL: http://www.wearepay.uk/what-we-do/payment-systems/faster-payment-system/.

4.2 Design options

The design options that could provide the common operational characteristics required to achieve functional consistency are presented in Figure 2.

Figure 2: Design options that could provide the common operational characteristics required to achieve functional consistency across the digital pound and commercial bank money.

Note that no single design option could, by itself, provide functional consistency across all forms of regulated retail digital money. In Section 6.3 we analyze how a number of design options could, collectively, provide functional consistency. The design options are summarized below.

Option 1. Provided by central bank.

Common operational characteristics are provided by the central bank operating the ledger (eg, the Bank of England).

Option 2. Provided by PIPs.

Common operational characteristics are provided by each PIP/ESIP, optionally by leveraging the services of partner financial institutions, such as commercial banks.

Option 3. Provided by TSPs.

Common operational characteristics are provided by leveraging services of TSPs.

Option 4. Provided by FMI.

Common operational characteristics are provided by an FMI. Note that an FMI could also provide technical services, but we cover such situations under option 3 instead.

5 Architecturally significant use cases and key capabilities

To evaluate the suitability of the design options, we now present some architecturally significant use cases and the key capabilities that support them. Note that we focus on the digital pound and commercial bank money in our use cases, and we do not elaborate some of the use cases for commercial bank money (such as opening an account) as they have established solutions.

5.1 User personas, use cases and supporting capabilities

We identify for the digital pound two user personas with differing demographics, abilities and motivations.

Laura.

Laura is a 20-year-old college student and a digital native. She primarily uses her smartphone and her laptop for all her financial needs, with occasional use of ATMs for a few cash transactions. She has an existing commercial bank account.

Bob.

Bob is a 70-year-old pensioner who relies on his bank branch and ATMs for his financial needs. He is not comfortable with using smartphones and websites for conducting financial transactions, due to a lack of internet access.

Laura and Bob’s customer journeys are presented in Table 1, along with the architecturally significant use cases and capabilities that support them. Note that some of the use cases have been adapted from challenges posed in the Barclays CBDC Hackathon 2022 (Barclays 2022) and from Barclays’ prototype of a novel use case of “payment on physical delivery” developed as part of Project Rosalind (BIS Innovation Hub and Bank of England 2023).

Table 1: Customer journeys of two user personas and the architecturally significant use cases and capabilities that support the user journeys.

(a) Laura’s customer journey
Use case		Supporting capabilities
(1)	Create a new digital pound wallet using a mobile app provided by a PIP	•  Completion of KYC checks  •  Wallet creation (create, set authentication, etc)  •  Alias management (selection/assignment of alias)  •  Setup of user holding limits across PIPs
(2)	Fund a digital pound wallet from a commercial bank account using the app	•  Integration of the app with Open Banking to initiate funding payments (eg, using FPS)  •  Interoperability between commercial bank money and digital pounds, including transfer of  •  confidential payment information  •  Enforcement of user holding limits
(3)	Order a product from online merchant, and on delivery, make a payment to merchant’s commercial bank account using a digital pound alias	•  Integration of merchant payment gateways with the digital pound ecosystem  •  Digital pound alias validation (initiated by merchant or payment gateway)  •  Programmable payments using digital pounds (lock funds at purchase and pay on delivery)  •  Interoperability between digital pounds and commercial bank money (eg, using FPS), including  •  transfer of confidential payment information between the merchant’s payment gateway and  •  Laura’s PIP
(4)	Order a product from online merchant and pay on delivery from Laura’s commercial bank account to merchant’s commercial bank account	•  Merchant payment gateway integration with Open Banking  •  Programmable payments using commercial bank money (lock funds at purchase and pay on  •  delivery)  •  Transferral of funds between commercial bank accounts (eg, using FPS), including transfer of  •  confidential payment information between the merchant’s payment gateway and Laura’s bank
(b) Bob’s customer journey
Use case		Supporting capabilities
(1)	Create a new digital pound wallet at a point-of-presence (eg, post office) and collect a physical smart card	•  Completion of KYC checks  •  Wallet creation (create, set authentication, etc)  •  Integration with card schemes (smart card issuance)  •  Alias management (linking card number to digital pound wallet)  •  Setup of user holding limits across PIPs
(2)	Deposit physical cash in a digital pound wallet at a point-of-presence (manual/automated) using the smart card	•  Integration with card schemes (card validation and user authentication)  •  Physical cash acceptance and verification  •  Integration with card schemes (transaction clearing and settlement for payment from the point-  •  of-presence operator’s commercial bank account to Bob’s digital pound wallet, including  •  transfer of confidential payment information)  •  Enforcement of user holding limits
(3)	Buy a product from local store and pay to merchant’s digital pound wallet using the smart card (linked to Bob’s digital pound wallet)	•  Integration with card schemes (card validation, user authentication and debit authorization)  •  Integration with card schemes (transaction clearing and settlement for payment from one  •  digital pound wallet to another, including transfer of confidential payment information)  •  Enforcement of holding limits for merchants, if applicable
(4)	Withdraw physical cash at an ATM using the smart card (linked to Bob’s digital pound wallet) in order to pay in cash at a farmer’s market	•  Integration with ATM network schemes (card validation, user authentication and debit  •  authorization)  •  Integration with ATM network schemes (transaction clearing and settlement for payment from  •  Bob’s digital pound wallet to the ATM operator’s commercial bank account, including transfer of  •  confidential payment information)  •  Physical cash disbursement

5.2 Key capabilities

We now select a subset of key capabilities (from the supporting capabilities presented in Table 1) that will be used to evaluate the suitability of the design options (presented in Section 4.2). We exclude setting and enforcing user holding limits because these capabilities support operational characteristics that are not appropriate for all forms of money and that are therefore not required for functional consistency. We also exclude other supporting capabilities (such as wallet creation, integrating apps with Open Banking, funds transfer between commercial bank accounts, smart card issuance, and physical cash acceptance and disbursement) because they have established solutions.

These key capabilities support some of the common operational characteristics (presented in Section 3) that are needed to achieve functional consistency, such as acceptability, inclusivity, ease of use, reversibility, payment programmability, transferability, confidentiality, interoperability, payment infrastructure compatibility and support for various payment types. Table 2 lists the key capabilities selected, with their motivations and the common operational characteristics they support.

Table 2: Key capabilities, with their motivations and the common operational characteristics they support. [${ }^{\text{a}}$Article 4(1) of the UK General Data Protection Regulation 2016 includes names, identification numbers and location data as examples of personal data (UK Government 2023). Of these, the names and addresses of payers and payees are mandatory fields in some payment message formats, such as the Clearing House Automated Payment System (CHAPS) pacs.008.001.08 (single customer credit transfer) format (Bank of England 2022).]

Motivation	Key capability	Operational characteristics
The digital pound model described in the CP states that PIPs/ESIPs would be responsible for recording the identity of digital pound users and carrying out necessary KYC checks	C1. Completing necessary KYC checks: the capability for PIPs/ESIPs to perform KYC checks, either by themselves or by leveraging certified digital identity service providers, such as OneID, Onfido and Experian (UK Goverment 2022)	•Supports identity-based access
The digital pound model described in the CP states that the Bank of England, as operator of the CBDC system, would not have access to personal data of users (note that most retail payment instructions contain both personally identifiable information (PII), such as names and addresses,${ }^{\text{a}}$ and confidential information, such as purpose of payment)	C2. Transferring confidential payment information between PIPs: the capability to transfer PII and confidential information for a digital pound payment from the payer to the payee, without it being accessible to the Bank of England	•Protects user confidentiality
The TWP envisages the use of a range of different aliases that could be used to route transactions between users, conceal identifiers of digital pound wallets on the core ledger and enable interoperability with existing payment infrastructures	C3. Alias management for digital pound wallets: the capability to generate, store, look up and validate aliases for digital pound wallets, including user-selected aliases (eg, mobile numbers) and assigned aliases (eg, card numbers)	•Protects user confidentiality•Supports ease of use for payment initiation•Supports interoperability with existing payments systems
The CP identifies interoperability with bank deposits as one of the key criteria for the digital pound model	C4. Interoperability with commercial bank money: the capability to transfer value between digital pound wallets and commercial bank accounts, including the transfer of confidential payment information and settlement finality	•Improves acceptability with people/merchants who do not have digital pound wallets•Supports transferability and interoperability•Supports payment infrastructure compatibility
The CP states that programmability could support innovation through improved functionality for users	C5. Programmable payments: the capability to both automate and streamline the payments process – for example, by triggering payments based on specific events or predetermined conditions (eg, users can lock funds at purchase and draw down the locked funds and pay the merchant on delivery)	•Supports payment programmability across all forms of money•Improves ease of use and integrity by automating payments•Supports recurring and split payment types•Supports automated rules-based reversibility
The TWP lists person-to-business payments using existing online and in-store POS infrastructure as potential functionality of the digital pound	C6. Integrating merchant payment gateways: the capability to integrate payment gateways used by merchants with the digital pound ecosystem; this includes initiating payments using digital pound aliases, validating aliases, requesting payment, and settling funds between digital pound wallets and commercial bank money (including transfer of confidential payment information)	•Improves ease of use and acceptability at merchants•Supports transferability and interoperability•Supports payment infrastructure compatibility
The TWP identifies smart cards as potential payment devices for the digital pound that could be used at existing online and in-store POS infrastructure; not all existing POS infrastructure may be upgraded to integrate directly with the digital pound ecosystem, so payments via card schemes would need to be supported	C7. Integrating with card schemes: the capability to integrate with card schemes (eg, Visa and Mastercard) to perform smart card validation, user authentication, debit authorization, clearing and settlement across digital pounds and commercial bank money (including transfer of confidential payment information)	•Improves ease of use and acceptability at merchants•Improves inclusivity using physical smart cards•Leverages card schemes for reversibility, transferability and interoperability•Supports payment infrastructure compatibility and various payment types
The CP identifies interoperability between digital pounds and physical cash as a key feature of a digital pound model; not all existing ATMs may be upgraded to integrate directly with the digital pound ecosystem, so transactions via ATM network schemes would need to be supported	C8. Integrating with ATM network schemes: the capability to integrate with ATM network schemes (eg, LINK) to support cash withdrawal, cash deposits and, potentially, other features such as balance checks, transfers and mini statements (including the transfer of confidential payment information)	•Supports interoperability with physical cash•Improves inclusivity and ease of use for users who need physical cash•Supports payment infrastructure compatibility

6 Evaluation of design options

We now evaluate the suitability of the design options (presented in Section 4.2) to provide the key capabilities (identified in Section 5.2). We describe the assumptions that underpin our evaluation, define a suitability rating model, evaluate the design options against the key capabilities, and draw some initial insights.

6.1 Assumptions

The following assumptions are made while evaluating the design options.

Alias management.

• •

  Any given alias (such as a user’s mobile number) would be mapped to a single digital pound wallet and not reused across multiple wallets.

• •

  Alias look-up and validation services would be accessible to PIPs, ESIPs and other participants of the digital pound ecosystem.

Interoperability between digital pounds and commercial bank money.

• •

  The FPS would be used to transfer funds between digital pound wallets and commercial bank accounts, as it provides immediate clearing for low-value payments.¹⁰¹⁰ 10 The future UK New Payments Architecture may provide interoperability between digital pounds and commercial bank money. URL: http://www.wearepay.uk/npa/about-the-npa/. However, the FPS would only use settlement accounts at the Bank of England to perform settlement and would not provide settlement directly on the digital pound core ledger.

• •

  The Bank of England would integrate the new digital pound core ledger with its existing reserve/settlement account ledger to enable fund transfers between them. However, the digital pound core ledger would not be directly integrated with commercial bank ledgers for funding or defunding.

Issuing smart cards linked to digital pound wallets.

• •

  The Bank of England would not get involved in issuing smart cards to digital pound users (eg, assigning common bank identification number¹¹¹¹ 11 Bank identification numbers are the first six digits of a bank card number or payment card number (specified in standard ISO/IEC 7812 of the International Organization for Standardization and International Electrotechnical Commission) used in credit cards, debit cards, stored-value cards, etc, to identify the card brand, the issuing institution or bank, the country of issuance, the card type and the category of the card. ranges across PIPs).

Support for existing payment infrastructures.

• •

  Merchants would use existing online and in-store POS infrastructure to accept digital pound payments from users. However, not all POS infrastructure would be upgraded to integrate directly with the digital pound ecosystem, so existing means of payment (eg, using cards or Open Banking) would need to be supported.

• •

  Users would be able to withdraw cash from their digital pound wallets using existing ATMs. However, not all ATMs would be upgraded to integrate directly with the digital pound ecosystem, so existing means of operation (eg, using cards and ATM network schemes) would need to be supported.

• •

  Merchant acquirers¹²¹² 12 Merchants partner with financial institutions that provide payment gateway, payment processor and merchant accounts, thereby allowing end-to-end processing and settlement of card transactions. In this paper we refer to these financial institutions as merchant acquirers. would be participants of UK payment systems. However, not all merchant acquirers would be PIPs because some merchant acquirers may not wish to take on all the responsibilities of a PIP.

6.2 Suitability ratings

We now define suitability ratings (“suitable”, “partially suitable” or “unsuitable”) that will subsequently be used to assess each design option against each key capability.

Suitable.

The design option could provide the key capability in alignment with the Bank of England’s key criteria, requirements and technology design considerations.

Partially suitable.

The design option could provide the key capability either in partial alignment with the Bank of England’s key criteria, requirements and technology design considerations or by introducing additional complexity, risk or cost in comparison with other design options.

Unsuitable.

The design option could provide the key capability but in conflict with the Bank of England’s key criteria, requirements and technology design considerations, or by introducing substantial additional complexity, risk or cost in comparison with other design options.

6.3 Analysis

Figure 3: Summary of preliminary evaluation of each design option’s suitability to provide each key capability. These design options are for provision of key capabilities by the central bank, PIPs, TSPs or an FMI. Note that, for some key capabilities, there is no single design option that is suitable and, instead, a combination of design options may be suitable.

This section includes a summary of our preliminary evaluation of each design option’s suitability for providing each key capability (in Figure 3), the preliminary evaluation itself (in Table 3) and some initial insights.

Table 3: Preliminary evaluation of each design option’s suitability to provide each key capability. [${ }^{\text{a}}$It is currently unclear whether novel privacy-enhancing technologies could allow a CBDC system operated by a central bank, as per the platform model, to support alias management without a risk of compromising user privacy in future. ${ }^{\text{b}}$If the CBDC system integrated directly with payment systems (without processing PII), the payment systems would need to be enhanced to support encrypted fields in messages and a participant key exchange mechanism that supports field encryption. ${ }^{\text{c}}$Some programmability use cases (eg, the “pay on delivery” cases in Table 1) require locking functionality to earmark funds. In this paper we assume locking functionality would be provided for each form of money by either the ledger systems via APIs or the programmability layer. ${ }^{\text{d}}$If the CBDC system integrated directly with card schemes (without processing PII), the card schemes would need to be enhanced to support encrypted fields in messages and a member key exchange mechanism that supports field encryption.]

	Option 1.	Option 2.	Option 3.	Option 4.
Capability	Provided by central bank	Provided by PIPs	Provided by TSPs	Provided by FMI
C1. Completing necessary KYC checks	Unsuitable. KYC capabilities (eg, integrating with identity providers) could be provided to PIPs/ESIPs by the CBDC system operated by the Bank of England. However, this could result in users’ PII being available to the Bank of England.	Suitable. Each PIP/ESIP could either perform KYC checks by itself or integrate with one or more digital identity service providers.	Suitable. Each PIP/ESIP could either perform KYC checks by itself or integrate with one or more digital identity service providers. In addition, TSPs could simplify the onboarding and integration of PIPs/ESIPs with multiple digital identity service providers.	Partially suitable. Supporting KYC checks and integrating PIPs/ESIPs with identity service providers falls outside the typical scope of an FMI.
C2. Transferring confidential payment information between PIPs	Partially suitable. Core ledger APIs could support encrypted payment information that is only visible to payers, payees and their respective PIPs, including APIs for secure distribution of encryption keys between PIPs. However, if keys are compromised, confidential payment information could become accessible to the central bank.	Unsuitable. Each PIP could onboard and integrate with all other PIPs in order to transfer payment information on a separate peer-to-peer channel; this requires all existing PIPs to onboard and integrate with every new PIP.	Suitable. TSPs could simplify the onboarding and integration of PIPs and enable PIPs to share confidential payment information on a separate peer-to-peer channel.	Partially suitable. Digital pound payments would be cleared and settled using the core ledger APIs; transferring confidential payment information between PIPs for such payments falls outside the typical scope of an FMI.
C3. Alias management for digital pound wallets	Unsuitable.${ }^{\text{a}}$ Aliases could be stored in the CBDC system operated by the Bank of England using a protection method (eg, a one-way hash function). However, this could allow the Bank of England to identify the user of a digital pound wallet from a known alias (eg, a mobile number).	Partially suitable. Each PIP could manage and store the aliases (which include a PIP identifier) of its users, and give access to other PIPs to look up and validate aliases on a separate peer-to-peer channel; this requires all existing PIPs to onboard and integrate with every new PIP.	Partially suitable. Each PIP could manage and store the aliases (which include a PIP identifier) of its users, and give access to other PIPs to look up and validate aliases on a separate peer-to-peer channel. TSPs would simplify the registration and integration of PIPs.	Partially suitable. PIPs could use an FMI service to protect aliases (eg, a one-way hashing function or mapping table) and, potentially, to map protected aliases to digital pound wallets. However, providing this service falls outside the typical scope of an FMI.
C4. Interoperability with commercial bank money	Unsuitable. Integrating the CBDC system operated by the Bank of England directly with existing payments systems could require the CBDC system to process PII (eg, payer and payee details) contained in the message formats of most payment systems.${ }^{\text{b}}$	Partially suitable. In order to settle payments between digital pounds and commercial bank money, each PIP could either be a direct participant of UK payment systems or an indirect participant via a financial institution that is also a PIP; PIPs that are not existing participants may incur higher costs.	Unsuitable. TSPs would not be direct participants of UK payment systems. Each PIP would integrate with its direct participant in the UK payment systems; introducing a TSP into this integration would increase complexity.	Suitable. An FMI could be a participant of UK payments systems and hold a technical settlement account on both the Bank of England settlement ledger and the digital pound core ledger; the FMI could then clear and settle payments between digital pounds and commercial bank money.
C5. Programmable payments${ }^{\text{c}}$	Partially suitable. A full programmability infrastructure in the CBDC system would not align with the platform model principle that the core ledger should provide the minimum necessary functionality. Also, this may result in functionally inconsistent programmability across all forms of money.	Partially suitable. A separate programmability infrastructure at each PIP would require each PIP to bear the cost and complexity of operating the infrastructure. Also, this may result in functionally inconsistent programmability across PIPs and across other forms of money.	Unsuitable. Providing a programmability layer falls outside the scope of TSPs as it involves automating payments based on events and conditions and, potentially, integrating with payment systems.	Suitable. An FMI could provide a common programmability layer that integrates with all relevant ledgers (eg, the digital pound core ledger and commercial banks’ ledgers) and payment systems, thereby enabling programmability that is functionally consistent across all forms of money.
C6. Integrating merchant payment gateways	Unsuitable. Merchant acquirers would need access to the core ledger APIs for payment processing, but not all of them would be PIPs/ESIPs. In addition, this option is unsuitable for alias validation and interoperability with commercial bank money (see rows C3 and C4).	Partially suitable. Merchant acquirers would need to integrate with every PIP in order to validate aliases and process payments. However, this option is not fully suitable for alias validation and interoperability with commercial bank money (see rows C3 and C4).	Partially suitable. TSPs could simplify the integration of merchant acquirers with PIPs in order to validate aliases and process payments. However, this option is unsuitable for interoperability with commercial bank money (see row C4).	Suitable. An FMI could simplify the integration of merchant acquirers with PIPs in order to validate aliases and process payments. In addition, this option is suitable for interoperability with commercial bank money (see rows C3 and C4).
C7. Integrating with card schemes	Unsuitable. Integrating the CBDC system operated by the Bank of England directly with card schemes could require the CBDC system to process PII (eg, card numbers and card holder names) contained in card scheme messages.${ }^{\text{d}}$	Partially suitable. PIPs would either be principal issuing members of card schemes or partner with such scheme members; they would use core ledger APIs to process transactions and would interoperate with commercial bank money for settlement (see row C4).	Unsuitable. TSPs would not be card scheme members and are unsuitable for providing interoperability with commercial bank money (see row C4). Also, introducing a TSP between a PIP and its principal issuing member would increase complexity.	Partially suitable. Becoming a card scheme member falls outside the typical scope of an FMI. An FMI could support card transaction settlements between digital pounds and commercial bank money (see row C4), with minimal change to card schemes.
C8. Integrating with ATM network schemes	Unsuitable. Integrating the CBDC system operated by the Bank of England directly with ATM network schemes would require the CBDC system to process PII (eg, card numbers and card holder names) contained in ATM network scheme messages.	Partially suitable. PIPs would either be members of ATM network schemes or partner with existing members; they would use core ledger APIs to process transactions and would interoperate with commercial bank money for settlement (see row C4).	Unsuitable. TSPs would not be ATM network scheme members and are unsuitable for providing interoperability with commercial bank money (see row C4). Also, introducing a TSP between a PIP and its ATM network partner would increase complexity.	Partially suitable. Becoming an ATM network scheme member falls outside the typical scope of an FMI. An FMI could support ATM transaction settlement between digital pounds and commercial bank money (see row C4), with minimal change to ATM network schemes.

We draw the following initial insights (from Figure 3 and Table 3) regarding achieving functional consistency via the various design options.

• •

  Each design option’s suitability for providing key capabilities by itself is summarized below.

  Option 1. Provided by central bank.

  Although the CBDC system operated by the Bank of England would provide foundational capabilities (such as payments between digital pound wallets) as per the platform model, it could be unsuitable or only partially suitable for providing the key capabilities identified in this paper. This is primarily because providing some of the key capabilities could result in users’ PII becoming accessible to the Bank of England, which could potentially conflict with the Bank of England’s privacy requirements and technology design considerations for the digital pound (as described in the TWP).

  Option 2. Provided by PIPs.

  PIPs could be suitable for providing some of the key capabilities (eg, completing necessary KYC checks). Some PIPs may need to partner with existing financial institutions to provide certain capabilities (eg, card issuance and transaction processing), but they may incur higher costs as a result.

  Option 3. Provided by TSPs.

  TSPs could be suitable for facilitating confidential transfer of payment information between PIPs, particularly if the information is sent via direct peer-to-peer channels between PIPs, with the TSPs merely simplifying onboarding and integration between PIPs.

  Option 4. Provided by FMI.

  An FMI may be the most suitable option for providing certain key capabilities (eg, interoperability and programmability). This is primarily because a regulated FMI can handle PII, become a member of payment schemes and provide common ecosystem services across both the digital pound and commercial bank money.

• •

  For certain key capabilities, there is no single design option that is suitable and, instead, a combination of design options may be suitable.

  • –

    PIPs and TSPs, working together, could be suitable for providing certain key capabilities such as alias management (with PIPs managing aliases and TSPs simplifying access for ecosystem participants that need to look up and validate aliases).

  • –

    PIPs and an FMI, working together, could be suitable for providing certain key capabilities such as integrating with card schemes and ATM network schemes (with PIPs handling scheme membership and transaction processing and the FMI providing interoperability between digital pounds and commercial bank money).

• •

  Common ecosystem services provided by TSPs and an FMI may be needed to enable most of the key capabilities. The TSPs and the FMI could also provide these key capabilities in a functionally consistent manner across all forms of retail digital money.

7 Summary and conclusions

In this paper we focused on a potential UK retail CBDC (the digital pound), the Bank of England’s platform model and the risk of fragmentation in payments markets and retail deposits if digital pounds and commercial bank money do not have common operational characteristics. We explored the important concept of functional consistency as a means to mitigate the risk of fragmentation, and we evaluated design options to support functional consistency across digital pounds and commercial bank money. Our exploration included

• •

  defining functional consistency for money and identifying the common operational characteristics required to achieve functional consistency across all forms of regulated retail digital money;

• •

  presenting design options (based on the provision of these common operational characteristics by the central bank, PIPs, TSPs or an FMI) to support functional consistency across digital pounds and commercial bank money;

• •

  identifying architecturally significant use cases (based on two illustrative user journeys);

• •

  selecting the key capabilities for the architecturally significant use cases and identifying the common operational characteristics that the key capabilities support;

• •

  presenting a preliminary evaluation of the suitability of the design options to provide the key capabilities; and

• •

  drawing initial insights from the preliminary evaluation.

Our key contribution to the design space for the digital pound is the insight that no single design option could provide all the key capabilities needed for functional consistency across the digital pound and commercial bank money. Instead, a complete solution would need to combine the suitable design option(s) for delivering each key capability. This will, therefore, be a complex design exercise requiring further analysis and experimentation.

8 Further work

Ongoing industry collaboration is needed to address the risk of fragmentation in retail deposits and payments, including evaluating the importance of functional consistency across digital pounds and commercial bank money as a means to mitigate the fragmentation risk.

The analysis framework and common operational characteristics in this paper could potentially be used to extend functional consistency to emerging forms of private digital money such as tokenized deposits and regulated stablecoins, and to explore functional consistency for other currencies. This could include identifying appropriate architecturally significant use cases, design options and key capabilities, and evaluating the suitability of each design option to provide each key capability.

The next steps to validate our initial insights could also include elaborating an industry architecture with common ecosystem services provided by an FMI and TSPs, building prototypes, and analyzing legal, operational and commercial considerations. For example, the UK Regulated Liability Network’s experimentation phase includes a common “platform for innovation” to explore functional consistency across digital pounds and commercial bank money (UK Finance 2023).

We also welcome and encourage the development of novel functionalities that are replicable across all forms of regulated retail digital money. We hope this design paper will inspire industry collaboration on functional consistency during the design phase of the digital pound, and we look forward to feedback.

Declaration of interest

The authors report no conflicts of interest. The authors alone are responsible for the content and writing of the paper.

Acknowledgements

We thank Dincer Ay (Barclays) and Michael Forrest (Barclays) for helpful input on merchant gateways, card schemes, digital identity and Open Banking.

References

• Bailey, A. (2023). New prospects for money. Speech at the Financial and Professional Services Dinner, July 10. URL: http://www.bankofengland.co.uk/-/media/boe/files/speech/2023/july/new-prospects-for-money-speech-by-andrew-bailey.
• Bank for International Settlements (2021). CBDCs: an opportunity for the monetary system. In BIS Annual Economic Report, Chapter 3, pp. 65–95. BIS, Basel. URL: http://www.bis.org/publ/arpdf/ar2021e3.pdf.
• Bank of Canada, European Central Bank, Bank of Japan, Sveriges Riksbank, Swiss National Bank, Bank of England, Board of Governors of the Federal Reserve and Bank for International Settlements (2020). Central bank digital currencies: foundational principles and core features. Report, October, BIS, Basel. URL: http://www.bis.org/publ/othp33.pdf.
• Bank of Canada, European Central Bank, Bank of Japan, Sveriges Riksbank, Swiss National Bank, Bank of England, Board of Governors of the Federal Reserve and Bank for International Settlements (2021). Central bank digital currencies: financial stability implications. Report, September, BIS, Basel. URL: http://www.bis.org/publ/othp42_fin_stab.pdf.
• Bank of England (2022). CHAPS pacs.008.001.08 (single customer credit transfer) usage guideline. BoE, London.
• Bank of England (2023). The digital pound: technology working paper. February, BoE. URL: https://bit.ly/41a6nqL.
• Bank of England (2024). Response to the digital pound technology working paper. Response Document, February, BoE. URL: https://bit.ly/4idjWM0.
• Bank of England and HM Treasury (2023). The digital pound: a new form of money for households and businesses? Consultation Paper, February, BoE and HMT. URL: https://bit.ly/3Z9rpDo.
• Bank of England and HM Treasury (2024). Response to the Bank of England and HM Treasury consultation paper: the digital pound – a new form of money for households and businesses? Response Document, January, BoE and HMT. URL: https://bit.ly/4g4syTi.
• Barclays (2022). Barclays CBDC hackathon 2022 challenges, version 1.0. Technical Document, September, Barclays. URL: https://eu-admin.eventscloud.com/docs/200007927/CBDC-Challenges.pdf.
• BIS Innovation Hub and Bank of England (2023). Project Rosalind: building API prototypes for retail CBDC ecosystem innovation. Report, June, BIS Innovation Hub and BoE. URL: http://www.bis.org/publ/othp69.pdf.
• Braine, L., and Shukla, S. (2022). Illustrative industry architecture to mitigate potential fragmentation across a central bank digital currency and commercial bank money. The Journal of Financial Market Infrastructures 10(4), 55–63 (https://doi.org/10.21314/jfmi.2023.003).
• Committee on Payment and Settlement Systems (2012). Principles for financial market infrastructures. Report, April, Bank for International Settlements and International Organization of Securities Commissions, Basel. URL: http://www.bis.org/cpmi/publ/d101a.pdf.
• European Central Bank (2023). A stocktake on the digital euro. Summary Report, October, ECB. URL: http://www.ecb.europa.eu/euro/digital_euro/progress/shared/pdf/ecb.dedocs231018.en.pdf.
• Financial Conduct Authority (2023). Regulating cryptoassets phase 1: stablecoins. Discussion Paper DP23/4, FCA. URL: http://www.fca.org.uk/publication/discussion/dp23-4.pdf.
• Garratt, R., and Shin, H. S. (2023). Stablecoins versus tokenised deposits: implications for the singleness of money. BIS Bulletin 73, Bank for International Settlements, Basel. URL: http://www.bis.org/publ/bisbull73.pdf.
• Hull, I., and Sattath, O. (2021). Revisiting the properties of money. Working Paper 406, Sveriges Riksbank, Stockholm. URL: http://www.riksbank.se/globalassets/media/rapporter/working-papers/2021/no.-406-revisiting-the-properties-of-money.pdf.
• Kiyotaki, N., and Wright, R. (1992). Acceptability, means of payment, and media of exchange. Quarterly Review 16(3), 18–21. Federal Reserve Bank of Minneapolis (https://doi.org/10.21034/qr.1632).
• Kosse, A., and Mattei, I. (2023). Making headway: results of the 2022 BIS survey on central bank digital currencies and crypto. BIS Paper 136, Bank for International Settlements, Basel. URL: http://www.bis.org/publ/bppdf/bispap136.pdf.
• Mu, C. (2023). Theories and practice of exploring China’s e-CNY. In Data, Digitalization, Decentialized Finance and Central Bank Digital Currencies: The Future of Banking and Money, Dombret, A., and Kenadjian, P. S. (eds), pp. 179–190. De Gruyter, Berlin (https://doi.org/10.1515/9783111002736-013).
• Reserve Bank of India (2022). Concept note on central bank digital currency. Report, October, FinTech Department, RBI. URL: https://bit.ly/41beFi2.
• UK Finance (2023). Regulated Liability Network: UK discovery phase. Report, UK Finance and EY. URL: http://www.ukfinance.org.uk/system/files/2023-09/Regulated%20Liability%20Network%20-%20UK%20Discovery%20Phase%20report%20.pdf.
• UK Goverment (2022). Digital identity certification for right to work, right to rent and criminal record checks. Guidance, January, Department for Science, Innovation and Technology, and Department for Digital, Culture, Media and Sport. URL: https://bit.ly/3AT1t6X.
• UK Government (2023). Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data (United Kingdom General Data Protection Regulation). Revised December 31. URL: http://www.legislation.gov.uk/eur/2016/679. 

Download PDF

• Keywords
• Central banks
• Digital currency
• Money markets
• Payments
• Forum
• More
  Less