Minutes of the CBDC Technology Forum – 14 May 2024

Meeting of the CBDC Technology Forum
Published on 02 August 2024

Minutes

Date of meeting: 14 May 2024

Item 1: Welcome

Tom Mutton (Chair) welcomed Members to the eleventh meeting of the CBDC Technology Forum.

The Chair noted the agenda for the meeting would comprise final presentations from two of the four subgroups that have been established on a time limit basis to help explore specific technology questions related to the digital pound architecture. The Chair then invited members of Subgroups 1 and 4 to present their conclusions.

Item 2: Subgroup 1 presentation

Members of Subgroup 1, tasked with exploring technology options to ensure privacy in a digital pound and the design of the alias service, presented their findings and conclusions.

Members of Subgroup 1 presented their hypothetical privacy model, which was an updated version of the model the same group presented to the Technology Forum in January. It considered different types of data, including account data, personal data, and transaction data. It also considered different roles, such as payer, payee, Payment Interface Providers (PIPs), and ledger operator. In this hypothetical privacy model, the ledger operator accessed only data that Subgroup 1 deemed strictly necessary, such as transaction time and account identifier. They noted that there were some data, such as account balance, which may or may not need to be visible to the ledger operator, depending on the routing model (the model of communication between PIPs).

They assessed three technology solutions, Monero, Zcash and Project Tourbillon, to understand the techniques that have been used to support privacy. They stated that the most promising techniques included the concept of one-time addresses although it would be a policy decision for the Bank as to whether those techniques were appropriate for a digital pound. Other techniques such as Bitcoin Improvement Proposal 32 technique also seemed useful. They noted that there were other techniques that were not appropriate for a CBDC because of the level of complexities those techniques could introduce.

Members of Subgroup 1 concluded that although there would be trade-offs between privacy and other considerations, such as functionality and usability, there were techniques that could be used to support privacy. They also encouraged the Bank to consider separating the roles of ledger operator and alias service operator in the digital pound architecture.

The Bank thanked Subgroup 1 for their presentation, noting that privacy was a non-negotiable priority for a digital pound.

Item 3: Subgroup 4 presentation

Members of Subgroup 4, tasked with exploring the requirements for providing a platform for innovation, presented their findings.

They stated that their presentation would focus on considerations around ‘locking mechanisms’ – a type of escrow functionality described in the Bank’s Technology Working Paper.footnote [1]

The first question they considered related to whether a locking functionality was desirable from a user’s perspective. One member of Subgroup 4, assessing a cash-on-delivery use case, reasoned that it was the 'promise to pay’, and not the form in which the promise was given or executed (ie, locking mechanism), that was important to users. As such, that promise might be implemented in different ways at the scheme level, although such arrangement would require that PIPs trust each other.

The second question Subgroup 4 considered was whether a locking functionality was important to a CBDC design and how the functionality could be implemented. One member of Subgroup 4 stated that in order to encourage adoption several use cases might require the locking functionality – eg, hotel reservations, restaurant reservations and vehicle purchases. They noted that there were three options for implementing a locking functionality: it could be implemented by the central bank, by individual PIPs or by a third party. Where the functionality was implemented by the central bank, this would guarantee consistency across PIPs, and where it was implemented by PIPs, PIPs could manage complex processes such as disputes.

The third question was around regulations for locking funds. One member of Subgroup 4 stated that regulations for existing payment systems, as set out in the Payment Services Regulations, allow commercial bank money (in the form of ATM funds) to be locked for one business day, with longer periods allowed for some use cases. They stated that since the Payment Services Regulations require strong customer authentication, there would be complexities around authorisation when locks are drawn down or released. They noted that the existing regulations might not support the breadth of use cases envisaged for a CBDC. They further noted that in banking sector, there were established practices for escrow services for high value payments. They explained that it would be important to consider how to scale this functionality for a digital pound, and there will also need to be considerations around how to handle disputes and how to retain viability.

The fourth question Subgroup 4 considered was how finality and irrevocability would work in an unauthorised payment scenario. Members of subgroup 4 focused on the ‘tap and go’ use case, noting that it would be important to consider how to implement this.

The final question was around dispute resolution. One member of Subgroup 4 stated that dispute resolution would require mechanisms such as chargeback for fraud, and a process for recovering funds. They considered two options, the first involved PIPs providing the means of chargeback, and the second involved an escrow agent handling chargeback and recoveries.

Members of subgroup 4 stated that they could not reach a conclusion on locking mechanisms because there were open questions that they needed clarity on, such as whether the ledger could record negative user balances. They also thought it would be useful to test data in a sandbox.

One Member asked whether considerations around a locking functionality would change based on whether the model was account or token based, since, for example, escrow works because of fungibility. One member of Subgroup 4 stated that the findings discussed might not apply to non-fungible (token-based) models.

Item 4: Closing remarks

The Chair closed the meeting and thanked Members for contributions.

Attendees

Bank of England

Tom Mutton (Chair)

Danny Russell

Members

Adrian Field, OneID

Alain Martin, Thales

Andrew Flatt, Archax

Ashley Lannquist, IMF

Bejoy Das Gupta, eCurrency

Edwin Aoki, Paypal

Georgios Samakovitis, University of Greenwich

Inga Mullins, Fluency

Joshua Jeeson Daniel, JP Morgan

Julia Demidova, FIS

Keith Bear, Cambridge Centre for Alternative Finance

Lauren Del Giudice, Idemia

Lee Braine, Barclays

Mark Shaw, Spotify

Paul Carey, Stripe

Richard Brown, R3Sarah Meiklejohn, IC3

Tim Moncrieff, Visa

Vikram Kimyani, Oracle

Apologies

Alan Ainsworth, Open Banking

David MacKeith

Dominic Black, Ledgerz

Gary King, Lloyds

Geoff Goodell, UCL

James Whittle, Pay.UK

Kene Ezeji-Okoye, Millicent Labs

Lars Hupel, Giesecke+Devrient

Michael Adams, Quali-Sign

Paul Lucas, IBM

Simon Brayshaw, Motorway

Tom Beresford, Starling

Will Drewry, Google

  1. Locking mechanisms refer to programmability primitives 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.