Response to the digital pound Technology Working Paper

Published on 25 January 2024

Executive summary

In February 2023, the Bank of England (the Bank) and His Majesty’s Treasury (HM Treasury) published a Consultation Paper on the digital pound. The Consultation Paper explained that the Bank and HM Treasury judged it likely that a digital pound would be needed in the future, and so further preparatory work was justified.

The Consultation Paper was accompanied by a Technology Working Paper which set out a high-level approach to technology design considerations and proposed an illustrative conceptual technology model for a digital pound. It sought to generate feedback and challenge that could inform the Bank’s work during the design phase.

This paper sets out a summary of responses to the Technology Working Paper. The Bank received 391 responses from both individuals and organisations (Annex). We are grateful for the feedback received and have used it to shape the workplan for the design phase.

Summary of feedback to the Technology Working Paper

There was broad support for the six technology design considerations set out in the Technology Working Paper.

There was broad support for the six technology design considerations – privacy, security, resilience, performance, extensibility and energy usage. Respondents also suggested additional considerations, such as interoperability, usability, accessibility and scalability. Some of these were already discussed in the Technology Working Paper but were not identified as key design considerations. The Bank and HM Treasury have agreed a set of design principles which take account of this feedback (Figure 1).

Figure 1: Design principles for a digital pound

A visual summary of the seven key design principles for a digital pound. These are: reliable and secure, user privacy and control, supports innovation, interoperable, adaptable and scalable, inclusive and attractive, energy efficient.

As stated in the Consultation Response and as set out in more detail below, privacy would be a core design feature of a digital pound. The Bank and the Government would not access users’ personal data, and legislation introduced by the Government for a digital pound would guarantee users’ privacy.

The Bank is committed to exploring technological options that would prevent the Bank from accessing any personal data through the core infrastructure. Respondents agreed that privacy-enhancing technologies (PETs) have potential to support the proposed policy objectives related to user privacy, set out in the Consultation Paper and Technology Working Paper. But there were mixed opinions on the application of emerging types of PETs, given that they could have implications for performance, security, computational loads, and overall system extensibility. Consistent with this commitment, the Bank will conduct experiments to understand the benefits and trade-offs of both well-established and emerging types of PETs, and how those technologies could be applied to support privacy in a digital pound system.

Respondents also broadly supported the Bank’s technical requirements and performance metrics for a digital pound, although some respondents thought it might be challenging to achieve the performance metric of 30,000 transactions per second. The Bank judges the requirements and metrics set out in the Technology Working Paper to be achievable but will use experiments to test this during the design phase.

The platform model remains the Bank and HM Treasury’s preferred model for a digital pound and will be developed further in the design phase.

The Technology Working Paper presented an illustrative conceptual model for a digital pound, which is based on the platform model described in the Consultation Paper. The majority of respondents agreed that the platform model was the most appropriate technology model for a digital pound given the policy objectives set out in the Consultation Paper.

To progress work in the most efficient and effective way, the Bank and HM Treasury will focus on one model of a digital pound. So, in the design phase, the Bank will develop the platform model described in the Consultation Paper further, and explore the possible architecture, components and solutions in depth.

Some respondents proposed alternative models.footnote [1] At present, the Bank judges those models to be less suitable than the platform model to deliver the objectives set out in the Consultation Paper and the Technology Working Paper. The Bank will continue to explore those models in the design phase, although not in depth.

A few respondents suggested models that the Bank judges to not be compatible with the stated policy objectives or design principles, for example models based on anonymous bearer instruments, which will not be taken forward. Those models make extensive use of self-custody, which increases security risks, would make it difficult for users to recover funds if their devices were lost or stolen, and are not inclusive of the needs of less technologically sophisticated users. Those models could also lead to completely anonymous payments and, therefore, would not align with the Bank and HM Treasury’s approach to privacy and the prevention of financial crime.

There was also support for the components and activities set out in the Technology Working Paper.

Respondents expressed support for the components and activities set out in the Technology Working Paper. Respondents suggested a number of factors for the Bank to consider when designing the core ledger, analytics hub, and alias service. Respondents also suggested features for the application programming interface (API) layer, such as push and pull payments. The Bank will consider these suggestions as the design phase progresses.

Respondents suggested that a digital pound system should support both new and existing devices; and that existing payments infrastructure should be used to support interoperability.

Most respondents suggested that a digital pound system should support both new and existing devices for making and receiving payments. During the design phase, the Bank will assess how a digital pound system could make best use of existing devices, as well as support new devices. The Bank will also explore, in collaboration with stakeholders, whether additional technical standards are needed to ensure interoperability and the required level of functionality and security.

Interoperability was highlighted by respondents as essential to a digital pound system. Almost all respondents noted that existing payments infrastructure should be used to support interoperability between a digital pound, other payment systems, and other forms of money. During the design phase, we will determine how a digital pound system would enable interoperability. We will also engage with stakeholders on standards, operating models and ecosystem interactions that could support interoperability.

Respondents agreed that government or central bank-initiated programmable money should not be pursued, but they deemed user-initiated programmable payments to be important.

