Crunchfish AB (publ) ($CFISH)

Well, they're trying to make physical cash work digitally. And my opinion is that it's absolutely not what we are trying to do here. What we're trying to do is to get digital money work offline. I have lived in Singapore. I have 3 daughters, 2 of them are born in Singapore. So I know it's an extremely connected society. But I think they had a wake-up call. They cannot build for the happy flow, assuming that we're always online, always connected all the time.

When the lights go out, what happens to payments? Are we just stuck for a period of time in the stone ages? Or are there ways that we can continue to pay, get paid and keep the economy going? I spoke with Joachim Samuelsson, CEO and Founder of Swedish Fintech Crunchfish, which is in the fray trying to talk about what is the best way to deal with payments when you don't have power. [Presentation]

Joachim Samuelsson from Crunchfish welcome to the program.

Thank you very much, Jame. Love to be here.

The topic that we are going to talk about today is what happens when things go offline, not because that you move offline, but an event happens, there's outage something blows up or gets shutdown and you guys that can't spend your money. How big a problem is this in real life? What kind of outages have we seen that are more than just an hour or 2?

Yes. It is a bigger thing than I think people realize. And it's funny because payment system has been built almost on the assumption that these black swan events never happens, but they do. And that's -- offline is not a problem where you're trying to address, where don't you have connectivity at all like on an airplane. Off-line is the resilience needed. And right now, the geopolitical situation, I just heard of that, there was one missile in Dubai, one of the major finance centers of the world hit the AWS center. Many banks in Dubai went black. And you don't -- that's not a 1- to 2-hour problem to solve. That's much bigger. We have India last year, they do 20 billion transactions a month. That's sort of like 10,000 a second on their UPI rails. They were down for hours, 3 times for hours. I don't know if it wasn't even longer once a day in April last year. You can just imagine -- just do the numbers, how many Indians are standing there not being able to pay because of an outage like that. So this is -- yes, we'll take Singapore, another financial center. You heard about the Microsoft bug that happen.

Was it a CrowdStrike issue or...

Exactly. Yes. They woke up. I have lived in Singapore. I have 3 daughters, 2 of them are born in Singapore. So I know it's an extremely connected society. But I think they had a wake-up call. They cannot build for the happy flow. Assuming that we're always online, always connected all the time. You don't build systems like that. Any system in the world, you have to build for resilience. And you can't assume everything will always work. But that's how the payment systems has been set up. They are set up for continuous operation. And the fact of the matter, that's not the case.

Right. How -- I mean, this is not a new issue in the sense that ever since we've had anything online, there have been points of failure. We talked about -- you mentioned the CrowdStrike outage, which hit many businesses. There's been cyber attacks over the years. There's -- or just electrical outages, right? I think it was last year when Spain and Portugal were down for about 24 hours. How much of this resilience do we just need to build in terms of just having redundancies, duplications, not allowing just 1 or 2 companies to dominate a particular sector? Should we just have more of all the same stuff, so it's more resilient and duplicative? Or are there ways or should we be thinking about solutions that ride on top of the status quo?

Yes. No, great question. Well, our -- my answer and our answer in my company Crunchfish, our approach is that this is ultimately an architectural problem or an architectural solution to this problem, which hasn't been known. And that's sort of, I guess, why we're having this interview because it's offline, which is sort of the thing, just having multiple alternatives, as you said, I think we have relied a little bit on that, and we rely on the ultimate offline payment mechanism, that's cash. That has always been the back fall -- fallback. But if we are in the world of digital, then just having multiple options tend not to solve the problem because there are sort of very central nodes like in my home country, we have the bank ID. So if bank ID, which is the electronic identification system of Sweden, if that goes down, it will knock out our instant payment system because you have to sign off for any sort of payment you do. But it will also knock out any sort of card payments because you use bank ID for that as well. If you're doing card payments online, then they require you to authenticate your payment with bank ID. And you can't log into any banks either. So -- and we don't have bank offices -- bank yes, the banks are online now. So this is a major black swan event. And so just having more of the same won't really do it. But what we are proposing is an architectural change to how we go about offline. That is what I believe is needed. Offline so far has been always seen as a hard problem to solve, and it's always been seen as a trade-off. Everybody understands somewhere that just building for the happy flow that online is all about probably won't do it. We probably need to look at resilience, but how should we do it? And there's been -- the whole problem has been framed in -- there's been 2 legacy approaches. Either is the approach where you are sort of trying to make cash work digitally. That's been very much the approach of the central banks. They are -- they've always been thinking that, well, we issue cash, that works offline. So when we're going to do central bank digital currency, probably what we should solve is let's make cash work digitally. I'm...

