A conceptual model for point-of-sale payment with Retail CBDC

Introduction

Central Bank Digital Currency (CBDC) is an emerging development in digital payments, with most central banks worldwide researching, piloting, or even operating a digital version of cash. A common definition includes the following characteristics [1]:

• a digital representation of a country’s or region’s existing currency,

• issued directly by the central bank,

• usable in electronic payments,

• instantly settled, and

• being legal tender.

Furthermore, there is a distinction between Retail CBDC, which can be used by anyone in the jurisdiction, and Wholesale CBDC, which is only available for regulated financial institutions [2]. The name refers to the idea that the former allows for retail payments, whereas the latter would be used by financial institutions exclusively. This paper focuses on retail CBDC and investigates how this new instrument can be used for Point-of-sale (POS) payments.

Two-tier model

Users must have a way to interact with the CBDC ecosystem. Most central banks are exploring a two-tier model, whereby the central bank acts as the sole issuer of CBDC, but intermediaries—such as commercial banks, FinTech companies, and other financial institutions—are responsible for onboarding users and distributing CBDC. In this setting, intermediaries would provide services to users, according to the rules set by the central bank and regulators. In other words, central banks would not be dealing with users directly. This naturally extends to both consumers and merchants.

Wallets and payments

To better understand how CBDC payments differ to today’s prevalent schemes, we first need to look at wallets. In CBDC, they are combinations of hardware and software that serve as containers of cryptographic keys. Depending on the CBDC implementation model, the keys may represent funds directly or serve as credentials to unlock funds stored elsewhere. Wallets should provide an easy-to-use interface that allows holders to conduct transactions. Both sides of a transaction would hold a wallet, and in most CBDC systems, they are symmetric: customer and merchant wallets differ only in their configuration. This allows for flexible payment flows, including direct peer-to-peer transactions. In this way, CBDC wallets resemble physical “cash wallets” more than other forms of digital wallets (see next paragraph).

Public money vs. private money

E-money operators, like PayPal, prepaid credit cards, and mobile money, are becoming increasingly popular around the world [3]. They, too, offer wallets to their customers. Their underlying instrument is a private form of deposit money, typically issued by a non-bank financial institution [4, 5].

CBDC however, is a direct claim from the user to the central bank, even in a custodial scenario (see also Table 1). This means the CBDC holdings managed by a financial intermediary through custodial wallets are not represented on that intermediaries’ balance sheet [6]. The situation can be compared to, for example, securities accounts. In the event of the managing institution’s insolvency, a user’s holdings are not at risk [7]. Consequently, a wallet holder is not exposed to credit risk from an intermediary, only operational risk [8].

For this reason, CBDC payments behave differently from private payment rails because there is no need for a (typically deferred) settlement step. CBDC could change the role of acquirers, with small businesses potentially opting to accept CBDC directly on their own devices without intermediaries.

Structure of this paper

I will first introduce the concept of CBDC wallets and discuss their different types (Section 2), focusing on their design and form factors (Section 2.4). Then, I will explain two methods for initiating payment, namely pull and push, and how they relate to POS payments (Section 3). This includes an overview of technical communication channels to execute a payment (Section 3.1). Finally, I will develop a conceptual model of POS payments, considering the unique characteristics of a retail CBDC (Section 4).

Design of CBDC wallets

In cryptocurrencies and CBDC, wallets are the primary point of interaction between users and the system. While ample studies exist on the former, CBDC wallets are not yet widely investigated in the literature. Fortunately, wallets for both domains share similar traits: They manage cryptographic keys that unlock funds and enable users to transact.

Wallets are the primary way for customers to initiate payments and for merchants to accept payments, therefore they play a critical role at the point of sale. This means that their design is affected by the interaction of hardware, software, UI/UX, security, and the physical environment in which they are used.

CBDC, being a new form of public money, increases flexibility for customers and merchants, providing them with more choices and, therefore, fostering competition. The flip side is that now, many more payment scenarios must be accommodated in the already crowded space.

Wallet types

As a starting point, we can categorize wallets across the three dimensions relevant to this paper: custody [9, 10], embodiment, and offline capability [11] (see table below).

Naturally, the design choices of the overall system, such as the ledger, influences which wallet types are supported for a given CBDC. Yet, this is not an exact 1:1 mapping, so multiple wallet types might coexist in the same ecosystem, as evidenced by the vast number of wallet implementations for cryptocurrencies [12].

The special case of offline capability

