Digital Pound Lab: Phase 2 update

Phase 2 overview

Phase 2 of the Digital Pound Lab focused on exploring how a digital pound might support innovative retail payments use cases. 

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 included 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. Unlike allowances, the money held in locks cannot be spent until the conditions are met or the lock expires. 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. 

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.

CRM.COM

CRM.COM explored how a digital pound could support customer rewards, loyalty schemes and digital-wallet balances within a commerce platform. The demonstration looked at how digital pounds could be used to back a customer reward scheme, while enabling digital pound settlement when funds entered or left the platform.

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.

Finoxy Labs

Finoxy Labs explored how a single wallet could support everyday consumer and small-business payment journeys, including rental deposits, parking payments, request-to-pay and conditional-payment services. The demonstration used programmable features, including locks, to support scenarios where funds are reserved and released only when agreed conditions are met.

LINK in collaboration with Consult Hyperion

LINK and Consult Hyperion explored how consumers could withdraw and deposit cash directly into digital pound accounts via ATMs, highlighting how digital pound services could connect with LINK’s existing ATM networks and infrastructure.

Leeds City Council x Aire Logic

Leeds City Council and Aire Logic explored how programmable payments could simplify recurring local-authority payment services such as council tax and other local-authority charges. The demonstration considered how conditional payments could help simplify payment collection while improving transparency and auditability.

Monesave

Monesave explored how users could initiate and authorise payments through natural voice interactions using wearable devices such as bracelets and rings, supporting more accessible payment experiences. The demonstration used voice authentication to enable users to check balances, top up wallets and make payments.

NOBO Finance Limited In collaboration with Dun & Bradstreet and Polygon

NOBO Finance, Dun & Bradstreet and Polygon explored how digital pound services could support SME credit assessment and settlement in cross-border trade finance. The demonstration combines consent-based wallet transaction data, open finance and commercial intelligence to create a reusable SME “bankable profile” and shows an electronic bill of lading backed invoice factoring flow in which an exporter receives a stablecoin advance and a UK importer completes final settlement in digital pounds.

OneID

OneID explored how digital verification services could support onboarding, establish trust between participants and help enable AI-assisted payment journeys. This does not imply that a digital pound would require digital ID; instead, the demonstration explores how Payment Interface Providers could choose to use digital verification services to make onboarding quicker and more convenient for customers.

The Scottish Centre of Excellence in Digital Trust and DLT

The Scottish Centre of Excellence in Digital Trust and DLT explored how funds could be reserved and automatically released when agreed conditions were met, helping to support trusted trade, reduce settlement risk and enable new approaches to trade finance and working capital.

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.

Transpact.com

Transpact.com explored how delivery-versus-payment arrangements could support marketplace transactions, deposit protection and other transactions where trust between buyers and sellers is important. The demonstration considered how funds could be held securely and released only when agreed conditions were met.

Yotra Ltd

Yotra explored how digital pound capabilities could support offline payments for public transport using existing smart-ticketing infrastructure. The demonstration considered how locked funds could be provisioned to a device and spent with a single tap while offline, before being settled through digital pound services when connectivity was restored.