Keywords

1 Introduction

In state-of-the-art financial relations, Know Your Customer (KYC) and Know Your Business (KYB) policies expect that customer parties, either individuals or entire corporations, endeavor verification of their identity. Particularly, a KYC/KYB mechanism ensures that the identification and verification of a client occurs against national and international regulations and laws set by governments, commissions, central banks, and financial associations. Each financial organization is able to estimate the risks involved with sustaining a new business–customer partnership. Within the wider Finance field of Anti-Money Laundering (AML) procedures, every financial institution is obliged to establish KYC and KYB operations at the time they register a new customer. As both the customer profile information and the relevant laws and rules are subject to changes over time, the updates and maintenance of the data become more complicated. Furthermore, the adopted centralized systems are exposed to new-generation risks of data protection and cybersecurity that form cheaper to launch relevant attacks led by more sophisticated adversaries year by year [1].

Blockchain technology and particularly permissioned blockchain networks are capable of providing security to the KYC and KYB processes through decentralization [2, 3]. The concept of decentralization mainly exploits the idea that the information is replicated across all network nodes. In this context, the information integrity cannot be harmed by sabotaging one or more nodes, and thus, a single point of failure is avoided. In particular, the permissioned blockchain technology isolates the sensitive information inside a dedicated private network where only privileged parties can access it. Particularly, every party is accepted into the network by an invitation from inside that enables the participant to engage in the blockchain activities. The customer information is kept safe on the private ledger where data transparency is offered to the privileged group of the legal network participants. Both the clients and the organizations are able to perform CRUD operations on the data (create, read, update, and delete) under pre-configured access control policies. For instance, the various features of permissioned blockchains enable applications of different policies that are able to separate legal parties into a higher privacy network running inside the initially defined private one. Improved privacy control and data immutability rule inside the aforementioned technological scenario, while they ensure legitimate customer data protection and management together with proper administration of the data by financial enterprises [4, 5].

2 Architecture

The implemented KYC/KYB blockchain solution resolves the aforementioned issues of the industry by exploiting blockchain technology as the underlying infrastructure. In Fig. 7.1, the high-level architecture of the solution is depicted.

Fig. 7.1
figure 1

High-level architecture of KYC/KYB solution

In general, the customer participant being either an individual or an entire organization needs to acquire financial services that are offered by financial institutions or organizations. For the completion of the relevant transaction, the financial institution requests that the customer identity information is documented specifically in KYC/KYB data format. Thus, after the data is legally verified, the customer participant uploads their KYC/KYB documentation to the KYC/KYB system that interacts with the permissioned ledger and stores the information on-chain. When a financial organization requires to initiate business relations with the same customer, the latter’s KYC/KYB information is easily and rapidly obtained through the access rights provided by the first financial institution since business partnership is already arranged with the customer. It is important to clarify that initially the customer has declared their consent in sharing KYC/KYB information among privileged participants of the blockchain network, while the privacy of the information is guaranteed. In this system, data security and efficient data management and maintenance govern since the united underlying blockchain infrastructure with common data structures offers stability, security, sustainability, and high transactions per second.

3 Use Case Scenarios

The design specifications of blockchain applications are tightly coupled with the definition of the underlying business intelligence. For each use case scenario, as they are analyzed at a later stage in the current section, the respective business objects prompt the corresponding developments and formulate the relevant blockchain submissions. The following sections provide the descriptions of the scenarios that are encapsulated in the solution by elaborating on the relevant details. The entire INFINITECH on-chain solution serves in principle the use case scenarios analyzed below. Use Case Scenario I: Assertion of Identification Documents

In scenario I, the customer asserts their identity documents to the corresponding financial organization through the KYC/KYB on-chain process. In particular, a customer representing either an individual or a corporation acknowledges their KYC or KYB information in order to initiate business relations with the finance participants of the permissioned blockchain network. In this context, each enterprise participant ensures the legitimacy of their customer, and thus, new business relationships are established. The scenario analysis is stated in Table 7.1.

