This article provides one potential use of the blockchain technology. I do not pretend to know everything about blockchain, I’m on a journey of discovery like most are in this new world. I have very likely made wrong assumptions, interpreted things incorrectly and so on. But hopefully you can appreciate my abstract thoughts.
If you have yet to be enlightened on the underlying technology that bitcoin is built on, and why it’s very cool, take a trip over to Richard’s blog here http://gendal.me/. He has been thinking about its future applications for a while and blogs about it for the benefit of Financial-Services-kind.
So I’m a technical guy, I spend my time thinking ideals, but ultimately have to deliver practically. Today I’m on the ideal side of the spectrum…
Although there are now 10’s if not 100’s of start ups trying to capitalise on the blockchain technology, in my opinion, there has yet to be a significant disrupter when it comes to the heart of retail transactional banking IT operations – it’s core account ledgers, holding our deposits and loans, and the core payment system, allowing banks to do what they do – Money In Money Out as I like to state… often…
Today I want to focus on the core ledgers, as everyone else seems to focus on payments – rightly so, as that’s where there is money to be made 🙂 It’s a costly business transferring deposits.
All core ledgers have to as a minimum support the management of customer balances to ensure the current position is known, and the associated transactions describing how it got to that state. In addition, they are typically wrapped in product and customer management solutions, along with other functions, statement processing, payments processing etc. that do not need to perform or be available as the balance.
These have historically been large monolithic platforms, be they custom or package solutions providing the bulk of the features in a tightly coupled system. A highly available monolith at that, typically because all core transactional processing applications require access to an up to date balance to make a decision – pay or no pay?
As banks have become more complex, through diversification of products, channels, geographies and regulatory pressures, additional systems have been introduced into the architecture over the years, requiring batch and real-time access to the balances and transactional data, with the latter typically being replicated between systems.
This then leads to a proliferation of transactional data throughout the estate, stored and managed in multiple places and likely on multiple technology platforms, with additional copies of that data stored in logs, backups, other databases, exposed by multiple other services and so on. These all come with multiple controls to ensure the balances and transactions are secure and controlled, reconcile and so on etc… you get the idea. All of this to support a multitude of purposes, from auditing, reporting, payment processing, to resilience and business continuity.
This can lead to a spiders web of complexity to ensure all systems can get access to the data they need when they need it, to transact when they need without impacting other systems and their consumers.
It’s right to separate concerns, especially processing concerns in the new world of micro services and the API economy, but is there a better way of having multiple copies of the core data, for all the above purposes without having a monolithic core ledger?
Now the blockchain or shared replicated ledger will no doubt revolutionise international and also domestic payments, and could become the scheme of all payment schemes (it certainly has potential to – if the banks allow it), but are we going to get there quickly? Probably not, their are too many parties, each with their own motivations. What about inter-group payments where it could be easily implemented? I think this is a big transitional win, only one player making the decision – so I expect a lot of the big players will no doubt be thinking of this. But what about within a single entity, big or small?
Let’s take a look at an oversimplified architectural view of a typical transactional bank:
This view understandably doesn’t show everything – this blog is meant to be produced quickly! but multiply it by say 10, then it gives you an idea of the complexity, with most of the key channel and processing solutions integrating with the central ledger.
Could the blockchain/shared replicated ledger approach be a solution to this complexity one day? Could the move to something like below help remove the monolith and simplify the estate?
I can see a number of benefits to this approach:
- Each processing solution can have it’s own ledger node, on an appropriately sized infrastructure (be it cloud or otherwise), most of these systems want to read the data to process it some way, e.g. display a current balance or produce a statement, they can merrily do this knowing they will not impact the performance of any of the other applications.
- If the ledger provides native replication at the application level, then you remove the need for a lot of the infrastructure solutions, disk replication, backups etc. If you loose a node, no sweat, you bring up another by replicating from one of the others, even consuming another online while you do this, after all they all talk the same language.
- One of the benefits of the blockchain is that it is immutable – there’s no going back once the transaction is committed, especially if you want to do something naughty, like hack an account balance or spend money twice. This is thanks to it’s native hashing and other very cool and geeky approaches. Having multiple nodes with each participating in a transaction (via mining, consensus or some other approach), you can ensure any bad apples are obvious and reject them. I suggest you Google this one.
- Could the ledger node be the record of truth for the processing application also? Is there still a need for technical reconciliation? what level of logging is required? I suspect less so.
- It forces the decoupling of the product, customer and other typical core banking features of the platform. These could be re-engineered to be service like, and on platforms that do not need such demanding NFR compliance.
Now there are some obvious challenges I admit:
- You can’t commit a transaction very quickly today (mining/consensus takes time for all the parties involved to agree the transaction is legit), one blockchain solution provider believe they can keep the commit latency down to 5seconds, but this a snails pace for most core banking ledgers today that can do this in under 100ms – for most banking transactions especially those supporting the new payment schemes, such as UK Faster Payments, or Australia’s New Payments Platform this would likely make the bank breach its industry SLAs. Visa and Mastercard use and ATMs wouldn’t be as friendly either, queues at ATMs tend to be long enough as it is!
- What about data retention? Do these ledgers grow with full transaction history forever? And what about all the disk space required to hold multiple copies of all this information? There are probably ways to already to switch ledgers out with new ones, and storage doesn’t have to that fancy with the blockchain, so cheaper solutions could probably be used to out way any extra copies.
- Data access, currently as I understand it, you’re limited to one access mechanism, service calls, e.g. RESTful services or thelike. Not very friendly to large analytical or reporting based solutions.
Anyway, that’s enough of a mind dump from me, What do you think? I’d appreciate your thoughts, so please post a comment – I’m tough skinned, plus I’m sure I have a delete comment button somewhere so don’t be shy 😉
John White 