I'm finding that I'm having very productive discussions with lawyers as ideas mature on how blockchain could be used in financial services

I should stress that I'm a technologist rather than a lawyer – a student job at a firm of Edinburgh solicitors rapidly demonstrated that Scots law was not for me. However, if you wish to build a blockchain architecture (or other distributed ledger) for financial services, then designing it in a legally compliant way from the start will save a massive amount of time and cost later. This was case with the build of the last generations of payment settlement systems and using good project design principles to get non-negotiable requirements in early will help determine the success or failure of the new generation.

It's a lesson I learnt early in my career as part of the team that designed & delivered CLS Bank, (the global system for real time foreign exchange settlement). Building one of the first real time (or near real-time) global settlement systems was a difficult project. Although the technology we would use now has moved on, the IBM case study on CLS Bank helps give an indication of the challenges and scale that any emerging blockchain systems will need to address. One of the biggest challengs that I worked on was that when regulation shifted, potentially the whole system design had to shift with it.

There is a culture in part of the start-up world that sees regulation (and law) as automatically negative and an invitation for disruption. The law and regulation for financial services may be tedious in places, but there are good reasons for that. The last decade's banking crises has highlighted systemic risk in a way which is less inherent for the markets Uber and Airbnb work in. On a more pragmatic level, the law is not going to change rapidly and working with the current environment is likely to make far more progress than bypassing or confronting the law directly. Pascal Bouvier has written very well on this (see for example, "Distributed Ledgers Part II: Clearing, Settlements & Legal frameworks") and I agree with his analysis that little in the legal framework for international settlement is broken. When it's not broken and is powerfully enforced, I find it difficult to see how the blockchain can thrive if it does not engage with the legal reality.

This was really brought home to me last month in discussions at the BitCoin and Blockchain Forum in a group chaired by Claire Harrop of Freshfields. The exciting thing about the blockchain is what the distributed ledger could enable. The challenge is how the legal requirements need to be applied in a distributed environment.

Data and territorial jurisdiction:

One of its biggest challenges when looking at designing a blockchain system is that as a distributed ledger is, well, "distributed". It may seem just a design difference over today's centralised ledgers but it has profound implications for jurisdiction and data.

The biggest (in a blockchain type design) is that what is in the ledger of one bank potentially needs to be distributed to all other parties in the system (otherwise it's not a true distributed ledger system). This is a radical difference from the current model, where each bank's ledger is unique to each bank. If the system is within a country, then this may raise issues of privacy, but all the data is covered under a single legal system.

The challenge comes when we look at using blockchain for settlement across multiple jurisdictions, say internationally or within the EU. This is where the big opportunity is (ask R3!) but it also presents challenges with what information is being sent where. If, like R3, the ledgers are held by a group of banks who have set up a legal framework with each other then there are potentially very few issues. Additionally, if tokenisation is used, so only the "markers" for data are exchanged, then that also helps manage many of the data privacy issues.

If, on the other hand, the ledgers start to contain information relating to citizens or be more widely distributed, then things may get a lot more difficult.

There isn't really space here to go into the detail of international data privacy and related law (it's a huge subject), but the principles are clear enough. Some countries (e.g. Germany) have strict rules about what data can and can't be shared across borders. Additionally, some groups of countries (e.g. the EU) also have rules that govern their members, but those rules are often principles that then each member then implements as legislation locally.

There are also jurisdictions (notably the US), which take a very broad view of the territorial reach of their law. Given the scale of US capital markets, and the nature of where most cloud solutions are at some level hosted, it would be madness to design a blockchain system (whether of settlement, loan syndication, or whatever) that wasn't compatible with US law. However, that creates issues in itself where parts of US law (such as the Patriot Act) are potentially incompatible with elements of law in other jurisdictions.

To date, most of this has been manageable under the EU/US Safe Harbour Agreement, although the rise of cloud has added to the complexity (back in 2011 ZD Net highlighted a number of potential cloud related legal issues in this series of articles). However, the current Safe Harbour harbour arrangements are now of uncertain status after the "Schrems v. Data Protection Commissioner" case.

My point is not to discuss the validity or otherwise of Safe Harbour and the reach of the US Patriot Act. Rather, there is a more fundamental point, that parts of the current legal environment have yet to form a clear body of law on data distribution – and distributing data (even if only minimal transaction records) is exactly the point of distributed ledgers.

There is also the issue of extra-territorial reach. The announcement of the "Bit Licence" for cryptocurrency firms by the New York Department of Financial Services in June was very welcome for regulatory clarity. Less welcome for non-New York based firms was the fact that having customers, data or back-office in New York (regardless of where you were based) might make you subject to its full provisions,

None of this removes the potential of blockchain, but it does mean that what data goes into the blockchain (and what doesn't!) is a critical design issue.

It also suggests that tokenisation will be a key design consideration for any distributed ledger system that is used internationally. If the actual data is not on the BlockChain, merely a token that represents other information (as NASDAQ has done with coloured BitCoins) then many of the issues are managable.

This leads nicely onto the next issue with Blockchain.... Roll-back.

Roll-back:

The great thing about the Blockchain is that once it's been distributed and the transaction verified, it is very hard to alter (although not technically impossible, of which more later). This is a good thing and one of the attractions that, once built into the blockchain, data is fixed.

The challenge comes with how you manage a situation such as the "Schrems v. Data Protection Commissioner" case. There, what was previously accepted practice, has now been ruled as needing revision. That's painful, but most systems can manage it by taking out the data that's at issue. With a distributed blockchain, any legal judgement that requires data going back years to be changed becomes more challenging. That's not to say that it cannot be designed in but that would remove the censorship resistance that is so important to BitCoin and is why throughout this article I've mostly used the term "blockchain".

One of the challenges in the BitCoin implementation of blockchain is that BitCoins effectively behaves like bearer bonds. To have a BitCoin is to own it, whereas the settlement of other assets has a lot of focus on legal title and (if need be) the ability to roll back or suspend settlement should other actors (courts, governments, etc...) require it.

None of this is insoluble with good design, but it will require carefully consideration of how any blockchain based settlement system operates day to day. On CLS Bank at the early pre-production stage, making manual fixes to message formats was not too hard, developing the audit trail around those fixes that complied with the requirements of every interested regulator was a significant piece of work.

Economic security vs. cryptographic security:

It's perhaps the least likely of my points, but legally it is one that I find very interesting.

Today the banking industry depends on encryption for most of its transaction security. If a message is successfully attacked, then generally speaking, either the keys were lost, it was sent to the wrong place or (if it's broken by brute force compute) the encryption was too weak. This makes for a reasonably clear understanding of risk, and with it, potential liabilities.

The fascinating thing about BitCoin is that it doesn't in principle rely on cryptography for security. Instead, it relies on economic security (the participants vested interest in the network), the difficulty of reverse engineering the blockchain and scale for much of its defences. These are good principles but very different from the cryptography based principles used today by most banks. Additionally, in a BitCoin based world it's important to appreciate that hashing and cryptography are not the same thing. Hashing does provide security (that of proof of work) but it is a different security to a different threat from the threats that cryptography addresses.

A blockchain implementation outside of BitCoin can avoid many of these issues but still needs to be secure. Whatever security is developed (tokenisation with homomorphic encryption for a closed system of only trusted participants, perhaps?), it needs to be one where the risks and liability can be defined and understood. Otherwise, no lawyer, risk officer or regulator is going to be keen on banks playing with potentially unknown liabilities.

I'm confident that for settlement a blockchain based system offers huge potential. The challenge is to create a blockchain based environment that complies with all the relevant regulation and legislation.