The inception of the General Data Protection Regulation (‘GDPR’) in May 2018 has made it easier for individuals within the UK and the EU (and sometimes those based elsewhere) to assert their data protection rights to object to the inclusion of false or outdated information about them in risk/compliance databases.
In most jurisdictions, businesses operating in regulated industries – including financial institutions, banks and many professional services firms – are required to carry out checks, including anti-money laundering (‘AML’) checks, on those who use their services. Most businesses which carry out these checks on a regular basis utilise subscription databases. These products, sometimes referred to as ‘risk management, ‘intelligence’ or ‘compliance monitoring’ databases, are commonly marketed as a ‘one stop shop’ for their users’ risk and compliance obligations, enabling users to assess current and potential customers and to avoid those individuals and businesses who may pose a risk.
Risk management databases vary enormously in scope, detail and intelligence. Some merely aggregate data that is (or was) publicly available (typically on the internet). Others also include data obtained from non-public (usually governmental) sources, such as worldwide sanctions lists and Politically Exposed Persons (‘PEP’) monitoring. Most comprise very large datasets compiled over a number of years. Whilst this may be attractive to users – who want to use a database containing as much information as possible – herein also lies the problem. Broadly speaking, this is manifest in two ways, which are set out below.
Data that should not be included in the database
Many risk management databases contain information that simply should not be included, either because its inclusion is unlawful, and/or because the data itself is inaccurate or irrelevant (in other words, it is ‘bad’ data).
In many instances, those operating risk management databases (who are ‘data controllers’ under the GDPR) fail to comply with their data protection obligations in respect of personal data at the point at which that data is first included in the database.
Pursuant to the GDPR, data must always be processed (i.e., used, or communicated to others) “lawfully, fairly and in a transparent manner in relation to the data subject” (Article 5(1)(a)). Just because the particular data may appear relevant and/or it might be useful to the database’s users, does not in and of itself justify the inclusion of that data in the database. Rather, the processing must be done in accordance with the ‘principles’ set out in Article 5 of the GDPR. It must also be done ‘lawfully’, which means the specific processing must fall within one of the categories (a) to (f) listed in Article 6(1) of the GDPR. It seems that data controllers operating risk management databases commonly fail to consider their obligations under these principles and select data for inclusion solely based on whether it appears it could be relevant.
Where data about an individual is added to a database, that is usually done without the knowledge or consent of that person (who is referred to as the ‘data subject’). In such circumstances (i.e., where the data has been obtained from another source), the data controller must also comply with the requirements of Article 14 of the GDPR, which obliges them to notify the data subject and provide the data subject with certain information about the processing. Data controllers operating risk management databases rarely, if ever, comply with this obligation.
Insufficient review mechanisms
Naturally, the data controller’s obligations do not end once the data has been added to the risk management database. Pursuant to Article 5 of the GDPR, they are obliged to ensure, inter alia, that personal data is kept up to date and that inaccurate data is erased or rectified without delay. In practical terms, this means that risk management databases should have sufficient mechanisms to perform ongoing review of the data contained within them.
Data continually goes out of date. Certain categories of data are prone to become out of date relatively quickly – such as addresses, PEP status, list of associates and corporate connections etc. Other types of data, such as news stories that mention the individual concerned, will become old but may remain relevant and it may be in the public interest for them to continue to be published, although this must always be balanced against the data subject’s rights. In some instances, however, outdated reports will create a misleading impression if they are presented without context and/or an account of subsequent events. If an individual was accused of a crime, for instance, for which they were subsequently exonerated, a press report detailing the original charge – without any other information – would present a grossly misleading impression. Reviewing this sort of data is more complex and requires a more nuanced and considered approach, and the obligation to perform it on an ongoing basis is a burdensome one for risk management databases with very large datasets. Unsurprisingly, risk management databases are not generally good at carrying it out.
Repercussions for data subjects
There are many ways that ‘bad data’ may end up in a risk management database. Databases which aggregate ‘adverse’ media reports pick up and republish negative news stories about an individual, often without considering context or bias. For example, it is common for high profile individuals living in exile to be subject to false negative propaganda by a hostile regime (e.g. Russian dissidents living in London). Risk management databases may republish those reports having failed to consider their source. Similarly, it is common for risk management databases to republish reports of unfair or politically motivated allegations. In those instances, the mere fact that allegations have been made might be correct, but publishing it to those who do not understand the political context (and, in doing so, endorsing it) will nevertheless be inherently unfair to the data subject. This is before one considers that the imputation drawn from repeating such allegations will often be one that imputes guilt (or something approaching that) and thus also amount to inaccurate data processing.
Fully complying with their obligations under Articles 5, 6 and 14 of the GDPR would of course place a significant burden on those operating risk management databases and increase their costs. It is not difficult to understand why they might cut corners. Unfortunately, this results in incorrect and irrelevant data making their way into these databases, often remaining there for many years. Such data is then relied upon by the databases’ users, often to the detriment of the data subject.
So, what, in practical terms, does this mean for those about whom bad data is included in a risk management database? Of course, many high-net-worth individuals and (current, or former) PEPs will be used to appearing in risk management databases. Others will be unaware that they are included. Either way, in many instances an individual will not know that one or more of the risk management databases contains inaccurate or unfair data relating to them until funds are frozen and/or they are refused banking or other services. At best this will be inconvenient and embarrassing; at worst it could cause significant financial loss.
Data subjects are not without recourse. Under the GDPR, proceedings can be brought to compensate an individual who has suffered damage and/or distress. The Court also has the power to require data controllers to erase or amend personal data. In certain circumstances, there may be an additional claim for libel. An alternative to civil litigation is a complaint to the Information Commissioner’s Office (ICO), which can compel a data controller to cease processing personal data where it determines there has likely been a breach of data protection legislation.
Any individual who is concerned that they may be the subject of bad data in a risk management database should seek assistance from a media and communications lawyer. In most instances, the first step will be to ascertain precisely what data is being published in the relevant database(s) by making a data subject access request (‘DSAR’). An assessment can then be carried out of the legal merits of the processing and any objection that should be raised.
This post originally appeared on the Brett Wilson Media Law blog and is reproduced with permission and thanks.