And what does that mean? What does that mean to make cash -- we're talking about physical cash, have some sort of digital component? What is that? It seems like a nonsense that we're talking about periods of time when digital doesn't work. Why not just have people make sure they've got some cash at home, so they can get past...

They definitely are saying that. And I agree that, that is -- that's probably exactly what you said. It's probably a better way of doing it because -- but what they have thought that they should solve digitally is actually to offer something that is like cash, but simply digital. So you have -- when you have cash, you have a token in your hand. You have a token and when you hand that over that token, which is backed by the Central Bank, you hand it over to me, Jame. And then I have it. Now I have a claim on the central bank. And they've been thinking, okay, that's how we should do it. So you are having a token in your hand, a digital token in this case, and you hand it over to me. And then I have it. So I have now a claim on the Central Bank. And that model is called immediate offline because immediately when you have handed over, immediately you paid me something. Now I have it. So there is no settlement this is actually -- the whole value is carried. You have money on your devices, like you have money in physical cash, you have money digitally. And when you have handed over the money to me, then I have it.

So we're talking about essentially mobile networks that would be -- we're assuming that the mobile network is working even if we are out of electricity for a period of time.

No, it doesn't have to be mobile here. We're just talking about you need to digitally be able to transfer something from one person to another. The mobile network doesn't have to be -- is offline. So you could buy any proximity method. This could be NFC, this could be QR, it could be BLE, it could be ultrasound. In some way, you are transferring something that you hold on a card on a mobile to me -- we're not having a network that...

You see the battery, the battery has to be working.

Yes, well, yes, you need an electronic sort of device [indiscernible]. Yes. So that's -- but what are they trying to do? Well, they're trying to make physical cash work digitally. And my opinion is that it's absolutely not what we are trying to do here. What we're trying to do is to get digital money work offline. That's not the same as trying to make physical cash work digitally. It's -- but that's how most central banks have thought they should go about it, but it's simply the wrong approach because it's an approach, which is very unfriendly to banks because banks wants to have money on their balance sheet. And here, you take out money from the balance sheet of banks, just like you take it out, when you withdraw from ATM. What you have on your bank account, you can now have in your wallet instead as cash. Now you have digital cash, not a good idea for banks. And also, because you bring money on devices, you need Fortnox security on the users' devices. and it's going to be hardware.

And you have to be prefunding that, I guess. You need some sort of -- you would have to consciously say I'm going to put x number of euros or whatever your currency.

No, it is not cash. Think of it as you go to an ATM and you withdraw physical cash. This is the same thing. You have to go -- you basically have to withdraw money because the money will no longer be in your bank account. It will be held by your purse, your digital purse on device. But it could be on a card or it could be -- but this means that because it has to be hardware, it's fine on a physical card, but just forget it on a mobile because if you're going to have hardware, you don't own the real estate of hardware on a device coming from China, if you are a European central bank. You are not allowed to put anything on their hardware, which they come with in their devices. And you have a very fragmented mobile -- mobile device market. So this is almost a nonstarter from this. There is no support for that. And also, you have to do the same thing on the recipient side, going then you have to put hardware that can accept those payments on the, say, car terminals. And so I would have think this is almost a nonstarter from the beginning. The third thing, if I just want to make it even worse, is that how are you going to govern it? There is governance today. Money needs to be governed. There is governance today for digital money. But all of a sudden, you have created a parallel digital money universe, just like cash is a parallel physical money universe, you created a parallel digital universe of money. Who wants that? I would say no one because -- but the whole thing is all framed on they're solving the wrong problem. What we are supposed to solve was how do we make digital money work offline. That is resilience, solving how do we make physical cash work digitally, that's a theoretical, I don't know, lab project to solve maybe, but it's not for scale, not for scale. And then the other approach is not as bad, but that's what we see on the card rails. That is the -- let's call it the deferred settlement. It's -- yes, everybody realized on the card rails that maybe the card terminal is not online all the time or particularly if you're on an airplane, that's a good example. The air steward is, when she comes around and you're going to pay for your meal, you can pay with a card. And because in that merchant category, an airplane on an airline, there they have allowed mobile payments as well. But that's just a special case. You can always pay offline if you have a physical card on the card rail, but it is treated as an exception -- and you have no control, Jame, if it's going to be allowed or not. This is set by the sort of the card scheme. It's called a lower limit, how much can they accept offline. But so you can influence it. And it's always bringing the risk forward because who knows, Jame, if you have money...

