This article was originally published in the Global Banking and Finance Review on 10 December, 2016.

Blockchain technology has received a lot of attention for its potential to revolutionise different sectors, and financial services is widely believed to be the area with the greatest potential for distributed ledger technology (DLT) to transform and disrupt existing processes.

Should its use be regulated and, if so, what shape would that take? How to respond to these questions is a challenge for product developers, financial markets participants and regulators alike. And, when should the regulator step in? Patrick Armstrong, a Senior Risk Analysis Officer at the European Securities and Markets Authority has recently described the answer to this question as the "regulatory "tipping point" - the point between "too small to care" and "too large to ignore"". I suspect that most observers would agree that the scale is somewhat tipping towards the latter.

The regulators' stance, at least in the UK and the EU, seems to be to support development, keep an open mind, monitor and "wait and see". It would be wrong to perceive this as regulators taking a passive approach. Rather, it might be interpreted as a stance taken to learn, without hindering the development of a socially and economically beneficial process or product.

The UK regulator's "regulatory sandbox", a part of Project Innovate, provides a good example of the pro-active approach. The regulatory sandbox was established to create a space in which start-up developers and incumbents can test innovative products, services, business models and delivery mechanisms in a live environment while ensuring that consumers are appropriately protected.

Of the firms currently using the sandbox to test their models, nine involve the use of DLT. These projects serve a broad range of financial services: from cross border money transfers to a payments platform allowing the Department of Work and Pensions to credit value to a mobile device; to streamlining the Initial Public Offering distribution process; and providing a system for automated customer authentication.

This latter use of DLT is one which is being observed with some cautious enthusiasm by regulators and industry bodies and the FCA sees it having the potential to offer innovative solutions to financial crime issues and as presenting real opportunities for the regulated sector to meet Know Your Customer and Anti-Money Laundering requirements more effectively. In turn, the technology does give rise to its own connected issues. One of the questions identified by regulators, for example, is how do individuals gain access to a distributed network and who controls this process.

A different use was recently tested by the Bank of England who undertook a Proof of Concept (POC) to explore DLT's application to the transfer of ownership of a fictional asset among several participants, including a central authority which could establish the supply of the asset and permission to access and use the ledger.

Several areas emerged as meriting further exploration by the Bank. These included:

  • The need for assurance that a system could operate with total data integrity and reliability at high speeds and high volumes.
  • The search for certainty that the privacy of the data in the distributed ledgers would not be vulnerable to cyberattack both now and in the future.
  • For DLT to be used in any central bank application, a high standard of privacy and resilience would be required.
  • Develop an understanding of how existing data processes and infrastructure might interact with distributed ledgers.
  • The Bank asserts that DLT systems typically use more energy and require more data storage than traditional ledgers. Consideration of how these can be minimised as systems increase in scale, will be important.

Any design of the technology and processes of regulation will have to take into account these factors.

The likely impact of regulation will be focused on systems, processes and controls rather than adding new regulated activities to the existing broad range of products and services which fall within the regulated ambit (leaving aside the question of cryptocurrencies). The focus will be on how regulated firms, using the technology, address the sorts of issues highlighted by the Bank of England above and how the regulators supervise those firms.

Of course financial institutions are already governed and supervised by legal and regulatory codes and prudential requirements.

Strict rules require regulated firms to establish, implement and maintain robust policies and procedures sufficient to counter the risk that the firm might be used to further financial crime. Where it is proportionate, taking account of the complexity of its business model, a firm must set out and maintain an audit plan to examine and evaluate the adequacy and effectiveness of its systems, internal control mechanisms and arrangements. For firms using DLT, extra focus will be directed at how these systems and controls are applied to the technology.

Prudential rules ensure that a firm's capital resources are assessed in relation to all the activities of the firm and, amongst other things, the risk of loss resulting from inadequate or failed internal processes, people and systems.

We think the regulator's expectations will be high.

Further interesting discussion arises from the distinction between, on the one hand, legal and regulatory codes which consist of legal obligations and, on the other, technical code governing software and protocols upon which distributed ledgers rely. This distinction was highlighted recently in a report by the UK Government Chief Scientific Adviser.

The fundamental difference between regulatory code and technical code is that regulatory code comes from outside the DLT physical environment and is "extrinsic" and, by contrast, technical code is "intrinsic". Regulatory rules can be broken but regulatory consequences and penalties may follow. If the rules of a technical code are broken, an error is returned and no activity occurs. The technical code means that the software is self-regulating, through the operation of the code itself, through rigid compliance with the rules even where that compliance might lead to undesirable outcomes.

Overcoming this form of technical rigidity, which from some perspectives is perhaps at the heart of the benefits of DLT, may give rise to the biggest of the regulators' challenges: recognising the strength and weaknesses of both technical code and regulatory code and how the two interact. DLT providers will need to design accordingly.