Note: This is an initial document, the purpose of which is to finalise on the detailed requirements for the PoC of Sovrin/Indy network for KYC purposes in Fineract. The community member can help to further improve this requirements document to make it more detailed and add use-cases that are deemed necessary for the PoC.

Current Use Cases Mentioned Below:

  • Opening a Bank Acccount
  • Securing a Loan
  • Transfer of Money

New Suggested Use Cases:

  • <TBD>
  • <TBD>

Background

KYC (Know your customer) is a fundamental banking concept. It refers to the process of identifying a new customer at the time of account opening, in compliance with law and regulation. The identification requirements may be lower for low value accounts ("Tiered KYC"). The term is also used in connection with regulatory requirements for a provider to understand, on an ongoing basis, who their customer is and how they are using their account. Most of the banks are mandated to perform basic/extensive KYC, before they can serve their customers.

Traditionally KYC is done in a centralised fashion where a central agency has the control over all the data. For example consider each bank like SBI, Deutsche, JP Morgan, etc. when creating a bank account, each of them requires a separate KYC process to be completed and all this data gets stored in their respective databases. Even the systems like Aadhar or social security number, etc. have the data stored in a central manner and maintained by the government. However, in recent times all these centralised identity servers continue to be hacked and the important and private data being stolen regularly.

With the advent of blockchain concepts and technologies, it is not ideal but imperative that we shift from the traditional identity management to a more secure decentralised claim-based identity management system. This kind of system has multiple benefits:

  • Decentralised system means that no one person has control over sensitive data.

  • It enables the re-use of KYC, i.e. each financial institution or in our case each customer using Fineract may not have to perform its own complete KYC, but re-use the KYC already performed by others (those who have the power as issuing authority for any kind of claim).

  • Cryptographic security is the heart of blockchain technologies enhancing privacy.

  • Claim-based system where the end user/customer has the control over his data.


The idea in long term is that Fineract leverage blockchain solution to verify the identity for its customer and thus provide more security and privacy to the end users.


Following are the important things to keep in mind with respect to KYC and decentralised identity management:

  • Issuing Authority: This power could be given to any relevant civil authority like federal government, state department, public sector entities, etc. It can also be given to recognised private or non-profit entities like Universities, Banks, financial institutions, etc. When dealing with the underbanked, a form of basic KYC can be self-issued and trusted upto a point.

  • Verifiable Claims: https://www.w3.org/TR/verifiable-claims-use-cases/

  • Tiered KYC: KYC will be tiered according to the users desired range of money transaction. With each level the amount of information collected to verify the identity increased and become stricter. The use-case here is that for some very basic operations like lets say transferring 20$ a basic KYC is enough, but for more important use cases like taking loans, etc. a more stricter regulation is required. At each level of kyc lets say from KYC-0  to KYC-4, the amount money that can be transacted increases. These kind of concepts help in flagging the Suspicious activities and also helps to comply with the AML/CFT (anti-money-laundering/counter-the-financing-of-terrorism).



Summary

This document explains the MVP requirements for Sovrin/Indy Proof of Concept which would later on enable Fineract to be integrated to the Sovrin network for identity management. The high-level goal for this project is to deploy a private indy network and try to perform basic identity management actions in order assess the viability of the blockchain solution. This would help the Fineract project to decide whether to become a part of the Sovrin foundation as a steward for identity management.

P0 requirements

  1. Setup and run an Hyperledger Indy Network with Stewards.

  2. Opening a bank account scenario.

  3. Applying for a loan scenario.

P1 requirements

  1. Performing money transfer to a merchant online.

PoC Scenario Description:

The important flows that are required to be covered for the PoC are related to the issuance of a digital certificate/identity and consumption of digital certificate as a verifiable claim for a financial transaction. For this purpose we would need to have the following:

  1. Issuing authorities - university (certificate), govt. (UID), Company (job certificate).

  2. Bank - for opening account and securing loan

Then we can integrate with the Indy SDK on customer end and backend APIs from Fineract end. Fineract may/may not be the steward for its organisations i.e. the issuing authority.


Requirement Details

A. [P0] Setup and run an Hyperledger Indy Network with Stewards.

For the purpose of the PoC, we will have to setup a local pool of indy nodes where we can test our scenarios. This phase is for “preparing the required infrastructure” required for testing and running all the other scenarios.

Starting and Indy network locally using docker: https://github.com/hyperledger/indy-sdk/blob/master/README.md#how-to-start-local-nodes-pool-with-docker

Getting started guides:

The expected results: The indy test network should be up and running with all the issuing authorities as trust anchors and Fineract as a steward. All the schemas for the required documents as mentioned below must be defined:

  • UID card (Aadhar card or Social Security?)

  • Job Application

  • Bank Account Application

  • Loan Application

  • Money Transfer Request

B. [P0] Opening a bank account scenario.

A customer wants to open a new bank account in a complete digital fashion without having to visit the bank for any kind of paperwork. Once integrated with sovrin this can be made possible if the customer can provide electronic credentials for all the requirements.

The expected results: The digital form required to be filled up to open a bank account must be powered by the digital certificates using the indy-sdk (in actual use-case it would be the wallet provided by sovrin). So when the user is prompted to fill up the form with various documents (let’s say initially opening account with KYC-0), then the user must be able to prove that information from the indy test network using the digital certificates issued by other authorities.

C. [P0] Applying for a loan scenario.

Let us consider the scenario where a customer wants to secure a loan for a solar home system. Now before securing the loan, the bank would want the customer to maybe update the KYC to say KYC-2 and in addition request for more details and information before processing the information. The purpose of this requirement would be to demonstrate the providing of these additional information using the Indy network.

The expected results: Again here the digital form required should be processed using the digital certificates provided the issuing authorities to the Indy network. This would help to verify and upgrade the KYC level of the customer. For the second part i.e. actually securing the loan, the bank would need information like the academic details (university transcript) and current employment details. These should also be available in the Indy Network and re-used for the purpose of loan application.

D. [P1]  Performing money transfer to a family member scenario.

Consider the scenario where a customer wants to send the money to an online merchant say a food company or an e-commerce company using the bank’s wallet (or the banks money transfer service). Today most if these online wallets are now being required to complete the KYC’s to prevent fraud and verify the customers. We would want to prevent this money from being laundered and go to actually the entity that has requested it.

The expected results: With the help of Sovrin/Indy we would always have a verifiable claim against all the parties connected to the network. The customer that wants to make the payment has a verifiable claim in his/her central repository that can be used to share her identity profile. The customer has also been sent a claim from the merchant verifying their banking information. By sharing these with the money transfer service, they can automatically verify the source and destination of the funds, thus being confident of the delivery of those funds and also satisfying the various regulations regarding the prevention of money laundering (AML/CFT).


2 Comments

  1. james dailey

    I'd like to keep the wiki structured in a consistent way.  I think this belongs in a new category of Proof of Concept work, or under Features to be Done (Outstanding Features) or Under "In Progress Features". 

    Rachit Kansal - can you let me know your preference?   

  2. Rachit Kansal

    Hi james dailey ,

    I think it makes sense to move it under Proof of Concept Work.