One of the most important motivations for CBDC adoption is offline capability. Many central banks investigating or implementing retail CBDC consider offline capabilities to be an important feature, including for the European Central Bank’s Digital Euro [13–15].

Today, payments can be made when both parties are offline, for example, with credit cards. Yet, there are two major differences to CBDC:

1. Credit cards face settlement risk because there may be a few days between payment initiation and the actual transfer of funds. CBDC would be settled instantly and irrevocably.

2. Credit cards are prone to double spending, where users spend more funds than they have available. This is by design: the risk is born by the card issuer, who charges interest. CBDC, being more like cash, does not have credit features and must therefore carefully protect against double spending [16].

Applying this to the terminology from above, existing payment schemes only support a weak form of staged offline payments. In contrast, central banks typically aim for at least intermittently offline payment capability. Implementations would reuse existing technology, such as hardware secure elements, to protect against double spending.

This is enabled by designing the CBDC to transfer value directly from one wallet to another.² Because CBDC wallets are symmetric, a basic merchant acceptance device could be independent of any acquirer and accept a peer-to-peer payment from a customer, just like cash today [17].

Coexistence of online and offline wallets

While some CBDC technology platforms cater exclusively to fully offline operation, with no possibility of using custodial and/or online wallets, the consensus among central banks is that both online and offline operations are desirable.

Consequently, a user could hold multiple wallets, some of them purely for online purposes and some others for (optional) offline use. This mirrors the current financial system, where online balances are held as deposit money in commercial banks, and offline “balances” are held as cash. In CBDC, a user could allocate their funds across different wallets. This could be frictionless, since moving money from one digital wallet to another could be facilitated through, for example, a smartphone, and would not require a trip to an ATM.

Applied to the point of sale, the smartphone used by the customer could represent multiple wallets. The Bank for International Settlements points out that it “is important that any online balances and offline balances are segregated, otherwise it may be possible for a user to spend the same value both offline and online and create a double-spend risk” [11]. Therefore, picking the correct wallet that sends the payment matters.

Obviously, this impacts the user experience at points of sale. In Section 4, I describe the necessary setup for such wallet negotiations.

Wallet form factors

CBDC wallets can come in many forms, evidenced by the existing CBDC proof of concept and pilot projects. The figure above provides some examples:

1. A smartphone, equipped with a wallet app. This app could either access a custodial wallet managed by a user’s preferred intermediary, or funds that are stored in secure hardware directly on the device (e.g., an embedded secure element or a SIM card [18]).

2. A dedicated and/or wearable device with a limited user interface, interacting through NFC. Examples include wristbands, smartcards, smartwatches, and keyfobs.

3. A merchant acceptance device. Examples include portable NFC/Bluetooth card readers that connect to a smartphone and dedicated POS terminals that may be based on a standard mobile operating system like Android. Because of CBDC’s symmetric nature, the merchant device could itself be (i.e., contain) a wallet.

Importantly, any form factor can work in a dual mode: (1) using funds stored directly on the device—which admits offline payments—or (2) serving as a strong authentication mechanism towards a custodial wallet.

In the first (peer) mode, the value transfer is directly executed between two devices. In the second (authentication) mode, the value transfer is authorized by the customer’s device, but executed from the customer’s custodial wallet.³ This means that the card merely serves as a vehicle to authenticate the user to their intermediary.

Offline wallets capable of peer mode are comparable to physical cash wallets. They would also be available for individuals (e.g. children or tourists) without a bank account in the domestic currency.

Comparison to existing POS payment schemes

Current card payment schemes support all of the above form factors, but they can only operate in authentication mode. Traditionally, this was the reason for their delayed settlement since the flow of funds was not triggered immediately after authentication. Modern account-to-account (A2A) payment eliminates this disadvantage by relying on instant payment transfers in the backend.⁹ Still, neither allows for (at least) intermittently offline payments that are instantly settled.

The table above summarizes the similarities and differences of existing POS payment schemes and CBDC.

Payment initiation

In the traditional world of bank accounts and bank transfers, initiation of the flow of funds can come from two different directions (figure above; [22]):

• A standard bank transfer flows from the sender’s bank account to the receiver’s. This is referred to as a push payment because the sender triggers it. Standing orders are also push-based, as are payments in cash.

• The receiver can also initiate the fund transfer: A direct debit (also known as debit order) is an example of a pull payment. Checks can also be classified as pull; even though the payer signs checks, the payee triggers the actual transfer.

