The GDPR Trap Hiding Inside Your AML Automation
Most compliance teams building AML and sanctions screening automation are focused on one number: 10 July 2027, the date the EU's new Anti-Money Laundering Regulation becomes directly applicable across all 27 member states. That focus is correct. But a separate rule, one most screening projects never budget time for, can quietly undo the automation you just built. It is Article 22 of GDPR, and it has nothing to do with AML law at all.
What Article 22 actually blocks
Article 22 of Regulation (EU) 2016/679 gives a customer the right not to be subject to a decision based solely on automated processing when that decision produces a legal effect or similarly significantly affects them. Freezing an account, blocking a payment, or rejecting onboarding are exactly that kind of decision. If your screening pipeline matches a customer against a sanctions list and the system itself triggers the freeze with no human in the loop, you have built a GDPR Article 22 problem, not just an AML control.
This catches teams off guard because the AML rulebook and the data protection rulebook were written by different committees with different goals, and they collide at the exact point where automation delivers its biggest efficiency gain: the moment of action. It is easy to automate the matching. It is legally risky to automate the consequence.
Why this matters more as you get better at automation
The honest reason most screening teams have not hit this wall yet is that most alerts never get automatically resolved. Industry figures commonly cited for sanctions and PEP screening put false-positive rates on fuzzy-match alerts at 85 to 95 percent, so most of what a screening engine flags is noise an analyst clears by hand anyway, which keeps a human in the loop by default, not by design.
The problem shows up exactly when a project succeeds. Once false-positive reduction work starts paying off and the system confidently auto-clears the obvious noise, someone proposes closing the loop on the other end too: let the system also auto-execute the freeze on a high-confidence true match, since the match is clearly correct. That single step, skipping the human checkpoint on the action rather than the alert, is where Article 22 exposure begins. The more precise your model gets, the more tempting that shortcut becomes, and the more exposed you are if you take it.
The regulatory picture you are actually operating inside
This is not an isolated GDPR footnote. It sits inside a stack of EU rules that all touch the same screening pipeline from different angles. The AML Authority, AMLA, has been operational from Frankfurt since mid-2025 and will directly supervise a cohort of higher-risk EMIs and PSPs once its technical standards land. PEP screening itself processes data correlated with political affiliation, which pulls in GDPR Article 9's special-category rules on top of Article 22, usually resting on a lawful basis under Article 6(1)(c) combined with Article 9(2)(g), though the exact combination depends on fragmented national implementing law. The EU AI Act's Annex III can separately classify fuzzy-match, risk-scoring, or network-analysis components as high-risk, and that classification has to be assessed component by component rather than declared once for the whole pipeline. None of these obligations replace each other. They stack.
What a defensible design looks like
The fix is not to slow down automation. It is to automate up to the decision and stop there, deliberately.
Separate matching from action. The system should surface a ranked, evidenced match. A person should authorize the freeze, the onboarding rejection, or the payment block. That separation is the entire Article 22 compliance story, and it costs you almost nothing in speed because the analyst review on a true positive takes minutes, not days.
Log the human decision as a first-class object, not an audit afterthought. Analyst identity, the evidence shown to them, a structured rationale, and a timestamp need to be captured automatically every time, not reconstructed later when a regulator asks why an account was frozen. A rubber-stamp approve button that nobody actually reads defeats the purpose and will not survive scrutiny.
Classify each AI component separately against the AI Act, not the pipeline as a whole. A deterministic list match and a machine-learning risk score sitting in the same workflow can land on opposite sides of the Annex III high-risk line. Treating them as one system either overstates your risk or, worse, understates it.
Build your legal basis for PEP data before you automate it, not after. Article 9 processing needs a documented basis that survives the specific member state you operate in. This is legal work, not an engineering ticket, and it belongs in the project plan from day one.
Revisit the exception, do not assume it. GDPR Article 22(2)(b) carves out an exception for decisions required or authorized by law, which could loosen the human-in-the-loop requirement in some AML contexts. Whether that exception actually applies to your specific freeze workflow is a question for counsel, not a default you get to assume in your architecture.
The part that actually gets missed
Most AML automation reviews ask "does this reduce false positives" and stop there. The AMLR 2027 deadline, AMLA's new supervisory reach, and the AI Act's component-level classification requirement all get attention because they are AML-shaped questions with AML-shaped deadlines. Article 22 gets missed because it reads like a data protection footnote, not an AML control, right up until a regulator or a customer complaint asks who, specifically, decided to freeze this account, and the honest answer is nobody did. The system did.
That gap between a system matching and a human deciding is the cheapest fix in this entire list, and it is the one teams skip first when they are optimizing for speed.
Novafin builds AML, KYC, and sanctions screening automation for EU payment institutions and EMIs, with the human decision checkpoint designed in rather than bolted on after a regulator asks. If you are mapping your screening architecture against both the AMLR 2027 deadline and GDPR Article 22, we should talk.