As stated in the Consultation Response, the Government has committed to introducing primary legislation before any launch of a digital pound that would guarantee that the Bank and the Government would not program the digital pound. This means that neither the Bank nor the Government would restrict how users spend their money.

Most respondents agreed that government or central bank-initiated programmable money should not be pursued, but that user-initiated programmable payments and smart contract functionality would be important for a digital pound system.

The Bank will continue to engage with stakeholders to understand which innovative functionality Payment Interface Providers (PIPs) and users might want, and to determine what infrastructure would be needed to support those features.

Wider feedback to the Technology Working Paper and the Consultation Paper highlighted privacy and programmability as areas of concern for some respondents. The Bank and HM Treasury have responded to this feedback by introducing a range of safeguards.

In addition to responses to specific questions posed in the Technology Working Paper, some responses (particularly from individuals) provided comments on the broader societal implications of introducing a retail central bank digital currency (CBDC), such as privacy considerations and the potential uses of programmable functionality. Respondents also raised concerns about the future of cash.

As stated in the Consultation Response, the Bank and HM Treasury have responded to that feedback by introducing a range of measures that would govern a digital pound, if the decision were made to introduce it:

  • Before any launch of a digital pound, the Government has committed to introducing primary legislation. This means that a digital pound would only be launched once both Houses of Parliament had passed the relevant legislation.
  • Privacy would be a core feature of a digital pound:
    • The Bank and the Government would not access users’ personal data – and legislation introduced by the Government for a digital pound would guarantee users’ privacy.
    • The Bank commits to exploring technological options that would prevent the Bank from accessing any personal data through the Bank’s core infrastructure.
  • The Bank and the Government would not program a digital pound – and legislation introduced by the Government for a digital pound would guarantee this.
  • The Government has legislated to safeguard access to cash, ensuring that it would remain available even if a digital pound were launched.

Further information on these measures is set out in the Consultation Response.

Summary of our proposed next steps

The Bank and HM Treasury have progressed to the next stage of work on a digital pound – the design phase. The Bank and HM Treasury expect to decide whether to proceed to the build phase around the middle of the decade.

The publication of the Consultation Paper and Technology Working Paper marked the end of the first phase of the Bank and HM Treasury’s work on a digital pound, the research and exploration phase. The Bank and HM Treasury have now moved to the second phase of work, the design phase. The priority in the design phase is to develop, in both policy and technology terms, the in-depth design of a digital pound.

At the end of the design phase, the Bank and HM Treasury will decide whether to proceed to build a digital pound infrastructure. If a decision were taken to move into this phase – known as the build phase – the Bank and HM Treasury would develop the prototype digital pound technology, first in a simulated environment and then in live pilot tests.

As stated in the Consultation Response, the Government has committed to introducing primary legislation in advance of launching a digital pound and that would be preceded by further public consultation.

The design phase has four key workstreams, which are interrelated.

The design phase has four interrelated workstreams: the blueprint; experimentation and proofs of concept; the national conversation; and the assessment. The purpose of those workstreams is to support a decision on whether or not to move to the build phase for a digital pound. That decision requires a comprehensive proposition, robust evidence of costs, and engagement with a wide range of stakeholders. The feedback received on both the Consultation Paper and the Technology Working Paper will help to inform the Bank and HM Treasury’s work on these workstreams:

  • Blueprint: a comprehensive description of a digital pound architecture, should a decision be taken to proceed to build it.
  • Experimentation and proofs of concept: experiments and proofs of concept will both inform the proposals the Bank will set out in the blueprint, and enhance knowledge and capabilities, whether or not a decision is taken to build a digital pound. The Bank has already conducted successful experiments on APIs, point of sale, digital wallet applications and offline payments.footnote [2] The Bank will continue to conduct experiments and proofs of concept in the design phase. Those will focus on a range of topics, including but not limited to:
    • the application of PETs;
    • core ledger design – both centralised and federated databases (ie, distributed ledger technologies);
    • interoperability;
    • further API functionality, building on the APIs defined in Project Rosalind;footnote [3] and
    • the alias service.
  • National conversation: a programme of engagement by HM Treasury and the Bank with the public, businesses and wider stakeholders to ensure that work on a digital pound takes account of all views. This will also build public understanding of a digital pound and user needs.
  • Assessment: a framework to evaluate the costs and benefits of a digital pound, to inform the decision on whether to proceed to the build phase.

In addition, the Bank and HM Treasury intend to publish periodically discussions on material considerations related to the design of, or technology for, a digital pound. This is in order to enable stakeholders to understand emerging thinking, and to seek expert input, feedback and challenge at an early stage. Potential publications are likely to include:

  • Project reports: These would set out findings of the Bank’s experiments and proofs of concept.
  • Design notes: These would explain the Bank and HM Treasury’s emerging thinking on digital pound technology and policy topics.
  • Forum minutes: These include minutes of, and materials discussed at, meetings of the stakeholder engagement groups.

These publications will ensure expert input is accounted for in the eventual digital pound blueprint. They will not, however, represent final decisions on the design of a digital pound.

