Liquidity and Interoperability

Interoperability

Why is this an important topic?

“It’s money that matters!” So goes the song by Randy Newman. In financial services (FS), liquidity management is equal parts important and hard. Hard because we have lots of regulation which dictates how much of it we need, but even harder than it might be because our financial market infrastructure is highly fragmented. Financial institutions have money in lots of places and it is a challenge to have the right amount of the right currency in the right place at the right time. I once joked with a colleague at Nomura that he was “bucket man”, managing all those different buckets of money. Now hard also translates to expensive. Trust me on that one or consult the box for a lot more detail.

So, if today’s world is hard & expensive, we would hope that as we design for tomorrow, things are easier and cheaper, perhaps even faster.

What’s new?

Digital assets with a good dose of things DLT is supposedly tomorrow’s world and maybe the global panacea for all ills in the world of FS.

Recently, something of real note happened. Berlin Hyp issued a native digital bond and settled it with “old fashioned” money in Target 2, the Euro Systems payment platform.

Interoperability was the magic ingredient in this transaction. Wonderful progress. I like to say that interoperability enables connectivity between the three key parts of tomorrow’s infrastructure, which I have dubbed the Holy Trinity: Marketplaces, Asset Custody and the Means of Payment (cf. Figure 1).

Figure 1: The Holy Trinity

In this use case, the means of payment was from TradFi, the world of today.  Good that there is re-use, good we could align the tech to allow interoperability between the new world and the old. This helps market participants towards having what I have dubbed a SPooL, a Single Pool of Liquidity.

But and it is a big one, this is not nirvana and a little short of what I think we really need.

Why is this not a really great solution, What is missing?

Firstly, operating hours. Target works 0700 to 1800 on working days. What we need is “always on”, i.e. 24 * 7 * 365.

Now the hours element does leave us some decisions to make. First, no matter what, on any given day there must be a specified time when the value date ends in a given currency. Two reasons for that. The first is simple: contractual obligations. Did the parties fullfil their obligations as per the agreement. The second is also simple, though more often than not glossed over by all the Tech Bros with stars in their eyes: the balance sheet. Every day, institutions need to be able to crystallise their balance sheet and to compare their ledger to an outside statement. Think about the year end audit for Nestle; their auditor looks at the ledger and sees you have a balance of EUR 75 million with Santander. They write back to Santander and say: “Please would you confirm Nestle’s balance with you as at the 31st of Decemeber and please send that confirmation directly back to us.” Without “stopping the action” at least for a nano-second and rolling the value date in the systems, this basic foundation of accounting and auditing is undermined. This is a basic control tool.

The second decision we have to make is regarding events which are recorded on Saturday and Sunday. Traditionally, in the limited number of cases where this things have happened on those days, they are recorded as value date Monday. Saturday and Sunday are simply not business days in our systems. We could make them business days, but I’d expect there to be some schizophrenia; in some systems, Saturday and Sunday would be business days, but in legacy systems not. At first glance, I’d say a) messy and b) on a par with the year 2000 aka Y2K problem; can be done, requires a lot of careful planning.

So, for now, I’d say we need a defined end to a value date in each currency and the weekend is the same as Monday.

The next reason for saying that interoperability with a legacy solution like Target2 is not nirvana is earmarking. The basic building block of interoperability is the ability to co-ordinate a settlement across the “Holy Trinity”. Payments are easy: has Olaf’s company got the CHF 10k to make this payment? The answer is a binary yes or no. That said, there would still be some limitations with our existing systems; programmability. For example: reserve an amount of CHF 15k in Olaf’s business account but only release the payment when a certain message is received.

Securities settlement, in the form of DvP or delivery vs. payment, is more complex. We want to have atomic settlement; either securities are delivered and paid for simultaeously, i.e. both things happen, or nothing happens. This dictates that some form of settlement coordination function guides the process: does the seller have securities? If yes, reserve them, then find out if the buyer has the funds to pay. Or you could start with the money side. The key capability here is “reserve” aka known as earmarking. Even if the process is super quick, you don’t want anybody to do anything with the one side whilst you sort out the other.

Now, in the example we started with, we have an on-chain solution for the securities doing the earmarking and interoperating with Target 2, where there is no earmarking. DvP will work as long as at least either the platform doing the D or the one doing the P can do earmarking. Spoiler alert: in Switzerland we have had this since the early ‘90s. All securities settlement uses cash which is in the payments system SIC.

