Digital Pound Lab: Phase 2 update

Phase 2 overview

Following the conclusion of Phase 2, we will publish further learnings from both phases, including additional participant use case videos. We also expect to host a Phase 2 webinar, where we will explore the use cases, as well as how work in the Lab may continue. More details on the webinar will be published soon.

Like Phase 1, Phase 2 involved developing two sets of demonstration use cases:

1. Bank-developed use cases: built by the Bank of England (the Bank) in partnership with Accenture (the Lab delivery partner) to demonstrate some of the Lab’s capabilities.
2. Participants’ use cases: built by the Phase 2 participants.

By sharing these demonstrations, we aim to show how the capabilities built in the Lab can support a range of use cases, and how innovative payment services can be developed from a basic set of building blocks, including aliases, trusted or verifiable credentials, programmability features, and common standards.

Figure 1: Overview of the Digital Pound Lab

Bank-developed use case demos

The Lab includes a range of capabilities intended to stimulate ideas for innovative use cases. For details on its design, including capabilities, see the Digital Pound Lab main page.

In Phase 2, we expanded and further developed use cases identified in Phase 1, alongside exploring additional use cases. For details on the key outputs of Phase 1, see the Phase 1 update.

Figure 2: Sample applications that support the demonstration of use cases in the Lab

All aliases and personal details presented in these demonstrations are fictitious and used solely for experimentation purposes; they do not relate to any real individuals or businesses.

One-time aliases

Users can make payments using one-time aliases. These are a type of alias designed to be used for a single transaction. They are generated as a random string that can only be used once, enabling users to conduct a transaction in private and preventing the recipient from seeing all their payment details. For example, when paying someone for a one-off good or service users may elect to use a one-time alias. The one-time alias can still be used for refunds, if required.

In the videos below, the payer’s name is shared with the recipient alongside the one-time alias, but it would also be possible to configure this so the recipient only sees the one-time alias. The first video shows the use of the one-time alias for a person-to-person payment, and the second shows a person-to-business payment.

Confirmation of Payee

Confirmation of Payee is an important service in payments today. 

The video below illustrates two potential outcomes: an exact match, where the payee name being entered fully matches the name that the alias belongs to; and a close match, where there is a small inconsistency between the name entered and the payee’s record. Whilst not shown in this video, there could also be no match, where the name entered does not match or is not sufficiently close.

Chat application – kitties

We previously demonstrated the kitties use case, enabling members of a group chat to contribute funds to a shared cause, in Phase 1, as an example of how third party applications could innovate when connected to wallets in the Lab. 

As mentioned in the Phase 1 update, kitties enable members of a group chat to contribute funds to a shared cause (eg a birthday present or event). We developed this use case using locks, which set money aside until the condition set by the user is met (eg a certain amount is raised or a certain number of people have paid). If the lock expires before the condition is met, the money, previously set aside, is returned to the relevant payees. 

The video below shows an expanded user journey, from the perspective of both the payer and payee organising a kitty in a group chat, through to the payments appearing in both wallets.

ESIP connections 

External Service Interface Providers (ESIPs) are third-party service providers that do not own the customer relationship but can, with user permission, enable payment or value-add services (such as budgeting tools). 

In the Lab, each ESIP connection creates a separate alias linked to the user’s primary wallet alias. This ensures that, if a third-party application is compromised, the user’s wallet information remains protected. Users are also able to disconnect their wallet from the third-party applications. 

The video below shows an example of how ESIP connections could operate in the Lab, with a user connecting their wallet to the chat application. This allows the user to authorise payments up to a specified limit from within the chat application, meaning they can make payments directly in the chat application without having to open their wallets. Users also have the option to choose to authorise each payment individually via their wallet if they prefer. 

This capability helps enable a number of use cases within the chat application, including P2P payments and ‘kitties’ (collaborative payments).

Allowances payment via e-commerce

The allowance use case was also developed in Phase 1 of the Lab. As mentioned in the Phase 1 update, allowances enable a user to permit another user, application or merchant to spend money from their wallet up to a specified amount and within a specified timeframe. Additional conditions can also be set – for example, the primary user may require that each payment is approved before it goes through. 

Allowances grant permission to spend – they do not set funds aside. The primary user can still use the money themselves even when an allowance has been granted.

In Phase 2, we extended allowance payments to e-commerce. The video below shows how users might use an allowance they’ve been granted to make purchases on the Baseline website.

Streaming micropayments

The Lab supports micropayments for streaming digital content. Users can, if they choose, make conditional, usage based payments, paying only for the content they consume. This could give users greater control over their spending.

The video below gives an example of how the use case could be implemented using two party locks with multiple drawdowns. Locks refers to a programmability feature that enables users to set money aside until certain conditions are met.¹ In this example, a user can stream an audiobook and pay only for the amount they listen to, with payments made to the vendor incrementally (eg per minute of content consumed).

Participant use case demos

We invited organisations to apply to test use cases in Phase 2, focusing on both innovative payment services that do not exist today and how a digital pound could improve existing use cases. We selected Phase 2 participants in accordance with the Lab’s terms of participation.

Participants in Phase 2 include: 

• CRM.COM
• Crunchfish
• Finoxy Labs
• Focus on Monesave
• LINK in collaboration with Consult Hyperion
• Leeds City Council x Aire Logic
• NOBO Finance Limited In collaboration with Dun & Bradstreet and Polygon
• OneID
• TECHT Labs
• The Scottish Centre of Excellence in Digital Trust and DLT
• Transpact.com
• Yotra Ltd

Below are demonstration videos from two of the current participants: Crunchfish and TECHT Labs. Other demonstrations will be included in the final Phase 2 update, which will be published following the completion of Phase 2.

The policy choices in these demonstrations were determined by the participants for the purpose of the experiment and should not be taken as an indication of future Bank policy. In addition, inclusion of participants’ demonstration videos in this update does not imply Bank approval or endorsement of the firms, their products or their services.

Crunchfish

Crunchfish developed an offline payments proof of concept demonstrating how deferred offline payments using a reserve, pay, and settle lifecycle could be enabled by adding a layer on top of a digital pound infrastructure. The demonstration includes offline payments at point of sale, showing online reconciliation as well as security controls to mitigate the risks of double spending.

TECHT Labs

TECHT Labs developed a conditional business-to-business payment solution, using their own smart contract platform to integrate with Lab components. The demonstration shows payments being locked and automatically released once agreed conditions are met.

^{1 Unlike allowances, the money held in locks cannot be spent until the conditions are met or the lock expires.}