Even if a decision is taken not to proceed to build a digital pound, collaboration with the private sector and technology explorations during the design phase will be beneficial. They will present opportunities for business-model innovation and help to build technology capability in the UK fintech sector. Collaboration with the private sector will also help to inform authorities’ regulation of private digital money, such as stablecoins and tokenised bank deposits. The technology explorations will also deepen the Bank and HM Treasury’s understanding of how such technologies might be deployed in wholesale payments and settlements.

The rest of this paper provides a summary of the responses to the Technology Working Paper, the Bank’s response to that feedback (‘Detailed feedback on the Technology Working Paper’) and further details on the steps that the Bank will be taking in light of this (‘Next steps’).

Detailed feedback on the Technology Working Paper

This section summarises the feedback received from those respondents who provided detailed feedback on the questions set out in the Technology Working Paper. Those questions were structured around the two sections of the Technology Working Paper – technology design considerations and illustrative conceptual model. To organise the Bank’s responses on the feedback, the questions and feedback are categorised into six sections:

  • Technology design considerations
  • Illustrative conceptual model
  • Core infrastructure
  • Devices
  • Interoperability
  • Payments functionality

Each section details the specific questions set out in the Technology Working Paper, a summary of the feedback to those questions, and the Bank’s response to that feedback.

Technology design considerations

What the Technology Working Paper said

The Technology Working Paper set out six technology design considerations that could organise and guide the Bank’s technology work on a digital pound, namely privacy, security, resilience, performance, extensibility and energy usage.

Those technology design considerations informed a set of technical requirements, including a throughput target of approximately 30,000 transactions per second, with the potential for approximately 100,000 transactions per second, and an uptime target of 99.999%. The Technology Working Paper also described potential approaches to delivering on those requirements, such as the possible use of PETs to support privacy requirements.

Questions asked in the Technology Working Paper
1. Do you agree that these six considerations are foundational technology considerations for CBDC? Are there additional or alternative technology considerations that the Bank should be focused on?
2. Which privacy-enhancing technologies (PETs), or other privacy mechanisms, might support the proposed policy objectives, and how might they be used?
3. Are the provisional requirements and metrics discussed in the paper, particularly for uptime, transaction throughput and transaction speed, realistic and appropriate?

Summary of respondents’ views

Respondents expressed broad support for the six technology design considerations. Most respondents suggested interoperability, usability, accessibility and scalability as additional considerations.

Most respondents agreed that the six considerations set out in the Technology Working Paper should be the highest priority technology considerations for a digital pound. Respondents in particular highlighted performance, privacy and security as important areas.

Interoperability, usability, accessibility and scalability of a digital pound were cited as additional considerations. Interoperability was highlighted by one third of respondents. Usability and accessibility were deemed to be important to allow all users to have a consistent and rewarding experience when interacting with a digital pound, regardless of their technical capabilities. Scalability was cited as important for accommodating increasingly large transaction volumes as future use cases develop and payments needs evolve, while meeting the performance metrics detailed in the Technology Working Paper.

Some of these considerations, such as interoperability and scalability, were already discussed in the Technology Working Paper as essential for a digital pound, but they were not described by the Bank as key technology design considerations.

Almost all respondents agreed that PETs could support the proposed policy objectives on privacy, but there were mixed opinions on the application of emerging types of PETs.

Almost all respondents agreed that PETs could be useful in supporting user privacy.

Several respondents cited the benefits of emerging types of PETs such as zero-knowledge proofs (ZKPs), homomorphic encryption techniques and blind proofs. But some respondents cautioned against adopting emerging types of PETs, noting they present performance, security and computational load trade-offs, as well as introducing complexities that might reduce overall system extensibility. Those respondents suggested that emerging types of PETs, such as ZKPs, should not be deployed, and well-established cryptographic techniques, such as data pseudonymisation, should instead be prioritised.

Additional types of PETs suggested by respondents included confidential computing, secure multi-party computation, federated learning, decentralised identities and group signatures.

Around half of respondents supported the requirements and performance metrics set out in the Technology Working Paper.

Around half of respondents deemed the requirements and performance metrics discussed in the Technology Working Paper to be realistic and appropriate. Feedback from the remainder was mixed, with the performance metric (transactions per second) thought to be the hardest to achieve by some respondents.

Some respondents thought that 30,000 transactions per second would not offer sufficient capacity for future payments needs. A few respondents deemed that even the stretch throughput of 100,000 transactions per second would be inadequate for a digital pound system.

Most respondents thought the resilience target of 99.999% uptime was technically challenging yet achievable. Some respondents noted they would like to see more information on how the Bank plans to test and measure these requirements and metrics during the design phase.

The Bank’s response

The Bank and HM Treasury have agreed a set of design principles to guide future work during the digital pound design phase. Those design principles take account of this feedback and give specific consideration to interoperability, usability, accessibility and scalability (Figure 1).

The Bank and the Government would not access users’ personal data – and legislation introduced by the Government for a digital pound would guarantee users’ privacy. The Bank will explore technological design options that would prevent access to personal data. This will include practical experimentation to assess the benefits and trade-offs of both well-established and emerging PETs.

The Bank has considered respondents’ views on the resilience and performance requirements and metrics set out in the Technology Working Paper. The Bank still judges them to be realistic but will monitor, test and, where appropriate, adjust them as the digital pound blueprint develops.