Table 7.1 Scenario I: Assertion of identification documents

Use Case Scenario II: Read Access for KYC/KYB Information

In scenario II, a financial organization as a legal network participant has read access to customer KYC/KYB documents information (Table 7.2). In particular, inside the permissioned blockchain network, each party is able to view the corresponding ledgers with the submitted client information. In this context, each financial organization has read access to this data stored on-chain, and by initiating a simple read access request, the financial organization fetches the information of a customer they are interested in. Additionally, upon using the system, each customer approves that their data may be accessed by the financial organization that they will initiate business relations with.

Table 7.2 Scenario II: Read access for KYC/KYB information

Use Case Scenario III: Sharing of Customer KYC and KYB Documents

In scenario III, financial organization A shares the KYC/KYB document information of customer B with the financial organization C through the secure and private blockchain network. In particular, each of the financial organizations participating in the permissioned network is eligible for accessing the data stored on-chain. However, depending on the different access control rights granted by the time of joining the blockchain network, there exists the case where different organizations are qualified to access different groups of data. In this context, together with the initial consent given by the client, a financial organization may grant access to another organization or institution for a specific KYC/KYB documentation (Table 7.3).

Table 7.3 Scenario III: Sharing of customer KYC and KYB documents

In the previous sections, all the relevant use cases of the designed blockchain solution are documented. For each of the scenarios, the related sequence diagrams are produced and analyzed in the following section.

4 Sequence Diagrams

The delivered use case scenarios of the previous sections correspond to specific UML sequence diagrams that are elaborated on in this section. The interactions between the different stakeholders are depicted in detail along with the components of the designed solution and their interoperability.

Scenario I Sequence Diagram

In scenario I, Assertion of customer identity documents, a customer provides their documentation information in order to be eligible for business partnerships with the participating financial organizations. Particularly, a customer actor, either an individual or an entire enterprise, acknowledges the requested KYC or KYB documents in the KYC/KYB system by uploading them on the ledger. This action is translated to an internal request that propagates the information inside the blockchain network, through the different blockchain components. The entire procedure is illustrated in Fig. 7.2, and the individually depicted Blockchain Modules are explained in Chap. 1, A Reference Architecture for Big data Systems and AI Applications in the Finance Sector (INFINITECH-RA), while their corresponding development exploitation on behalf of the current solution is analyzed in the dedicated implementation section. Finally, the data is safely stored on the INFINITECH private ledger, and afterward, further actions and use case scenarios are enabled to emerge and execute, i.e., use case scenarios II and III.

Fig. 7.2
figure 2

Scenario I sequence diagram

Scenario II Sequence Diagram

In scenario II, Read access for KYC/KYB information, the blockchain network parties are constituted by the financial organizations that are able to inspect the KYC/KYB documentation information of the clients. Through the underlying private and secure blockchain network, the different organizations obtain access to a customer’s KYC/KYB submitted data and are able to estimate the risk of establishing business relationships with them. As stated, the customer data submission is already accompanied by the customer’s consent of the KYC/KYB information exploited by the legal parties of the network, i.e., the financial organizations. As in Fig. 7.3, through the sequential execution of the blockchain components, the read access is propagated to the financial organization that requested it.

Fig. 7.3
figure 3

Scenario II sequence diagram

Scenario III Sequence Diagram

In scenario III, Sharing of customer KYC/KYB documents, sharing of customer B information among participant organizations A and C takes place. Particularly, organization C obtains customer’s B information through the cooperation of organization A. Since the customer data already exists inside the secure and private blockchain ledger, organization C requests it indirectly. Organization A responds to the request by granting read access of customer B information to organization C. In such an efficient data sharing system, the customer and the financial organizations benefit from the underlying technological features and infrastructures since, for instance, the customer avoids reentering their KYC/KYB data to a different system of a different organization, while the financial organizations rapidly obtain customer information and make decisions upon new business relations establishment (Fig. 7.4).

Fig. 7.4
figure 4

Scenario III sequence diagram

5 Implementation Solution