Both directions have advantages and disadvantages. Yet, there is a trend towards push payments at the point of sale. One factor driving this are mobile payments, which often use merchant QR codes that customers scan with their mobile devices [3].

Many of these schemes operate as A2A and support instant settlement. They experience rapid user adoption, for example Pix in Brazil [23], UPI in India, and Swish in Sweden [24]. Other countries with a higher market share of debit and credit card payments, for example the United States, are slower to catch on [25].

Pull payments are often associated with settlement delay credit. This is why in the context of CBDC, most central banks only consider push.¹⁰ In other words, funds flow from wallet to wallet at the request of the payer.

It stands to reason that push payments in retail CBDC are most relevant at the point of sale. They could be designed in both the peer and authentication modes. Conversely, pull payments would not be able to work in peer mode.

Communication channels at the point of sale

Zooming in on physical merchant locations, this section describes the technical communication channels that are available at the points of sale, i.e., for proximity payments. For simplicity, I will also assume that the merchant has a “smart” acceptance device, which may come in the form of a standalone POS terminal or a smartphone.

Equipped with such a device, a merchant has the following options to accept a payment:

1. A smart card can be inserted into a card reader, e.g., of a standalone POS terminal or a mobile reader connected to a phone via Bluetooth.

2. A smart card or other mobile and/or wearable device can be touched via NFC.

3. A merchant-presented QR code (either static or dynamic) can be scanned by the customer with their smartphone.

4. A customer-presented QR code (either static or dynamic) can be scanned by the merchant with their POS terminal.

Debit and credit cards mostly focus on the first two (with merchant- and customer-presented QR code payment specified by [27]). The actual payment gets transmitted through a card network. Conversely, A2A schemes mostly rely on merchant-presented QR code, which contain the merchant’s account or wallet number. The customer’s app then initiates a fund transfer to that account.

No existing payment scheme uses any of the communication channels available at the point of sale for actual fund transfer. This is delegated to backend processes at a suitable intermediary, either the customer’s own bank (like in A2A schemes), or the merchant’s acquirer (like in debit and credit card schemes).

This is where retail CBDC provides a new technological opportunity: NFC and Bluetooth could unify payment initiation and execution.¹¹ The next section develops a conceptual model how this payment scenario can coexist with other traditional methods, as well as how QR codes could be leveraged for CBDC payments.

Payment model for CBDC

To summarize, the earlier sections of this paper have established

• the fundamental characteristics of a retail CBDC, as an instantly-settled payment instrument that is a direct liability of the central bank, and therefore carries no counterparty risk;

• distinguishing characteristics of retail CBDC vs. other instruments, and its similarity to cash;

• different wallet types and consumer choice, including the option for offline payments with direct value transfer between wallets; and

• the higher relevance of push payments vs. pull payments at the point of sale.

Based on this, the remainder of this paper introduces an existing mechanism to distinguish between different payment options at the point of sale and enhances this concept to enable CBDC payments.

Consumer choice and complexity

As discussed earlier, users will have ample choices about wallet form factors. For example, they may choose to only use custodial services through an intermediary, only use a smart card, or a combination thereof. In developed economies, it is likely that users may opt for a smartphone to access their various wallets.

This poses a challenge for UI/UX design. Imagine a customer wanting to pay at a store with their smartphone. On the smartphone, they may have a banking app as well as a credit card (e.g., in Apple Pay), a CBDC wallet app, and additionally offline CBDC holdings stored on the smartphone (e.g., in the SIM card). The customer now faces the choice to pick the appropriate payment channel. Both parties may have (diverging) preferences: The customer may prefer to use their credit card due to cashback and the merchant may prefer to accept CBDC due to lower fees. A similar issue arises should the customer present a smart card with multiple co-badged schemes.

List of AIDs (samples)
American Express	A00000002501
Discover	A0000001523010
MasterCard	A0000000041010
Maestro	A0000000043060
…	…

This is not a new problem. Domestic and international card schemes co-exist today on shared infrastructure, i.e., customer cards and merchant terminals. In a process known as Application Selection [28], mutually supported schemes, then select from that list based on prioritization on the customer’s card (see figure above).

In the prevailing payment landscape, these complexities are well understood. Current technology provides sufficient flexibility to integrate new payment schemes. CBDC could therefore be seamlessly integrated, although certain specialties must be considered. This mainly concerns offline payment, which is discussed in this section. Note that this technology can run on cheap commodity smartphones and on existing POS terminals, limiting merchants’ need to invest into additional hardware.

Contact and contactless (NFC) payments