Illustrative conceptual model

What the Technology Working Paper said

The Technology Working Paper set out an illustrative conceptual model, based on the platform model described in the Consultation Paper. The platform model is based on a public-private partnership, in which the Bank would issue a digital pound and provide its core infrastructure. Private-sector firms, called Payment Interface Providers (PIPs) and External Service Interface Providers (ESIPs), would integrate with the core infrastructure and deliver services to users.

The illustrative conceptual model features the core ledger, application programming interface (API) layer, alias service and analytics as part of the Bank-managed infrastructure. It also features programmability primitives, such as locking mechanisms that could allow PIPs and ESIPs to implement innovative services by earmarking funds on the core ledger. Those features would be implemented by PIPs and would require user consent. The platform model also considers devices that could allow users to access and use a digital pound, as well as functionality for offline payments, and interoperability with other forms of money.

Questions asked in the Technology Working Paper
4. Are there other significant components or activities that the Bank should consider in designing a CBDC?
5. Are there alternative models that might better address the technology considerations and technical requirements outlined in this paper?

Summary of respondents’ views

Most respondents agreed that the platform model was the most appropriate approach, although some suggested alternatives.

The majority of respondents agreed that the platform model was the most appropriate architecture to meet the policy objectives set out in the Consultation Paper, and the technology design considerations and technical requirements described in the Technology Working Paper.

Most respondents agreed with the components and activities making up the platform model but had detailed comments on how we might go about designing and delivering them. Some respondents proposed alternative models they considered better able to deliver on the objectives set out in the Consultation Paper and the Technology Working Paper.footnote [4] The Consultation Paper explained that those models were less suitable, given our aims and objectives, than the platform model.

A few respondents suggested models that the Bank judges to not be compatible with the stated policy objectives or design principles, for example models based on anonymous bearer instruments, which will not be taken forward. Those models make extensive use of self-custody, which increases security risks, would make it difficult for users to recover funds if their devices were lost or stolen, and are not inclusive of the needs of less technologically sophisticated users. Those models could also lead to completely anonymous payments and, therefore, would not align with the Bank and HM Treasury’s approach to privacy and the prevention of financial crime.

The Bank’s response

The Technology Working Paper put forward an illustrative conceptual model, based on the platform model, for feedback. Having taken account of the feedback received, we judge that the platform model continues to best serve our aims and goals for a digital pound. Therefore, the platform model will be developed further in the design phase, where we will explore the architecture, components and solutions in depth. While the platform model is our preferred model, we anticipate that it will evolve and adapt over the course of the design phase, taking account of our further research and experimentation. More detail on the proposed model for a digital pound will be confirmed in the blueprint, which is expected to be completed by the end of the design phase.

While the work during the design phase will focus on further elaborating the platform model, we will continue to explore alternative models, although not in depth. That will include closely engaging with developments in digital currency technology, and actively considering the merits of alternative models as we develop the digital pound blueprint.

The Bank and HM Treasury will also engage widely and frequently with stakeholders to ensure that their perspectives and expertise are reflected in the digital pound design as the design phase progresses.

Core infrastructure

What the Technology Working Paper said

The Technology Working Paper set out potential approaches for implementing the core ledger, API layer, analytics hub, and alias service.

As stated in the Consultation Paper, neither the Bank nor the Government would have access to users’ personal data. The Technology Working Paper noted that the Bank might collect two categories of data. First, operational metadata (or system performance information) which would allow the Bank to maintain the core ledger and the API layer. Second, the Bank may wish to collect aggregate data, subject to effective anonymisation and privacy protections, in order to undertake economic and policy analysis. These data would not include personal data, and no users would be identifiable through this collection and analysis.

Questions asked in the Technology Working Paper
6. Other than those described in this paper, are there additional important factors to consider related to ledger design?
7. What are the most appropriate approaches or technologies for collecting and analysing aggregate transaction data?
8. Do you agree with the need for aliases (both well-known and disposable)? If so, should the alias service be hosted as part of the Bank-managed infrastructure, or should it be distributed across the CBDC ecosystem?
9. What features would a CBDC API require to enable innovative use cases?

Summary of respondents’ views

There was a wide range of views on ledger considerations. Respondents expressed mixed opinions on whether the core ledger technology should be centrally governed.

Respondents addressed a wide range of considerations in their responses. Most respondents agreed that the core ledger should be able to scale to accommodate increasing transaction volumes and maintain high transaction speeds. Respondents also mentioned security and immutability as considerations in ledger design. Other criteria cited by respondents included fault-tolerance, redundancy and extensibility.

Respondents had mixed opinions on the most appropriate design for the core ledger. Some respondents believed the core ledger should utilise centrally governed technologies, while some respondents were in favour of distributed ledger technologies (DLTs). A small number of respondents proposed a hybrid architecture which incorporates centrally governed technologies with some elements of DLT.

Respondents suggested a range of tools for collecting and analysing operational metadata and aggregated and anonymised data.

Neither the Bank nor the Government would have access to users’ personal data. The Technology Working Paper explained that the Bank might need to collect two categories of data – operational metadata (or system performance information) and aggregated and anonymised macro data. No digital pound user would be identifiable through the analysis of these data.

