Digital pound experiment report: Offline payments

Background

In February 2023, the Bank of England (the Bank) published a Technology Working Paper, which accompanied the Bank and HM Treasury’s joint Consultation Paper on the digital pound. The Bank and HM Treasury confirmed in January 2024 that further preparatory work was justified to enable us to respond to developments in the payments landscape and to reduce materially the lead time if there is a future decision to introduce a digital pound. The Bank and HM Treasury have therefore moved from the research and exploration phase of work on a digital pound to the design phase, which will result in a decision around the middle of the decade on whether to build a digital pound.

The objectives of the design phase are to:

• cut lead-times on digital pound development and equip ourselves with the knowledge and capabilities to move into a build phase, if required;
• determine the technology feasibility and investment needed to build a digital pound;
• articulate, in detail, what the technology and operational architecture for a digital pound would look like;
• assess and evaluate the benefits and costs of a digital pound architecture;
• deepen the Bank’s knowledge of CBDC technology and support stakeholder understanding of our technology approach;
• support the development of the broader UK digital currency technology industry through collaboration, knowledge-sharing, experimentation and proofs of concept; and
• provide the basis for a future decision on whether to move to a build phase.

As part of the design phase, the Bank is conducting experiments and proofs of concept in collaboration with private sector innovators and a range of stakeholders. These experiments and proofs of concept do not indicate a decision to build a digital pound or a final digital pound design. They aim to assess the technical feasibility and technology and policy implications of a digital pound, in order to help the Bank and HM Treasury explore the design of a digital pound and provide evidence to support a decision on whether to build one. By partnering on experiments and proofs of concept, the Bank and HM Treasury seek to catalyse private innovation in digital currency technologies, encourage innovative digital money business models and support knowledge sharing across the UK fintech sector.

Project overview

We define ‘offline payment’ as a payment that occurs while neither payer nor payee has access to the CBDC network, usually due to the lack of an internet connection. The Technology Working Paper proposed that an offline payment functionality might provide additional resilience in the event of network disruption or outage of telephony services, and support financial inclusion and certain payment use cases, such as transportation.

The Technology Working Paper also explained that offline payments could create challenges verifying the authenticity of funds and increase the risk of fraud, including double spending and counterfeiting. While acknowledging the risks and complexities that offline payments might introduce, we committed to examining various approaches to addressing them. This project explored those challenges from a technology perspective.

This project aimed to assess the technical feasibility of implementing an offline payment functionality for a digital pound. We explored four solutions which used different technologies to implement peer-to-peer and person-to-business offline payments (see Table A below). In particular, we focused on whether offline CBDC payments could achieve the following:

• finality and irrevocability;
• double spend and counterfeit detection; and
• compliance with fraud and anti-money laundering regulations that require financial firms to monitor transactions.^{footnote [1]}

In addition, we explored offline payments at points of sale in our point-of-sale proof of concept, the findings of which were published in May 2024.

We are grateful to Thales, Secretarium, IDEMIA Secure Transactions, Quali-Sign and Consult Hyperion for providing the offline solutions which were assessed in this project and providing valuable insights for the findings set out in this report.

Findings

Final and irrevocable payments

It was technically feasible to make final and irrevocable offline CBDC payments.

All solutions achieved final and irrevocable payments by transferring funds from the payer to the payee with immediate confirmation and settlement, enabling the payee to spend those funds immediately without having to reconnect to the network.^{footnote [2]} This required funds to be stored locally on the user’s smartphone or smart card.

Funds were transferred (or downloaded) from each solution’s demonstration core ledger to user devices through the user’s payment intermediary. When using smartphones, funds were loaded directly to the phones, and when using smart cards, a smartphone’s NFC capability was used to transfer funds to the cards.

Although it was considered necessary for ensuring immediate settlement, the requirement that funds be stored on the user’s device raised user experience questions. First, an offline payment could only be made if users downloaded funds in advance.^{footnote [3]} In the event of unexpected outages, if funds were not downloaded in advance, the offline functionality would not be usable until the user received an offline payment from another user. Second, all solutions displayed an online balance separate to an offline balance within the same wallet application. This meant that when making a payment, users had to choose which balance they wanted to spend from.^{footnote [4]} While this was not an insurmountable issue, careful user experience guidance appeared necessary.

Once funds were downloaded to the user’s device, we needed to determine how users could make payments. We observed two payment flows for making payments between devices: a synchronous flow and an asynchronous flow.

Synchronous payment flow

This flow requires both the payer’s device and payee’s device to take part in the transaction; that is, both parties need to perform an action in real time in order to complete the transaction. In this flow, the payee’s device sends a payment request to the payer’s device, and the payer’s device generates a response (accept or decline) to that request. If the request is accepted, funds are immediately transferred from the payer’s device to the payee’s device, and the payee’s device verifies the payment and sends an acknowledgment to the payer’s device.

