Written by CBDCs are everywhere – and nowhere. Everyone is discussing them, but almost no one is actually deploying them. Sure, this is in part due to the early stage thinking that is going into working out what is actually required but it’s also due to the tricky business of actually working out how they would be implemented. Developing a retail payment solution is a lot harder than creating a Central Bank backed payment instrument.
The list of problematic issues is long, but we’ll look at three of them here. Firstly, who actually provides the wallets that users will interact with? Secondly, who takes liability when something goes wrong? And thirdly, how does a retailer actually accept a CBDC? But let’s be clear, these are simply the first round of issues.
Deploying a CBDC is anticipated to require that users – consumers, merchants, etc – will need to access a wallet. Now, in this context wallets are really just a place to provide a user interface and a secure storage mechanism. What is actually being stored is itself a matter for some debate, but we won’t worry about the token versus account argument here. Now clearly the wallet provider has a key role in the provision of CBDCs into the market but it’s not at all clear who would do this – or why. It would, of course, be possible to mandate that existing regulated payment institutions provide wallets – but CBDCs are generally presented as a means of circumventing the existing financial ecosystem and anyway, previous experience of mandating banks to provide user interfaces hasn’t led to great outcomes.
Most likely it seems that wallet providers will be driven by for profit business opportunities and will need to be lightly regulated – if they are regulated in the traditional sense at all. In this context it seems reasonable to imagine wallet providers will develop their own business models, some of which will be based on end user propositions that aren’t CBDC centric. The CBDC would just be a low-cost (hopefully), instantly settled payment option that underpins the actual business of the wallet provider. Quite how that squares with the idea of inclusivity that underpins most CBDCs is hard to imagine – but finding ways of allowing financially excluded individuals to participate in a CBDC will require some smart thinking. More on that another day.
The next challenge is liability. As we know with card payments, liability can sit with any of the parties (apart from the schemes) because, at various times they are in possession of actual funds. So, for example, an acquirer is required to stand-in for a merchant if a refund is required and the merchant is unwilling to pay. The acquirer handles the funds being settled on the merchant so they can use this cashflow to fund disputes if required. In CBDCs there is no such funds flow – the intermediaries never touch the funds, which remain securely stored in the settlement systems run by the Central Bank. So what happens when my pair of shoes don’t arrive and the merchant refuses to refund me? Or when the car dealer goes bust before my shiny new Tesla arrives?
Finally, what about acceptance? If we want merchants to accept a CBDC we’ll need to find a way for them to do this that doesn’t involve ripping out existing systems or significantly changing them. If we’re genuinely supporting inclusivity we have to assume that not all users will have smartphones. Enabling users and merchants with CBDC capability under these circumstances is going to require some clever reuse of existing technology. Alternatively we need to rethink some of the assumptions we’re currently working to.
Of course there are lots of other issues – but there are obvious potential solutions for many of the challenges currently being investigated, such as whether systems can be scaled to meet demand or whether offline can be securely implemented. We know we can solve these, even if there’s work to do to agree how. There are more fundamental issues that we’re going to need to resolve if CBDCs are ever going to be deployed. Rules around what a wallet provider must do, rules around liability, rules around acceptance.
Sounds a lot like a payment scheme, doesn’t it?
