Community
As technology continues to evolve and the flow of data becomes ever faster, it is essential to ensure that there is a trusted relationship between financial services firms and their customers. Know Your Customer (KYC) is a concept that has been around for many years in financial services as firms and their customers (or clients) begin to get to know one another and share information prior to doing business, and on an ongoing basis when factors evolve.
The modern process of KYC covers a number of activities related to verifying the client’s identity and determining the potential risks of starting a business relationship with them. However, many firms continue to struggle every day with the difficulties of ‘onboarding’ new clients and managing the associated checks, particularly since it involves the sharing of personal and confidential data, and I believe much could be done to improve the processes and to consolidate customer data.
As new technologies emerge it is therefore useful to review them to see if they could provide a benefit for the complex and manual KYC processes, and in particular those of onboarding new customers.
Could blockchain provide the answer?
Whilst there are many proposed use cases being mooted for the application of distributed ledger technology (DLT), some of the attributes of permissioned data, only available to those actors who require it, suggests that it could have a part to play in more efficient future KYC processes.
One such possibility is provided by the Hyperledger Fabric - a permissioned blockchain infrastructure which uses ‘peer nodes’ with precisely defined roles to execute smart contracts (chaincodes), the results of which are stored in cryptographically safe and consistent blockchain structures. This makes it ideal for managing sensitive client data, since the blockchain structures offers an ‘append-only’, cryptographically consistent system of record (SoR). By design, it therefore supports keeping “one version of truth” for sensitive client data. When an employee searches for a piece of data, they automatically obtain the single, correct version, checked automatically by the logic of the interconnected nodes. They don’t need to reach out to any other employees to check, since the code itself takes care of consistency.
What’s more, the information stored is immutable and cannot be changed, since the unique architecture of the blockchain prevents any tampering or amendments being made to the data. As a result, users of the application can trace the entire history of any data changes and have certainty that the registered changes are authentic and not forged.
Improved business flow
Taking this logic a step further, data stored in this way can then be securely re-used across the entire organisation. When the same client wants to buy a new product or service, the previously verified due diligence documents can be used once again, without repeating the lengthy and painful checks. A shorter and cheaper process means a happier client and a more efficient firm.
However, the safe re-use of data requires one more condition to be met; that of the precise definition of access levels to data granted to specifically defined users. Specific access levels can be defined by the use of a deep permissioning system, implemented via the use of smart contracts. Data is protected by the use of cryptographic mechanisms, whereby the user can only access it when the correct permissions are assigned.
The required business flow contains a list of documents and data sourced from both internal sources and publicly available databases. To improve the process, each piece of information needs to be more efficiently verified and confirmed (or rejected) by the appropriate employees within the organisation.
Building a blockchain-powered KYC solution
If we look at how a blockchain tool is built, the first step is to create a consortium or structure that defines the set of departments (or actors) in a network that are willing to conduct transactions with one another. In our scenario of KYC, these are the Client Centre, Due Diligence and Risk Assessment departments. Each of the departments has its own ‘peer node’ which hosts:
The second step is the creation of a ‘channel’, which is the primary communication mechanism which members of a consortium can use to communicate with one another. Channels are useful because they provide a mechanism for private communication and private data sharing between members of a consortium. They also provide privacy from other channels, and from the overall network.
Whilst there are a number of options, Hyperledger Fabric is very powerful in this regard, since it allows departments to share infrastructure yet keep it private at the same time. There’s no contradiction here – different consortia within the network need different information and processes to be appropriately shared, and channels provide an efficient mechanism to do this.
Additional data privacy using customised private data collections
A private data collection is a combination of two elements. The first is the actual private data maintained on a blockchain and sent ‘peer-to-peer’ to exactly the department that is authorised to see it via the ‘gossip protocol’. In our use case, the department is able to see detailed information about the company and its representatives after sending a request, which then must be approved by the manager who ‘owns’ the actual data.
The second element is a ‘hash’ of this data that is endorsed, ordered and written to the ledgers of every peer on the channel. The hash serves as evidence of the transaction and is used for safe validation - it can also be used for audit purposes.
The individual components of the blockchain network can be perceived as different ‘actors’; the active elements inside or outside the network that are able to consume services. Each of these actors have a digital identity encapsulated in an X.509 digital certificate. These identities matter since they determine the exact permission over resources and access information that actors have in a blockchain network. Furthermore, a digital identity has some additional attributes that are used to determine the permissions.
In our test scenario using Hyperledger Fabric, the union of the identity and the associated attributes is called a ‘principal’. These principals are similar to UserIDs, but are more flexible, since they can include a wide range of properties of an actor’s identity, such as their organisation unit, role, or even the actor’s specific identity. For an identity to be verifiable, it must come from a trusted authority. With Hyperledger Fabric this is achieved thanks to a membership service. In our sue case, each department has a separate MSP service that defines the rules that govern the valid identities.
In conclusion
As the complexity of business requirements continues to grow, the ability to achieve them requires teams to be equipped with the appropriate modern tools to do so. As technology evolves, old methods eventually expire as better methods prevail, and this is when we should consider devising efficient new tools. For KYC processes, the integration of well-known mechanisms with new technologies, such as distributed ledger technology and smart contracts, can provide solutions that deliver new quality and a fresh approach to old issues.
We are convinced that in a world where data volumes continue to expand, as does the focus on privacy and data protection, the opportunities offered by blockchain and its application using practical thinking, can provide a far better and more secure way in which to really know your customers.
This content is provided by an external author without editing by Finextra. It expresses the views and opinions of the author.
David Smith Information Analyst at ManpowerGroup
20 November
Konstantin Rabin Head of Marketing at Kontomatik
19 November
Ruoyu Xie Marketing Manager at Grand Compliance
Seth Perlman Global Head of Product at i2c Inc.
18 November
Welcome to Finextra. We use cookies to help us to deliver our services. You may change your preferences at our Cookie Centre.
Please read our Privacy Policy.