Some respondents suggested that a digital pound system should conduct real-time streaming of operational data. They cited several stream processing platforms and tools that could assist in achieving this.

Many respondents mentioned SQL based data warehousing, business intelligence and data science tooling, such as R, Python and Spark, for analytical workloads and batch processing. These data would flow from the core ledger, API layer and other real-time and data streaming systems. Some respondents mentioned management tools for maintaining the quality of these data.

Most respondents agreed that analytics should take place on a separate platform, away from the core digital pound system. That would mean that the collection and analysis of data would not impact the performance of the core system.

Respondents agreed that there should be no collection or analysis of personal data. A few respondents noted that PETs, such as differential privacy and confidential computing, could be applied to those aggregated datasets to ensure privacy.

Almost all respondents agreed that both well-known and disposable aliases would be needed. Most thought the alias service should be part of the wider digital pound ecosystem, rather than part of Bank-managed infrastructure.

Respondents agreed that disposable aliases could help to support privacy requirements, and well-known aliases could help to route and simplify payments by providing a simple identifier and by encouraging interoperability across payment types.

A small number of respondents encouraged the Bank to limit the number and types of aliases to avoid complexity, as alias management overheads can be high. Respondents generally agreed that the alias service should be hosted in the wider digital pound ecosystem to avoid placing the burden on the core infrastructure, and to ensure user privacy is maintained.

A small number of respondents thought the alias service should be hosted by the Bank, or some centralised third party. This would enable data recovery in the event of failure in the wider ecosystem infrastructure and enable users to easily move their accounts from one PIP to another.

A broad range of features were identified for the API layer that could support innovative use cases.

Respondents generally agreed that the API layer should be secure, standardised, simple to connect to, and easily interoperable with other systems. Some respondents suggested that the API layer should support features such as escrow functionality and push, pull, and offline payments.

A few respondents also thought the API should allow users to check their digital pound holdings directly and receive a verifiable proof of balance, rather than rely exclusively on information provided by their PIP.

The Bank’s response

The Technology Working Paper explained that the use of centrally governed, distributed database technologies might be more efficient and appropriate for the core ledger than DLT or blockchain-based solutions. However, we will continue to assess a range of approaches and monitor ongoing technology developments.

We are exploring technologies that could potentially distribute the alias service functionality across a digital pound ecosystem, such that the alias service would not be part of Bank-managed infrastructure. The technologies we are exploring include decentralised identifiers, decentralised public key infrastructure and verifiable credentials. With these technologies, we are assessing whether it is possible to design a privacy-preserving alias service which would not only prevent the core ledger from accessing personal data, but also, limit the sharing of personal data between users and PIPs.

The Bank experimented with API design in Project Rosalind,footnote [5] which was a joint project with the BIS Innovation Hub London Centre. Building on the Rosalind APIs, the Bank will conduct further exploration of API functionality, including assessing additional features mentioned in responses to the Technology Working Paper. This might include developing a sandbox, provided by the Bank, which would enable technologists and stakeholders to test the APIs and develop innovative use cases.

Devices

What the Technology Working Paper said

The Technology Working Paper listed a number of devices that might be used to make digital pound payments. While those devices would be developed by third parties, the Bank might need to work with manufacturers to determine minimum standards for how those devices would interact with a digital pound ecosystem, for example in order to support interoperability. Wherever possible that should involve using well-established, industry norm standards (eg, EMV).footnote [6] Bespoke standards for digital pound devices or infrastructure should be avoided wherever possible.

Question asked in the Technology Working Paper
10. Do you agree with the suggested list of devices for making payments with CBDC?

Summary of respondents’ views

Most respondents expressed support for the devices set out in the Technology Working Paper. Some respondents suggested additional devices.

Almost all respondents agreed with the suggested list of devices. Most respondents agreed that there should be integration with existing point-of-sale devices, as well as smart devices and smart cards. That would mean neither merchants nor consumers would have to invest in or familiarise themselves with new devices in order to use a digital pound.

A few respondents thought that additional devices and form factors, including the use of short message service (SMS) and quick response (QR) codes, should be included. Several respondents, particularly those in the technology sector, expected the list to expand over time to include developments such as autonomous vehicles.

The Bank’s response

The devices listed in the Technology Working Paper are the minimum set of devices and form factors that a digital pound system would likely need to deliver its required functionality and attain the policy goals set out in the Consultation Paper. Those devices and form factors included smartphones, smart cards and point-of-sale devices.

The Bank will conduct experiments to understand how a digital pound system might take account of developments in devices, and support both existing and new devices that private-sector firms might develop. The Bank will also work with stakeholders to assess the viability and utility of form factors, such as QR and SMS. Furthermore, as set out in the Technology Working Paper, the Bank will explore whether technical standards are needed to ensure interoperability and the required level of functionality and security.

Interoperability

What the Technology Working Paper said

The Technology Working Paper explained that a digital pound should be interoperable with other forms of money, including cash and bank deposits. One option for achieving this is utilising existing payments infrastructure, subject to technical, functional and operational viability.

Question asked in the Technology Working Paper
11. How viable is it to enable interoperability between CBDC and other forms of money using existing payments infrastructure?

