KYC, GDPR and DLT pt2: Potential Solutions

In a previous article I looked at how Distributed Ledger Technology (DLT) can be applied to the issue of making sure you understand who you are doing business with i.e. Know Your Customer (KYC). The opportunity here is to reimagine what is normally not a differentiating business process by mutualising your operations with your competitors. Unfortunately, Version 0 and Version 1 of the solution collided with GDPR’s right to be forgotten which makes the use of immutable records problematic. How can you take advantage of a Distributed Ledger’s characteristics if one of those directly contravenes the law for certain types of data?

Here I take a look at potential solutions to this problem.

Version 2

As a reminder, a person has a right to have Personally Identifiable Information (PII - like their  name, Date of birth etc) removed from systems if there is no compelling need for the system to keep it. If storing PII in an immutable store is a problem then the solution must be to not store it there. The next version is very similar to Version 1 but no PII data is stored on ledger, only the evidence that it has been checked is.

1. Any PII is stored in a standard database off ledger (this may or may not be centralised) with the location being submitted on the ledger

2. The process is the same as in Version 1, with the validators resolving the location on the ledger to the off ledger storage, performing their checks and then signing a hash of the PII to indicate that it is valid

3. The customer then controls which businesses can see this PII and validation and when they can see it

4. If the customer wants to exercise their right to be forgotten then they remove the off ledger storage

A bit more complicated than Version 1 but we are starting to see the bones of a workable solution. Unfortunately, earlier in 2018 the EU ruled that encrypted PII and hashes of PII also are themselves PII. This is because of the concept of “linkability”. Given enough data you can resolve this pseudo anonymised data back to real individuals. The ruling is woolly on this point in that it talks about how reasonable it would be to put the full picture back together.

There are techniques that make this harder (e.g. salting the hashes for each business) but a solution’s compliance to GDPR will be determined on a case by case basis depending on how “linkable” the information left on the ledger is. That means that any platform employing these techniques would be wise to get a legal review - but their fate will ultimately be decided by the, as yet, unwritten case law.

Version 3

If we assume (in the worst case) that putting any PII in any immutable store is not allowed at all then the “right to be forgotten” leads us to categorise all use cases into three buckets:

1. Business to business e.g. Trade Finance or Supply chain

2. Business to single consumer (where one person’s data and updates are completely independent and never interact with another’s) e.g. KYC or Health Records

3. Business to multiple consumers (where one person’s transactions are linked to another person’s) e.g. betting platform

Looking at these in turn, A) Business to business should be unaffected in that there is no PII to worry about. B) and C) look intractable but B) has an intriguing possibility where you seperate each person’s transactions onto a separate ledger instance. In this situation the right to be forgotten is satisfied as the customer’s ledger in its entirety could be deleted. In fact you can think of this solution as being a cross between Version 1 and Infrastructure As Code as ledgers are created, managed and destroyed on an ongoing basis. The problem then becomes one of managing lots of micro ledgers. The sequence would be:

1. When a new person wants to be checked a ledger is created

2. [Steps as in Version 1]

3. When a bank wants to know about a customer the customer (now fully the data controller) publishes the existence of their ledger to the bank

4. When they want to be forgotten the whole ledger can be removed

This works but the problem becomes an economic one: can you create these micro ledgers cheaply enough that everyone can have one each?

Other options

There are other technologies that could be brought to bear in a potential solution to the right to be forgotten:

• Self Sovereign Identity - Here the core problem of KYC is solved. A bank does not care where I live or how old I am but it does care that I have the right to do business with them. So why not solve the original problem of storing the rights of the individual (rather than some proxy data) with the individual. These projects are in their infancy and are probably a step too far for organisations today.

• Zero Knowledge Proof systems - This is a cryptographic technique where you can prove that you know something without disclosing the thing that you know. At the risk of oversimplifying, PII storage would be less of an issue if it was never transferred in the first place. While the technology has been around for a while, it is largely untested in the enterprise and so again it may be too soon.

• Blockchain inspired technology - Fundamentally what cross party workflow needs are characteristics of blockchain systems - e.g. immutability except where all a participant’s data is no longer needed. There are a class of DLT systems that are not solely blockchains which are well placed to deliver the first GDPR compliant immutable ledger!

Conclusion

As you can see, as a new piece of technology is applied to an existing process it goes on a journey. For KYC and DLT this journey is just beginning and certainly not solved. What we can say for sure is that

• More businesses rather than fewer will need to conduct KYC checks

• GDPR reality will become clear with real fines being handed down

• The continual need for reducing costs means that mutualising your operation with potential competitors will be unavoidable.

This last point is, for me, the crux as once this has been reliably demonstrated, all cross-party workflow processes will be in scope - resulting in endless possibilities.