Tokenised Deposits: good, bad or ugly? - Olaf Ransome

These things are all the rage, so it is worth spending a little time to understand what they are, how they work and what the implications are for your business. If you are in treasury or transaction banking, or trading, I’d offer the view that having some insight and a view on this is essential.

I tend to have strong views which are loosely held; when the facts change, I change my view. Last week at Future of Finance’s “Digital Money” event, I had the chance to talk about this; I learned something and adjusted my views.

Today, any retail or corporate client will have a cash balance in an account with its bank. In very simple terms, the typical TradFi or legacy tech in most banks is a one-trick pony. It simply allows a client to send in a simple instruction of “Pay X to Y’s account at Bank Z on Day T”. Yes, we have many ways to send those instructions; web login, app, SWIFT, but the payment is quite a simple instruction.

Tokenisation is about the use of new technology to represent our assets; they might be securities, real-world assets or money. Along with that comes a desire to have a means of payment which is “always on”. i.e. 24 * 7 * 365, “programmable”, and interoperable.

The promise of tokenised deposits is that programmability means we can “orchestrate” payments. IFTTT, if this then that, is a well-known explanation of these things. Last week, somebody told me about when you do all the paperwork to buy a house in the UK, there might be as many as 16 parties involved. If you have a programmable payments infrastructure, then many good things can happen.

Whilst there are lots of banks looking at tokenising deposits, JP Morgan with its Onyx product has been among the pioneers. They happen to have used Blockchain technology to create new internal payment rails. Until now, this has been useful for making payments between any two JPM clients and it can be combined with existing legacy payments capabilities to pay to a counterpart using another bank. Quite useful, but not nirvana.

Should I do anything about tokenised deposits?

If you are a JPM Client, whether you come from an FI, an NBFI, or a corporate, you should be talking to your JPM representative. What’s in it for me (WIFM)? Come to a view on whether you can and should use the new infrastructure.

If you are a client of another bank, then for all your major currencies, tokenised deposits should be a topic for you next relationship meeting. The same WIFM question.

Be curious.

What else do I need to know?

Particularly if you are the Treasurer, you should have an eye on what the rest of the bank is up to, because there are ways that this new world of tokenised deposits may play out, which will make us all less rather than more efficient.

I have said many times that a tokenised deposit is only useful inside the four walls of the institutiin which issued it. In other words, payor and payee both have to bank at the same place. New tech it might be, but with new tech like JP Morgan’s Onyx, any payment is made by a good old-fashioned in-house book transfer.

Last week, Ownera’s Anthony Woolley challenged my thinking and made the case that through inter-operability, tokenised deposits could be used for payments between two parties who bank with two different banks.

I worked through the accounting, cf. Figure 1. In my example Swiss Bank #1 has Citi as its Nostro. It wants to make a payment of USD 150 to German Bank #1, which uses JPM as its USD Nostro.

Technically, Anthony is right. The foundation of such an arrangement would be that each bank has to have an account in the other bank’s books; tokenised or not. Settlement is then by book transfer. In my time at Credit Suisse, this method was used with UBS; each bank had a USD and a gold acount in the other’s books.

So, it can be done. Would it be a good thing if many banks have their own unique tokenised deposits and there is interoperability between them? My Bankers’ Plumber view is: “not really, and anything inter-bank would be a step backward rather than forward.” Here’s why:

The arrangements would be fine for payor and payee. The payor sees a debit and the payee sees the credit. Broadly, German Bank #1 is indifferent as to where JPM has its USD balances. Tokenisation does not change that. If the tech stack is “new & improved” that is entirely separate.

As soon as we introduce interoperability to the mix here, as Anthony suggested, I think a number of dimensions are involved around things we don’t really want.

Firstly, there are some implications for the two banks.

1. Counterparty risk: JPM has an unsecured receivable vs. Citi. It consumes a small sliver of credit risk appettite that a normal, old-fashioned FedWire payment would not. It adds complexity to keep track of that exposure; does JPM allocate a fixed piece of its credit appetite for Citi to that business, or try to manage intra-day?
   
   
2. Liquidity Fragmentation: JPM now has another bucket of money to manage. Firsty, more buckets = more work, more operational risk and less efficiency of liquidity management. Secondly, the balance at Citi is in a discrete system; JPM will have to choose to have Citi make a payment on the FedWire in order to get those funds back to their main USD account, which would be at the Fed.
   
   
3. Commercial vs. central bank money: The use of central bank money for payments and settlements is the preferred approach (cf: Principles for financial market infrastructures – PFMI, Principle 9). Settlement in commercial bank money is widespread today; as soon as payor and payee are at the same bank, it happens. But it generally doesn’t happen for inter-bank settlements; in any payment system, the major banks pay each other via an FMI in central bank money. Changing that mix is theoretically possible, but not really a good thing, because it creates credit-based dependencies.

For the client banks, Swiss Bank #1 and German Bank #2, the benefits are mixed at best. Good: tokenised deposits allow for programming and use cases which today’s legacy tech stack does not. Bad: the system still relies on the use of intra-day credit. If Citibank makes the payment by allowing Swiss Bank #1 to be overdrawn, then both parties’ intra-day liquidity buffers are impacted.

Figure 1: Accounting Entries with bi-lateral Nostro arrangements

My conclusion for the Treasury fraternity; keep a very close eye on your business and product people. Steer them away from “new solutions” which increase the number of accounts you hold.

I have heard it said of advertising that “it is not necessarily a good thing or bad thing; it depends on the use to which it is put.”

Thanks for reading. Please do let me know what you think of these notes. Feedback via the comments would be great.

Please feel free to get in contact via LiquidityFinder here

My thanks: to Dominic Hobson and Wendy Gallagher at Future of Finance for having me on the panel last week, to Keith Bear for being a great host, to Anthony Woolley for challenging me, as welll as to my fellow panelists: Emma Landriault, ShearinCao, Roberto Pagliari, John O’Neil and Marcy Dumitrescu.

Olaf is a liquidity and financial services expert. He is the founder of 3C Advisory  You can message Olaf directly here.