Clearing the liquidity fog in 300 milliseconds
Nick Ogden founded one of the first e-commerce sites in the world with Wine Warehouse in 1994. After noticing that his customers wanted multi-currency quotes, he launched payments processor WorldPay in 1997 – a full year before PayPal.
Cashflows followed in 2009, the UK’s first non-bank payment institution and first European non-bank member of Visa and Mastercard. Then in 2017 Ogden created Clear Bank, the UK’s first clearing bank for more than 250 years.
Now Ogden is the founder and CEO of RTGS.global (RTGS), a new payments initiative which aims to eliminate risks surrounding the invisibility of liquidity when banks make cross-border payments. FinTech Futures caught up with him to get the lowdown on his latest venture.
FinTech Futures: When was the seed planted for the idea that would become RTGS?
Nick Ogden: This one has been brewing for a while, back in the early days of WorldPay when we were trying to deal with 40,000 payments to our merchants a month, which was massively complicated.
All of the businesses that I’ve had – WorldPay, Cashflows, ClearBank – have had these issues in relation to international payments. Going through the process of setting up a bank is an interesting process where you get to learn about liquidity and leverage and risk and all the rest of it from the other side of the table.
It was officially about six months ago that I realised what the missing component was regarding all of the international payments being made today. It was the ability to ensure that liquidity existed when the transaction was being made.
When you visit a hotel, they will take your passport and credit card and say ‘welcome!’. In banking and international payments, they don’t do that. They ask for the passport and then say, ‘what do you want to do’? Interbank liquidity is invisible. It was wondering how to get to the point of making it visible again which was the eureka moment.
FF: How does RTGS provide that liquidity information?
Ogden: If a customer of a UK bank wants to make a payment to a European supplier in euros, he goes to his bank and says, ‘can I buy €5,000 because I’ve got to pay Pierre in Paris for something I bought from him?’. The bank will say that’s fine and tell him what the rate is.
The bank goes off to check the rate, comes back and confirms to the UK customer that it is going to cost him – let’s just use a 1:1 rate to keep things simple – £5,000. He agrees and the transaction goes ahead.
What then takes place is effectively a credit check and a credit movement between the two banks irrespective of a customer, and the two banks must know that they trust each other. The UK bank wants to make sure the French bank has the €5,000 and the French bank wants to make sure that the UK bank has £5,000 to pay them.
It’s all just standard normal commerce and there’s delays and there’s risk associated with the time lapses between the knowledge and the payments being made.
What we have done is develop a system where all the basic components remain the same. If you drop RTGS into the example, the transaction is passed to us, and what we do is look at the UK bank and check that it has the £5,000 to pay the correspondent bank in France. If that answer is yes, we put something called a ‘liquidity lock’ on that money.
What we then do is take the transaction through – and this is all happening in milliseconds, obviously – to the French bank and say, ‘we have a UK bank which wants to buy €5,000, do you have that? They answer yes, of course, so we put on a lock on that figure as well.
At this point nothing has moved. The UK bank messages its customer to proceed with the transaction and it gets authenticated. That sends a message to us at RTGS, where we then produce something called a ‘liquidity block’. This a combination of the two previously mentioned locks plus some special code [Ogden mentions RTGS has a patent for this in 154 countries] which allows us to uniquely unlock the transaction, check it has taken place and check that both corresponding ledger entries have been made in both banks.
FF: How long does that process take?
Ogden: For a businessman making a payment on a Sunday afternoon to a supplier in France, it would take about 30 seconds, the bulk of which would be the businessman considering the rates and performing his authentication.
We have tested our network from edge-to-edge and from New York to Sydney, we’re at about 300 milliseconds.
What this offers for commercial banks joining the network is an ability to offer customer service levels which have long been overdue. Not only can they pay their suppliers more quickly, they will be paid more quickly in return.
FF: What’s under the hood? You had a big partnership with Microsoft and Azure with ClearBank, has that crossed over?
Ogden: We’ve built a completely new technology stack, but yes, it is in partnership with our Microsoft chums over in Redmond. I have a great photograph of [Microsoft CEO] Satya Nadella standing in front of an RTGS logo.
FF: You were one of the pioneers of e-commerce with Wine Warehouse, launched payment processor WorldPay in 1997 and started the UK’s first clearing bank for 250 years. You appear to have found another niche with RTGS – why you?
Ogden: I don’t know. I can tell you my wife worries about this [laughs]. Perhaps I’m just mischievous!
The example I always use is when we built the world’s first e-commerce store back in 1994. The main struggle we had wasn’t technology or software, it was finding a cable to connect a 486 PC to an X25 switch. In a way my career has been about finding the right bits of cable to help connect the right components.
A big change we’re also making on this is that we’re getting central banks access real time into the back of their domestic RTGS portals. Regulators can see transaction flows in real time. This makes things beneficial to the banks from a de-risking perspective as well.
FF: How would RTGS interoperate with other global payments initiatives like Swift’s gpi?
Ogden: We don’t interoperate with them at the moment, but we didn’t set this up to go out and tell the world that we were going to compete with X, Y and Z. Rather, we want to say that there is a better way for everything to work. Risk always causes delay and friction in any transaction.
If we can try to find a way of modifying the risk, that should reduce the friction or improve the speed of the transaction by unlocking the liquidity so that we know the funds are really in existence. That mode doesn’t exist. Nobody does that today.
We are potentially complimentary to Swift and we are having conversations with them. We certainly haven’t gone out to try and beat them. Anyone who thinks that is stupid, by the way, because Swift has been in existence since 1971. Is it possible for us to take on a global market dominant position like that in a matter of weeks or months?
FF: What has been the market reaction you’ve had to RTGS?
Ogden: We’ve got green lights from everybody. By the end of this year and the early part of next year, we will have completed discussions with the G20, with our pilot ready for 2020. What we’re going to do is add in a single commercial bank per country in for the trial of our pilot in the first half of 2020. That’s all looking pretty good at the moment.
FF: What’s the internal roadmap for RTGS, in terms of staff and office locations?
Ogden: Well, I seem to be living on an aeroplane at the moment. I was in six or seven countries in six or seven days or something ridiculous like that. We’re virtualised and don’t need an office at the moment – we have developers around the UK and communicate well with the people working for us in Canada and London.
FF: Perhaps you could invest in some sort of Air Force One?
Ogden: [Laughs] No, thank you. I must admit I got on a flight back from a trip to Canada, North America and the Caribbean countries, reclined the seat and didn’t wake up until we landed at Gatwick.
FF: Was now the best time for RTGS?
Ogden: That’s another thing. We need to see multiple bank accounts in multiple banks in multiple jurisdictions all in real time. The technology to do that correctly has only really existed within the Azure cloud from April this year.
Even if you produce a cunning plan of how to do it, the technology to execute it would have been clunky and certainly wouldn’t have got to the performance speeds that we’re now experiencing in relation to the test work our engineers are doing.
FF: Are you getting any concerns from banks when it comes to connecting to their legacy systems?
Ogden: No, we’re not. We’re also talking to several big software and service providers who deliver banking systems to allow them to integrate our containers into their products. Those conversations are ongoing and all positive.
The first pilot is what we’re calling the desktop pilot – there are no technical integrations required for that. Whilst we can map out quite cleverly how everything can work out from a technical point of view, the devil is in the detail when it comes to the operational level.
When it comes to that, you really need to go out and do a proper operational trial with dummy money which is what we’re planning to do in 2020 to identify any challenges that we may need to overcome or map around.
Once that’s concluded satisfactorily, and central banks are happy that we haven’t identified any massive clangers, or that if we have, we’ve resolved them, we’ll move into a real money pilot at the end of 2020. We have to tread softly, and when it’s right we’ll turn it all on.