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.
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…