John Whelan is blockchain lab director at Banco Santander, where he specializes in the application of blockchains, distributed ledgers and smart contracts within the financial industry.
The following article is an exclusive contribution to CoinDesk’s 2017 in Review.
For the past couple of years, there has been an extraordinary amount of hype around the potential of blockchain (or more correctly distributed ledger technology) to transform the banking industry.
The reason for this hype is quite profound: DLT has given us the opportunity to rearchitect the financial industry.
In the years ahead, we will move from a system of many banks with many ledgers (with all the associated reconciliation, central clearing parties, auditing, etc) to a simpler system of many banks but fewer ledgers where reconciliation is automatic. Central clearing parties may no longer be necessary and regulators will have a real-time view of the positions and risks across the industry.
But this transition, if it finally happens, is going to take a long time, and the chief reason is simple: legacy bank infrastructure and the tens of billions of dollars that have already been spent on building that infrastructure.
The core bank systems of today, designed with security in mind, are extremely robust and secure. But as a result, they sacrifice flexibility and aren’t exactly friendly in how they communicate with other technologies.
Luckily though, over the past several years, the APIs of core bank systems have been upgraded to be REST-compliant and some even support events and web sockets.
So, integrating a DLT platform with a core bank system can be relatively straightforward even though the underlying DLT network topology, architecture and security considerations may still be a work in progress.
Keeping it simple
The key to any successful integration is to minimize complexity.
Certain use cases and transaction processes (e.g. cross-currency swaps) are complex and touch upward of 20 computer systems. And although very promising for the application of DLT, they may not be the obvious place to start as we move forward with the first real-money pilots.
Other transaction processes like cross-border payments are simpler, and it is these kinds of applications that are probably the closest to production.
So, how do integrations work in practice? At Banco Santander, our Blockchain Lab starts by building a prototype to tackle a specific business problem on a particular DLT platform (ethereum, Hyperledger Fabric, R3’s Corda).
In order to make the prototype as close as possible to the real thing, first we will build a limited core bank simulator that emulates the core bank systems for that particular application.
Next, we will map out the process flow for the use case that we are building and then spend the next two to three months in a series of sprints that result in an application that is robust enough to demonstrate to the business.
If the business leaders like what they see, they may support taking the application to the next phase: pilot.
At Santander when we say “pilot,” we mean running the application on real money systems, though at limited scale. (The pilot phase is when the bank’s IT teams – corporate IT and ops, security, infrastructure – get involved.)
Together, we will do an architecture and security review of the prototype application and figure out all the necessary modifications that will need to be made to plug it into the bank’s pre-production environment.
But because we have already been building on core bank simulators, connecting to the real core bank systems becomes significantly easier. These pilot integrations have been taking us four to 12 weeks, depending on the amount of work involved.
Once the pilot integrations have been done, performing a robust series of tests on a defined schedule is the next step. It is during these tests that bugs are identified and squashed.
The chief concern here is maintaining atomicity between the core bank system and the blockchain. In other words, it is imperative that the numbers that are reflected in the core bank are exactly the same as the numbers that are present in the blockchain.
In practice, though, this is not too difficult to achieve and the two systems play quite nicely with each other. Very nicely, in fact.
A sample use case
A good example of a hypothetical integration process might be the development of a killer app like digital cash (aka a “fiat-backed stablecoin” in industry parlance) that will support micropayments, pay-per-download of digital content and the natural extension of Internet of Things, the machine-to-machine economy.
Digital cash as a concept is not new and has been tried before, starting with the original Ripple gateways in 2013 and followed by later attempts like BitAssets that involved backing the stablecoin with a non-fiat asset.
More recent efforts like basecoin are at the white paper stage, with theoretical approaches to creating an algorithmically backed stablecoin. And, while we are waiting for central banks to issue digital versions of their own currencies (very possible, but unlikely to happen for quite some time) existing commercial banks could get the ball rolling.
So, what integrations would be needed to deploy a fiat-backed stablecoin?
First, we would have to identify the components and integration points needed for a simple tokenized digital cash system as follows:
- User wallet: The user registers his or her blockchain wallet with the digital cash platform. Know your customer(KYC) checks would be performed at this time. An integration with a KYC system is required.
- Escrow account: The account at the bank where the funds from all the different users are pooled. Segregation of those funds happens on the distributed ledger.
- Tokenizer: The interface between the core bank system and the blockchain. This application detects incoming transfers to the escrow account and creates the matching amount of digital tokens in the user’s wallet. It also handles redemptions of tokens and triggers their destruction and the corresponding transfer of real funds from the escrow account back to the user’s bank account.
- Transactions: These occur directly between user wallets on the blockchain. No integration as such is needed, although regulations may require that both wallets conduct KYC in advance and anti-money-laundering (AML) screening might be required for transactions above a certain size
From a technical point of view, building a digital cash application is quite straightforward.
Very few integrations with core bank systems are required. The “tokenizer” does most of the work, with KYC and AML being done off-chain if needed.
Of course, there are many legal and regulatory challenges that will need to be overcome before bank-backed digital cash becomes a reality on public blockchains.
But for blockchains, particularly smart contract platforms, to reach their true potential and become an integral part of the lives of the Earth’s 7 billion people, enabling tokenized versions of real money is an essential step.
Admittedly some of the technology is not quite ready to support digital cash at scale. But the good news is that from an integration point of view at least, creating a fiat-backed stablecoin might not be too difficult.
In fact, it might be the easiest integration of all.
Disagree? CoinDesk is looking for submissions to its 2017 in Review series. Email news@coindesk.com to pitch your idea and make your views heard.
Miniature technicians via Shutterstock