Individual Decentralized Identity(DID)Management

Individual Decentralized Identity(DID)Management


Use your IDC APP to safely access partner websites and services.Automated onboarding.


Use your IDC APP to safely access partner websites and services.Automated onboarding.


Most requests take less than 60seconds to fully KYC/AML.

Digital Identity Management on DLT

Financial institutions are required to carry out the Know­Your­Customer  (KYC) process as part of the on­boarding process before they conduct  business with a new client. As the number of regulatory requirements  related to the KYC process and Anti­Money Laundering (AML) rules has  grown, the incentive for financial institutions to find a cost­effective and  user­friendly method to carry out the KYC process has increased. Digital  Identity (D­ID) management has been identified as a possible means of  streamlining the KYC process, enabling multiple banks to rely on the same  shared, secure and auditable source of digitised client information instead  of having to collect and verify the information individually and repeatedly. 

Proof-of-Concept work

In the first phase of the DLT research project, the HKMA and ASTRI formed a D­ID Working Group with five banks to study the feasibility of applying DLT to D­ID management through a Proof­of­Concept (PoC) project. The Working Group developed the following structure and features for the PoC prototype:

  • Selective client information to be stored as immutable and auditable records in the DLT ledger;
  • Each of these pieces of dat is added to the DLT system through the consensus process among the validating nodes of the participating banks;
  • Ledger contents to be simultaneously synchronised in multiple locations served by validating nodes or full nodes, to provide data redundancy; and
  • User privacy to be protected transparently through a client­controlled interface relating to banks’accessib lity to client data.

  • Two different configuration options for the D­ID management system are possible:

    Sector-wide Digital-ID Management on DLT

  • Multiple banks could form a consortium with a high degree of collaboration among parties, or jointly  subscribe to the same D­ID service provider. 

  • Digital-ID Management on DLT for a global FI

  • A global bank could create an internal DLT network that stretches across the jurisdictions and different lines  of business in which it operates. 

  • In this PoC work, the first configuration option was  chosen because multiple banks are involved in the  Working Group. 

    The system is deployed as a permissioned DLT  network, where a membership control policy is  enforced to ensure that only registered participating  banks and clients may access the system. 

    When a client first establishes a relationship with  one participating bank, on top of the regular onboarding KYC process, the bank verifies all the client’s  important identity information (including digital documents) and stores the hashes1 of this data  and the related metadata in a distributed ledger  accessible by all participating banks. The data is  tagged to a unique D­ID for that client. 

    If the client later establishes a relationship with  another participating bank, the on­boarding KYC  process becomes much simpler because the  second bank can access the hashes stored in the  DLT network, compare them to the hashes of the  documents that the client now presents, and confirm  the authenticity of the information and documents  submitted immediately. 

    Annex – Digital-ID Prototype

    (1) Hybrid data storage

    (2) Process-flow

    a) First time on-boarding: federated identity Client needs to visit the bank office to perform first  time on­boarding.  

    (i) Using a phone, the client:   
    (1) creates an RSA2 asymmetric key pair   
    (2) submits the public key with a complete  set of personal information and  documents   
    (3) grants access rights to the bank  to upload the hashes of client KYC  information and documents to the DLT  network   

    (ii)  Bank staff submit a request to Identity  Manager to create a certificate for client 

    (iii)  Identity Manager generates certificate  and passes it to client through the bank.  The certificate contains client information  (including client ID) and client’s public key. 

    (iv)  Bank staff verifies authenticity of client  information and documents, and after  successful verification:   
    (1) stores the hashes of the client  information and documents in the DLT  network   
    (2) stores the client information and  documents in the bank’s private  database 

    b) Repeated on-boarding

    (i) By phone, the client:   
    (1) submits the complete set of personal information and documents     
    (2)grants access rights to the bank to retrieve the hashes of client KYC information and documents from the  DLT network   

    (ii)  Bank staff accept submitted information and  documents only if their hashes are the same  as those in the DLT network

    (iii)  Upon accepting client information and  documents, bank staff:   
    (1) store client information and documents in the bank’s private databas  
    (2) optionally add a reference log to the DLT network for the corresponding hash entries

    c) Information update and real-time sharing

    (i) Client:   
    (1) enters new personal information and document by phone      
    (2)visits any bank office and submits the new personal information and  documents to the bank by phone   

    (ii)  Bank staff verify authenticity of client information and documents, and if the  information and documents are authentic: 
    (1) store hashes of the client information and documents to DLT network 
    (2) store client information and documents in the bank’s private database 

    (iii)  Staff of other banks holding the client’s old  information and documents will notice the new hash updates in the DLT network. They  may do the following to receive the client’s up­to­date information and documents:  
    (1) require client to submit new personal information and documents  
    (2) verify the hashes of received client  personal information and documents against the new hashes on DLT network
    (3) store the client information and  documents in the bank’s private database upon successful verification
    (4) optionally add a reference log to the DLT network for the new hash entries

    d) Client verifies own KYC information hashes in DLT network

    The client may at any time access the DLT network  to receive the hash entries of his or her personal  information and documents for the following  purposes:   
    (1) To determine whether the first time  on­boarding bank has verified his/her  information and documents and uploaded  the corresponding hashes to the DLT  network     
    (2) To determine whether subsequent  information and document updates have  been verified by the accepting bank and the  corresponding hashes have been stored in  the DLT network   
    (3) To determine which banks have been  accessing his/her hash entries on the DLT  network 

    (3) Overall data flow in the prototype demonstration

    (4) Prototype demonstration

    a) First time on-boarding

    The client is on­boarding to HSBC Bank for the  first time. 
    Shown below is a prototype demonstration. On  the left is the client’s mobile phone, on the right  is HSBC’s computer. 
    (i)  Client sends personal information to HSBC

    (ii)  HSBC stores hash of verified client  information to DLT ledger 
    Both client and bank see the hash in DLT ledger. 

    b) Repeated (Online) on-boarding

    After on­boarding to HSBC Bank, the client now  on­boards to Bank of China (BoC). 
    (i)  Client sends personal information to BoC
    BoC sees that the hash of the client’s personal information has been verified and  stored in DLT ledger by HSBC. Hence, BoC  does not need to perform verification again.

    (5) Client KYC data dictionary Information Data

    (6) Security configuration

    a) System security — membership only participation

    After on­boarding to HSBC Bank, the client now  on­boards to Bank of China (BoC). 
    For system security, participating nodes are granted  membership certificates by the Identity Manager.  Ownership of a legitimate membership certificate is  required to gain access to the DLT network. 
    Ownership of a legitimate membership certificate can only be proven by holding the corresponding private key. 
    As for access rights, banks with full access rights can read and write information in the DLT network. Some players with read­only access rights can refer to  this data on the DLT network. 
    The visibility of the data will need to be carefully managed so that only participating banks with which a client holds specific accounts will be able to view that client’s information.