BY KEITH PRITCHARD
This article was first published in Global Banking & Finance, July 2018.
There are a wide range of opinions about blockchain and distributed ledger (DL) technologies within the financial services industry, ranging from severe scepticism to zealous advocacy. Even though blockchain regularly hits the trade media headlines, it is vital to ensure that the designed platform will deliver real benefits and properly fit the business’ operational needs rather than just rushing into implementation. Getting it right is expensive, but so too is getting it wrong: beyond possibly providing proof of concept, there will be very little else to show if you get it wrong, except for a dent in the finances and plenty of red faces. There are many critical factors to contemplate – some of those affecting the investment banking arena are discussed below – before making the decision to start an implementation project and, perhaps surprisingly for some, it doesn’t necessarily have to be a case of all or nothing.
Distribute data, functionality or both?
One of the first key decisions is to decide whether the proposed DL platform will distribute both data and functionality or whether it will distribute data only and have the functionality supported by a central Trusted Service Provider (TSP).
Distributing data is beneficial for many reasons. It can lower barriers to entry for service providers on the network and so increase competition amongst those services using the data. It can also reduce the need for complex and expensive reconciliations between participants in that market. If functionality is distributed, although it would avoid the need for a TSP, a downside is that it would almost certainly result in higher technology costs. Consider, for example, the calculation of cashflows in the interest rate derivatives market where we might implement one of two models. In the first model a TSP is involved and calculates the derivative cashflows, distributes them to all the parties who will automatically accept its calculations. In the second model the functionality is distributed and implemented as smart contracts. Each member of the blockchain network would have the code to calculate the cashflows running on their own server. They each then run that software and, via a consensus process, ensure that the calculations performed by each member agree. Once consensus is reached they each then save that cashflow to their local chain. This multiple execution and consensus process is one of the reasons the full blockchain design has earned a reputation of being slow. In reality this only applies if you distribute functionality execution to the members of the network.
Distributing functionality can also create difficulties in platform management. Imagine when software needs to be amended or a calculation changed: blockchain provides a very elegant mechanism to perform the distribution of the new software. The issue is that the software change needs to be updated for everyone at exactly the same time. Anyone familiar with investment banking back office processes will be only too aware that each will have protocols about when software changes will, and critically won’t, be permitted – for example many won’t permit any software changes immediately prior to a year end. Finding a time for an acceptable time for all for making the change won’t necessarily be an easy task. Distributing functionality may also increase the overall technology running costs for the members of the network. Consider a situation where the TSP described above is replaced by distributed functionality for a market that has 15 members. Under this model the costs of running the functionality is 15 times higher, in total for the market, than running the functionality once under the TSP model. Under the “distributed functionality” model, the market would also need to run a set of new services on each node to support the consensus process further adding to the cost. Need for a strong business case Where there are existing platforms that support the target market or process, having a clear business case for implementing a blockchain platform is essential. This is not peculiar to blockchain projects but would equally apply to significant architecture reengineering. The problems the project is intending to deal with must be clearly identified and understood and we must then align the elements of the blockchain design to the elements of the problem we are trying to solve. A robust diligence process also needs to carefully consider the alternative technological options available to solve those problems and determine whether blockchain really is the best solution. As discussed above, the business case needs to address whether functionality will be distributed or will be supported by a TSP, given that distributing functionality to the ledger nodes is highly likely to increase technology costs for the members of a market as a whole. Some practical considerations Ahead of proceeding with a blockchain implementation, there are some important additional considerations that should be taken into account:
Duplication of effort – If blockchain is adopted, it’s likely that many businesses will continue to maintain traditional Enterprise Databases (EDB) alongside the chain, especially if complex queries need to be supported. Quite apart from the resultant duplication in work, we would also require regular reconciliation to ensure that the DL and EDB remain synchronised. Thus, we might find that we have simply replaced reconciliations between members of a market with reconciliations within the infrastructure of each member.
Network Administration – We’ve already noted the difficulty in arranging simultaneous upgrading for all DL participants., But it’s also important also not to forget that maintaining a private network would need a centralised administration for managing the build and testing of the software and other administration activities such as key management and network member on-boarding.
Recovery from error – Attention needs to be given to what happens if something goes wrong: say a malicious hack or software bug results in incorrect data being saved to the chain. In an EDB, erroneous data can easily be corrected, but in blockchain you cannot change historic data. To correct the error, you’d have to pass a correcting transaction through the entire network. In many situations this might be considered a good thing, but experience tells us that at some point a time critical direct update to underlying data will be required. The key point here is that the reaction to these failure scenarios needs to be thought through as an integral part of designing the platform.
Data privacy & protection – Private and commercially sensitive information are another contentious issue. Even though such information can be cryptographically protected, the mindset of many executives is such that they won’t be happy about storing private data on blockchain as they’ll be worried about possible security breaches making their data viewable to competitors. It is likely that many businesses will choose to continue maintaining a separate EDB for their private dataRecovery from error – Attention needs to be given to what happens if something goes wrong: say a malicious hack or software bug results in incorrect data being saved to the chain. In an EDB, erroneous data can easily be corrected, but in blockchain you cannot change historic data. To correct the error, you’d have to pass a correcting transaction through the entire network. In many situations this might be considered a good thing, but experience tells us that at some point a time critical direct update to underlying data will be required. The key point here is that the reaction to these failure scenarios needs to be thought through as an integral part of designing the platform.
– cue synchronisation issues again! There are ways of engineering the block chain platform to be selective about what data is stored on which node of the network, but again these are critical design issues that need to be considered in advance.
Trust – One of the key features of the model of blockchain in which you distribute both data and functionality is the fact that you no longer need to trust any actor on the network. In the case of a financial services network, however, trust is almost unavoidable;
Most Financial Services applications will likely be closed networks in which the credentials of the members are known and proven in advance (consider “Know Your Customer regulations”). Thus, there will, as a minimum, need to be some service provider who is trusted by the network to manage this type of admin function.
In our previous example of cashflow calculation on a derivatives network, typically the calculations require the use of some market observations (interest rates, share prices, credit ratings etc.). The question then arises as to where this observation data comes from and it needs to be from somewhere that the network trusts as a source of this data.
So, what to do? There is no doubt that blockchain should be one of the tools in the technology toolbox for solving business problems. We do need, however, to ensure first that we fully understand the nature of the problems we are trying to solve and then whether some aspects of the blockchain design might be the most appropriate way of solving those problems. Think carefully about whether you really want to distribute functionality. It adds additional cost and the technical processes will be more complex than the traditional TSP alternative. Looked at from that perspective, within Financial Services I don’t see much benefit in distributing complex functionality to the nodes of the network. On the other hand, I see significant benefits in distributing data as it is both a way of reducing reconciliations and it will also lower the barriers to entry for service providers to the market. Blockchain certainly provides highly viable and valuable technical options for solving business problems and it will be an increasing part of future business, but it won’t get everything its own way. Choices abound, think carefully when you make your decision.