Distributed Ledger Technology – yes, no or selective implementation?
- Keith Pritchard, Director at JDX base60 Consulting
- 02.05.2018 06:45 am undisclosed , Keith Pritchard, Director, JDX base60 Consulting has a 27-year career in applied technology in investment Banking. With a PhD from Oxford University, Pritchard launched his consultancy career at Price Waterhouse, moving to JPMorgan to oversee derivative pricing and risk management systems. Stints at Bank of New York and RBS followed before he returned to JP Morgan to head up the global technology division for derivatives and FX post trade. He joined JDX last year as part of the firm’s focus to provide clients with support and guidance in practical applications of Distributed Ledger Technology (DLT) projects while meeting complex regulatory requirements.
There are many factors to take into account when considering implementing a blockchain based platform. there was an interesting poll at the recent DTCC Fintech Symposium 2018, that sought to gauge the primary concerns about implementing blockchain, when it posed the following question to its delegates:
“What aspects of implementing blockchain technology do you believe present the greatest challenges?” [1]
- 35% Business Case/Unknown costs
- 17% Interoperability/compatibility
- 17% Legal and regulatory framework
- 15% Technology maturity
- 9% Data privacy
- 5% Changing market behaviour
- 2% Other
There are two aspects of this that I think are worth discussing in more detail, the first is “why is it so difficult to create a business case” and the second is “why is solution design not highlighted as a bigger issue”.
In Financial Services, and particularly in Investment Banking, one significant difficulty in making a business case is that there is typically an existing infrastructure already in place supporting the target business or process. Replacing that infrastructure with a new one, getting all members of the market to change the way they interact with the new infrastructure and going through the significant amount of testing involved can be prohibitively expensive. Even if the new platform is cheaper to run and more efficient, the point at which that investment is paid back by the savings may not make for a good business case.
Another key factor I’ve seen in the failure of business cases is where they are not absolutely clear on what is the business problem that is being addressed, which aspects of the overall blockchain design can help solve those problems, what other technology solutions were considered and why was a blockchain solution considered more appropriate than other technology solutions. Without a logical and rigorous exploration of all of these aspects then the suspicion can grow amongst the business sponsors that the project is being proposed by technologist for technology’s sake or is simply part of the ‘current hype’ surrounding the technology.
As an example of this, which will lead into my second theme of application design, consider the fact that one aspect of a blockchain solution that is often put high on the list of advantages is that it can be designed in such a way that it avoids the need to trust a central authority or service provider. This is certainly true and in some problem domains this may be a significant benefit. However, in the context of Investment Banking, do we have a problem today with trusting service providers or centralised utilities such as the exchanges, clearing houses, regulatory reporting trade repositories etc. etc? I would argue that trust of such market infrastructure providers is not a significant issue, probably does not feature even in the top 10 of problems that we need to solve and so does not really add to the case for a blockchain solution.
The last statement made above does, however, have an implied fallacy – that there is a single blockchain solution architecture. There are many different blockchain infrastructures that have emerged since Bitcoin first hit the headlines: Ethereum, Corda, DAH, IBM, AxCore, Quorum to name but a few. These provide different ways of achieving a distributed ledger and allow different capabilities to be implemented independently. Thinking about the different capabilities that the platforms bring and which of those capabilities helps solve the business problems we have identified is a key step that I believe often gets missed out in trying to make the business case for a blockchain project.
As an example of this second theme, that of solution design, consider the issue of whether we want to design a Distributed Ledger solution that distributes data only or one that distributes responsibility for functionality execution as well as data.
The standard “distributed functionality” model for a blockchain application is one in which not only is the chain used as a way of distributing synchronised data to every member of the network, but also all business logic is executed by every member. Consider, for example, the calculation of a derivatives cashflow based on a newly published market rate. The ‘distributed functionality’ model involves a piece of code that calculates the size of the cashflow (the code is contained in a Smart Contract – something I’ll come back to) being run by every member of the network. A process called consensus then runs which checks whether all members agree on the size of that cashflow and if they do then the result gets committed to the chain.
The alternative “service provider” model for a blockchain application is one in which the blockchain is used only to synchronise data. In this model, functionality is supported by a service provider who then distributes the results of executing that functionality to every member of the network who accept that result as true and commits it to their chain. In our example this service provider would calculate the size of the cashflow and distribute to all members, with no consensus process being necessary.
Depending on your problem domain, one or other of these design patterns may be most appropriate which in turn may influence the choice of DLT framework you decide to use. I work in the Investment Banking domain and, for the majority of industry problems I encounter, the model of distributing data and functionality is a significantly worse choice than that of distributing data only and having functionality supported by a service provider.
Distributing data such that all members of a network see identical data at the same time can provide significant benefits in reducing reconciliations and the operational error correction processes that result from members in the market using different data. These reconciliation and operational process can consume a surprisingly high proportion of an investment bank’s technology and operations cost. This is a key area that can be used to add to the business case for implementing a Distributed Ledger.
If we take the additional step to distribute functionality we introduce the benefit of not needing to trust a service provider (as discussed above, in Investment Banking I do not see this as a significant benefit as trust in service providers is not problem that needs addressing today). We do, however, introduce some significant downsides with this approach:
- Total running costs are likely to be higher given that all members are running the business logic instead of a single service provider running it.
- We introduce the consensus process which will add latency and cost.
- Every member needs to accept any updates to the codebase of the functionality (for new capabilities or bug fixes) at the same instant. Given the individual restrictions that many banks have on when software can be implemented (e.g. no software updates 2 days before month end, 2 weeks before year end, IMM dates etc.) there may be a very restricted set of dates when changes can be made across the industry.
It is these factors that lead me to the conclusion that distributing functionality to the members of a blockchain network actually makes the business case worse for the Investment Banking business cases I have come across.
Before leaving the subject of distributed functionality I want to touch on Smart Contracts, the mechanism by which distributed functionality is executed by each member of a network. In many quarters there appears to be the assumption that Smart Contacts are a something new, something that can solve the problems of automating agreements written in legal documents. Smart Contracts are code, nothing more, nothing less. They can do nothing that any other piece of code in a traditional architecture can’t do, they are not somehow ‘smarter’ than existing coding practices. Whenever you see the words ‘Smart Contract’ simply replace them with ‘Code’ and see if you still believe the claims being made.
- Understand and clearly articulate the problem to be addressed
- Identify which aspects of a blockchain design might help solve those problems
- Review what other technologies might also help solve those problems
- Compare the available technology approaches and decide which one best fits and delivers the best business case
Blockchain is not the solution to every problem, but it is a new and powerful addition to the toolbox of capabilities that technology solutions providers can bring to bear on business problems.