If we move on and look at FX settlement aka PvP or Payment vs. Payment, the same rules apply. At least one payment system must be able to earmark.

The next vital ingredient in making the cake that I’ll call “setting up tomorrow’s means of payment properly” is something rather technical: “settlement finality”.  Whilst this is more important in wholesale markets than retail ones, it is a big deal. If you settle a transaction, you’d like to be sure that nobody can come along later and unwind what happened. You want protection from any bankruptcy or other court. As a rule, that requires the platform on which the event is processed to have a formal designation that events there are with settlement finality. This is a designation provided by a national government under the local, national laws. So, in the UK, the Treasury make this designation.

The last vital ingredient is what I refer to as “having a balance which is directly held, directly addressable and with settlement in central bank money.” Today, in any currency, there are a limited number of institutions which are allowed to have accounts at the central bank. Our two tier banking system then means that those without that permission need a correspondent bank or Nostro for their activity in that currency. This is where we enter the territory of “tokenised deposits” – more in that paper I mention above. Imagine Liquidity Finder (LF) owes me GBP 100 for this article. LF banks with Halifax, my business banks with RBS. In the good old fashioned world of today, when LF instructs a payment to me, there is a transfer of GBP between the accounts of Halifax and RBS in the payment system, where their accounts with the central bank are debited and credited.  Simples. That too is what is going on in the example we started with.

This two-tier system gets in the way of really useful interoperability and programmability. Imagine you are ZKB, my local cantonal bank here in Zurich, and want to trade intra-day liqudity in USD / GBP. You want to sell GBP and buy USD. Your UK correspodent is HSBC, where you have a balance of GBP 100mm and want to sell 75mm vs. USD to enable you to settle some USD denominated business. Let’s say you put an order into a marketplace, where ING is a  potential counterpart. ING has some credit risk if it relies on seeing your balance at HSBC. That is commercial bank money. If ING happens to bank in GBP with HSBC, then that is fine if the balance moves in a good old fashioned book transfer or “internalistion” if you prefer. If ING does not bank with HSBC, it will want to receive funds at its bank and not some token from HSBC which is an IoU – again see the paper I cited for a fuller story.  Same story on the USD side; we are restricted to a correspondent banking model, even though those banks with access to central bank accounts do not want to be a Nostro for any but the choicest clients.

So, what is needed to make this work is the ability for wholesale market participants to be able to directly hold a balance of central bank money or its equivalent in both their home currencies and in foreign currencies. If that were possible then we would have a SpooL in each currency and maximise the efficiency of making payment and settling trades.

As the Bankers’ Plumber, that for me is nirvana. If you are a central banker, that is the thin end of a wedge which leads to hell. The reason is monetary policy and a very special kind of “run risk”. When Silicon Valley Bank and Credit Suisse were collapsing, there was a “run on the bank”; funds were moved to other banks, keeping the two-tier banking principal intact. But if the market infastructure allowed wholesale market participants to hold central bank money or its equivalent, there would be very wide access and in a crisis everybody would avoid the banks and hold this new instrument, which would endanger the two-tier banking system. Too much access to central bank money being a dangerous thing as it were.

This is where things get a little tricky to explain and understand. During the business day, we all want to settle trade & make payments. So, during the day, no central bank should be overly concerned if ZKB from a Switzerland has a big pile of GBP. Rather, our central bank friends should be worried, and rightly so, about the end of day. It is then and only then that monetary policies come into play.  In simple Bankers’ Plumber terms; to progress here we need to separate out the settlement part from the monetary policy part. I have an idea how to do that, but that is a topic for another day. Or you can just ask me.

Which gets us to

Digital assets are not about to replace our TradFi or legacy solutions in one big bang. That said, digital assets will enable financial markets to interact and interoperate in new ways. Hopefully as we chart out those “new ways”, we can solve for the inefficiencies and frictions we have today. The means of payment is the enabler in all of this. A SpooL in each currency is the enabler.

So what?

Assume that in the not too distant future that:          

1) If you are an issuer: you will want to do a native digital issuance. Learn by doing; look at how you might do one now, and then do an issuance.

2) If you are an institutional investor: you will want to hold and trade native digital assets. Start with your custodian and find out what they are up to.

3) If you are a Treasurer: you are in the same boat as an institutional investor.

I am reminded of an old adage that some Irish friends of mine used to quote: “If you are not in it, you can’t win it”. With what is going on in matters digital assets, you shoud seek to acquire knowledge when you can and not when you have to.

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.

Author

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