Summary of respondents' views

Almost all respondents agreed that utilising existing payment infrastructure and standards to deliver interoperability was the preferred option. A small number of respondents suggested that new infrastructure should instead be developed to enable interoperability.

Almost all respondents supported using existing infrastructure and standards to support interoperability between a digital pound and other forms of money and payment systems.

Respondents highlighted some existing infrastructure they considered a digital pound system should interoperate with, including existing point-of-sale devices and automated teller machine systems (ATMs), card networks, and interbank payment systems. Some respondents also noted challenges to be overcome, including alignment on messaging standards and protocols as well as the implementation of legislative and regulatory frameworks.

A small number of respondents suggested new infrastructure should be developed to enable interoperability between a digital pound system and other payment systems and forms of money.

Respondents encouraged the Bank to collaborate widely on these matters and to prioritise interoperability during the design phase.

The Bank’s response

The Bank and HM Treasury have included interoperability as a design principle for a digital pound (Figure 1). This design principle states that users should be able to conveniently exchange digital pounds with other forms of money.

During the design phase, the Bank will determine how a digital pound system would interoperate with existing infrastructure, payment systems and other forms of money. The design phase will also include wider engagement with stakeholders on standards, operating models and ecosystem interactions to support interoperability.

Payments functionality

What the Technology Working Paper said

The Consultation Paper set out potential payments in scope for a digital pound: peer-to-peer and person-to-business payments, both in store and online. The Technology Working Paper also set out two categories of payments functionality that a digital pound system might need to support, and that PIPs would offer: user-initiated programmability and offline payments.

The Technology Working Paper explained that neither the Bank nor the Government will develop central bank-initiated programmable money.

Instead, the Bank would aim to support user-initiated programmability. This refers to programmable paymentsfootnote [7] which would be designed to give users greater functionality from their wallets and digital pound holdings. Those innovative services would be implemented by PIPs and ESIPs and would require user consent. The Bank would provide the basic infrastructure (programmability primitives) to enable only PIPs and ESIPs to develop those services.

Questions asked in the Technology Working Paper
12. Is programmability and smart contract functionality an important feature of a CBDC system? If so, what is the best approach to enabling such functionality?
13. How important is offline functionality in a CBDC system? What are the most effective ways to implement offline capability?

Summary of respondents’ views

Most respondents thought user-initiated programmable payments and smart contract functionality would be an important feature of a digital pound system.

There was broad support for user-initiated programmable payments. Respondents noted that user-initiated programmability could support innovation, simplify and automate payments and increase transparency.

Almost all respondents agreed with the Bank’s position that central bank-initiated programmable money should not be implemented. They agreed that the Bank should expose programmability primitives through the API layer to allow PIPs and ESIPs to offer innovative services to users. Some respondents suggested that scheme rules and regulation would be needed to maintain user trust and confidence in the system if user-initiated programmable payments were offered.

Although most respondents agreed that smart contracts were essential to deliver programmable functions, some respondents thought smart contracts should not be hosted on Bank-managed infrastructure because of the complexities they could introduce.

A number of respondents provided feedback on broader societal implications of a retail CBDC, without commenting specifically on the questions set out in the Technology Working Paper. Those respondents were not in support of programmability or smart contract functionality at all. While the Bank and HM Treasury have made clear there will be no programmable money implemented by the authorities, those respondents cautioned against enabling programmable capabilities of any type, including in the private sector, in case they could be used in the future to restrict the types of payments users might make.

Offline functionality was generally deemed to be important.

Offline functionality was generally deemed to be important. The two main reasons given were to support financial and digital inclusion, and to enhance resilience in the case of system outages. The small number of respondents who did not deem offline functionality important cited security, fraud and financial crime as the reasons.

Respondents suggested ways to implement offline functionality, including using trusted hardware and devices, ringfencing funds for offline use and smart cards. Some respondents thought communication technologies like near-field communication (NFC), Bluetooth and QR could be used.

The Bank’s response

As stated in the Consultation Response, the Government has committed to introducing primary legislation before any launch of a digital pound. Such legislation would guarantee that the Bank and the Government would not pursue government or central bank-initiated programmable money.

Our current position is that smart contracts would not be hosted on the core ledger. We will continue to examine which API features are needed to enable the private sector to build and host smart contracts.

The Bank and HM Treasury will continue to engage with stakeholders to understand which innovative functionality PIPs and users might want, and to determine what infrastructure would be needed to support those features. This will include further development of the functionalities that we experimented with in Project Rosalind.footnote [8]

As stated in the Consultation Response, we intend to explore offline settlement capabilities further. Following the publication of Requests for Information, the Bank and HM Treasury have set up digital pound working groups to engage with experts, including on offline payments. Their input will be considered alongside the feedback from individuals and experts set out in this document.

Next steps

Feedback on the Technology Working Paper has shaped the Bank’s priorities for, and approach to, the design phase, in particular the model of a digital pound we will explore further in our work.

Feedback has helped us set our priorities, shape our approach, and adjust the model of a digital pound we will explore during the design phase.

