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
-
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.