I. THE CONCEPT OF DISTRIBUTED LEDGER TECHNOLOGIES1 AND ITS LIMITATIONS
Over the past year there has been a measurable increase in interest related to cryptocurrency systems by financial institutions and governmental organizations.2 For instance, many private banks including Barclays, have their in-house teams exploring this technology. Yet, in conversations with some of the researchers and software developers they typically say, “I like the blockchain but not bitcoin”. The Blockchain is seen as one of the most disruptive technological invention. Underlying the Blockchain is the ‘Distributed Ledger Technology’ (DLT).3
Distributed ledger is a common database that is spread across the network in multiple sites, institutions or countries. The records are stored in the form of continuous ledgers, rather than blocks and to register transactions on the ledger the participants should reach ‘consensus’. For instance, Ripple, which uses different methodology to achieve consensus, selects up to 200 validators (known as the Unique Node Validators) who are trusted not to collude in defrauding the participants in a transaction.4 Similarly, a blockchain is one such data structure which provide secure and valid form of consensus.5
The distributed ledgers may either be ‘permissioned’ ledger which has owner/s, who can add or verify the contents of the ledger or ‘unpermissioned’ ledger which is open for the public and cannot be owned. The main distinction between the DLT and other cryptocurrency systems lies in the way the transactions are validated. Bitcoin blockchain uses pseudonymous and anonymous nodes to validate transactions, whereas in case of distributed ledger it requires legal identity, such as permissioned nodes to validate transactions. As a consequence, the distributed ledgers are able to host off-chain6 assets due to their authenticated, permissioned system of validation which the Bitcoin and other unpermissioned systems cannot.7
According to Lawrence Lessing, the digital world is regulated through interaction between law (referred as legal code) and software or hardware (referred as computer code)8. In case of DLTs, it relies on technical code which consists of software and protocols. Technical code is intrinsic unlike legal code and the system will rigidly follow these rules, even if the compliance of the same leads to undesirable or unforeseen outcomes.9 Because the current financial systems and DLTs have different rules, it raises questions at different levels as to: who makes these rules? How are they regulated? There may be no straightforward answers to all these questions primarily due to complexities surrounding the technology itself. Due to these complexities, regulating DLTs may become challenging to the regulators.
While analysing the concept of DLT in a legal perspective, there can be certain limitation which cannot be ignored. Predominantly, these technologies are still at the nascent stage of development and it is too early to say which specific model of DLT will prevail in the market. DLTs in practice have a wide range of models, with varied forms of access controls and different degrees of centralisation, to suit the needs of the businesses. The ‘permissioned’ DLT is seen as a congruent model in the current financial market. For instance, the R3 CEV consortium, which consists of 24 largest banks of the world, stipulates that membership of the network is limited to a trusted few, meaning that there needs to some safeguards built into the ledgers to protect the interests of the participants.10 However, the existence of ‘unpermissioned’ model cannot be denied especially while dealing with regulation of DLTs.
Usually all debates surrounding DLTs is largely focused on the technology itself, and how the roll-out of this technology can be disruptive for various sectors. While very little is known about the legal and privacy challenges this technology poses. The legal research in the past has mainly focused on regulation of crypto-currencies like bitcoins. Therefore, the questions that need to be addressed from the legal perspective are: how secured are the personal data collected through the use of these technologies and how does one regulate these new forms of technology, where no single person or entity can be held accountable? The recent enactment of the General Data Protection Regulation, 201611(GDPR), step up the level of data protection throughout the European Union and has expanded its scope. At this juncture, it becomes necessary to understand the implications of general data protection principles on the core features of DLT and provide a proper legal framework within which distributed ledgers can operate.
II. DISTRIBUTED LEDGER TECHNOLOGIES AND TERRITORIAL SCOPE OF THE GDPR
One of the key features of the new General Data Protection Regulations (GDPR) is its extended geographical scope. The current EU Directive 95/46/EC considers only the location where the personal data is processed to determine its geographical reach. The Directive applies in cases where the Data controllers are located outside the EEA but the equipment is used within the EEA. This includes servers, employees, as well as more traditional forms of equipment.12 Under the Regulation, an EU based data controller is covered within its geographical scope where the personal data is processed. In cases outside EU presence, the GDPR will still apply when: (a) the personal data of an EU resident is processed in connection with the goods or services offered or (b) the behaviour of a EU resident is sort to be monitored.13
This GDPR’s two limb test is a significant expansion of reach of the EU data protection law. The EU courts have also made clear their view in this direction stating that a broad interpretation of the current EU Directive was necessary for the protection of individuals’ rights.14
a) EU ‘established’ data controllers
Establishment, according to Rec.19 of the current Directive 95/46/EC implies to “the effective and real exercise of activity through stable arrangements”. Establishment was considered by CJEU in Weltimmo15, where the court held that establishment is a “broad” term and it should not be restricted to the legal form. Even a single representative in EU may constitute an establishment. In Google Spain16 case, the processing of personal data by its associates was inextricably linked to the activities carried out by the EU based establishments. The form of arrangement, whether they are carried out through a subsidiary or a branch, is irrelevant.
Here, the distinction between permissioned and unpermissioned models of DLT becomes relevant. Under the principle of establishment, in case of permissioned DLT, the GDPR is likely to apply to the “proprietor” of the DLT in EU who has a clear legal and technical authority. On the other hand, in case of unpermissioned DLT, the issue may be complicated, as there is no single legal entity in control of this system. In these cases, the GDPR may apply to the businesses that focus on such system, like “exchanges” and “wallet providers” in EU.17
b) Non-EU organisations targeting or monitoring EU based data subjects
This is a scenario, where, the “proprietor” or the “exchanges” and “wallet providers” are situated outside EU. But the regulation will apply to DLT where they process personal data pertaining to EU data subjects in connection with: the “offering of goods or services” (even if the payment is free); or monitor the behaviour of individuals within the EU. As regards the offering of goods or services, an important point is mere accessibility of a site from EU is not sufficient. It should be apparent that the DLT “envisages” the activities to be directed towards EU data subjects.
However, it is pertinent to note that the issue of data controller in case of DLT remains unsettled. Due to the complexities involved in the technological models of DLTs, identification of a data controller may be challenging.
III. APPLICABILITY OF THE GDPR TO DISTRIBUTED LEDGER TECHNOLOGIES
Under the Regulation, there are three main categories of data: Personal data, Anonymous data and Pseudonymous data. According to Recital 26, GDPR anonymous data is any information from which the person to whom the data relates to cannot be identified and anonymized data is no longer considered as personal data and is outside the scope of EU data protection law. Pseudonymization is a form of de-identification. Though this concept is not formally defined under the Regulation, the pseudonymised information constitutes personal data.
Like the Directive 95/46/EC, the GDPR applies to ‘personal data’. However, the GDPR’s definition of personal data is more detailed and makes it clear that information such as an online identifier like an IP address can also constitute personal data. According to the Attorney General\’s opinion in Breyer v. Federal Republic of Germany18, the IP addresses may well constitute personal data, especially where the user’s internet access provider has data stored, which in combination with the IP address can identify the user. However, this case is pending before the CJEU.
To establish the application of GDPR to DLT, the data stored in the distributed ledger must constitute personal data as defined under Article 4(1) of the GDPR, which states that the information in question has to be related to an ‘identified or identifiable natural person’. Particularly, in case of permissioned DLT majority of the transactions consists of off-chain assets such as property registers or smart contracts, which usually involve personal information of the owner or of a contracting party.19 However, the accuracy and security of the assets stored in the ledgers are cryptographically maintained through the use of ‘keys’ and ‘signatures’ that control the distributed ledgers. The personal information stored in the ledger is in the form of digits, IDs, which is unique to every individual participant in the network.
The deciding factor is if the data were rendered anonymous in such a way that the data subject is no longer identifiable, then the GDPR would not apply to DLT.20 But if the data were rendered pseudonymised, then the data stored in the ledger would constitute personal data in which case the GDPR would apply to DLT.
IV. ISSUE OF DATA CONTROLLERS IN DISTRIBUTED LEDGER TECHNOLOGIES
The Data controller is an entity under GDPR that determines the purposes for which and the means by which personal data are processed. Under Article 4 (7) of the GDPR:
“Controller” means the natural or legal person, public authority, agency or any other body which alone or jointly with others determines the purposes and means of the processing of personal data; where the purposes and means of processing are determined by EU or Member State laws, the controller (or the criteria for nominating the controller) may be designated by those laws”.
Why is it an issue in case of DLTs? The data controller under GDPR is vested with important responsibilities and performs different tasks. The controller is responsible for and must be able to demonstrate compliance with the principles of Data Protection including the individual’s right to erasure21, access and portability22, issuance of breach notifications23.
The data controllers play a key role in appointment of representatives24 and processors25. Another important function of the data controller stipulated under the GDPR is data protection by design and by default. Article 25 of the GDPR states that the data controllers must ensure that in the planning phase of processing the personal data and the implementation phase of any new product/service, the Data Protection Principles and other appropriate safeguards must be adequately addressed and implemented.
This provision in the GDPR imposes an additional responsibility on the controllers by requiring them to ensure that data protection compliance is imbibed into their data processing activities, not only at the time of processing but prior to the processing itself. In addition, the controller is required, by default, to process only the minimum amount of personal data necessary which is known as data minimisation.26 So for this type of regulatory system which revolves around central intermediaries the DLTs may pose a significant challenge. At this point, it important to draw distinction between permissioned and unpermissioned model of DLT. The issue of data controllers may be different depending upon the model of DLT.
a) Permissioned DLT
In case of permissioned DLTs, there usually exists a ‘proprietor’ with clear legal and technical authority. So, it is for the proprietor to determine how the code is modified, and up to the participants of the system to decide whether they are comfortable with the proprietor exercising authority over the software. Generally, service level contracts and other conventional means are adopted to establish responsibilities and to enforce them. Therefore, permissioned DLTs are not very different from financial networks like software-as-a-service (SaaS) systems.27 So, there can be two scenarios emerging from this model: First, the ‘proprietor’ may act as data controller but in all cases the participants may not agree with the proprietor’s authority. Second, the proprietor and participants of the system can act as joint controllers. Article 26 of the GDPR28, states that:
(1). “Where two or more controllers jointly determine the purposes and means of processing, they shall be joint controllers. They shall in a transparent manner determine their respective responsibilities for compliance with the obligations under this Regulation, in particular as regards the exercising of the rights of the data subject and their respective duties to provide the information referred to in Articles 13 and 14, by means of an arrangement between them unless, and in so far as, the respective responsibilities of the controllers are determined by Union or Member State law to which the controllers are subject. The arrangement may designate a contact point for data subjects”.
For considering the proprietor and participators of the system as joint controllers, the provision requires transparent and clear allocation of responsibilities. This allocation of responsibilities inter-se between the participants and the proprietor is not readily identifiable. Also it may be impossible to ascertain in certain cases.
b) Unpermissioned DLT
Identifying data controllers in an unpermissioned DLT is more complicated, as there is no single legal entity in control of the system. The technical code for distributed ledger systems for instance, Bitcoins is produced by private actors in an ‘ad hoc process’. The ad hoc process is one where the software is governed by a handful of informal institutions and power holders.29 In these cases the “exchanges” and “wallet providers” may be considered as data controller. However, in absence of a data controller, the GDPR cannot not be implemented effectively.
V. RIGHT TO ERASURE AND ITS APPLICABILITY TO DISTRIBUTED LEDGERS
The Data subject\’s right to erasure of information (also known as the ‘right to be forgotten’) is part of the GDPR. The decision of the CJEU in Google Spain v AEPD and Costeja Gonzalez30, ruled on the questions relating to interpretation of the current EU Directive 95/46/EC and its applicability to search engines. The CJEU held that search engines are data controllers; that EU data protection law applies to their processing of the EU data subjects, even if they process the relevant data outside the EU; and that the ‘right to be forgotten’ applies to data online unless there is a public interest behind such data being retained.
The grounds for erasure of data are enumerated in Article 17 of the GDPR:
“where the data is no longer necessary in relation to the purposes for which they were collected or otherwise processed; where the data subject has withdrawn consent to processing and where the data subject objects to the processing.”
Further, the erasure must be carried out “without delay”, subject to limited restrictions. The important aspect of Article 17 of the GDPR is that these rights are not absolute and the data controllers are required to perform a balancing act against any competing rights to freedom of expression when considering the requests for removal.
There is twofold issue involved in the effective implementation of this provision vis-a-vis the DLT. First, according to Robert Sam, one of the salient features of DLT that distinguishes it from other cryptocurrencies is ‘immutability’ which he terms as settlement finality31 whereby the data once registered into the ledger cannot be deleted or altered. Second, as discussed earlier, it is the difficulty that is attached with the identification of a data controller in different models of DLT. Data controllers are essential part of this provision because it is they who can process the erasure requests made by the data subjects.
Nevertheless, DLTs cannot be said to have rendered this provision redundant. It can be argued that owing to this unique technological feature of the DLT, the personal data stored in the ledger is necessary for the purpose of processing.32 But it remains to be seen whether this technological feature would itself constitute a ground while dealing with the exceptions such as legitimate interests of the controller or balancing the interests of the controller and the data subject.33
VI. THIRD COUNTRY TRANSFERS AND JURISDICTIONAL ISSUES
One of the key selling points of distributed ledger technology is that it enables an integrated approach to cross border transactions as the networks are distributed across different institutes and countries. However this also poses a number of jurisdictional issues. Every transaction potentially comes under the legislative umbrella of wherever the ledger exists whether in respect of financial services or data protection. This would force the distributed ledgers to comply with a potentially high number of legal and regulatory regimes. In particular, the GDPR may create legal and regulatory issues for DLT that enables the transfer of data across different jurisdictions.34 Under the GDPR, a data controller can only transfer personal data outside the EEA to a country if there is an adequate level of protection for the rights of data subjects. The adequacy of the level of protection associated with such data transfers may be ensured in following ways: the controller can carry out an assessment of the adequacy of the protection; controller may use contracts to ensure adequacy; controller can obtain Commission\’s approval for a set of Binding Corporate Rules governing intra-group data transfers.35
In case of DLTs, the following issues arise for consideration under the GDPR:
(1) The problem specifically lies in unpermissioned DLT model, where the technical code can emerge from both the private actors as well as from the public sectors such as TCP. In such cases it is yet to be seen as to who will conduct the risk assessment to decide whether the proposed transfer will provide an adequate level of protection for data subjects rights;
(2) How will unpermissioned DLTs comply with measures such as Model Contract Clauses or Binding Corporate Rules considering the fact that the current regulatory regimes under the Member States are facing difficulty in its implementation36; also, there is no single legal entity in control of this system.
(3) Under the GDPR, the consent derogation clause has been amended. So, before exporting personal data, it remains to be seen how the unpermissioned DLTs will comply with the provision which mandates that the data subjects should be sufficiently informed of the risks of data transfer.37
(4) The question also arises in case of unpermissioned DLTs regarding a fraudulent or erroneous data transfers where the locus of the ‘act’ may not be clear as the transaction may have occurred simultaneously in ledgers situated at different places. A further complication can arise when the ledger itself is the source of problem. In addition to the ambiguity as to the locus, the absence of formalised standards and procedures within the network can potentially leave the data subjects with no relief.38
VII. COMPLIANCE OF BREACH NOTIFICATION
The Data controllers are now subject to a personal data breach notification regime. Article 31 of the GDPR states that
“in the case of a personal data breach, the data controllers shall without undue delay” and if feasible, within 72 hours after having become aware of it, notify the personal data breach to the supervisory authority”.
Data controllers must now expected to maintain an breach register. Non-compliance with this provision may lead to an administrative fine up to €10,000,000 or in case of a business enterprise, up to 2% of the total worldwide annual turnover of the preceding financial year, whichever is higher.39
The DLTs are thought to exist independent of human involvement, and are solely governed by mathematical algorithms. This is a misconceived notion. The technical code of DLTs are produced and maintained by humans. Technologies are vulnerable to attacks. So in any event if the ledger were to malfunction or be tampered with, there would be no system to report any breach as a second line of defence.40 Moreover, were a DLT becomes the default network in financial services, dominated by major private solutions; it may become a vehicle for collusion, particularly in the aftermath of the FX and LIBOR scandals.41
Even though the technology may have enabled dis-intermediation of certain centralised functions, DLTs cannot fulfil the range of functions that are performed by the intermediaries.
2017-1-24-1485288205