The AI Act Exempts Fraud Detection and Not AML

Annex III of the EU AI Act lists what counts as “high-risk”. That classification is the trigger for the Act’s heaviest obligations: a documented risk management system, human oversight built into the design, a conformity assessment before anything is deployed. AI used to assess a natural person’s creditworthiness or credit score is named there explicitly, and by extension so is a good deal of what a bank would call fraud and risk scoring.

Then the Act carves one thing back out. AI intended for financial fraud detection is excluded from the high-risk category, provided detecting fraud is the system’s main intended purpose.

Sounds like it covers most of what a financial-crime team runs.

It doesn’t, and the European Commission has said so in terms. The exception is to be read narrowly. It does not extend to AI systems used for anti-money-laundering or counter-terrorist-financing checks.

Why this distinction is bigger than it looks

Sit with what that means operationally.

A transaction-scoring model built to catch card fraud or account-takeover fraud can plausibly sit outside the high-risk regime, because catching fraud is its stated purpose. Now deploy a materially similar model to flag transactions for AML review, or repurpose the one you already have, or dual-label it so it does both. The exception is gone. Nothing about the technology changed. The purpose did.

Two systems, near-identical architectures, trained on overlapping data, doing recognisably similar scoring, landing in entirely different compliance regimes depending on how the deployer describes what the thing is for.

Plenty of compliance functions run exactly one shared detection model across both fraud and AML, and not out of laziness — the underlying transaction-anomaly problem genuinely overlaps, and building twice is wasteful. For those firms this is not a paperwork nuance. High-risk classification means Article 9 risk management, Article 14 human oversight designed into the system rather than bolted on afterwards, and a conformity assessment, all applying in full once the relevant provisions take effect from 2 August 2026. A system that was fine to deploy quietly as “fraud detection” needs the full high-risk treatment the moment its actual use includes AML screening. What it was originally procured as does not enter into it.

The part most teams will get wrong first

Not ignorance of the Act. Most compliance functions know it exists and know credit scoring is high-risk.

The mistake is subtler. It’s assuming the fraud detection exception is broad enough to cover anything that scores a transaction for risk, when the Commission has narrowed it to systems whose main intended purpose is fraud detection and has specifically excluded AML/CFT from riding along on it. A model doing double duty has to be assessed against its AML use on its own terms. It does not inherit an exemption earned by its fraud-detection framing.

So there are three questions worth putting to every transaction-scoring or alert-generation system you have in production, or in procurement right now. What is this system’s stated intended purpose? Does its actual use match that purpose exactly? And if AML or CFT screening is any part of what it does in practice, has anyone assessed it against the full high-risk obligations, or did it simply get waved through under the fraud exception?

For firms operating in or serving EU markets, that assessment has a hard date attached.

For UK firms watching from outside direct scope, it is still the clearest signal yet of how a major regulator has chosen to draw the line between fraud AI and AML AI. The FCA’s principles-based approach has never required UK firms to make that distinction explicit. Worth making internally anyway. It is the right question independent of which regulator is asking it, and at some point somebody will ask.