Streamlining the Know Your Customer procedure with blockchain
Credit to Author: Alexander Moiseev| Date: Fri, 14 Jun 2019 16:45:39 +0000
Last year, I wrote a post about the possible privacy implications of applying blockchain technology to such areas as education, health care, and human resource management. However, a blockchain-based solution to a problem plagued by the shortcomings of traditional approaches can help with dealing with personal data as well. I am talking about KYC (know your customer), and recent advances in using blockchain for KYC procedures.
The term “know your customer” originally came from financial services. Banks needed to identify their customers, make sure they didn’t cheat, and be able to check their credit history. So, banks developed a set of documents and a procedure that pretty much standardized the handling of loan requests.
Later, other areas of business adopted the model. If company A wanted to do business with company B, A would need a set of documents including (but not limited to): company B’s registration number, tax number, and bank routing and account number. Typically, the authenticity of these documents have to be verified by a third party, and that’s where bureaucracy kicks in.
Normally, processing the paperwork — making phone calls and requesting required confirmations — takes a lot of time and effort. That’s a problem. But sometimes clerks simply stamp the papers without thorough checking. Bigger problem.
When bureaucracy checks fail, the bureaucracy does a strange thing: introduces more checks. Take the banking industry, for example. In 2017, according to a Thomson Reuters survey, KYC procedures took an average of 32 days, up from 28 days in 2016.
Using digital signatures, once viewed as a possible solution to these problems, cannot obviate the authenticity checks of documents required by KYC procedures. And digital signatures can be forged or stolen.
Blockchain technology can dramatically reduce the time needed for authenticity checks. Commercial blockchain architects invented the term privileged nodes some time ago. In our example, when company A needs a set of documents about company B verified, it sends a request to a certification node (owned by the state or an authorized agent). The certification node checks that company B has provided the consent for the documents requested, checks the validity of the documents (i.e., that they have not expired) and only then returns them to company A.
All of this logic can be programmed into a smart contract and tweaked to the needs of the businesses involved. For example, the smart contract may be programmed to yield the full set of documents or an incomplete set of documents that haven’t expired and that company B has consented to provide. In the latter case company A can decide whether to take the risk of continuing to do business with company B, or to halt further operations.
The innate flexibility of smart contracts, in this case, gives businesses freedom of choice, which is essential for a market economy to flourish. For example, company B may not consent to providing a specific document to company A, but it can notify A that such a document exists and has been verified by a privileged node.
We can apply this approach to dealing with consumers’ personal data, where identity management is caught between the rock and hard place of antifraud measures and the GDPR. On the one hand, knowledge that a given consumer has a clean credit history verified by a credible authority is essential for antifraud measures, but on the other hand, banks have no need to keep or store that data.
Furthermore, consent can expire in smart contracts — so, for example, company A loses access to certain documents from company B once consent has expired. Sounds perfect, doesn’t it? Well, not really; we still need to be very careful what information is included in the blocks exchanged through the blockchain network. Even without those documents, the distributed database should contain some of their characteristics, such as checksums or hashes and expiration dates. The availability of this info, along with the data about requests and consent, on the distributed ledger can reduce the time required to pass the KYC procedures from days (or months, let’s be honest) to hours or even minutes!
What I’m talking about here is not a theory. IBM has supported the commercial blockchain platform Hyperledger since 2015, and the company has already demonstrated a working KYC proof-of-concept for a bunch of global banks, including Deutsche Bank and HSBC. In the B2C domain, NEC is actively pushing a one-step KYC solution that aims to improve the customer experience dramatically.
To make sure it all works as intended, we must pay close attention to the smart contract behind such a solution. Smart contracts are not immune to mistakes, and mistakes in this case will ruin the idea of secure automatization of the KYC. We already know that the current state of smart contract writing culture is far from perfect.
That is why the core of our blockchain security package is a smart-contract code review. Our antimalware experts identify known security vulnerabilities and design flaws as well as look for undocumented features of smart contracts. They present a detailed report on any vulnerabilities detected and provide guidance on how to fix them. Learn more on the Kaspersky Token Offering Security webpage.