Why Isn’t Blockchain Working?

Banks and financial institutions are struggling to bring Blockchain and DLT applications into profitable production. In a market where proof-of-concept (POC) is actually the business model for many firms, we need to be honest about the state of our industry.

There are a variety of reasons blockchain projects within financial institutions fail, some of which boil down to naivety when it comes to live deployment including a lack of understanding of secure deployment procedures for banks. There is a clear disconnect between the high levels of IT security that banks expect vs the innovation-first approach taken by some blockchain frameworks, which fail to take into account deployability and interoperability with existing systems.

To get code inside a bank's secure perimeter requires a meticulous deployment approach. Don't expect that your code can just pull components from the internet. Nothing gets into a bank's systems without every line of

Anthony Culligan , Chief Engineer, SETL — Anthony Culligan, Chief Engineer, SETL

code being screened, checked and approved.

What’s more, low speed, limited scalability and a lack of a strategy for Integration with existing systems, are often to blame. To go from POC to a live system, banks need to plan for high volume and massive scale. They need to work within the array of systems that banks currently deploy. These include links to SWIFT, hardware security modules, enterprise identity systems and many more.

Other reasons why financial institutions struggle to bring DLT projects into profitable production include the use of exotic and unsupported coding languages, a fixation on a particular technology instead of a business goal and lack of analysis of benefits to the end customer.

The 10 reasons why blockchains are not working are described below in further detail and include:

Lack of understanding of secure deployment procedures
Low speed and scalability of chosen ledger
Difficulty of integration with existing systems
Exotic or unsupported coding languages
Fixation on a particular technological approach over business aims
Not analysing customer needs
A misunderstanding of regulatory constraints
Not having a clear strategic vision beyond the PoC
Unrealistic assumptions on decentralisation
Assuming a crypto element within a market infrastructure

What is needed to overcome the barriers to the successful deployment of blockchain projects, is a combination of deep-seated financial market infrastructure expertise, a proven track record in and understanding of operating in regulated high-performance organisations and an appreciation of the complexity and security implications of deploying at scale.

The 10 challenges can be remedied by providing a robust and permissioned toolset for financial institutions to build applications that interoperate between existing infrastructures and a range of enterprise ledger technologies including Corda, Besu, Fabric, DAML and SETL's own high-performance ledger. Moreover, the toolset provided must have the ability to handle high volumes of transactions and operations at the extremely high speeds that the market has come to expect.

Top 10 Reasons Why Blockchain and DLT Projects Fail to Get into Production

Lack of understanding of secure deployment procedures

The process of deploying into a secure bank environment is complicated. Within the secure perimeter of a bank, access to the internet will be tightly controlled and any computer code which is included within an application cannot just be downloaded or injected from external sources. Any common module which is part of an application will typically have to be included from the bank's internal repositories. An application may need to be amended to use those approved modules. Strict roles are applied in the deployment process to ensure a clear separation of responsibilities between the developers, the dev-ops teams and the eventual operators of the software. Many DLTs are not structured to be deployed in this way.

Low speed and scalability of a chosen ledger

Institutional volumes can peak at 1000's of transactions a second. Furthermore, for each transaction, there may be a multitude of events that need to be triggered and serviced. For example, in many jurisdictions, a movement of a security from one client to another needs both the sender and the receiver of the security to acknowledge the transaction before it is executed. Transactions will be held in various states and any change in state will need to generate messages. DLT technologies, which cannot process at the speeds required, might take hours to clear backlogs causing delays and failures in other processes.

The difficulty of integration with existing systems

Most DLTs are self-contained systems and very little thought is put into how they integrate into the complex array of systems that financial institutions deploy. Interoperability needs to start with interoperating with other non-DLT systems. A significant proportion of instructions from counterparts will be in the form of standard financial messages such as FIX or SWIFT messages. Those messages may be carried on any of a number of transport layers such as KAFKA, MQ or even FTP. Having updated a balance on the DLT, another collection of systems, such as ERPs will need to be notified. DLTs which don’t pay attention to integration present sub-optimal solutions in these areas.

Exotic or unsupported coding languages

Before any custom code is deployed live within a financial institution, it needs to be security scanned. There are industry-standard tools that do automated checks for everything from poor programming techniques to known hacks and vulnerabilities. These tools draw upon decades of programming experience around established languages such as JAVA, JS and C++. It takes significant community involvement for the body of knowledge to build up so that these checks can be efficiently automated. Domain-Specific Languages integral to some DLTs lack the critical mass to do this. This means that the experts are harder to recruit, automated code security checking is sparse and the cost of maintaining the system is much higher.

Fixation on a particular technology approach over business aims

Many DLT experts and innovators have invested time and effort in a particular technology. It is natural for them to want to validate that investment and to use that technology in a live environment. This can lead to a less than optimal design vs the business aims. For example, a DLT technology that is primarily designed for bilateral interactions is unlikely to be the best choice for a token-based platform. It may be possible to hammer a square peg into a round hole in a POC, but it is unlikely to pass the test of live implementation.

Not analysing customer needs

Customers of financial institutions want outcomes. A good solution using DLT will have measurable benefits for the financial institution and for its customers. Designing a solution starts with the needs and leads to the best technology to meet those needs. It would be rare that the customer's need is a DLT or a Blockchain. The need is likely to be lower costs, faster settlement, more automation or more functionality. A good solution may not even expose the DLT at its core. Solutions that impose extra burdens on users, such as the need for every participant to run a node, will face barriers to adoption.

A misunderstanding of regulatory constraints

Blockchains and DLTs do not sit outside the regulatory obligations of financial institutions. Those obligations include measures that protect the client's privacy, measures that safeguard assets and measures which ensure the integrity of the market as a whole. DLT and blockchain systems that share data, even on a pseudo-anonymous basis, will not meet these requirements. Some DLT's, for example, expose the whole chain of transactions of a token as a means of verifying the token's uniqueness. This is unlikely to be a compliant approach.

Not having a clear strategic vision beyond the POC

Transcribing an existing system onto a DLT is not a strategic vision in itself. Blockchain and DLT are members of a family of technologies that are transforming our personal and business interactions. Understanding broadly how those changes are evolving in any particular business sector is likely to indicate possible future states. Only with a rigorous analysis of relative strengths and weaknesses can a business devise a technology strategy that may include a component of DLT or blockchain as part of the overall strategy.

Unrealistic assumptions on decentralisation

Financial markets are sophisticated mechanisms of trust. Centuries of experience have evolved into numerous models for transacting and investing which incorporate varying degrees of trust. Third parties, escrows, organised markets and regulators are all valid and useful elements of the trust markets. Intermediaries perform valued roles as advisors, aggregators, network providers and organisers of Liquidity . A fixation on eliminating all intermediaries from a transaction is often impractical from the regulatory point of view, unwieldy for the end user and can involve some technical sleight of hand which hides points of centralisation such as mining pools, notaries or network operators.

Assuming a crypto element within a market infrastructure

Some of the more hyped blockchain technologies require the use of a proprietary token to submit transactions or process smart contracts. A typical approach has been for those tokens to be 'pre-issued' to the company or the founders and for a portion to be sold via an ICO. The implied promise to token holders during the ICO is that someday, mainstream finance will adopt the system and there will be huge demand for their token. In reality, the inclusion of a crypto-token makes the technology harder to adopt as it introduces uncertainty of costs for the user, exposes banks' business models to speculation, creates operational risk around key management and exposes the bank to anonymous trading activity.

Anthony Culligan, Chief Engineer at SETL