Am I good for that sandwich? Sandwich on my plate...

Exactly. Exactly. So what we've done, Jame, sorry for rambling, but I just want to bring this home. We've invented a third category for offline payments, which doesn't have the systemic risk failures of the other 2. The first one has this systemic risk on the device. If you crack the device, you have money on the street, which are false, bad if it's digital. Secondly, in the deferred model, you have that in a longer outage, you're going to have a lot of unmanaged credit. People have paid without checking, if they are solvent or not for it. What we do is something quite similar to the card rail, how they do it, but we add a step of a reservation. So you, Jame, you create your off-line capacity yourselves. You create -- that whilst you are online, you create that capacity. So you can decide, if you're going to a festival, where you know the connectivity would be bad, well, then you may want to put sort of $2,000 there. So you can go to the shops there at the events and pay for it, even offline. And -- but with that, adding that reservation, what do we do? Well, we take away the credit risk because you cannot spend more, Jame, than you have actually control yourself because you've essentially set it up for yourself, how much you can pay offline. And we have a deterministic settlement. It will always settle because the money has already been taken aside. So we are -- we're getting the best of both worlds, plus that it becomes very banking-friendly because, guess what, this is like a smart contract. We have -- the bank have moved the money from you, Jame, and they put it under the custody of the bank. It's like an escrow. They hold it.

But why it is necessary the bank that holds it? I mean this could be done on -- in Hong Kong, where I live, we use a card called Octopus, but you could also use Alipay or I'm sure there's a zillion version of these in Europe and Sweden. Why not -- that's not a bank, that's a wallet that's a digital wallet. I keep money there on -- it's basically in a debit format. And yes, I take the money out of my HSBC bank account, and I put it. I leave a certain amount on the Octopus and I use that for my spending around town.

No. Maybe I was a bit careless there, just to say the banks. Any regulated institution would be fine. But in order to hold money in a regulated -- in a regulated space like payments or money, you need to be regulated by the Central Bank. But that could be a wallet, that doesn't have to be a bank. Any regulated institution, who are allowed to hold electronic money, digital money is fine.

Right. Okay. And of course, they're enjoying the float in the meantime, while for whatever money I have on balance.

Exactly.

But -- why couldn't -- so if the concern is what happens if the lights go out or if you're going to be in a place where you're not certain about being able to spend money as you would on a normal day. What's to stop a wallet provider or a bank, I can pay straight out of my bank account as well from just building in some sort of escrow service that you can access, if there is a power outage.

Well, that's exactly our solution. We are not a stand-alone solution. We are like -- if you remember the commercials in the days, Intel Inside. We are sort of in a way, governed offline inside. So we would do -- we would add this capability to any payment service in the world. We -- first of all, we will provide it on a system level, meaning that we will have off-line acceptance in the system. So the system can accept offline payments. That's the starting point. And then we go to the issuing side, and this is where we need a little bit heightened security, and we provide an isolated runtime environment on the device, the mobile device that on the issuing side they're using. But the good thing here with our solution, this is what we're doing in India, we are providing -- it can only be one system. So we are providing it to the MPCI on the system side to be able to...

The National Payments Corporation of India.

Yes, they're behind UPI and RuPay, the National Card Rail and now the Digital Rupee as well. So we're putting in the ability to accept payments. But then we are actually -- and that's a requirement from MPCI. They would like a vendor-neutral solution, where anyone can actually help the banks or any unregulated institution as well to offer the ability to pay on the issuing side. It doesn't have to be our wallet. And we could provide that. That's -- anyone who conforms then to the protocols and the specs of the system that we have helped them create here, they can provide an off-line wallet. It could be the in-house wallet, Google Pay are huge in India, for instance. They stand for 30% on the UPI rail. They can do their own. That's fine. We can also -- we certainly are one who can supply it. MPCI have developed their own wallet, offline wallet that they can supply theirs. So we're creating a vendor-neutral issuing -- e-issuing side that anyone can provide it there. But then we need to set up the system in this architecture that I told you about that it's -- the paradigm is basically reserve pay and settle that whatever people are going to have as capacity needs to be pre-reserved -- so you create that. And that reservation, Jame, doesn't have to come from debit. It can come from credit as well. If you are a trusted customer with a bank, they maybe give you $10,000, you can buy that any time. You can put aside maybe $1,000 of that of that credit limit that you always -- every time you sync online, you would always top it up. So you always would stand there with $1,000. You don't think about it really. You can do it that way.