During the design phase we will focus on developing in detail the digital pound proposition, with a particular focus on the operational, functional, and technology model for a digital pound. That will involve determining the technological feasibility and investment required to build and operate a digital pound infrastructure. In turn, that will support an overall assessment, made together with HM Treasury, on the benefits and costs of building and running a digital pound architecture. The activities during the design phase will equip us with the knowledge and capability to build a digital pound and shorten the development lead times, were a decision taken to introduce one in the future.

In addition to responses to specific questions posed in the Technology Working Paper, some responses (particularly from individuals) provided comments on the broader societal implications of introducing a retail CBDC, such as privacy considerations and the potential uses of programmable functionality. Respondents also raised concerns about the future of cash.

As stated in the Consultation Response, the Bank and HM Treasury have responded to that feedback by introducing a range of measures that would govern a digital pound, if the decision were made to launch it:

  • Before any launch of a digital pound, the Government has committed to introducing primary legislation. This means that a digital pound would only be launched once both Houses of Parliament had passed the relevant legislation.
  • Privacy would be a core feature of a digital pound:
    • The Bank and the Government would not access users’ personal data – and legislation introduced by the Government for a digital pound would guarantee users’ privacy.
    • The Bank commits to exploring technological options that would prevent the Bank from accessing any personal data through the Bank’s core infrastructure.
  • The Bank and the Government would not program a digital pound – and legislation introduced by the Government for a digital pound would guarantee this.
  • The Government has legislated to safeguard access to cash, ensuring that it would remain available even if a digital pound were launched.

The design phase will have four key workstreams, which are interrelated.

The Bank and HM Treasury envisage four workstreams in the design phase.

  • Experimentation and proofs of concept: focused experiments in collaboration with innovative private-sector firms to establish the technological feasibility of different design choices.
  • Blueprint: a comprehensive description of the digital pound architecture, should a decision be taken to proceed to build it.
  • National conversation: a programme of engagement by HM Treasury and the Bank with the public, businesses and wider stakeholders to ensure our work on a digital pound takes account of all views. This will also build public understanding of a digital pound and user needs.
  • Assessment: a framework to evaluate the costs and benefits of a digital pound, to inform our decision on whether to proceed to the build phase.footnote [9]

The four workstreams of the design phase complement and reinforce one another. For example, experiments and proofs of concept will be relevant in the national conversation on the future of money by showing the potential use cases that a digital pound might generate. Both will also inform the design choices ultimately proposed in the blueprint.

The assessment of whether to proceed to the build phase will be based on the specific design of a digital pound detailed in the blueprint, as well as being informed by the national conversation on the future of money. The build phase would then execute the design of a digital pound as specified in the blueprint.

The Bank will continue to partner with private firms to conduct experiments and proofs of concept.

Experiments and proofs of concept, conducted with private-sector firms, will allow the Bank to understand better the state-of-the-art for technologies and to what extent they can meet our design requirements. The Bank has already completed successful experiments in relation to API, point of sale, digital wallet applications and offline payments.

To ensure a fair and transparent approach to our partnerships with the private sector, experiments and proofs of concept will follow appropriate governance, in line with procurement law and the Bank’s procurement policy.

The design phase will present enduring benefits for the UK fintech sector, even if we do not build a digital pound.

Technologies for a digital pound are also relevant to other new forms of digital money issued by the private sector, such as stablecoins and tokenised bank deposits. It is likely that digital currency technologies will be significant in shaping the future of finance.

Even if a decision is taken not to proceed to build a digital pound, collaboration with the private sector and technology explorations during the design phase will be beneficial. They will present opportunities for business-model innovation and help to build technology capability in the UK fintech sector. Collaboration with the private sector will also help to inform authorities’ regulation of private digital money, such as stablecoins and tokenised bank deposits. The technology explorations will also deepen the Bank and HM Treasury’s understanding of how such technologies might be deployed in wholesale payments and settlements. Given that digital currency technologies are likely to be significant in shaping the future of finance, the benefits of the design phase can be expected to endure even if a decision is taken not to introduce a digital pound.

The design phase will set out a clear proposition for a digital pound. That will include setting out the product and technology proposition for a digital pound that would be proposed for the build phase.

The design phase will set out a clear proposition for a digital pound from the perspectives of the Bank and HM Treasury, end-users, merchants and intermediaries. To that end, the blueprint will set out the product and technology proposition for a digital pound that we would propose for the build phase.

The Technology Working Paper and the Consultation Paper set out objectives for a digital pound. Taking on board the feedback received on both papers, the Bank and HM Treasury have developed a set of design principles (Table A). These will guide work in the design phase by providing a framework to develop the blueprint for the digital pound proposition, alongside continued engagement with stakeholders.

Adhering to these design principles will support the Bank’s core purposes of monetary and financial stability, and HM Treasury’s objectives of an inclusive and innovative digital payments ecosystem, while delivering a digital pound platform that is secure, private, adaptable, energy efficient, and interoperable with other payment rails.

Table A: Design principles for a digital pound

Principle

Summary

Reliable and secure

A digital pound should always be available so users can trust they can make payments at all times

User privacy and control

No access to personal data by the Bank and the Government through the Bank’s core infrastructure