Asynchronous payment flow

This flow does not require the payee’s device to take part in the transaction in real time, although the payer must obtain the payee’s wallet address or wallet ID. In this flow, the payer’s device uses the payee’s wallet address or wallet ID, which can be shared out-of-band, to generate the payment. The payment does not need to be sent to the payee’s device directly. For example, it can be generated as a QR code, printed or otherwise provided to the payee later. It could also be sent via short message service (SMS), email, etc. Because the payment message includes the issuer’s public key, the payee’s device can verify the transaction when the payment is received.

While the asynchronous flow seemed to enable more innovative ways to pay, once funds were sent from the payer’s device they were spent and irrecoverable, even if the payee’s device never received the payment. This was because the flow does not require an acknowledgment from the payee to the payer; if the payee never claims the funds, the funds would be lost. In contrast, the synchronous payment flow allowed funds to be recovered if payments failed.

Risk management

Double spending and counterfeiting risks were primarily addressed using secure elements.

Double spending occurs when the same funds are spent more than once. This risk is more acute for offline payments since they take place disconnected from the ledger, making it more challenging to verify that funds have not already been spent. Similarly, there might be challenges verifying the authenticity of funds used offline.

The solutions we observed in this project addressed security challenges around double spending and counterfeiting primarily through using secure elements. A secure element is a microprocessor chip with enhanced security protections that should prevent unauthorised access. It can be embedded in smart cards and smartphones, or in removable Subscriber Identity Module (SIM) cards. Most modern smartphones already have secure elements embedded within them.

We explored two approaches to using secure elements. The first involved the complete offline solution, including cryptographic keys and transaction data, being stored in the secure element. The second involved the storing of some components of the offline solution in the secure element (for example, only the relevant cryptographic keys) while other components, such as transaction data, were stored in the device’s local memory. It was critical to protect the private keys, in particular,^{footnote [5]} as access to a user’s private key would allow the creation and approval of fake payments.

Both approaches seemed to offer some double spend and counterfeit prevention, but a thorough security assessment would be needed to determine the level of protection provided and the degree of residual risk. Since the security of the solutions relied on secure elements, if the secure elements were breached, double spending and counterfeiting would be possible.

The secure elements also had limited storage capacity which impacted the number of transactions that were possible before the devices needed to reconnect to the network. In one of the solutions we observed, this impacted risk detection mechanisms, including the solution’s ability to store a large number of bogus IDs, particularly on smart cards where storage was limited compared to smartphones.^{footnote [6]}

Online reconciliation was used as a fallback security measure in all four solutions to detect counterfeiting and double spending.^{footnote [7]} Being retrospective, online reconciliation helped to detect and identify counterfeiting and double spending, but it could not prevent either. At the point at which online reconciliation happens, users would have already suffered losses.

Additional countermeasures had an impact on user experience and costs. Measures such as risk mitigation limits had a negative impact on user experience since they prevented users from making further payments offline, often unexpectedly.^{footnote [8]} There might also be financial inclusion impacts since more expensive, higher-end devices were needed to guarantee stronger security.

A local transaction record was needed to support risk detection.

The Technology Working Paper stated that an offline transaction record might be needed to support double spend detection and reconciling with the core ledger. As such, it might be necessary for user devices to store a local transaction record, which would be uploaded to the ledger when the user reconnects to the network.

We observed three approaches in this project:

• Full transaction records: These transaction records comprised cryptographically verifiable chains of transactions. Each consecutive transaction was linked to the previous transaction. This was achieved in a token-based solution using UTXO currency techniques. In an account-based solution, a similar technique was used to create a chain of signatures.
• Partial transaction records: These transaction records comprised the minimum data needed to complete a transaction but there was no verifiable chain of transactions. Alternative options included using decentralised identifiers and anti-replay counters to populate a table of transactions. Payment intermediaries could then check whether the decentralised identifier matched the transaction amounts.
• No transaction record: Devices did not store a transaction record, and payments were effectively anonymous as there was no data to say what devices the value had been held on previously.

Full transaction records and partial transaction records enabled counterfeit and double-spend checks when the user reconnected to the network, but this was only possible when intermediaries shared data with each other. The extent to which they could conduct those checks was limited by the amount or quality of data shared. When there was no transaction record, it was not possible to conduct checks for double spending and counterfeiting at all.

Privacy-enhancing technologies were applied to protect personal data when users reconnected to the network.

We explored privacy-enhancing technologies that might enable users to reconnect to the network and share their transaction records with their payment intermediaries without the demonstration core ledgers gaining access to personal data.

