Several years ago Blockchain and Distributed Ledger Technology (DLT) were going to solve all problems: from streamlining payments, to world peace! Since then, most have fallen away as not having the business case to support them, but a few use cases have stood the test of time. Know Your Customer (KYC) is one of these. There are many DLT based KYC solutions out there; in fact how those solutions have evolved over time is an interesting case study on how to re-work a business process on DLT.

Existing regulation requires many types of businesses to perform checks on their customers to avoid doing business with those involved in illegal activities. These checks include:

• Validating identity documents

• Checking jurisdiction

• Identifying Politically Exposed Persons (PEPs)?

• Reviewing negative news

These checks, as well as others, are required when you onboard a new customer and, depending on the customer’s risk level, regular repeats need to take place. Unfortunately, these checks all cost money and they don’t amount to a significant competitive advantage for the business: they are just a cost of doing business.

Since the arrival of DLT there has been the intriguing possibility that these costs can be dramatically reduced. Currently every institution a customer trades with has to perform those checks. With a permissioned DLT, a customer can be checked once with the results placed on the ledger which can then be used by all institutions looking to trade with them. This secure reuse of the the results naturally leads to the business aim of reduced costs for all. As an additional benefit, the customer can maintain their own information updating it as required and even revoking an institution’s permission to see it. This has GDPR implications more of which we will cover later.

Below is the journey of one solution we are aware of.

Version 0

Like other transformational technology, Blockchain and DLT have often been described as a solution looking for a problem. Platform vendors eager for market share have been applying this technology in all sorts of domains they are not experts in. The first version of a KYC solution may have looked like:

1. A customer contributes some Personal Identifiable Information (PII) onto the ledger. For example their passport information and / or previous employment

2. This information is validated by the certifying authority (e.g. the Passport Office or the previous Employer)

3. That validation is recorded on the ledger

4. The customer can permission businesses to see it or not as they see fit

Unfortunately this process, while achieving the cost reduction business aims, is impractical, naive and doesn’t cover all the checks. The business aims are met as the checks are performed only once and thus the costs are reduced. It is simplistic as this does not meet the functional requirements - in short the process is wrong.

Version 1

A more appropriate sequence would be:

1. The customer takes a selfie picture or video with their identity document. This is stored on the ledger

2. This selfie is validated by one of the many services who provide automatic document validation through an automatic agent listening to the ledger and forwarding the information to a service’s API. Their approval (or rejection) is recorded on the ledger.

3. Once approved the identity document is used by a KYC outsourcer to perform the checks described at the top of this article.

4. Once those are passed, the PII and the associated checks are published or revoked to the businesses that ask for them.

5. Optionally, the receipt of the information can trigger payments from the business to the entities who executed the checks.

This last point is a good example of the difference between digitising a process or making it digital. The former is where you replatform a process onto a DLT but it looks largely the same. Cost reduction can occur due to streamlining and the removal of intermediaries. The latter is where you start to rethink the process completely. Starting with a blank canvas and today’s technology: How would we design this process optimally? Changing the dynamic of who pays for this and then shows how this business process is starting to become digital. Becoming digital is where new revenue streams will come from.

Version 1 does, however, run into the problems of GDPR. Since May 2018 systems in Europe have to make sure that if they store PII then they are compliant with the rights of the individual. The main issue here is that GDPR specifies the right to be forgotten. In other words, if the individual wants their data removed from a system, then the Data Controller (in a permissioned DLT, this might be the party running the platform) has to make sure there is no evidence that the individual was ever there; or the Data Controller needs to demonstrate a compelling need to retain the information.

Unfortunately, one of the strengths of Blockchains and Ledgers in general is that they store an immutable version of the data. This makes PII data removal difficult to say the least.

In the next article I will look at how you can address the GDPR issue and yet still maintain the benefits of applying DLT to the problem of KYC.