Setting aside QR code payments for now, CBDC would introduce two new applications corresponding to the transfer modes discussed above: direct value transfer between wallets (peer mode) and authentication towards a custodial wallet (authentication mode).

In practice, however, the peer mode is vastly different from existing payment schemes: they were not designed for direct value transfer. Additionally, it would be capable of offline payments.

The Bank of England, in a POS feasibility study, has investigated this flow (among others) [29]. They define the peer mode to be “a payment […] made between two devices without network connection, supporting offline payments.” Note that this leaves open whether the payment recipient is a merchant or any other CBDC wallet holder.

The Bank’s study found that the existing EMV applications “were not appropriate for storing offline balances.” To transact with those offline balances, the Bank had to implement new software running on the customer device, as well as “a new kernel [on the terminals] that could interact with it” [29].

This result highlights that CBDC presents a new means of payment that enables more use cases, beyond what is available in the market today. Merchants could decide whether to accept payments to a hardware wallet contained in a smartphone or POS terminal or forward them to a custodial wallet. This selection can also happen dynamically depending on the availability of an online connection, but it could also be influenced by regulatory considerations.

Despite the broad agreement that CBDC should enable such offline payments, there is little progress towards standardization. This may be caused by the fact that the implementation of an offline CBDC payment protocol is highly sensitive to the design decisions about the overall CBDC system, which differ widely across countries.

Conversely, the authentication mode can work similarly to existing payment schemes. One of the five lots of the Digital Euro tender, entitled Secure Exchange of Payment Information [30, 31], is likely to deal with this.

The European Central Bank has not shared any more details yet. It is plausible though that a card-initiated CBDC payment could mimic an A2A payment, with the customer’s card carrying authentication information towards their custodial CBDC wallet. As the study by the Bank of England demonstrated, this could be compatible with existing EMV kernels [29].

The figure above shows a possible payment journey. The following steps are executed:

1. Customer presents a payment device, such as a smartcard.

2. Customer device and merchant terminal negotiate mode, resulting in either (a) peer or (b) authentication mode.

3. The flow branches:

   1. In peer mode (illustrated in red) ...

      1. The merchant terminal instructs the customer’s hardware wallet contained in the smartcard to initiate a peer payment.

      2. The customer’s wallet transfers funds offline to the merchant’s wallet contained in the terminal.

      3. Optionally, the terminal can later (or immediately) forward the funds to the merchant’s custodial wallet. ¹²

   2. In authentication mode (illustrated in green) ...

      1. The merchant terminal contacts the customer’s bank, forwards authentication information, and initiates a payment. ¹³

      2. The customer’s bank transfer funds online from the customer’s custodial wallet to the merchant’s custodial wallet.

      3. The merchant’s bank notifies the terminal that the payment is completed.

There is no clear picture yet of how a mode would be selected. In addition to preferences configured by the customer’s device, either by the issuer or the user directly, the following considerations might come into play:

• availability of online connection (in case both parties are offline, then payments must be executed directly between hardware wallets);

• local regulation regarding acceptance limits (non-merchants may only be allowed to accept some maximum amount offline to prevent money laundering); and

• presence of secure hardware in the POS terminal (NFC-enabled cheap smartphones may not have the necessary technology to accept offline payments).

However, because online and offline CBDC balances are segregated, it seems clear that offline payments should serve as a fallback option. Otherwise, users may be forced to top up their hardware wallet frequently.

Depending on the form factor, the UI/UX can be designed to require little user intervention at the point of sale. Take Apple Pay: users can set a default card that is used when the side button is pressed. Physical cards do not allow this flexibility.

For merchants, the trade-off is similar. Due to associated high risks, they may not be interested in holding large offline balances in their device. As described above, should the device break, their income would be lost. The European Central Bank has clarified that businesses have a “zero daily holding limit” of Digital Euro, with only “intraday holdings possible” [32], albeit not for technical, but rather regulatory reasons.

Point-of-sale terminals may need to be upgraded to consider dynamic factors in Application Selection. From the consumer side, the central bank could provide sensible defaults: e.g., on a smartphone, to use online payments whenever possible. This should prevent overburdening users with choice. Combined with an auto-top up feature where a minimum balance on a hardware wallet is maintained, this could enable a frictionless payment experience. Additionally, regulation and lower transaction fees could lead to CBDC being preferred over debit and credit card schemes in the market.

QR code payments

Payments with merchant-provided QR codes are easy to implement, provided no offline support is required. This approach closely follows A2A payments.