The privacy-enhancing technologies we assessed included data pseudonymisation, ephemeral key management and confidential computing. Using these technologies, it was technically feasible to store an offline transaction record while protecting personal data when users reconnected to the network.

We also explored other emerging techniques: Direct Anonymous Attestation and BIP32. Direct Anonymous Attestation was used to protect transaction records and prevent personal data from being shared between payer and payee, and BIP32 was used to prevent payer from tracking payee.

We explored whether a centralised system could be used to facilitate data sharing between payment intermediaries and thereby enable checks for double spending, counterfeiting, and potentially fraud and money laundering.

This project explored a further option of having a centralised system, separate to the core CBDC system, which collected pseudonymised transaction records when the user reconnected to the network. The system also used confidential computing to prevent the operator from accessing user’s personal data. Machine learning techniques were applied to detect counterfeiting, but it could also be used to detect patterns that indicate fraud and money laundering, similar to the processes carried out by financial and non-financial institutions today.

It was technically feasible to apply risk mitigation limits to minimise the risk of money laundering. User authentication mechanisms were also implemented.

The Technology Working Paper stated that offline risk mitigation limits, whether on the number of consecutive offline transactions or based on time or value, might help to reduce the scale and impact of double spending. This project suggested that those limits could also minimise the risk of money laundering.

The offline solutions assessed in this project implemented different risk mitigation limits. Those limits included:

• maximum number of consecutive transactions offline;
• maximum offline payment amount;
• maximum cumulative amount for offline transactions; and
• maximum amount of offline balance stored.

We observed challenges that arose when implementing those limits. For example, time-based limits were difficult to implement on the smart cards since those devices did not have an internal clock. But even on devices with an internal clock, for example smartphones, security concerns around trusting the clocks made time-based limits challenging to implement. We also observed potential user experience issues. For example, we needed to consider how limits would be communicated to users and whether incoming or outgoing payments would be processed when the limits were reached. Further, these limits relied on the secure element for enforcement and needed to take account of the storage constraints of the secure elements. If the secure elements were breached, those limits could also be breached.

We also explored how an offline CBDC could meet other requirements, such as strong customer authentication.^{footnote [9]} User authentication was implemented on smartphones using the smartphones’ native authentication mechanisms, including CDCVM (via facial recognition and fingerprint), and PIN. CDCVM was also implemented on smart cards via fingerprint sensors. When CDCVM was used, the user’s biometrics was stored on their own device and was never shared with the payment intermediary or the online CBDC system.

Communication technology

We explored NFC, and a combination of QR and BLE technologies for communicating between user devices.

NFC was useful for card-to-phone and phone-to-card payments, but it limited the amount of data that could be shared between payer and payee during a transaction.^{footnote [10]} NFC also revealed user experience issues. Since different mobile devices had their NFC readers in different areas, it was challenging for inexperienced users to make payments seamlessly.

BLE was useful for phone-to-phone offline payments. It also allowed more data to be sent between payer and payee. This was useful for transmitting large transaction chains that occurred in the UTXO solution. Since the smart cards were not battery operated, BLE could not be used for card payments.

There were performance trade-offs for both NFC and BLE when users stored a transaction record. Although NFC was faster when establishing a connection between devices and for completing initial transactions, transaction times increased as the transaction record increased in size. BLE was slower when establishing a connection between devices, but transaction times did not increase at the same rate when the transaction record increased in size. We observed that transaction times would be consistent if no transaction record was stored, but this would prevent double spend and counterfeit detection.

Reflections and next steps

Offline CBDC would be an innovative feature with potential to support different policy goals, such as resilience or financial inclusion. This project demonstrated that it might be technically feasible to implement an offline payment functionality for a digital pound but there are security, performance, and user experience challenges which need to be explored further. One key area is the security challenges related to double spending and counterfeiting. Heavy reliance on secure elements meant that if the secure elements were breached, double spending and counterfeiting might occur. Secure elements are commonly used in payments today, but they are, in most cases, paired with immediate online authentication, thus limiting losses. In contrast, the online layer in an offline payment (online reconciliation) occurs only after the transaction has taken place and losses have already been incurred.

This project showed that there are several technology choices that could be made for offline payments today, but those are dependent on policy choices, such as risk appetite, product proposition, or liability, which have an impact on the options available for mitigating security risks. Our policy work on offline digital pound payments is ongoing. We expect to conduct a policy assessment to determine what these findings might mean for a digital pound. No final decision has been made on whether an offline payment functionality would be implemented if a digital pound were launched.

This project explored offline payments from a technology perspective only. There are other factors, such as policy, operational, legal and commercial considerations, that will impact the design choices for offline payments. In addition, there are technical challenges that were not addressed in this project, such as what happens to offline funds if a user loses their device.