Tokenised Deposits. What are the use cases where they will help?

Timing is everything, apparently. This week saw Fnality announce that they it completed their Series B funding round. Fnality is based on what I have dubbed a “Type C” tokenised deposit. A reminder. I see that a tokenised deposit could be either:

1.????????? Type A: issued by a commercial bank or organisation without a specific claim on specific assets.

2.????????? Type B: issued by a central bank, in other words CBDC.

3.????????? Type C: issued by a private organisation with a specific claim on a specific pool of assets.

Fnality will be a payment system and use balances in a central bank account to settle transactions and make payments in real-time. I would offer the view that if there was a Fnality equivalent available in every currency, then from a Bankers’ Plumber’s view, this would be nirvana; it would offer what I have called a SPooL, a single pool of liquidity in each currency. Inter-operability would enable one balance in a currency to serve any Payment need: P as in one-way payment, DvP, delivery vs. payment and even PvP, payment vs. payment.

The token or balance is one of the key ingredients, but not the only one. The other is inter-operability, the ability to interact with marketplaces and asset custody or securities settlement systems. This is where terminology matters. In last week’s post, I introduced the term “controllable electronic record (CER)”. That was brought into circulation by Santander’s John Whelan , with some help from BNY’s Larry Miller . Underneath all that Fnality is doing, or that #RLN and RTGS.Global intend to, is simply an electronic record aka a ledger. Those different firms or consortia are making different choices about the underlying technology. They are also enabling interoperability aka programmability in order to make the balances controllable. For my money, that makes “controllable electronic record” a great term to describe what we have or want to have.

That CER is not exclusive to Type C tokenised deposits though. In fact, JP Morgan just announced that they are offering their corporate clients capabilities to support programmability on their ONYX network. And Citi are following suit, see here.

Essentially these are new rails inside the major banks that offer “always on” and first versions of “programmability”. This might be as simple as “pay as long as balance will not go down below USD 100” or “Pay Counterpart X if payment Y from X is received first”.

These new rails are effective at moving money between clients of the same bank. Depending on the scope of the new solution, they might also enable clients to make conditional fiat payments to payees who use other banks. In this case, there is a cross-over from the new to the old; the new system a decision is made to make a payment, which is then executed over the fiat rails. Perfectly acceptable in a simple one-way payment.

It is not really interoperable; it is inside the 4 walls of the bank. Not likely to do more sophisticated things like “Siemens wants to make payment X to counterpart Y only if unsecured risk exposure to Y would stay below 100”. This because the risk exposure is inside the Siemens systems.

Let’s use a sell-side example to highlight how a CER would help us change the capabilities of our infrastructure. Imagine …

Switzerland’s ZKB knows it needs to make a USD payment to meet a margin call. Today, ZKB is dependent on its USD Nostro to make that payment. That will often lead to an intra-day overdraft, which will be factor in determining the intraday liquidity buffer requirements for both ZKB & its correspondent. Ideally, that is something to be avoided. How might this look different with new digital asset capabilities?

1.????????? ZKB has some collateral, but that collateral is not eligible with the SNB, the Swiss National Bank.

a.???????? ZKB does a collateral upgrade trade using HQLAx and Eurex to execute a DvD, delivery vs. delivery, trade.

2.????????? Then with the eligible collateral it executes an intra-day repo with the SNB for immediate settlement[1]; the collateral is earmarked whilst the settlement system checks that the SNB has the money in place to settle. Then CHF “cash” is then available in a Type C token.

3.????????? ZKB then puts an order into a new marketplace, for example Finteum, to do an intra-day swap of CHF for USD. The marketplace uses interoperability to reach into the CHF payment system and earmark the funds for the order, then does the same in the USD payment system for whoever is offering CHF. Only when both sides are confirmed as earmarked, in other words the CER has been controlled, is the execution confirmed and the funds are moved in each currency. ?

4.????????? ZKB uses the USD to meet its margin call, without being reliant on an intra-day overdraft.

Alongside this we will need new capabilities for monitoring and managing our intraday liquidity; how much collateral of each quality do I have, where is it, can I use it, what payments still need to be made?

“Controllable electronic records” of the kind that a Fnality Payment System will offer are the enabler for new financial market infrastructure.

To finish, a quick aside. After last week’s post: John Whelan offered the view that Type A tokens would work too. I’ll stand by my view of “not outside the four walls of the bank which issued them”. In all the cases above where I described earmarking, i.e. using the CER to specifically put a certain amount of funds aside, if that process looks at a balance in a commercial bank account, for example ZKB has USD 100 at Citi, at that moment Citi may or may not have that 100 at the Fed. And, if some settlement or payment process relied on that 100, the process cannot then readily control when Citi transfers those funds to the payee’s correspondent. The process would have to control both the ZKB balance in its Citi account and the Citi account at the Fed.

Thanks for reading.

If you would like to talk more about things liquidity, please just type: “Can we talk?” into the comments box.

I am a long-time and long-in-the-tooth hawk on matters liquidity. I work closely with a great team of people at Planixs where I am the Liquidity Futurologist. Planixs is in the business of making sure FS firms can avoid what happens when liquidity dries up. I hope that together we can make liquidity sexy. ?

Want to know how?banks?really work? Maybe you are in a?FinTech, a?bank?or a?consulting?firm. Maybe trying to do something new.?Understanding how to make things work properly is a good investment of your time.

The Bankers’ Plumber’s Handbook is about how investment banking works, how to do operations?properly and keep control.?

The book tries to make it easy for you and includes a collection of real-life, true stories from 30+ years of adventures in banking around the world. True tales of Goldman Sachs and collecting money from the mob, losing $2m of the partners’ money yet still keeping my job and keeping an eye on traders with evil intentions.

So, you might like the tool kit, you might like the stories, or you might only like the glossary, which one of my friends kindly said was worth the price of the book on its own.?Or you might like all of it.

Go ahead, get your copy!

Hard Copy via Create Space:?https://lnkd.in/eSDz8tCu

Soft copy via Download:?https://lnkd.in/eac5zWBD?- Cheapest option

Please feel free to get in contact: https://www.dhirubhai.net/in/bankersplumber/ and olaf.ransome@3cadvisory.com.

?

#Liquidity #LiquidityManagement #LiquidityMatters #FinancialServices?#RegulatoryConfidence #Planixs #Realiti

[1] Actually, this capability is available today in the fiat world. In Switzerland, securities trades and payments already use SIC, the RTGS system. This something like a SPooL without the controllable electronic record or the PvP part for FX.