What is the challenge of getting people to accept that they would be -- I mean, you're sort of asking people to lock up some money for an indeterminate amount of time in the event -- in the event that the lights go off for a day or 2. That's -- how do you get people to actually do that? Because if they're wealthy enough, I would like to think that I could -- I could probably survive 1 or 2 days without spending money. I mean, obviously, there might be cases where that's -- where I had a critical problem. But if I'm poor, the issue for me is not can I survive 2 days. The issue is I need that money now. I don't have -- it's a luxury that I can't afford to lock up INR 1,000 or INR 10,000 in my -- in this -- I only will use in some kind of very theoretical event that may not be -- even if it is real from a point of view of getting people to change their behavior and put their money in the sort of permanent escrow, how do you think about that?

Well, I don't think it is what you described. What I think these black swan events, which are very rare, they are very dangerous from a system perspective because they won't just kill your ability to pay, Jame. It will actually then kill the whole system. No one. The lights will go off. And when payments can't work, society stops, simple as that. So -- but that's not the reality from a person on the street. What they would like to have is just the ability to pay in a predictable manner all the time. And what they are hit with constantly is that, oh, I'm now in a garage. Oh, right now, I didn't have connectivity. Oh, all these things which is happening on a -- this is not on a -- it's not a rare thing that happens every maybe second year. This happens on a daily basis. So what we are talking about is the ability in a predictable way to pay. That is how it is for a user. But turn it around, think for a merchant. How do you think a merchant would survive, if they are hit for hours, not having been able to sell anything because no one can pay. So is it important -- more important there?

Yes. But Joachim, this is where we get into a scale issue. So I mean, I agree that the problem of an outage is far greater at the merchant level than it is for an individual...

At the system level...

Right. But there, we're dealing with huge amounts of money potentially that would have to be covered or at least partly covered or some way that credits and debits could still flow even if the money is deferred, even if the settlement comes later. But if it's an escrow basis, there's no way that merchants could tie up an entire day or 2 days' worth of their their...

But the merchant doesn't tie up. Jame, the merchant doesn't tie up anything. They are recipients. The one who tie up offline capacity are the payers. They are the one who tie that up, not the merchant, they don't tie up anything. So -- but think of it this way. You are like me. We remember -- at least here in Sweden, we hardly use cash anymore. But I'm old enough to remember that you always went to the ATM and you took out -- you always had maybe SEK 1,000 or SEK 500, that's sort of $50 to $100. You always had that, that was just how it was. I never thought, oh, I am putting -- I'm not going to get interest on SEK 500 to SEK 1,000 because I took out and have something. I never thought of that. And this will be the same. What I'm offering is essentially the mechanism that will be like in the good old days, where people just always were able to pay. It was cold cash. People are always able to pay. And it's not -- I don't think people should think of it, oh, I'm going to put it in escrow and it is simply -- now we're really talking about cash-like behavior. We're getting back to that because we are making the digital system work offline. And the capacity that you reserve for yourself is very similar to how we just -- no one asked, why do you go to the ATM to take out some money? Why do you do that? Well -- well, that's just to be sure I can pay for my ice cream or for whatever it is.

But I want to get back to this question of scale because merchants are also payers. They have to pay salaries, they have to pay vendors, they have to get supplies. And for many of them, they're running very large cash management systems every day, even if it's an e-commerce seller in the local market. So how -- given that they would not be able to treat this as just cash in pocket. They would need something a little more enterprise level or a little more robust. And how does that...

