A Crash Course on Digital Cash (Part 4)
Exploring the Future of Digital Cash: An Expert's Take on Blockchain, Stablecoins, and Tokenized Deposits.
I guess now is as good a time as any to come back to the very reason why I wrote a couple of articles dedicated to digital cash.
The original plan was to explain a few things and then hone straight into what I wanted to talk about. The problem is that every time I start to research the topic, I come across another report that makes me think someone has to say something about its content, like this UK Finance Report from 2023 ‘Unlocking the Power of Securities Tokenisation’ in particular its miraculous but often surreal description of the benefits of tokenisation 🙄 (Face with Rolling Eyes Emoji). Another time: ‘aufgeschoben ist nicht aufgehoben’ (Postponed is not abandoned). What I want to talk about is this:
Which of the following statements are correct
(select all statements that are correct):
You look at your bank statement and think, “I own this money."
You just bought a Frappuccino and think, “I own this beverage.”
Well, it took a few extra rounds (this being part 4), but this question has been on my mind ever since this nebulous RLN idea popped up. In case you don’t know it: the Regulated Liability Network (RLN) is a proposed solution by a group of banks to create a shared infrastructure for payments based on DLT. This brings me to my main topic: What options are in the run to offer digital cash, and here I am really just referring to blockchain, i.e., token-based solutions, and which alternative seems preferable and why.
One additional comment: The payments market, broadly speaking, is unique; it is used to a variety of alternative payment assets with different infrastructures for high-value and low-value payments for instance. In other words, different market segments operate on a unique set of institutional arrangements, and asking the question, “which one is the best?” should yield my favourite answer: it depends.
Conceptual models for ‘tokenized’ cash
In my mind, there are three broad buckets of very distinct conceptual models on how to tackle digital cash (institutional segment):
The coins: Stablecoin, aka Tether or USDC and more recently , tokenised deposits aka JPM ‘Coin,’ and wholesale pre-funded tokenised deposits - what used to be called Utility Settlement Coin (now Fnality). And I would put into this category some hybrid ideas like Fluent.
Then there is what seems to be the equation: RLN (Regulated Liability Network) plus CBDC (Central Bank Digital Currency) equals the “unified ledger”.
And there are complementary initiatives like UDPN (Universal Digital Payments Network, describing itself as ‘a global messaging network supporting government-regulated digital currency systems.’).
It’s an interesting word choice, 'coin,' since it would typically refer to the native crypto assets (e.g., Ether) and not a non-native tokenised asset (e.g., ERC token); in other words: a coin is the opposite of a token, so JPM ‘Coin’ should actually be JPM ‘Token’. Or maybe not. Coming back to the initial multiple-choice questions, it's worth highlighting what bank deposits are: claims.
Tokenized deposits are not really tokens
A bank deposit is a contractual right between the depositor and the bank. This means that the bank is not holding your money. Instead, you lend your own money to the bank, and it's no longer ‘your’ money; it’s the bank’s money now, and the bank owes you the money back on demand: on-demand bank deposit. Requesting the bank to pay, the token representing your claim would need to be burned. Hence, why tokenised deposits lack some of the principal qualities I would expect from a token construct, or they can only materialise between two deposit holders of the same bank.
“Tokenised deposits could be designed to resemble the workings of regular bank deposits in the current system [...] Like regular deposits, they would not be directly transferable. (BIS, p. 90)”
Oh, what a surprise, I did not see this coming. This doesn’t mean it could not be useful to overcome constraints of the legacy infrastructure, which seems to be the initial driver for the JPM coin, or cover payment needs for any digital asset activities before it gets converted back into a “normal” cash ledger entry.
But I'll let you in on a little secret. There is a way to tokenize cash, but without suffering the consequence that a deposit is a claim and therefore not transferable. And it goes all the way back to the 1940s when the use of plastic chips became popular in casinos. Hmm, gambling in Sin City as the way to solve this conundrum? To avoid any confusion, I am obviously not serious, but I do have a serious point. When you exchange your money for such a chip, the legal arrangement would be in the form of "bailment" rather than a credit arrangement in the case of a bank deposit (although I would not rule out less favourable terms at certain casinos). In a bailment, one party gives some property (say a 100 US Dollar note) to the casino for a specific purpose, with the understanding that the property will be returned or accounted for upon request. But you retain your ownership (unless you gamble it away of course). And so, in a certain way, these plastic chips are the better cash token model (assuming ownership is the only thing that matters here which is not the case, of course). Food for thought.
Whilst my innovative model of tokenized US Dollar banknotes by running a Las Vegas hotel did not take off (yet), there are other approaches (creating solutions for transferable cash on ledgers) that did. One being Fnality, leveraging a specific account structure. Then there is une toute nouvelle chose: ‘Coinvertible’, a Euro-denominated Stable Coin by SGForge, Societe Generale’s tokenization subsidiary.
Bank issued stable-coin dilemmas
The Smart Contract code review awards high scores for documentation and code quality, but identifies a high severity issue related to a highly permissive role allowing access to user funds based on SG Forge's compliance requirements. This review has an annoyingly lax use of language, making it at times quite confusing:
Authorization through tx.origin:
tx.origin should not be used for authorization
Not Relevant
Block values as a proxy for time:
Block numbers should not be used for time calculations
Passed
I suppose 'Not Relevant' suggests that the aspect (e.g., tx.origin) does not apply to the smart contract's design or functionality, hence there's no need to evaluate it. So, if it doesn’t use block numbers either, how can it be passed? The requirement would need to say 'time calculations should not use block numbers’ to warrant ‘passed.’ Do you see my point? The overview is often unclear in those details. Mon Dieu! Que s'est-il passé avec la précision du langage ? Oh well, since the provider of the review is from Estonia, maybe I should say: Hei, mis siin juhtus?
Currently issued volume: 11 EUR million, of which 10 million is held - by themselves, it seems. But I may have gotten this wrong. So, should I train an AI to monitor activity and alert me to rising volumes? I am not so sure this will be needed. A bank-issued stablecoin, whilst creating an asset one could transfer, is faced with two, I would think, insurmountable problems: the AML requirements of a bank restrict to whom this coin could be transferred. And secondly, no other bank would have any interest in enabling their clients to use a third-party stablecoin because this would eliminate Net Interest Income for this bank and redistribute it to the stablecoin issuer, and by that, render many custody franchises economically no longer viable. Let’s see how it turns out. That’s my hunch, at least for now.
And then there are intriguing concepts like Fluent, which calls itself a 'federated bank-led stablecoin.' This is a fitting description for a layer 1 network organizing cash movements between banks. US+, their stablecoin construct, maintains a 1:1 ratio with the U.S. Dollar, backed by provably sufficient bank reserves and fiat deposited with vetted federated banking partners. Although volumes remain modest, and the construct faces challenges, it's important to explore this and similar concepts. They merge elements of existing stablecoins and deposits, creating something new. But some say we should go further. Such as the proponents of the RLN network.
RLN: Really Lofty Notions
It's very difficult to describe my views on this RLN idea. The problem statement is a real one: bad customer experience for cross-border payments depending on correspondent banking services. I have my own endless examples of stuck payments, overcharging, errors, delays, and clueless client service agents. Do I think that distributed ledger technology could help? Maybe. Do I think, therefore, that a concept using DLT to improve international payments, such as the one proposed by RLN, could work? Absolutely not.
There are a few reasons for this, but it comes down to two things: A single global system is neither feasible nor desirable. Maybe start with the desirable first.
When was the last time the front office people went to sit down with operations, and the head of trading starts the conversation with: "I am really sorry, but I cannot think of anything more we could ask you for. You operate at such low costs, you can meet all client requirements, it's so flexible." This never happens. And being tied to one model compared to all the different needs across markets is very often an awful experience.
But why is it not feasible?
As soon as the system would be considered systemically important for a particular currency, central banks will insist on having the responsible entity located in their jurisdiction. There are similar constellations with SWIFT and other organizations, and solutions can be found, but the cost of maintaining such an arrangement quickly becomes more like those of a plethora of systems rather than a single system.
Am I too critical here? Possibly. Ernst & Young has a big, colourful report about the RLN. In there, it says: “the RLN is able to support all 19 building blocks set out by BIS (Bank for International Settlements), all aimed at enhancing cross-border payments.”
Area 3: Implement international guidance and principles
RLN solution: Operating in alignment with central banks and regulatory institutions' directives.
Ok, I mean, one would hope that's a given. Let's try another one.
Area 12: Extend and align operating hours
RLN Solution: Payments can be settled 24x7 by leveraging smart contracts.
Since every transaction has to be screened (AML) before a transaction, and elsewhere the report admits that, this means every bank has the compliance people working 24x7 to deal with the hits this would create. Yes! That’s a lot of additional costs. No, it can wait. Ok, but then you don’t have 24x7. Things like this are usually added to such projects halfway through, at which moment people say, "Uh, how do we get out of this?"
Lastly, and this is important, the deposit token held by a client cannot be directly transferred, so the central bank system would need to be used, or in the case of RLN, some form of wholesale token. Ok. There are the compliance requirements and the need to check for payment capacity (also mentioned in the report). And this is very important. The transactions need to be throttled to protect the liquidity position of the bank, as otherwise, the bank would go bankrupt the moment the RLN system goes live.
So, looking at it, it seems that RLN addresses one of the real problems in payments, which is how to allocate a big lump sum payment, JPM (JPMorgan Chase) just wired in 100m USD, and then break this down to the beneficiaries. The RLN model would have a segregated wallet address for each beneficiary on their system to make it immediately clear to whom a payment is for. This problem could be solved much quicker and simpler through conventional means. But leaving that aside, it also means that all the work to allocate the amounts to the underlying beneficiary solely rests with the sender. "JPM, I don’t want your 100 million. I want 5,000 separate payments. And make no mistakes because I don’t want to deal with clients complaining about getting too much or too little." And this is another problem with such grand ideas. The DLT system cannot solve these problems, but it works like a charm once the problem is solved.
The technical requirements
One solution I'm increasingly warming up to is the UDPN, besides the fact that they publish rather whimsical YouTube videos like this one, Proof of Concept 10. If you need help from an award-winning filmmaker, give me a call. Ha!
But it addresses something extremely important, which is helping an institution connect to a variety of digital cash arrangements without the need to develop and maintain expertise in every underlying blockchain protocol. If cash tokens become a thing, such a solution will be needed, and one could hope it supports an accelerated implementation.
(end of part 4).