On 21 January 2022, the Luxembourg financial sector supervisory authority, the Commission de surveillance du secteur financier (“CSSF”), has published a white paper (“Whitepaper”) on distributed ledger technology (“DLT”) and blockchain. The publication of this Whitepaper is a reaction to a considerable number of solicitations of the CSSF from different market participants, ranging from well-established institutions to start-ups, wishing to use DLT and blockchain for various purposes.
While the CSSF recognises the disruptive potential of the DLT and blockchain technology on the financial sector and the advantages of these technologies, it also takes its role as regulator seriously, and, therefore, wants to acquaint the different players of the financial sector with the inherent risks that come with these new technologies.
The CSSF emphasises that the Whitepaper is not a binding document, nor does it constitute a positive or a negative assessment of DLT. The purpose of the Whitepaper is to adequately inform the financial sector in order to ensure that the advantages as well as the risks of these new technologies are appropriately taken into consideration by financial and non-financial institutions providing (or intending to provide) services to the Luxembourg financial sector.
In the Whitepaper, the CSSF reiterates its technology-neutral approach when it comes to innovative projects, i.e. the legal characterisation of a project is assessed on the basis of the services provided and not of the underlying technology – a position that the CSSF has maintained over the last years.
Definition and key characteristics
In the Whitepaper, the CSSF does not only (A) provide us with its definition of ‘DLT’, but also (B) sets out, which the CSSF considers being, the two key characteristics of the DLT, namely the consensus mechanism and the usage of cryptography.
A. Definition
“DLT is a technology allowing a network of independent and often geographically dispersed computers to update, share and keep a definitive record of data (e.g. information, transactions) in a common decentralised database in a peer-to-peer way, without the need for a central authority.”
It is doubtless not without interest to note that the CSSF has elaborated a definition of DLT in its Whitepapers, in particular, as, to this date, the Luxembourg legislator has not given a legal definition of the term, but only refers to DLT as “a secured electronic registration mechanisms” in the law of 1 August 2001 on the circulation of securities (as amended, inter alia, by the law of 1 March 2019) and in the law of 6 April 2013 on dematerialised securities (as amended, inter alia, by the law of 22 January 2021).
Although the CSSF stresses that the Whitepaper is not a binding document and, that, consequently, the said definition should not be considered as being an “official definition”, one cannot ignore that the issuer of the Whitepaper is the Luxembourg regulator, which indisputable confers a certain weight to this definition.
B. Key characteristics of DLT
Over the last decade, numerous blockchains and other databases based on DLT have emerged with a wide variety of different characteristics. For this reason, the CSSF sets out two key common characteristics which distinguishes DLT from other types of databases, videlicet, (i) the consensus mechanism and (ii) the usage of cryptography.
i. As DLT is, by definition, not centrally controlled, DLT-databases require an alternative mechanism that ensures that all new entries in the database are legitimate. It goes without saying that this safeguard mechanism is quintessential for the integrity of the database.
This so-called consensus mechanism can vary depending on the nature, the goal, and the underlying asset of the DLT. The two most prominent examples of such consensus mechanisms are the ‘Proof of Stake’ and the ‘Proof of Work’, which are being used for the validation of most cryptocurrency transactions.
ii. The second key characteristic of DLT is asymmetric cryptography, which ensures the allocation of the key pair (i.e. the private and the public key) to each user of the DLT-database.
The cryptography not only guarantees that only an authorised user can execute a certain transaction, but also that, once a transaction has been validated, it cannot be retroactively altered, nor can its authenticity be denied.
On this point, it may be worth mentioning that the CSSF does not consider the distribution aspect, i.e. the distribution of the database over multiple nodes, as being one of the key characteristics for DLT. This is not an omission but a choice by the CSSF as distributed databases are not exclusively used in the context of DLT but have been in use years before the emergence of DLT, notably with the emergence of cloud computing.
Taxonomy and use-cases
It is important to understand the different configurations of DLT as each configuration entails a different set of risks. For this reason, section 2.2 of the Whitepaper gives a short but clearly laid out overview on the different DLT types (e.g. differentiating between public and private DLT, restricted and unrestricted DLT, permissioned and permissionless DLT…). The different DLT configurations will not be further discussed herein as this would exceed the scope of the present article.
However, please note that we will not further discuss the different DLT configurations as this would exceed the scope of the present article.
The aforementioned brief taxonomy on DLT configurations is illustrated with a set of examples of use-cases of DLT technology in the financial sector, namely use-cases of DLT solutions in the context (i) of customer due diligence solutions, (ii) of transfer of funds and assets, and (iii) of fund distribution.
DLT ecosystem
In order to get the whole picture on DLT and its inherent advantages and risks, one must not only understand the various configurations of DLT, but also the roles of the different participants of the DLT ecosystem. For this reason, the Whitepaper sets forth an overview of these participants:
- the DLT developer who develops the application code on which runs the DLT;
- the infrastructure service provider who delivers the infrastructure for the DLT, including, in particular, the provision of nodes for the distributed ledger;
- the solution provider who designs the “business solution” for the (end-)users;
- the user(s) who (as its/their name suggests) uses the distributed ledger; and,
- depending on the set-up, the end-user.
In some scenarios, one must differentiate between user and end-user, but this is not always the case. For instance, a regulated entity may offer the transfer of assets via a DLT-based platform to its clients. In this case, the former would be the user while the latter would be the end-user. However, in a different scenario, the same entity may use a DLT for an internal database (which the client cannot access). In the second set-up, a differentiation between user and end-user would be redundant.
It should also be noted that the different roles are not necessarily carried out by different persons/entities. For example, the user may also be the solution provider of the distributed ledger or provide the infrastructure for running the DLT-database. Hence, the two or three (or more) of the aforementioned roles would be assumed by one entity.
DLT related risks
The Whitepaper differentiates among (A) governance related DLT risks, (B) DLT-specific technical risks, and (C) other (traditional) ICT risks.
The CSSF underlines that these risks should always be considered on all levels of the ecosystem. For instance, a mistake of the DLT developer may corrupt the entire database or the non-compliance of the infrastructure service provider with applicable regulations would most certainly have an impact on the solution provider and the (end-)users.
A. Governance related DLT risks
According to the CSSF, the first question one should raise when considering implementing a DLT-based solution is whether the use of DLT is justified. Indeed, the use of DLT may be tempting due to its obvious advantages. However, risks associated with DLT may outweigh these advantages in certain situations.
For instance, one should consider the potential impact of the DLT project in relation with the business continuity. As already illustrated in the example above, an issue at the level of one ecosystem participant may have a significant impact on the other participants.
Another aspect which should be taken into account is the legal risk: have all participants obtain all necessary licences to pursue such activity? Does the distributed ledger produce the expected legal effects? Who is liable in case of a malfunction of the DLT?
B. DLT-specific technical risks
The Whitepaper sets out a number of technical risks that are specific to the DLT, i.e. the risks related (i) to the consensus mechanism and nodes management, (ii) to smart contracts, (iii) to key management and (iv) to data protection.
i. Considering that all new entries into the DLT-database need to be validated through the consensus mechanism, it is evident that this algorithm must be well designed and intensively tested as a flaw in the algorithm would jeopardise the integrity of the whole DLT-database.
In line with the above, one should also ensure a high-quality nodes management, as the functioning of the consensus mechanism depends on a proper management of the nodes. One must, among other things, determine the minimum number of nodes required for the consensus mechanism to work and considers possible safeguards for the prevention of monopolising the validation process by the major players of the database.
ii. Similar to what has been pointed out with regard to the DLT-database itself, the Whitepaper stresses out the importance of the integrity of the smart-contracts, or more precisely, of the underlying code. The CSSF further suggest considering the implementation of a resolution process for flawed smart contracts.
iii. Another issue which should be considered when implementing DLT-based solutions is the management of the pair of keys. As a reminder, the loss of a private key generally leads to the inexorable loss of the assets stored on the distributed ledger. In the Whitepaper, the CSSF even refers to a “very high-risk unknown in the conventional financial sector” and suggests that the private key should not be directly owned by the end-user in order to avoid such an irreparable issue. One possibility to mitigate such risk would be the use of wallet providers, which safeguard the keys for its clients.
iv. Finally, the Whitepaper draws the readers’ attention to the privacy concerns in relation with the DLT. The very nature of the technology implies that the ledger is distributed, and, hence, (depending on the DLT-type) accessible to a larger number of people and/or entities. Depending on who may access the DLT-database, one may consider what information should be stored in the database. This is particularly important with regard to the obligations under Regulation (EU) 2016/679 of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data (“GDPR”).
In addition to privacy concerns under the GDPR, one may add the professional secrecy obligations as potential issue for certain market participants. As a reminder, most entities that are supervised by the CSSF are subject to professional secrecy obligations, which prohibits a long range of professionals including credit institutions, investment firms and other professionals of the financial sector, from disclosing client-related information to third parties (unless such disclose is expressly permitted or required by law).
C. Other (traditional) ICT risks
The Whitepaper also reminds its readers that not only DLT-specific risks should be taken into account when implementing a DLT project, but also other risks in relation with information and communication technology, including, among other things, risks in relation with business continuity and cybersecurity.
How to deal with this whitepaper
In its conclusions, the CSSF points out that innovative technologies such as DLT is particularly challenging for financial regulators. While the CSSF reiterates its acknowledgement of the advantages as well as of the opportunities that DLT brings to the financial sector, it also underlines that the development, the implementation and the use of DLT requires a thorough assessment of all the risks involved.
The CSSF further specifies that the list of risks set forth in the Whitepaper should not be read as an exhaustive list, but that the Whitepaper only summarises the main problematics encountered by the CSSF when dealing with DLT.
Finally, the CSSF emphasises its openness to consultation and exchange with all participants of the financial sector in order to further develop innovative projects and the related regulatory framework.
In this regard, the Whitepaper should be viewed as guidance when starting a DLT project and before approaching the CSSF. In particular, the appendix enclosed to the Whitepaper summarising DLT-specific key questions and considerations constitutes, in our view, a useful “checklist” when preparing a first project to discuss with the Luxembourg regulator.
Cover picture: Copyright © Adobe Stock / LuckyStep
