RBS builds Ethereum-based distributed clearing house
Richard Crook, head of Innovation Engineering at RBS talks about a cross border payment system using distributed ledger technology.
The RBS Emerald system, which is a proof of concept with no plan or date to go live at the moment, was set up to explore the creation of a Deferred Net Settlement (DNS) system like FasterPayments. Richard Crook, head of Innovation Engineering at RBS, explained that while the UK's FasterPayments is near instantaneous, cross-border payments are a different story.
Crook said: "If you are trying to make payments in Europe – France to Germany, or UK to France – at worst, it's a three-day round trip, and it's certainly a two-day batch cycle. They do not have an equivalent of the FasterPayments service."
Unlike domestic payment systems, cross-currency international payments have no central authority, like the Bank of England. A set of requirements for an equivalent faster payments service in Europe has been tabled, but it could be years away.
In the meantime, RBS saw the opportunity to prove the Emerald distributed ledger system in a domestic setting, which it did using technology partner GFT and Google's cloud platform.
Emerald aims to meet the Single European Payments Area (SEPA) Instant Credit Transfer scheme, which allows for more than one clearing and settlement mechanism. In this case, a distributed ledger can provide a viable alternative. The performative requirements are expected to be somewhere between 10 and 25 seconds.
The goal of the Emerald performance testing was therefore set as 100 transactions entering the system every second (sufficient for a national level domestic payment system), and a round trip time of under 25 seconds (sufficient to meet the ICT requirements).
The underlying model takes a risk-based approach called the creditline model, tracking balances and limits, rather than building and counting a store of value – "a bean", to use the accountancy term. As such Emerald's bilateral counter=party model, which allowed entities to owe each other money, is closer in kind to the Ripple model.
Crook said: "But what we found with Ripple was it is highly constrained to its proprietary model and we couldn't flex it in some of the ways we wished to. Specifically we didn't want to be exposed to a digital currency –XRP – and we continue to point out that we don't enjoy using any currency where the majority of it is owned by a few."
In accordance with SEPA's emerging new requirements, RBS built a clearing and settlement mechanism that was capable of performing and scaling with the GFT test rig. "We showed that Ethereum and the Emerald application that we built could meet the requirements of these emerging next-generation SEPA payments.
GFT's engineers were able to get under the hood of Ethereum and retune it for the specific Emerald use case. Nick Weisfeld, head of GFT's blockchain team, said, "in this case it was crucial to rapidly iterate through test cycles and identify components of Ethereum that were preventing RBS achieving their targets. Once we knew the blockers GFT and RBS engineers were able to retune those components to meet the use case".
"So fundamentally what we have built is a distributed clearing house, if you were to operate it as a commercial entity. Or a distributed real time gross settlement system, if you were to operate it as a central bank's ledger," said Crook.
The team used the Ethereum Virtual Machine, the part of the protocol that actually handles internal state and computation of accounts, which have the ability to maintain an internal database, execute code and talk to each other. "What we were interested in was the capability to create a distributed network, a consensus around a ledger and a very simple smart contract at the end of that."
The use of Turing-complete blockchain capabilities to carry out functions like making payments have been criticised from some quarters, with the suggestion that it's like using a sledgehammer to crack a nut.
Crook said: "We have worked quite hard to make sure that people are not using blockchain where it isn't necessary. We always start by reasoning that if you could use a database, you should use it.
"In this scenario, if there was a single entity that is doing the clearing between the different banks, or financial institutions, then you would just need a database with an API.
"In the Emerald use case we were trying to create distributed clearing house where there is no central counterparty that you are working to. Where there is a central bank such as the Bank of England or the European Central Bank, I would absolutely question anybody suggesting that you need a blockchain," he said