Skip to main content
Back Custom print Text Only Rich Text Print

  • Distributed Ledger Technology (DLT)

    • Governance

      1. 3.115Institutions should establish an approved and documented governance framework for effective decision-making and proper management and control of risks arising from the use of DLT. The governance framework should include the following, as may be relevant depending on the type of DLT:
        1. a.Cover the following elements integral to the functioning of a DLT Application:
        2. b.Ownership model of the DLT platform and the Nodes running on it;
        3. c.The model used to operate and manage the distributed ledger (e.g. a consortium, a single Institution);
        4. d.Rules to govern the ledger(s) including participant and validator rules and restrictions;
        5. e.Approval processes and procedures to grant access to create, read, update or deactivate Data stored on the distributed ledger(s);
        6. f.Managing public and private keys;
        7. g.Consensus protocol; and
        8. h.Off-chain procedures (if any) including parameters for the validity of an off-chain activity and any standards or requirements for off-chains systems are defined and complied with.
        9. i.Define the roles and responsibilities of the key groups involved with respect to the design, development, and operation of the distributed ledger(s). Key groups may include:
          1.  i.Core group who will design, govern and operate the distributed ledger(s);
          2.  ii.Qualified users of the distributed ledger(s), such as other Institutions and miners;
          3. iii.Participants involved in the distributed ledger(s), such as owners of cryptocurrency etc.; and
          4. iv.Third Parties including Outsourcing Service Providers such as custodians or software developers involved in delivering the service.
      2. 3.116Reviews of the DLT Application should be conducted with oversight from Senior Management, prior to launch and thereafter on an on-going basis to ensure its reliability and security.
      3. 3.117Institutions should establish clear and unambiguous governing rules for participants of the distributed ledger(s) for onboarding, on-going operations and dispute resolution.
      4. 3.118When Outsourcing to an Outsourcing Service Provider, Institutions should ensure that access to information is adequately controlled, monitored, reviewed, and audited by the Institution’s internal control functions, and regulators, or persons employed by them, including supervisory reviews by the respective Supervisory Authority.
      5. 3.119Institutions should ensure that their DLT Applications maintain appropriate evidence and records to enable the Institution’s internal control functions, external auditors, regulators, and other authorities to conduct their audits and reviews. Accordingly, Institutions should:
        1. a.Record and store the additional evidence and information to provide auditors with a complete representation of processes, internal controls, financial statements, etc., and for proper accounting treatment of the transaction;
        2. b.Ensure that a log of records of the DLT Application is fully available and accessible to the relevant parties to audit and review;
        3. c.In the event that the DLT is in the form of a blockchain, ensure that off-chain activities, rules and protocols associated with and any link to on-chain activities are recorded and stored; and
        4. d.Ensure that the DLT code and subsequent updates are recorded and stored.

    • Design

      1. 3.120Institutions should design their DLT Applications to be efficient and effectively secure IT assets and any customer assets. Institutions should, where possible, ensure the design and architectural aspects of the DLT are optimised to cater to the specific use of the technology and the needs of the Institution.
      2. 3.121Institutions should consider the following principles when developing the design of a DLT Application that manages financial assets:
        1. a.Flexibility: To define the DLT Application narrowly, which is easier to optimise, or flexibly, which may incur higher costs (more difficult protocol, less predictability, larger target for attacks, etc.);
        2. b.Traceability: To ensure that the distributed log of records and any off-chain records are traceable and anonymity is avoided;
        3. c.Capacity: To ensure that the DLT Application’s computing and Data capacity is commensurate with the Institution’s needs and is scalable depending on the intended use;
        4. d.Security: To ensure that the activities and records on the distributed ledger(s) are secure;
        5. e.Confidentiality: To maintain confidentiality of Data and implement adequate controls over the set-up and number of Nodes; and
        6. f.Resilience: To ensure that the system is resistant to Data loss, loss of integrity, unavailability, or manipulation.
      3. 3.122Institutions should define rules relating to Data and technological architecture of the DLT Application during the design phase to ensure that internal control functions, external auditors and Supervisory Authorities can effectively access the application (when applicable) and monitor compliance.
      4. 3.123Institutions should appropriately determine the type of access, whether permissioned or permissionless, granted to participants based on an assessment of the operations performed, level of security and Data stored using DLT. For instance, Applications involving any of the following elements should use permissioned systems:
        1. a.Customer assets, funds or other forms of ownership, rights or interests such as contracts;
        2. b.Personal Data; or
        3. c.Requirements for a controlled set of participants or restricted access.
      5. 3.124Institutions should establish controls to ensure the integrity and security of the network and DLT Application. These controls may include, but are not limited to:
        1. a.Implementing processes to limit Node processing ability and limit the potential for a Node to process an excessive number of transactions;
        2. b.Designing the Application to allow blocking of IPs/Nodes that generate too many new transactions; and
        3. c.Developing permissioned DLT Applications with individual Nodes that comply with security standards and requirements to guard against attacks.
      6. 3.125Institutions should establish appropriate consensus protocols or platforms to accept and validate new records. The consensus methodology should be based on the Institution’s requirements with respect to performance, scalability, consistency, Data capacity, governance, security and failure redundancy.
      7. 3.126Institutions should avoid storing clear-text Personal Data on a blockchain and instead use sidechains or other private storage options.
      8. 3.127Institutions should introduce cryptographic key management to control access to confidential information and Personal Data. Institutions should institute controls with respect to key generation and management and ensure an appropriate and secure storage and transmission mechanism for private keys. The key management controls should cover offline root keys (split amongst multiple owners) and online root keys (stored on hardware security modules).
      9. 3.128With respect to the issuance of keys to Staff and other personnel:
        1. a.Institutions should issue individual keys to Staff and other persons working on behalf of the Institution for audit, supervision and review purposes;
        2. b.Institutions should embed internal checks and verifications on the transactions and activities executed through the distributed ledger such as Staff sign-off on requests or transactions; and
        3. c.Institutions should ensure they can internally identify the Staff signing-off messages or requests on the distributed ledger.
      10. 3.129Institutions should, if possible, ensure that the design of the DLT Application allows for change i.e. add new functionality or remove unwanted or incorrectly functioning features within the DLT Application.
      11. 3.130Institutions should, if possible, introduce mechanisms to manage forks (i.e. conflicts arising from incompatible versions of the DLT that are broadcast within a short time period) and ensure that the situation is resolved quickly and the integrity of the DLT is maintained.
      12. 3.131Institutions should, if possible, introduce user access management and authentication to provide controlled access to the DLT Application. Staff and Outsourcing Service Providers should be provided access to only those parts of the system they need to perform their responsible business or operational activities. Institutions may consider if, in certain cases, it might be feasible to accept transactions only from selected, authorised IP addresses.
      13. 3.132Institutions should develop controls to ensure confidentiality and integrity of code(s) and prevent alteration of code(s).

    • Anonymity and Pseudonymity

      1. 3.133Institutions developing Permissionless DLT Applications should ensure that users are not anonymous or pseudonymous, as allowing anonymity and pseudonymity can facilitate criminal purposes like tax evasion, bribery, money laundering or terrorism financing.
      2. 3.134Further, Institutions should consider using mechanisms such as chain analytics to follow and monitor transactions on pseudonymous blockchains.

    • Management and Monitoring

      1. 3.135Institutions should ensure that their DLT Applications are reviewed and monitored on a periodic basis to evaluate performance, detect technology and security related incidents, ensure the adequacy of controls, and promptly take any remedial action.
      2. 3.136Institutions should ensure that code is reviewed and validated on an ongoing basis at regular, predetermined intervals to identify any weaknesses. Institutions should ensure code is performing its expected functions and is secure.
      3. 3.137Institutions should conduct vulnerability assessments and penetration tests specific to the DLT Application to identify weaknesses or flaws in the security processes.
      4. 3.138Institutions should manage and monitor information integrity, privacy and confidentiality in the implementation of the DLT throughout its lifecycle (e.g. by conducting privacy threshold analysis, privacy impact assessment, and Data protection impact assessment). Institutions may adopt processes such as sharding and pruning during the design of the Application to further manage privacy and confidentiality mechanisms.
      5. 3.139Institutions should further ensure adequate control and monitoring of the DLT through an even stringent focus on encryption than traditional controls with a particular focus on key management. A related control to consider is encrypting the ledger(s) with more than one key and applying on-chain encryption.
      6. 3.140Institutions should review the distributed log of records and transactions within the ledger(s) to identify suspicious patterns and connections to monitor any anomalous behavior using analytics and testing.
      7. 3.141Institutions should adopt operations security controls including standard infrastructure controls such as virus checking schedules, zero-day exploit remediation, maintenance schedules, capacity, and backup management.
      8. 3.142Institutions should adopt security incident management controls that describe the processes around reporting, escalation, and response to any breaches. Institutions should monitor if one of the Nodes increases processing power and is executing a significantly higher number of transactions.
      9. 3.143Institutions should ensure that adequate human resources are put in place for implementing security controls to monitor access to the DLT Application and system. Institutions should ensure that these controls are updated when Staff leave or change roles.
      10. 3.144Institutions should maintain and monitor physical and environmental security through use of hardware security modules, physical security measures such as CCTVs, physical barriers, traditional key security, and access controls.

    • Data Standardisation and Interoperability

      1. 3.145Institutions should not maintain Personal Data on the ledger(s) and such Data should be maintained off-chain.
      2. 3.146Data retention will need to be factored into the underlying design of the network for Nodes to purge ledger information after certain defined time periods. Where Data retention rules apply to individual Data sets, destruction of keys used to encrypt the on-chain Data should be implemented.
      3. 3.147Depending on the Application, Institutions should consider the principle of interoperability when planning the design of the distributed ledger(s). Institutions should establish processes to prune the distributed ledger(s) and remove records older than a specific time period or enable processes that allow Data stored on the ledger to be forgotten (i.e. destruction of keys used to encrypt Data).

    • Business Continuity

      1. 3.148Institutions should ensure appropriate business continuity planning with respect to DLT, as it covers the potential loss of Data and processing capability due to loss of servers or connectivity, and risks such as cyber-crime.
      2. 3.149Institutions should plan, establish, and periodically test arrangements to maintain the continuity of the service/process performed by the DLT Application in the event of an incident that affects the availability of the Application
      3. 3.150Institutions should ensure that their business continuity plan encompasses all the complex technical areas of DLT, from key storage and key regeneration in the event of catastrophic Data loss to creating new keys when a cyber-crime incident compromises Data security.
      4. 3.151Institutions should consider DLT specific scenarios such as network malfunction or compromise of Data integrity in their business continuity plans.
      5. 3.152The Institution’s business continuity plan team should include specialists in DLT and should monitor cryptographic advances and vulnerabilities such that proactive responses can be developed to avoid system outages.
      6. 3.153In solutions involving public key infrastructure, Institutions should ensure that the business continuity plan covers the technical integrity of the key generation mechanisms (certificate authorities, hardware security modules etc.), the business processes involved in the secure transportation of the private keys and the authorisation layer around these mechanisms.

    • Customer Protection

      1. 3.154Institutions should disclose the relevant governing rules to Customers participating in the distributed ledger(s).
      2. 3.155Institutions should disclose any Fees associated with the on-going operation and management of the distributed ledger(s) including providing notice that Fees may be charged by Third Parties, where applicable.
      3. 3.156Institutions should advise Customers on what they should do to protect their keys from misuse. In particular, Institutions should inform Customers of the consequences of sharing their private keys and other security information.