Enable privacy-preserving payment options

Money is not programmed by the Bank or the Government

Support innovation

Provide public infrastructure and functionality at good value-for-money to support innovative services

Lower barriers to entry to promote competition in payments

Interoperable

Users would be able to exchange digital pounds conveniently with other forms of money

Users of a digital pound would be able to pay non-users conveniently, and vice versa

Adaptable and scalable

Support our prioritised payment and non-payment use cases

Built with future trends in mind

Adaptable to support use cases we cannot currently anticipate

Inclusive and attractive

Attractive to individuals and businesses

Designed to be widely accepted

Able to sustain a range of private-sector business models in the ecosystem

Energy efficient

Without compromising user choice, a digital pound would support the Government’s net-zero plans

A digital pound would be at least as energy efficient as existing payments infrastructures

Delivering the blueprint will require specialist input from a range of stakeholders, including technical experts. As such, the Bank and HM Treasury have increased their external engagement and will ensure stakeholders are informed and involved throughout the design phase.

In addition to the CBDC Engagement Forum (with members from industry and civil society) and the CBDC Technology Forum (with technical specialists) set up in 2021, the Bank and HM Treasury have set up the CBDC Academic Advisory Group (AAG) to ensure that cutting-edge research from a range of academic disciplines is given due consideration.

The Bank and HM Treasury have also recently set up working groups following the publication of Requests for Information to explore particular topics in detail. There will also be a structured programme of market research that will provide evidence to inform design choices in accordance with the design principles.

Later this year, the Bank and HM Treasury intend to explain in more detail the approach to the design phase, including plans for experimentation and proofs of concept, the considerations the blueprint will seek to address and the methods to be used to gather evidence to support the development of that blueprint.

Additionally, the Bank and HM Treasury intend to publish periodically discussions on material considerations related to the design of, or technology for, a potential digital pound. This is in order to enable stakeholders to understand emerging thinking, and to seek expert input, feedback and challenge at an early stage. Potential publications are likely to include:

  • Project reports: these would set out findings of the Bank’s experiments and proofs of concept.
  • Design notes: these would explain the Bank and HM Treasury’s emerging thinking on digital pound technology and policy topics.
  • Forum minutes: these include minutes of, and materials discussed at, meetings of the stakeholder engagement groups.

These publications will ensure expert input is accounted for in the eventual digital pound blueprint. They will not, however, represent final decisions on the design of a digital pound.

The Bank and HM Treasury expect to decide whether to proceed to the build phase around the middle of the decade.

At the end of the design phase, the Bank and HM Treasury will decide whether to proceed to build a digital pound. If the decision was taken to move into the build phase, the Bank would develop the prototype digital pound technology, first in a simulated environment and then in live pilot tests.

As stated in the Consultation Response, the Government has committed to introducing primary legislation in advance of launching a digital pound and that would be preceded by a further public consultation.footnote [10]

Figure 2: Roadmap for the digital pound project

A roadmap showing the three key phases of the digital pound project. The publication of the Consultation Paper and Technology Working Paper concluded the research and exploration phase. We are now in the design phase, which comprises four key workstreams described  in the main text. The final phase would be a build phase, if a decision were taken to proceed to build a digital pound. Only after this would a launch decision be taken.

Annex: The Bank’s approach to reviewing responses

The Bank received 391 responses to the Technology Working Paper, the majority of which were from individuals.

The Bank received a total of 391 responses from individuals and organisations. 352 of those responses (90%) were from individuals and 39 responses (10%) were from organisations.

Responses by organisations captured a variety of firm sizes, ranging from large firms, small and medium-sized enterprises and sole traders. The technology sector represented the largest portion of organisational responses (44%), followed by financial services, including payments and fintech (20%) (Chart 1).

Chart 1: Organisational respondents by industry

A chart showing the percentage breakdown of the organisations that responded to the Technology Working Paper. These are: Technology (44%), Financial Services (20%), Trade body (13%), Consultancy (5%), Academic (5%) Regulatory, (3%) and other (10%).

All responses were manually reviewed, with common themes identified.

The 13 questions posed in the Technology Working Paper were structured around two sections of the paper – technology design considerations and the illustrative conceptual model of a digital pound. The questions comprised both open-ended and close-ended questions. All responses were manually reviewed, with themes, areas of recommendation and challenge identified.

  1. For example, some respondents suggested the delegated model, which would require intermediaries to hold digital pounds on their own balance sheets.

  2. The Bank expects to publish findings from experiments and proofs of concepts. Refer to ‘Next steps’ for further details.

  3. Further information on Project Rosalind can be found on the BIS website.

  4. For example, some respondents suggested the delegated model, which would require intermediaries to hold digital pounds on their own balance sheets.

  5. Further information on Project Rosalind can be found on the BIS website.

  6. EMV (Europay, Mastercard and Visa) is a set of specifications which enable card-based payments to be consistently accepted across different payment schemes.

  7. For example, automated payments or delivery-versus-payment functionality.

  8. Further information on Project Rosalind can be found on the BIS website.

  9. Refer to Consultation Response for further information.

  10. Chancellor’s letter to Economic Affairs Committee and Treasury Select Committee, May 2023.