Written by Introduction
We were delighted to get a lot of good feedback on Neil’s previous blog on Mondex Memories and CBDCs and its relevance to CBDCs and thought it would be interesting to respond to some of the more interesting – and difficult – points raised in a follow-up blog. Before addressing those I wanted to put the Mondex program into some historical context. They were very different days – we didn’t have an intranet until 1996, let alone internet access. There were no SDKs – although actually we did build a precursor to one of those – or APIs and the idea of remote payments was still in its infancy (although we did that too).
Back in the day – and in my case the day was 18th February 1991 – I became the most junior member of Neil’s small team specifying and developing Mondex and its associated technology. By the time we finished, a decade later, I was running the day to day operation of a large specialised software engineering group. What happened in between was that we helped – along with a lot of other clever people – lay the foundations for the modern retail payments industry.
When we started, based on the invention of Tim Jones and Graham Higgins and led by Dr David Everett, the technology we were dealing with was incredibly rudimentary. Making secure person to person transfers between smart cards was almost impossible with the smartcards of the day. We had microprocessors with 2K of EEPROM and no cryptographic coprocessor support. The chips had no protections against any kind of error. My very first task was to figure out how to run RSA on one of those things to manage the Mondex cryptographic payment protocol (my answer, roughly, was you can but you probably want to go for lunch while waiting for it to complete).
By the time we finished, we had developed half a dozen unique smart card operating systems, culminating in Multos, with cryptographic support, data protection in both hardware and software, advanced memory management capability and fully firewalled multi-application execution, all certified to the highest security levels available and capable of running both Mondex and EMV at commercially acceptable speeds.
We were there before EMV, before Javacard and were the precursor to nearly every other development in payment cards ever since. Of course, it was a time during which there was lots of innovation in smartcards – there were many innovative e-purses out there being developed and I don’t intend to credit the Mondex team with the sole invention of these ideas. But we were unique in that Mondex was unaccounted, and that created some unique problems in design and the technology stack – and means that many of the ideas being discussed for CBDCs now were basic requirements for the Mondex program then.
Oh, and we survived being bombed out of the NatWest Tower in 1993! On to the specific points …
Lack of developer support
One of the points made in commentary was that Mondex didn’t succeed because it didn’t give the developer community enough support. We wouldn’t totally disagree with that – there were aspects of the commercialisation that struggled, largely because of factors outside of the control of the technical teams. And, of course, back in the mid 1990’s there was still a bit of a proprietary “command and control” attitude to these things. For a CBDC program to be successful it really does need to ensure that developers and third parties can engage effectively.
A particular challenge for any retail payments system is to allow for ready integration with disparate merchant (bricks-and-mortar and online) systems. For a CBDC, if the central bank chooses to use the retail banks as a distribution channel then they must be enabled to offer competing apps while ensuring the integrity of the underlying assets. Beyond that ensuring that fintechs can access and use a CBDC will determine how widely it gets used. Central Banks have the opportunity to create some very interesting competitive situations if they do this well.
Blockchain and CBDCs
A number of good points were made, in relation to Mondex, about whether blockchain is needed to support CBDCs. At one level it’s obvious that the answer is no – a Central Bank, by definition, runs a centralised ledger. As one poster noted, Mondex didn’t need a blockchain to work. However, the underlying question is about accounting. With anonymised e-cash supporting direct peer-to-peer payments then you don’t know who has the value at any one time (this opens up some points on fraud management, which we’ll look at later). If, at best, you only have an imperfect understanding of where the money sits at any given time then that raises some interesting questions about what is on the ledger at any given point.
Most people would probably want their transactions recorded to ensure that if they have a technology issue then they can get their money restored – but some people will want pure anonymous transfers. In a solution available to everyone, then clearly it won’t be possible to mandate that everyone has a mobile phone and network connectivity (indeed the system needs to be resilient to communications failures). So – if value is distributed in anonymous locations what is the purpose of a centralised ledger?
Truthfully, we don’t really see the advantage of blockchain in CBDCs. But you can see a line of argument that would suggest something less centralised. Although if you had a fully convertible cross-border CBDC structure then that might be different – you could, for instance, imagine spending sterling CBDC in Sweden and having the Swedish Central Bank run a node of a global blockchain for synchronisation with the Bank of England. But, frankly, getting to that point seems like a big stretch from where we are today.
Might offline value with P2P payments lead to infinite money printing?
All technology is, ultimately breakable. When some hacker comes along with their quantum computer in a few years, the entire cryptographic underpinning of a CBDC would be broken. Right?
Well, maybe. But probably not.
This issue was at the heart of Mondex. If we assume – as we did – that all technology is ultimately breakable how do you prevent the unlimited printing of money? But of course, in a way, the same issue arises with printed cash. What stops someone from investing in cash printing technology and then running off an unlimited supply of £10 notes? (Google Operation Andreas for the attempt to do just that in the early 1940s.)
The answer with e-cash is the same – largely – as with real cash. Once you’ve bought your printing press (or quantum computer) you can make as much cash as you want – but distributing it without detection is another matter. Getting a lot of fake cash into the Mondex system was hard and, without revealing too many secrets, not all Mondex cash was the same, while maintaining the primary requirement for anonymity. Significant changes in the value in distribution could be detected quickly – although not as quickly as we could today – and addressed. Just as a Central Bank would respond to a lot of fake tenners by withdrawing them and replacing them with new, more secure ones, so could Mondex. Only Mondex could do it quickly because, at some point, fake cash had to come into contact with real purses.
Obviously, the idea that electronic money can be forged is anathema to many. But if you want a CBDC that offers the properties of real cash then that’s an inevitable consequence. The question is not whether it’s possible but how much is tolerable and how you manage it. And, of course, Central Banks were – in the main – supporters of Mondex. They viewed it as a cash equivalent with better controls and visibility of money flows. Without Central Bank support Mondex would never have seen the light of day.
What about privacy?
Mondex was anonymous by design, but that was back in the days before KYC and AML and all of the other compliance rules that now dominate the financial industry. At the time, as a bunch of young and idealistic technologists we saw Mondex as a way of preserving anonymity through electronic cash when all of the other electronic payment instruments were, as far as we could tell, accounted and therefore, ultimately, led to an identity. However, there was nothing in the Mondex design that prevented identity requirements being loaded on top of it.
From a CBDC perspective if the requirement is inclusivity then anonymity, in some sense, seems to us to be a requirement. That clearly runs counter to the prevailing culture of increasing compliance around identity in payments. If there were an effective digital identity scheme in place that could assert that an identity was already in use in the scheme it would be possible to have CBDC accounts with spending limits on them – the problem is not limiting the spend on a single account but limiting the number of accounts that a single individual can access. Of course, that brings us back to digital identity, but that’s another blog entirely …
