The emergence and development of cryptocurrencies and Blockchain technology has increased interest in cashless societies and digital currency. As a result, governments and central banks throughout the world are considering the use of government-backed digital currencies. John Davies and Lars Hupel explore the distinctiveness of CBDC compared to cryptocurrencies. They emphasize the technical underpinnings, architecture, and practical applications of CBDC, focusing on its potential to facilitate offline payments, enhance security, and ensure efficient, instantly settled transactions. The conversation underscores the flexibility of CBDC and its coexistence with existing payment methods, making it a compelling topic for tech-savvy individuals. This discussion offers technical audiences valuable insights into CBDC's technical foundations and its transformative potential in the digital payment landscape.
Lars Hupel: Yes, thank you. My name is Lars Hupel, and I work as a chief evangelist in a German company called G&D, Giesecke Devrient. That's a bit hard to pronounce so we always say G&D. And the company works in, broadly speaking, payments, digital infrastructure, security. I am an evangelist in the section for digital currency.
John Davies: Excellent. As I said, my name's John Davies. I'm CTO, one of the co-founders of a company called Velo, Velo Payments, where we've stayed very clear of cryptocurrencies. Hopefully, well, I'll explain for obvious reasons, but we do traditional payments in the United States domestic cross-border, Europe, UK. We've just launched a product in the UK for open banking, which we should be rolling out in Europe as well. As I said, very much traditional leading-edge payments, but outside of the crypto side.
New vs Old Payment Methods
John Davies: So, what does an evangelist do? Are you evangelizing your products or you're evangelizing the technology behind them?
Lars Hupel: Well, I guess I'm explaining things. That's the general idea. And it's not just about the product itself but also, generally speaking, the space that we're working in, which is Central Bank digital currencies, or CBDC for short, which also has nothing to do with cryptocurrencies.
John Davies: Good.
Lars Hupel: So Central Banks are investigating kind of bringing the physical cash into the digital world so that you can have a payment instrument that works both online and offline, is backed by the Central Bank, guaranteed by the government, and so on and so on. This is kind of a continuation of one of our core businesses, which is G&D is a cash company. So we are printing cash, we are offering cash management solutions. And now we're also getting into this CBDC space for a long time, talking with Central Banks around the world.
One of the things that I do is explain the product that we're developing, a solution for Central Bank digital currency, but also more broadly going to conferences like GOTO Amsterdam and explaining what the hell digital cash is in the first place, why you should care, why it's interesting from a technology perspective and also try to kind of bring both the economic point of view and the technical point of view together, and see how they align.
John Davies: I like the idea of printing cash. Can I have a sort of testing rig at my house?
Lars Hupel: No, like, they don't even let me near the printing machines.
John Davies: I can imagine. I mean, this is predominantly Java, this conference, I'm guessing your background, like mine is Java?
Lars Hupel: Quite a while ago, yes. But funnily enough, at some point, I don't even program that much anymore. So, I'm an engineer at heart. But nowadays I just do workshops mostly. But I do have a Java and Scala background, so I've been doing open-source Scala for about 10 years.
John Davies: Oh, cool. Okay.
Lars Hupel: So, that's been a while.
Technology and Programming Languages in CBDC
John Davies: Yes, it's interesting to see where the languages fit in. I was... One of my talks a couple of days ago was on processing astronomical data, and one of the audience asked, why are you using Java for this? It's Java is still a predominant language, I think, for this sort of backend, for certainly for people in this conference. But I'm curious as to in your world, is it, do you still see Java as the strongest language, people aren't moving in, and Scala it's on the JVM, but do you not see any other languages?
Lars Hupel: I think from my perspective, which was also a bit surprising to me because I always thought of the financial world as being quite conservative, that the language stops mattering so much when you container array all your applications. So we're building our product cloud native. So it's, everything is dockerized. We have some components that are written in Go. We have some components that are written in Java. We have clients side things as well, but we thought that we would need to go to the banks and explain to them what Docker is and how to run it. But it turns out they already have Kubernetes running. So, to some extent, the language doesn't matter anymore. Because you give them a container registry and then they can pull it and I mean, obviously the end of the story is you still to write integration and so on. And there these ISO standards are king, right? So you need to be speaking those ISO message formats or maybe even some older formats. And, they're the implementation language. I mean, we are not touching their code. They're not touching our code, but they somehow need to speak with each other.
Recommended talk: When To Use Microservices (And When Not To!) • Sam Newman & Martin Fowler • GOTO 2020
John Davies: That is one of the advantages, obviously, of the sort of microservices world, one of them. Do you, and just touching on the microservices, I mean, have you guys gone for the several hundred microservices or half a dozen?
Lars Hupel: No, it's more on the half-a-dozen side. So we have the kind of, a unique problem, well, it's not unique, but like it's, like, a rare problem to solve, which is that all components run in different organizations. So we have components that are running in Central Banks, we have components that are running at commercial banks. We have components that are running at any kind of payment service provider. And then they have all their ideas of how to run, you know, cloud-native code microservices.
So, like, the thing that we're trying to solve here is also interconnect between those, different groups of services, let me say. And while there are, technically speaking, only a handful of different types of services, you must imagine that they're running replicated in many different banks. And they all need to talk to each other, and they all need to have a different versioning strategy. Maybe some banks will be eager to deploy the new use version right away because they're a modern digital-first bank, or some others prefer to have, like, the good old version from a year ago. So I think in terms of implementation, it's more on the side of half a dozen, but in terms of actual deployment, it then is probably more on the hundreds.
John Davies: So did you get into ISO 20022?
Lars Hupel: This is a kind of a quick question because yes, we did get into it and we do have a few people working in our team from the payments world, but as I've been told, I'm not an expert in that. As I've been told, there's no one way to do ISO 20022, and they all have their different dialects. So, right? Basically what we have to do is individually, reach each player in the market, we have to sit down and say, "What parts of ISO do you implement? What parts of interest of you?" And then we're gonna have to kind of customize our solution to deal with that specifically and also possibly in the dialect.
John Davies: It's hard. It's, by definition, the standard for standards.
Lars Hupel: Yes.
John Davies: And no one bank, or country, or anything follows it. So it makes life incredibly difficult. And, it doesn't even need to be in XML. It can be in JSON, it can be anything. So yeah, everyone says, "Oh, you've got ISO 20022. We can hook into it," but it never works that way.
Lars Hupel: The other problem that we're facing is that many of the existing messaging formats are not designed with a token-based system in mind. So you're typically dealing with account numbers and, like, transfer from one account to another account, and then the events that are kind of originating from that. And we use, or not just we, but it's generally inside CBDC that you have a direct transfer of value. So when I want to make a transfer to your wallet, that is a different bank, my bank would take this token from my wallet and directly post it over HTTP, to your bank. And then they would immediately have the value, there's no additional settlement step involved or anything like that.
So for that, we have our messaging protocol, which is based on JSON and rest and what all the cool kids are doing. And, for that, we don't need to integrate with this ISO. It's just that when you have business cases, like, I want to convert from deposit money to CBDC, then you have to speak that language. But if we're in our nice little newly designed, almost greenfield system, then we can just do whatever fits best for the purpose.
John Davies: So what happens then if you meet another cool kid company in France, for example, who's got their cool technology and you now want to integrate into a transfer with them? So presumably you better go back out to international standards?
Lars Hupel: Yes, very much so, and we see that in some countries in the African market, which are very advanced in that kind of interconnect between different payment rails. So we have been running a pilot project in Ghana and they have mobile money. To explain that maybe for the audience, mobile money is a prepaid balance on a SIM card that you can text each other. So if I have 20 euros on my prepaid SIM card, I can text you 10, and then you can use it for airtime or you can just text something else. It's very popular for buying groceries and for like, just, you know, prepayments generally speaking.
Ghana has a regulation that allows you to text prepaid balance to a bank account and vice versa, which I believe was very hard to implement initially. But now they have a nice working system where they have banking cards, bank accounts, payment service providers, mobile money credit cards, and so on. They are all integrating seamlessly. It's going to a national switch infrastructure, which now works fairly well. It's still not exactly instant, so you need to wait for like half a day for some of those payments to settle, but it's a lot better than what they had before, and it's a lot better than what we have sometimes here in Europe. So, we are also relying on these existing stems in the country. And I'm not sure what they're using there in Ghana, but I'm fairly sure that this also has to be country-specific to some extent.
John Davies: So, a couple of questions is, is that based on, or similar to M-PESA, which is using...
Lars Hupel: M-PESA is, like, the original.
John Davies: So it's based on the same?
Lars Hupel: Yes. And, M-PESA is from Kenya, I think.
John Davies: Kenya, yes, and Tanzania.
Lars Hupel: I think they were the first ones to do that, but now basically every Sub-Saharan African country has that sort of thing. And they're all called differently I think. But it's the general idea.
Security in Money Transfer
John Davies: So going back to the European side, you talked about making a payment from you to me. I like it, I prefer it that way. What about the security of what you're putting in my name, you're putting in I presume it would be my bank details in Europe, for those in the U.S., are fairly open. When we send an invoice, we put the bank details, etc., so that's not secret as it is in the States. But under GDPR, you're still sending personally identifiable data. So, how do you manage the security side of this in terms of data privacy?
Lars Hupel: Yes, has just been published by the European Commission on their investigation, digital euro privacy is very high on the list yet KYC is also a requirement. KYC, which means know your customer means that commercial banks that are going into a relationship with a client, so if I'm opening a bank account at a commercial bank, they will need to collect my data just because they're required by law to do that. We designed our solution in such a way that this KYC data stays local within the commercial bank. So if I want to make an outgoing payment, my bank is responsible for authenticating me, and they're probably doing that with their existing user management systems. So we have a demo implementation based on Keycloak, but the banks are not gonna use Keycloak, plain and simple.
John Davies: No.
Lars Hupel: And they have also PSD2 and so on. So all of that data stays local. As I mentioned already, the token transfer goes directly between the banks themselves, so to the target wallet. The receiving bank will not learn about my KYC data because it's kept local. Now, the banks still have some kind of fraud detection systems. They have some kind of money laundering detection systems and so on. So if they find some issues, they would find it locally within their data. And then you have additional legislation that tells banks, okay, if you have the suspicion of reasonable suspicion, you need to, you know, report it to someone and that's what they can do. But we've tried to design it in such a way that the token itself has no personal anything information whatsoever, and everything stays between you and your bank unless you are trying to commit a crime, which is if they would report it.
Recommended talk: Processing Data From The James Webb Space Telescope • John Davies • GOTO 2023
John Davies: So presumably it's going through the traditional, as you said, anti-fraud, anti-money laundering, anti-terrorism, etc. So it's going through the same...
Lars Hupel: We're trying to put a kind of an account-based view on these tokens because banks know how to deal with account-based systems. They know how to detect if an account is receiving unusually large amounts of money. And we're not telling them, you know, you need to rewrite this entire system to be based on tokens or to detect unusual token flows. Instead, we're kind of emitting events that they can then feed into their existing systems and then also can match with their normal traditional accounts.
The Advantages of CBDC and Offline Payment
John Davies: So this effectively from what you're saying, playing devil's advocate here, is no different from transferring euros from one account to another, because you're going through the same, you've got the KYC, you've got the assumption that both sender and receiver have been through KYC, therefore if you're sending money and the other one has an account, therefore, they've been through KYC at the destination bank, everyone has to go through the same anti-fraud, anti-money laundering, counter-terrorism, etc. What's the difference then with the Central Bank mechanism as opposed to through traditional?
Lars Hupel: Yes, that's a fairly good question, we get that asked a lot because if you only have online payments between wallets held at banks, there would be no material difference. The UK has instant payments between banks. The Euro has instant payments between banks, so that's...
John Davies: Pretty much every country.
Lars Hupel: Maybe except for the U.S. but...yeah. So what CBDC offers as an additional value is, first of all, offline payments. So you can kind of download your tokens onto a wallet that you are physically carrying with you, which we call a bearer wallet, because it's like you're bearing it, you are carrying it around with you, and that's the same type of token, and there's no need for like, you know, kind of settlement. You don't need to ask the Central Bank if there's a valid token and whatnot. So I could download some of those tokens from my bank wallet onto my bearer wallet, and then I could transact with you offline.
And you could also have, so that's the second point, you could also have non-banks offering these kinds of wallet services, which you can do because CBDC is a liability of the Central Bank. So you don't need to be fully regulated like a bank because then you have like deposit requirements, insurance requirements, and so on. And with CBDC that just, you just don't need it because it's like cash, it's immediately guaranteed by the Central Bank. So you can have the seamless new use case online, and offline, but you can also have new use cases enabled by payment service providers who can now operate much more flexibly than they could have previously done.
Another point form for mobile money, mobile money is backed by deposits. So every mobile money operator like Vodafone or MTN or whoever in the African area needs to have one or more deposit accounts, and they need to have regulations like, don't keep more than 20% of your funds in one account, because what if one of those banks goes bust and so on. And they could dramatically simplify that if they got access to Central Bank money, which is pretty much guaranteed. So there's no way for anyone to go bust in that. And that just gives you a whole lot more flexibility in how you conduct yourself.
John Davies: Trying to find some other similarities, stored valued cards, for example. So you mentioned some of the mobile phone companies, in some cases, they offer, you know, the ability to pay using your phone account, it goes onto your bill, not dissimilar again from Amazon or Apple I think now. Again, what would be the advantages?
Lars Hupel: So that's also true. We've had offline payments for a while. What we haven't had so far is consecutive offline payments. So I pay you offline and then you turn around and pay someone else offline. That doesn't work right now, there was, even for the stored value cards that we had, for example, the Geldkarte in Germany, I've heard that something like that existed in the Netherlands as well. At some point that only allowed for customer-to-merchant transactions and the merchant had to wait for, I don't know, end-of-day for the money to arrive in the bank account. And with CBDC, the idea is that you can have peer-to-peer offline payments. You can have a person to merchant to delivery, something like that. So in Ghana, we found that we... there were a lot of merchant-to-merchant transactions because there were quite long merchant-to-merchant chains, and it's instantly settled. So they don't need to wait for one or two days for this transaction to clear.
CBDC vs Cryptocurrencies
John Davies: So twisting the conversation or moving the conversation slightly, I was asked on this panel yesterday, you and I sort of shared a seat or shared the...
Lars Hupel: Panel.
John Davies: Nobody shares my seat. When I came to that, I was invited and I sort of looked, oh God, this is gonna be a whole bunch of cryptocurrency things. As we went through the introductions, I thought, oh, okay, they're not crypto, he's not crypto. You and I sat next to each other, and oh, they're not crypto. So it looks as if we're all, sort of, it turned out pretty much the whole panel, interestingly, was relatively agreed in terms of where we sit with this. Do you have challenges with what you are doing with people assuming that it's because it's not fiat currency as in the differentiating from just pure cash and money in a bank account, but do you have people getting confused with cryptocurrencies and where they sit? Because obviously if you're trying to promote something new, everyone's going, oh, it's another one of these, you know, you get rich quick things.
Lars Hupel: Of course. It happens all the time. And we get that, sort of, from multiple sides at the same time. So to some extent when we talk about digital currency, that word has been associated with cryptocurrencies.
John Davies: Exactly.
Lars Hupel: I have to explain, as an evangelist, that it's not the same thing and it's orthogonal to the blockchain. So you can do digital currency backed by whatever, on whatever platform, on the database, on the blockchain. You can have it backed by deposits, you can have it something like a stable point. So there are all sorts of different design choices, and that makes it very hard to give, like, a good narrative about it. So what we always start with is it's Central Bank money, so it's money that you already know, it's just in a different form. And we can choose to run that on DOT if there's a requirement to do so. But we can also choose to run it on databases because it's already a centralized system. It's already a Central Bank doing that.
And from the other side, from the, let's say the cryptocurrency enthusiasts, there's very often the notion that Central Banks should do less rather than more. So they're not convinced that if the Central Bank is digitizing currency, that they have any material advantage because they already have Bitcoin, they already have stablecoins, so they can also already transact seamlessly, digitally maybe with sort of less string than keywords, and few rules, and so on. But they don't see any…
Recommended talk: Demystifying Blockchain: Infrastructures, Smart Contracts & Apps • Olivier Rikken • GOTO 2023
John Davies: Anonymous, half an hour to get your transaction through.
Lars Hupel: Exactly. So, we're trying very carefully to position ourselves in that.
John Davies: You also can't, if you were transferring money through your phone, we had no network with Central Bank currency, so you could do that.
Lars Hupel: Yes.
John Davies: Whereas, with a distributed ledger, obviously you need...
Lars Hupel: Exactly.
John Davies: ...internet access, etc.
Lars Hupel: Yes. Because what we are doing is we're having you build a trusted system where all the wallets that are participating in the system are somehow authenticated, they're somehow regulated. So when I was to give you Bitcoin offline, you had no reason to trust me, I'll give you a valid Bitcoin. But if I'm using my official wallet, sending your official wallet some, some...
John Davies: Yes, just like a password, you can verify the signature.
Lars Hupel: Exactly, right? And this is a challenge, right? We also hear a lot that offline, you know, it's not a big issue. Why would you need it? Because, like, we have 5G everywhere and the answer is no, you don't.
John Davies: No.
Lars Hupel: No, you don't. Not.
John Davies: You go out into the sticks and you try to pay for something.
Lars Hupel: Exactly. Yeah.
John Davies: As I found out in Germany when I was cycling in the Black Forest, it's trying to pay for your cake and a beer.
Lars Hupel: You don't even have 3G. You might have 2G if you're lucky.
John Davies: I had cash.
Lars Hupel: You're lucky.
John Davies: Are you competing, with mobile money or is this different?
Lars Hupel: We're not exactly trying to compete with existing payment rails. So we're not trying to compete with cash, we're not trying to compete with deposits. And also ECP has made it abundantly clear that they would don't want cash to go away. They don't want banks to go away. So what we see CBDC is as, first of all, more choice for the consumer. So giving them one more option to pay may be in situations where they were not able to pay before. And then also as a second point, to serve as a foundation for different payment rails to become more efficient.
So for example, if you have payment service providers today that have to partner with an existing bank and have very strict collateral requirements and then have to wait for the RTGS to clear certain transactions, then it maybe goes through multiple different chains of intermediaries, this could be made a lot less, it could have a lot of friction when using an instrument that is directly backed by the Central Bank and is like immediately settled. So while in many situations there's no actual user experience difference, if I am paying for an existing car, there might be in the backend less cost, less time, less turn fuel, less turnaround time. And that in turn also means that I have to pay less at the shop because of the...
John Davies: So you're giving both the merchant, the consumer, and...
Lars Hupel: Exactly.
John Davies: ...all the parties the choice.
Lars Hupel: Exactly.
John Davies: Which is what we have today. You can pay with cash, you can pay with your phone, you can pay with your credit card, your debit card, and your AMEX.
Lars Hupel: Yes.
John Davies: Okay. So it's just basically you are complementing all the others.
Lars Hupel: Exactly, yeah.
John Davies: Okay. That's pretty cool. Well, Lars, that's great. Thanks very much for... hopefully everyone's learned, you know, quite a lot. Thank you very much.
Lars Hupel: Thank you for having me.
John Davies: You're welcome.