Yes. But we sold that as well. This is -- if you're -- if you don't want -- the ability to pay forward is there. If I pay you, Jame, P2P, what I paid you offline without you syncing -- making a sync online, you can pay forward what you did received from me, because if I pay you something offline, that will actually up your balance. Now you -- it's not just what you reserve for yourself, but you also receive some offline money, which I have reserved previously, but you could pay that forward. Similarly, if you're a merchant, say you are a small merchant, who buy goods, they sell goods and they have to buy new goods as well. What they receive, if they have a wallet now, they can be just like you, Jame, that if you receive something from me, you can pay forward. They can do that as well. So that is definitely solved. If you are a larger merchant, where you are not -- you're not going to do it for paying forward. If you're a big retailer, you're not planning to spend from that wallet, that sort of cashier that have received. Whatever is collected there, it's not something you pay forward with. Well, then you only have what we call an offline terminal. You have just -- it's like a wallet, but you can only receive you can only receive payments. But it will just be collected there. And when connectivity comes back, then all those like a money order checks, that's sort of the physical equivalent of our system. It's like a postal order money orders. They will all be banked and then they will get into the system. So this is definitely a big scale type of operation that also supports the small-scale merchant that needs to immediately pay forward as well. That just means that they will essentially be working as a -- they would be just like they have the same offline wallet that you would have as a person because they need the ability to pay.

Yes. So Joachim, before we had this chat, I looked at some of the research or some of the comments about this problem from some of the central banks, and it is indeed a complex issue. So one of them, I think it was Bank Canada we've talked about the issues around hardware. This might be -- and the complexity and the security issues around that. I think we've referred this when we're talking about some of the previous solutions, which is not what Crunchfish does. But what is necessary for this to work from a -- in terms of devices or just the systems of banks or card processors?

Well, the -- if we start on the front end, on the payer side, you need an isolated runtime environment. So you can't -- this runs -- if you have a mobile phone, it runs on an app. That app needs to be -- have a heightened security with an isolated runtime environment as well. That doesn't come natively with just any app development. That rich world or rich execution environment that is called, that anyone can hack that. So that won't do. So you need to increase the security. And you need to secure it in a way that when you are executing operating offline, then it needs to be isolated from a hacker in a way because when you are operating on the data there, then you need to decrypt things. Otherwise, you can't do debits and credits, plus or minuses. And that's a dangerous spot. But if that is done in a secure isolated runtime environment, then that is fine. That does not have to be in hardware. That's the good part of it here because we do not -- in our architecture, we don't deal with money. We are just dealing with payment instructions. It's a huge difference. If you have money, I can sympathize with that you probably want to have hardware because the only -- a hardware, secure element in hardware does also provide an isolated runtime environment. But the good thing with the hardware is this, that if you try to tamper with it, it can actually self-destruct. That's what the hardware can do. And a software, a virtual secure element can't self-destruct. So you can have more chances to try to crack it. But if you are relying on a back-end system and you do have settlement, so we don't do this. We don't have money. I don't hand over something to you, Jame, and then you have it. If we just skip that idea, which I think is flawed from the start digitally, you should do settlement because that is what makes it still digital money. And that would -- any payment instruction that happens offline, before we move any money, before we settle, it would be validated that this is a legit transaction. Otherwise, no money would be moved.

All right. So let's go to the second question I had from Bank of England, which was looking at questions around examples of double spend -- accidental double spending, when you're going between offline and online. And related to that is just consumer confusion, whether malign or genuine. You're saying, if there is a settlement, then there should not be any opportunity for double spend?

No. That would be -- what we do with our isolated runtime environment in the front end here on the payers' device, what we are stopping them from is to signing out in a way bad money orders or bad checks. So that's what we do. But it's just -- it's never money. It's just sort of a payment instruction. This will be validated before any money would be moved. That will always sort of happen. The Bank of England, we work closely with Bank of England. We are selected by them. And they have said they're not going for the immediate model. They think that's premature, and I absolutely agree with them. But they've said we might consider for the digital pound the deferred model. I think they have now come to realize that the governed -- governed offline model that we propose is an even stronger model because then we are -- we don't have the risk here of signing out just personal checks, which is sort of not potentially covered because that's what [ deferred ] is. But by having that reservation set that I talked about, then we essentially do the deferred model, but we add reservation so you can have -- yes, you can't spend more than you control, which is really the key thing to have as well. Bank of England likes that.

Well, look, Joachim, thank you so much for joining on the program today.

Thank you, Jame, for having me. It's been great. Thank you.