I was extremely fortunate to be invited to the recent BIS Securing The Future Monetary System conference in Basel.  This was a terrific event, bringing together some of the cleverest people in security from the worlds of banking; academia and industry to discuss the issues faced in securing our future CBDC based monetary systems.

I was there to speak about the technical considerations in Offline CBDCs, however I was also fortunate enough to take part in a roundtable on CBDCs and machine-to-machine payments, which was utterly fascinating, and produced some great insight and thinking that I thought I’d share, within the bounds of the Chatham House Rules. First, some background.

The call for Machine-to-Machine CBDCs

The GBIC model of three distinct types of CBDC is one that has always appealed to me. The GBIC is the voice of the main German banking associations: the National Association of German Cooperative Banks (BVR), the Association of German Banks (BdB), the Association of German Public Banks (VÖB), the German Savings Banks Association (DSGV), and the Association of German Pfandbrief Banks (vdp).  It was fascinating to have such a conservative organisation discussing not two but three kinds of digital currency in their digital euro policy paper. They call for a digital currency ecosystem encompassing:

  • A Wholesale CBDC, issued by the central bank but for use in capital markets and interbank transfers. The GBIC’s experts are calling for this form of the digital euro partly because, by adopting this approach, the ECB would be able to include further digitalisation of central bank accounts in its project. The ultimate aim is to achieve improvements which can benefit consumers, enterprises and also the banking sector.
  • A Retail CBDC, again issued by the central bank to be used by private individuals in the euro area in the same way as cash for everyday payments, e.g. to retailers or government agencies. It should be possible to use the digital euro like cash, anonymously and offline. They assume that credit institutions will provide consumers in Europe with the necessary smart wallets.
  • An Industry CBDC. What the GBIC call “tokenised commercial bank money” which will be made available by commercial banks to meet a corporate demand arising from Industry 4.0 and the Internet of Things. Tokenised commercial bank money could facilitate transactions based on “smart” – i.e. automated – contracts and thus increase process efficiency.

In other words, in addition to wholesale CBDC for institutions and retail CBDC for people, they want industrial CBDC designed for Machine-to-Machine payments to satisfy the demand that will arise from the Internet of Things (IoT). Therefore a roundtable session considering Machine-to-Machine CBDCs was going to be interesting. The round table had a great flow, considering three aspects of Machine-to-Machine CBDCs starting with:

What do we mean by CBDC M2M Payments?

Do we mean human induced CBDC Machine-to-Machine payments, or do we mean a fully autonomous exchange of assets? i.e. me pressing a button on my car user interface to allow it to pay the fuel dispenser for my electricity / diesel / petrol or a machine doing it’s own thing, buying and selling as it goes. Of course we went for the second one, much more interesting. As an example, the group considered a set of solar cells generating and putting electricity into the network, and an electric vehicle consuming that energy and paying for it.  Where is the human here? Are they explicitly involved in the payment process, well no, so do we have humans at the edge, disintermediated by the system, only involved at set up? Just what are the implications here?

We then consider whether these payments are open loop or closed loop CBDC payments. For Machine-to-Machine, a closed loop CBDC ecosystem could bring benefits, where micro-payments can take place between machines, predominantly offline, only going online occasionally, effectively enabling the machines to cash in and cash out. What if we go further and consider a fully autonomous AI machine, providing services, consuming resources, making and receiving payments as it goes, can this legally be the case, or is there always liability with humans accountable? Something that needs serious consideration.

How does regulation fit in?

How do we regulate for machine-to-machine CBDC payments? Indeed is regulation required? Of course it is, but not we cannot wait for this to appear retrospectively, too often in payments the regulator is playing catch up. For machine-to-machine CBDC payments, visionary regulation is required.

Regulators need to work together with the industry in order to understand machine-to-machine use cases, liabilities and put regulation in place ahead of machine-to-machine CBDC payments taking place. It was the view of the table that proactive, visionary regulation won’t be perfect, but principals-based regulation is needed in order to provide standards and trust. The table postulated that this could be implemented by smart contracts, with regulation at the edge where it can make use of the standard / regulation in place at that time, allowing change to quickly propagate. For example, we can imagine a tax compliant CBDC system for machine-to-machine CBDCs, updating to the latest tax regime. This may bring us to a place where technology, regulation and governance are intertwined, boundaries are not clear, where we have rails and assets. Good, well considered, clear regulation is essential to manage this.

What can we learn from the systems we have in play today?

Today we have bad actors in the system, using their own AI engines to feed their rules into the system.  So how do we apply the brakes? If / when things do go wrong where is the liability at the end of the chain? Is it even possible to find who is responsible in such an autonomous AI system with many interactions and components?

We concluded that to does this effectively we need to build the system with ethics embedded in the system, and perhaps for visionary regulation for machine-to-machine, or robot to robot, CBDC payments Asimov’s laws are not a bad place to start.

It was a fascinating event, with great conversations on all aspects of CBDC solution security. If you want to know more about CBDCs then please get in touch.

4 comments

    1. Hi Lance, yes it’s fascinating.
      It really depends on the design of the retail CBDC, and how many offline payments it would be allowed to make.
      The GBIC model sees the IoT CBDC as a predominantly offline CBDC, many payments, small value, so I tend to think that a dedicated IoT CBDC makes sense.
      For larger M2M payments, potentially with more risk, then an Online retail CBDC would work fine.

      1. How is a closed loop CDBC different from a private ledger shared between participants in the closed loop ecosystem, Gary?

        The question of liabilities that you raise has direct implications for the creation of juridical identities for machines in the same way that corporations or companies created juridical identities for groups of humans. Fun times

      2. Hi Nick, yes you’re right, a shared private ledger is one implementation option for a closed loop CBDC. There will be various ways of doing this, it will come down to the type of IoT machines in the ecosystem, the connectivity capability, value of transactions etc, etc. It’ll be interesting to see the different approaches as they emerge.
        Liabilities is fascinating in this space, and that’s before we start talking about Smart Contracts 😉 This is why we think the regulators need to put some ground rules down early. As you say fun times ahead!
        Happy New Year to you, take care.

Leave a Reply

Discover more from Consult Hyperion

Subscribe now to keep reading and get access to the full archive.

Continue reading


Subscribe to our newsletter

You have successfully subscribed to the newsletter

There was an error while trying to send your request. Please try again.

By accepting the Terms, you consent to Consult Hyperion communicating with you regarding our events, reports and services through our regular newsletter. You can unsubscribe anytime through our newsletters or by emailing us.