Skip to main content
Entire section Custom print Text Only Rich Text Print

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).