AI has become essential for effective anti-money laundering work. It has to be. No compliance team can manually review every customer relationship or transaction at the volume and in the detail regulators expect. At the same time, using AI and automation for this work is subject to a growing stack of regulatory requirements. Some are already in force, like the GDPR and the AI Act, and some new, like the EU's Anti-Money Laundering Regulation (AMLR).
The AMLR makes one thing explicit: algorithms alone can no longer decide whether to onboard or walk away from a client. It becomes directly applicable on 10 July 2027, but the groundwork, updating data governance, systems, and processes, needs to start well before that date.
What's actually changing
The AMLR is part of a broader legislative package that also created the new EU Anti-Money Laundering Authority (AMLA). AMLR applies to a wide range of obligated entities, financial institutions, insurers, crypto-asset providers, gambling services, lawyers, notaries, real estate agents, and trust or company service providers. From 2029, it extends to professional football clubs and agents as well.
Most of its obligations in the AMLR aren't new. They're being harmonised across the EU, some existing requirements are clarified, and the scope of obliged entities is expanding. This is an evolution, not a revolution.
It's worth being precise about what kind of change this is for automated data processing and AI adoption in the AML/CFT compliance. The AMLR doesn't replace the GDPR, it adds AML-specific rules on top of it.
The requirements around automated data processing in customer identification and ongoing monitoring will place real demands on process, documentation, and correct implementation, and on keeping track of a growing set of overlapping regulatory interpretations.
Automated processing still requires human oversight
AML customer due diligence (KYC) involves large processing of personal data. If the AML obliged entity uses automation which can have a direct impact on the customer they are already subject to Article 22 of the GDPR. Where automated decision-making is permitted, whether under contract, consent, or a legal obligation, the GDPR already requires safeguards protecting the data subject's rights. That includes the right to obtain human intervention, to express a point of view, and to challenge the decision.
Where the system also involves AI, the obliged entity has to comply with the AI Act too, typically its transparency requirements.
So the AMLR doesn't introduce an entirely new obligation here. What it does is clarify what human oversight actually has to look like, and how it has to be carried out, when automated processing is in use. Under AMLR, the decisions on whether to start or maintain a business relationship, carry out a transaction, or adjust the level of customer due diligence should never be left entirely to automation and must involve meaningful human intervention to ensure that the outcome is accurate and appropriate.
Special category data gets clearer rules, and clearer limits
Special category data covers personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, along with genetic data, biometric data used to identify someone, health data, data about a person's sex life or sexual orientation, and data relating to criminal convictions and offences. Processing this kind of data is normally prohibited, and where it's permitted, it's subject to specific safeguards under Articles 9 and 10 of the GDPR.
The AMLR expressly allows this data to be processed for preventing money laundering and terrorist financing. But it adds requirements on top of that permission:
- Customers must be informed that this data is being processed for AML purposes.
- The data must come from reliable sources and stay accurate and up to date.
- Processing must not result in biased or discriminatory decisions.
- Appropriately high security measures must be in place, particularly around confidentiality.
For obliged entities, this means keeping more detailed records of exactly where special category data shows up in AML and CFT processes, and being able to demonstrate compliance with both the GDPR and the AMLR at once. In practice: more complexity, and more regulatory sources to track for what used to be a single process.
AML data can't quietly become business data
This is a distinction organisations need to draw from the outset, and apply across every process, tool, and piece of infrastructure they use, not just implement once and forget. Compliance here needs to be checked on an ongoing basis, not assumed.
What this means for GDPR compliance in practice
None of this is abstract. It requires mapping existing AML and CFT processes: what data they use, how that data is processed (manually, automatically, or by AI), how the affected individuals are informed, and how the whole process is documented and internally controlled. Then keeping all of it current, and being able to demonstrate compliance with the GDPR, the AI Act, and the AMLR at the same time, not as three separate exercises.
That last part is where most teams actually struggle, not with any single regulation, but with tracking all three as they move and interact with each other.
This is exactly the kind of layered, moving target that's hard to track by hand. Horizon Scanning watches AMLR, GDPR, and AI Act developments, related methodologies, regulatory guidance and court decisions. It maps what changed against the obligations you're actually tracking, and flags it before your next audit does.
A few questions worth sitting with before July 2027 arrives:
- Do you know what data you use for AML/CFT, where it comes from, and how it's processed?
- Are you aware of all the regulatory requirements that apply today, and the new ones coming into effect in 2027?
- Do you keep track of every relevant regulator, including new ones like the AML Authority (AMLA) and the AI Office?
If the honest answer to any of those is "not entirely," that's the actual starting point, not the AMLR's entry-into-force date.