When MiFID II met GDPR: Encrypt personally identifiable information or risk fines of €20mm+

Under MiFID II and MiFIR, when processing personally identifiable information, due consideration must be given to the Data Protection Directive, a.k.a. Directive 95/46/EC[i]. That directive will be repealed on 18 May 2018 when the new General Data Protection Regulation[ii] enters into force, taking its place.

Personally identifiable information is required under MiFID II / MiFIR

What does that have to do with placing orders and transaction reporting? In order to serve their purpose, transaction reports will have to identify the [natural] person that makes the investment decision, as well as any person responsible for execution and competent authorities will need full access to records at all stages in the order execution process, from initial decision to trade, through to execution for up to five years, meaning that investment firms and trading platforms will have to keep records of all orders and transactions[iii]. The details of the person who decides to trade, then, will need to be communicated at each stage with both the investment firm and the platform provider storing them. This is akin to the tagging algos that make investment decisions.

Further, where transactions are carried out on behalf of clients, records must contain that client's identity.

Thus several classes of natural person need to be included in transaction reports and, potentially, on orders.

So how do you identify a natural person? The answer is that ‘to ensure consistent and robust identification of natural persons… they should be identified by a concatenation of the country of their nationality followed by identifiers assigned by the country of nationality of those persons.[iv]’ In the case of the UK, its the national insurance or passport number. Where not available, natural persons may be identified by a concatenation of their date of birth and name. Additionally, transaction reports should include the full name and date of birth of clients who are natural persons.

The intersection between MiFID II /MiFIR and GDPR has not been given as much consideration as it deserves, yet time is running out for both

The above means personally identifiable information not only exists within MiFID II / MiFIR, but needs to be shared in a form that only authorised persons can access it, yet may be stored on more than one host, and for up to five years. It is this that makes it important to understand the intersection of MiFID II/MiFIR with GDPR.

Unlike its predecessor, with GDPR if data somehow falls into the wrong hands, for instance via a data breach or incorrect processing, firms must self-report the incident to their supervisory authorities and, depending on the nature of the transgression, to the data subject who may be liable to compensation, which could be significant if many data subjects are impacted by an event.

Fines can be €20mm or 4% or worldwide revenue, whichever is the greater

The regulation gives supervisory authorities, and national courts, power to impose administrative fines of up to €20mm or 4% of worldwide revenue per incident, whichever is the greater[v] (though the concept of proportionality is contained within the text). Exemption from self-reporting, and from the fine, is available where personal data is rendered unintelligible to anyone not authorised to access it, through the use of, for instance, encryption. It’s worth mentioning here that Article 87 specifically states that national identification numbers shall be used only under appropriate safeguards for the rights and freedoms of the data subject (i.e. the natural person).

How will you relock data?

Given that FIX connexions (that most ubiquitous of trading protocols) are often not secured by virtue of running clear case over shared networks, not only should you be thinking about how to secure data at rest if you don’t already do so, but how to go about securing data in transit both on home territory and in the domain of another organisation where the data may end up. Not only that, but you need to think of how you allow access to that data on a need-to-know basis, e.g. a one-time basis, and how you relock the data once the person granted access to the data has completed whatever action it was they needed access for. This is not an easy puzzle, though there are solutions; however, the right one may differ depending on other organisational requirements.

It's not easy, but solutions are available. It's not just about encryption. It's much more than that.

Encryption is not the only model mentioned in the regulation, but it is the without doubt the most secure way to make data useless to unauthorised eyes and derisk the large fine. Solutions do exist–I know of several that can be implemented–but they need to be planned in across the workflow, not left to the last minute. Remember, each breach is an event in its own right and cyber attacks are ever on the increase. Don’t risk multiple fines.

Footnotes / references:

[i] They also reference the Regulation (EC) No 45/2001, though references to the Data Protection Directive are what concern us here because the 45/2001 is concerned with the processing and movement of data by and between EU institutions and bodies. You can see the reference in main recital 24 of MiFIR and 106 of MiFID II.

[ii] The General Data Protection Regulation, or Regulation 2016/679/EU, or GDPR, can be accessed in one of the EU official languages from here: https://eur-lex.europa.eu/eli/reg/2016/679/oj

[iii] See recital 34, article 25, and article 26 of MiFIR for more information.

[iv] RTS 22, recital 7.

[v] See Article 83, paragraph 5 of GDPR for details of the fine.