To accept a CBDC payment, the merchant’s POS device could generate a dynamic QR code containing the merchant’s wallet address, the amount, and a unique transaction ID. The customer scans the code and initiates the transaction through their wallet app.

Fortunately, adding a QR code payment option can be designed unobtrusively. A suitable POS terminal can display a QR code and wait for an NFC connection simultaneously. The customer simply chooses to do one or the other. Should the merchant not have online connectivity—for example, because of an outage—the QR code would not be displayed.

Therefore, the customer’s behavior (by scanning a QR code) directly and unambiguously selects the payment flow.

But this assumes that only one QR code standard is in use in a country and that that standard has either been purposely designed or has been made compatible with CBDC. Already in 2021, the World Bank has identified a “proliferation of QR codes in the market, harming compatibility and customer experience” [21, 33]. As a solution, they suggest harmonization, for example, by central banks taking a national approach. This has been conducted successfully in the Bank of Thailand’s retail CBDC pilot, which also tested offline payments [34].

Discussion

David Birch, a financial services advisor, agrees that “CBDCs have to work offline” and asks, “why not make all of the transactions offline so that there are no scaling issues?” Birch argues that this would simplify the “whole design and implementation” [35].

This may be true from a technical perspective. But it is also not a silver bullet: there are additional non-technical arguments why online and offline payments will co-exist well into the future. They represent the fundamental trade-off between accessibility and resilience. An online balance can be easily accessed through multiple devices, and device loss does not imply loss of funds. For offline balances, it is the exact opposite.¹⁴

Even today, many POS terminals support a dozen different card payment schemes, domestic and international. With no standardized cross-border retail CBDC on the horizon, there is little chance of domestic CBDC crowding out major card networks.

It is, therefore, imperative that a retail CBDC design integrates into the existing payment landscape. A well-designed point-of-sale experience can avoid the impression of fragmentation while still realizing efficiency gains provided by instant settlement and low transaction fees.

An interesting side effect of the CBDC technology is that the peer payment mode could also be provided in non-proximity situations. Direct value transfer not only works via NFC or Bluetooth but could also be conveyed through 4G or Wi-Fi networks. Birch calls this “edge transactions”.

Conclusion

There is no doubt that retail CBDC is moving forward, with the Digital Euro currently being one of the most prominent projects. The European Central Bank clarified that offline capability and merchant payments are within the scope of the Digital Euro. Similarly, the Bank of England has investigated point-of-sale payments through a proof of concept, analyzing the implementation of three different payment modes [29].

Globally, the Bank for International Settlements observes that “throughout 2023, both retail and wholesale CBDC work progressed to more advanced stages” [36].

This has led to user adoption becoming an increased focus of research. Yet, as Lin and Chen point out, “there is a gap in the research on CBDC consumer adoption and its UX” [37]. Within that small body, there is even less treatment of POS payments [37–40].

This paper sought to contribute a conceptual model for the interaction between customers and merchants through CBDC wallets. Because wallets can work both online and offline, they can contribute to increased resilience and financial inclusion. Instant settlement and CBDC being a central bank liability also reduce risk and enable more flexible payment scenarios. The model can also be applied to other forms of tokenized monies, such as stablecoins or tokenized deposits.

However, this also leads to an increase in complexity. To some extent, this can be alleviated by leveraging existing standards (e.g., EMV for authentication mode), which are suitable for online CBDC payments. QR codes can also be offered unobtrusively by integrating CBDC wallet addresses into domestic or international QR code standards.

The remaining challenge is the user experience for offline payments. I have presented an approach based on the existing Application Selection mechanism of POS terminals to automatically select the source of funds, depending on static and dynamic factors. This does not prevent tech-savvy users from defining their preferences. On the merchant side, smartphones could also serve as acceptance devices, lowering the barrier to conduct business.

The burden is on central banks and technology providers to adequately weigh technological trade-offs and provide reasonable defaults. However, more research is needed to understand user behavior when confronted with new payment methods. This is necessary to foster user adoption and to ensure that retail CBDC becomes successful.

Acknowledgements

I thank my colleagues Nicole Saleh, Charalampos Karagiannis, Vratul Kapur, and Raoul-Thomas Herborg for their comments on an early draft of this paper. Special thanks go to John Kiff, who has contributed numerous suggestions for improvement. I appreciate the comments from the anonymous referees at JPSS, which greatly improved the paper. This work has been partially supported by the Federal Ministry of Education and Research (BMBF), Verbundprojekt CONTAIN (13N16582).