← InsureGuardAI blog

· Yair Knijn

You screened an EU customer against a US list, and your DPO can't name the lawful basis

The financial-crime team built the screening pipeline; the DPO signed the record of processing without reading the list configuration. Now an EU policyholder has filed an Article 15 request asking why their name was run against the US Treasury's SDN list. The DPO opens the file and finds one lawful basis for the whole pipeline: Art. 6(1)(c), legal obligation. That is the wrong answer for half of what the system does, and the right answer was never written down.

The assumption that broke things is common: that "we screen for sanctions compliance" is one processing activity on one basis. It is not. The basis depends on which list the name is checked against.

Why EU/UN listings give you 6(1)(c) but US listings may not

An EU asset-freeze regulation or a UN Security Council designation, transposed into EU law, binds your firm directly. Screening an EU data subject against those lists sits cleanly on Art. 6(1)(c): processing necessary to comply with a legal obligation to which the controller is subject. Documented, defensible, accepted.

US OFAC listings are different in kind. OFAC primary sanctions bind US persons; they do not, as a rule, impose an EU-law obligation on an EU insurer screening an EU resident. A Swedish court and the Swedish data protection authority walked through exactly this for a company screening against OFAC: wanting to comply with US sanctions can be a legitimate interest, but it is not a legal obligation under EU law and does not automatically override the data subject's rights. So your US-list screening does not get 6(1)(c) for free. It falls to Art. 6(1)(f), and that puts a balancing test on your desk.

Legitimate interests, proportionality, and data minimization for screening

Running on legitimate interests means you owe a documented Legitimate Interests Assessment, not a sentence in a policy. The purpose has to be specific: your own sanctions exposure on dollar-clearing correspondents, not a gesture at "global compliance." Then you test necessity. Are you running every party against every list when the risk only justifies a subset?

Data minimization bites harder than people expect. A screening hit is special-category-adjacent: it implies, rightly or wrongly, suspicion of terrorism, proliferation, or serious crime. Keep what you need to clear or escalate the alert and nothing else.

The DPIA you owe under Article 35 for high-risk screening processing

Article 35 makes a DPIA mandatory where processing is likely to result in high risk, and systematic evaluation of people producing legal or similarly significant effects is the textbook trigger. Screening can get someone refused a policy or reported to an FIU. That is high-risk processing by any honest reading, and "compliance signed off" is not a DPIA. The assessment has to cover at least:

Retention, false-match handling, and subject rights inside a sanctions pipeline

The false positive is where data protection and financial crime collide. A fuzzy match cleared as "not our customer" still generated a record asserting a named person might be sanctioned. You need a retention rule that separates a confirmed hit you must keep as AML evidence from a cleared false match you should not hoard. Article 15 access, Article 16 rectification of a wrong match, Article 18 restriction during a dispute: all apply, and the AML carve-outs are narrower than the financial-crime team assumes.

InsureGuardAI was built so the lawful basis is a property of the screening run, not an afterthought. Each match in a workspace records which list source fired, the threshold that produced it, the analyst decision that cleared or escalated it, and the raw response as evidence, so the DPIA and the regulator read the same file. When your DPO is asked to name the basis for a given hit, the answer is in the record, not in an assumption. See how that fits your own pipeline here.