This section explains the particulars of the implementation of the INFINITECH Know Your Customer/Know Your Business On-Chain Solution. The designed and developed solution has several important parts that are underlined below in order to present in a more clear and coherent way the built framework and the technological manifestation of the presented concept architecture and use case scenarios.

Chaincode Structure

In Fig. 7.5, the KYC/KYB chaincode structure is depicted at a component level. As stated, the depicted Blockchain Modules are explained in Chap. 1, A Reference Architecture for Big data Systems and AI Applications in the Finance Sector (INFINITECH-RA), though there is a following individual short description for consistency.

Fig. 7.5
figure 5

KYC/KYB chaincode structure

The Blockchain Writer component undertakes the responsibility to submit new transactions to the blockchain ledger. In the Know Your Customer/Know Your Business Use Case, the Blockchain Writer component refers to the transactions submitted for registering a new customer on the private ledger, updating an existing one and withdrawing the KYC/KYB information of an existent participant.

The Blockchain Reader component is used in order to read the ledger state and fetch a particular party’s KYC or KYB submitted information.

The Smart Contract Executor component’s main purpose is to consolidate the business intelligence of the defined use case and execute the chaincodes on the blockchain ledger.

The Blockchain Authenticator component is responsible for performing the authentication of the blockchain network user in order to grant access to a specific channel of the blockchain network.

The Blockchain Encryptor component performs the encryption of the related data that are involved and produced within the smart contract execution.

The Blockchain Decryptor component performs the decryption of the data encrypted by the Blockchain Encryptor component.

Web Application

With regard to the KYC/KYB web application, the following analysis presents the user interface (UI) framework essential services and their functions that are hitherto developed for the user interaction with the on-chain part of the solution. In Fig. 7.6, the application code structure is illustrated.

Fig. 7.6
figure 6

KYC/KYB application code structure

The Clients Service is responsible for retrieving the requested KYC or KYB information from the blockchain ledger and for delivering it on the web interface of the participant channel organization.

The New Client Service is responsible for delivering the KYC or KYB data of a newly inserted client on the specified blockchain end points in order to be submitted on the ledger.

The Permissions Service is responsible for switching the access control state of a financial organization.

The KYC/KYB App constitutes the main user web interface end point through which the end-user can initiate all the permitted actions and navigate into the application.

The Blockchain Service is responsible for submitting new use case related data on the blockchain ledger after triggered by the web user interface. The functionalities enable immediately the corresponding chaincode functions.

Navigation

With regard to the web application navigation routes by a web end-user, the following illustrations depict the relevant views’ information accompanied by their descriptions. In general, the last part of the implementation showcases in a practical way the important parts of the user interface framework that is hitherto developed for the user interaction with the blockchain ledger. In Fig. 7.7, the specific Clients view displays the KYC/KYB information of the on-chain submitted participants as seen from the account of User One of Financial Institution One. In every Clients view, the ledger information that the specific financial institution user is allowed to read is depicted as defined from the underlying blockchain mechanisms. In Fig. 7.8, the New Client view depicts the user interface (UI) that a financial institution user exploits in order to register the KYC or KYB information of a new client. Upon right form completion, the new client is being inserted and the submission sends the data to the ledger. In Fig. 7.9, the Permissions view displays the control access status of a financial institution. Every request for access from other financial institutions is depicted in this view, while the financial institution user is able to permit or forbid access.

Fig. 7.7
figure 7

Clients view

Fig. 7.8
figure 8

New client view

Fig. 7.9
figure 9

Permissions view

6 Conclusions and Future Works

In this chapter, an efficient and accelerated KYC process exploiting the underlying blockchain technology is analyzed using the INFINITECH KYC/KYB On-Chain Solution. The state-of-the-art financial sector is greatly benefited by the solution since the addressing of various technological issues including trust, immutability, secure data sharing, and confidential transactions. Such blockchain approaches are meant to disrupt the financial scene as promoting the adoption of new secure enterprise data networks. For the current solution, future plans are being under consideration for integrating with the technological results presented in Chap. 8.