The introduction of the General Data Protection Regulation in Europe raises some critical questions about Distributed Ledger Technology. At the top of the list: Does GDPR really apply to DLT, and is it even enforceable?
There has certainly been a sufficiency of discussion about blockchain and cryptocurrencies over the past several years, covering things such as investment safety and whETHer they are actually currencies. But the introduction of the General Data Protection Regulation in Europe has introduced some unanswered questions about the foundation technology for all this, Distributed Ledger Technology.
The DLT Approach to Data
There is no shortage of definitions of how DLT works, but we can use this one:
“Distributed ledger technology (DLT) is a digital system for recording the transaction of assets in which the transactions and their details are recorded in multiple places at the same time. Unlike traditional databases, distributed ledgers have no central data store or administration functionality. In a distributed ledger, each node processes and verifies every item, thereby generating a record of each item and creating a consensus on each item’s veracity. A distributed ledger can be used to record static data, such as a registry, and dynamic data, i.e., transactions.”
According to the UK Government Chief Scientific Adviser:
“[D]istributed ledgers are inherently harder to attack because instead of a single database, there are multiple shared copies of the same database, so a cyber-attack would have to attack all the copies simultaNEOusly to be successful. … But this is not to say that distributed ledgers are invulnerable to cyber-attack, because in principle anyone who can find a way to ‘legitimately’ modify one copy will modify all copies of the ledger. So ensuring the security of distributed ledgers is an important task and part of the general challenge of ensuring the security of the digital infrastructure on which modern societies now depend.”
This is indicative of most of the discussion of the vulnerabilities of DLT, in that it focuses on the technology’s resistance to altering a data record. Because there are many copies of a single record, all presumably protected by encryption and keys, the general conclusion is that it is very hard to modify all the records at once. What is not so clear is what happens if one or more of the records is out of sync with other records of the same transaction.
In that case, is there some foolproof way to determine which record(s) prevail, and which are assumed to be false? Or do we face the situation where, since we don’t have agreement between all the nodes, we freeze the record until we can resolve the disparity? Think about that event in a highly volatile market, for example. And we have already seen multiple instances of nefarious behavior in the cryptocurrency space, so we should already be aware of the possibility of hacking DLT data.
The GDPR Approach to Data
The GDPR views this data as somETHing of an asset, which appears to be owned by some person, either natural or institutional. Although the rule itself never mentions data ownership, the obligations owed to data subjects by controllers and processors (C/Ps) are exactly the same as if the subjects owned the data. The subjects can instruct the C/Ps what to do with the data (within boundaries) and the C/Ps have the same obligations of care and protection as if the data had monetary value. Given that each record of a transaction must contain data components identifying the parties, it appears clear that any DLT records of transactions done by EU natural persons are subject to the GDPR. Since the nature of DLT is to have multiple (perhaps hundreds) of records of every transaction, there will, by that logic, be up to hundreds of copies of personal data regulated by GDPR.
But what does GDPR say that is applicable to DLT data? A lot, as it turns out. To begin with, Article 5 requires that the data be “processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures (‘integrity and confidentiality’).”
GDPR differentiates between the responsibilities of data controllers and processors. It says in Article 4 that a controller “determines the purposes and means of the processing of personal data,” while a processor “processes personal data on behalf of the controller.” So, one of the GDPR questions regarding DLT is: Which of the nodes would be construed to be a controller, and which would be processors? Since GDPR says that the controller is responsible to the data subject for the actions of the processor, presumably whoever introduces the transaction into the DLT is the controller – and is responsible to the data subject for the processors.
Then, Article 14 requires:
Where personal data have not been obtained from the data subject, the controller shall provide the data subject with the following information:
(a) the identity and the contact details of the controller and, where applicable, of the controller’s representative;
(b) the contact details of the data protection officer, where applicable;
(c) the purposes of the processing for which the personal data are intended as well as the legal basis for the processing;
(d) the categories of personal data concerned;
(e) the recipients or categories of recipients of the personal data, if any;
(f) where applicable, that the controller intends to transfer personal data to a recipient in a third country or international organisation. (emphasis added)
Of course, the GDPR has multiple opt-outs, such as:
Paragraphs 1 to 4 shall not apply where and insofar as:
the provision of such information proves impossible or would involve a disproportionate effort.
For DLT, is each node that is not a controller deemed to be acting as the controller’s representative? Assuming that each node does not receive the personal data from the subject, do these requirements apply to every instance of the data? What constitutes disproportionate effort?
In addition, Article 34 says, “When the personal data breach is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall communicate the personal data breach to the data subject without undue delay.” This refers to a breach at any processor and must be reported by the controller. In other words, for every piece of data in the DLT subject to GDPR, one node will be designated as the controller; all other nodes will be processors. Thus, we presume that the processors owe certain levels of safety and reporting to the controller, and the controller owes that level of safety and reporting to the subject.
Questions to Be Answered
Obviously, there are several larger questions that need to be answered at the intersection of DLT and GDPR.
Does GDPR really apply to DLT? On its face, the answer seems obviously yes. Nothing in the GDPR language exempts any particular kind of data or processing structure. But the structure of DLT appears to make the GDPR requirements fiendishly difficult to implement. In all likelihood, ESMA and/or the EC will have to issue a specific finding about this question.
If GDPR doesn’t apply to DLT, what protections do DLT data subjects have against breaches? The whole purpose of GDPR was to afford data subjects specific protections against loss or misuse of their personal data. If GDPR is deemed not applicable to DLT, does that mean that some entity’s unilateral decision to adopt DLT in a particular business case means that its customers have de facto given up GDPR protection without knowing it?
If GDPR does apply, which nodes are construed to be controllers, and which are processors? Is it as simple as who originated the transaction? How would the processor nodes know which node is the controller for each transaction? What is the mechanism for communication of: 1) controller identity, where data has been passed from one node to another, and 2) breach notification? Can the data subject hold the controller legally responsible for the actions of a processor node in the DLT?
Does this mean that, in some cases, GDPR is essentially unenforceable? If the data structure of DLT means that portions of GDPR are unenforceable, or perhaps inapplicable, we may have a situation where natural persons have some data protection in one area and much less in another. If so, will service vendors have to inform data subjects that GDPR applies in this situation, but not in that one? If DLT becomes the structure of choice throughout the financial markets, will GDPR simply fade away?
Regulators have a reputation, perhaps well-earned, of effectively preventing the last problem they faced, but not necessarily the next one. DLT, at least as it is manifested in the financial markets, appears to have its own set of unknowns, and whETHer regulation will, at some point, have to address those, it is even now pretty clear that GDPR isn’t structured to do that.