EU AI Act · use case
EU AI Act for Fraud Detection and Anti-Money-Laundering AI
Financial fraud detection is expressly excluded from the high-risk credit entry of the EU AI Act, but AML and law-enforcement uses are not. Where the line sits and what to document.
Classify my system in 3 minutesFree, no account. Pre-filled for this use case.
Risk tier
Depends on use
Minimal risk for financial fraud detection (Annex III(5)(b) exception); high-risk where used for law-enforcement purposes (Annex III(6))
When it applies
Article 5 applies since 2 February 2025; high-risk obligations from 2 December 2027.
Regulation (EU) 2024/1689, Annex III(5)(b) exception; Annex III(6)(a)-(e); Art. 5(1)(d) predictive policing ban; Art. 5(1)(c) social scoring
Fraud detection is the one financial use the EU AI Act carves out by name. Annex III(5)(b) makes creditworthiness AI high-risk “with the exception of AI systems used for the purpose of detecting financial fraud”. Payment fraud scoring, account-takeover detection, chargeback prediction and card-transaction monitoring are therefore minimal-risk under the AI Act, as long as fraud detection is genuinely the purpose.
The exception is narrower than it looks. Anti-money-laundering (AML) transaction monitoring, sanctions screening, and any system whose outputs are used by or on behalf of law-enforcement authorities to assess the risk that a person commits an offence fall under different entries, some of them high-risk and one of them prohibited.
Classification
Why this classification applies
The recitals explain the fraud exception: detecting fraud protects consumers and the integrity of the financial system, and such systems do not determine access to credit by themselves. The exception is about purpose: a model that blocks a suspicious transaction is fraud detection; a model that lowers someone’s credit limit because of fraud risk has drifted into creditworthiness evaluation.
Annex III(6) lists law-enforcement uses as high-risk, including AI used by or on behalf of law-enforcement authorities to assess the risk of a person offending or re-offending, as polygraph-like tools, to evaluate the reliability of evidence, or for profiling in the course of investigations. Private-sector AML systems are not law enforcement, but where a bank runs analytics specifically on behalf of an authority, the entry can apply.
Article 5(1)(d) prohibits risk assessments of natural persons to predict the risk of committing a criminal offence based solely on profiling or personality traits, except to support human assessment based on objective, verifiable facts linked to criminal activity. Fraud models built on behavioural facts (device, velocity, transaction pattern) are outside the ban; “propensity to defraud” scores built on demographics are not.
Obligations
What you have to do
- Write and keep a classification memo stating that the system’s purpose is detecting financial fraud, with evidence that outputs are not used for creditworthiness or limit-setting.
- Check the model against Art. 5(1)(c) (social scoring across unrelated contexts) and 5(1)(d) (predictive assessments based solely on profiling).
- Apply GDPR safeguards: legal basis, DPIA for large-scale monitoring, and Art. 22 rights where a block has significant effects on the customer.
- AI literacy for fraud analysts (Art. 4) and clear escalation for false positives that cut customers off from funds.
- Where any output is supplied to a law-enforcement authority for the purposes in Annex III(6), treat that use as high-risk with the full obligations.
- Re-assess whenever fraud scores are reused in onboarding, KYC, or credit decisions.
Paperwork
Documents to have on file
Get these documents drafted for your system
Run the free assessment, then unlock the Compliance Pack: a PDF report plus editable first drafts of every required document and a 90-day plan. €49 one-time, no subscription.
Common mistakes
Where companies get this wrong
- Reusing the fraud score to decline credit or reduce limits. That reuse turns the system into creditworthiness evaluation, which is high-risk.
- Building “fraud propensity” from demographics or postcode. This is close to a prohibited profiling-only risk assessment and is a discrimination risk under GDPR.
- Assuming AML equals fraud. AML monitoring is not covered by the fraud exception and needs its own classification.
- No customer recourse when a false positive freezes an account. GDPR Art. 22 rights apply and regulators treat lack of recourse as a serious failing.
FAQ
Frequently asked questions
Is chargeback or refund-abuse detection in e-commerce covered by the exception?
Yes, detecting fraudulent transactions or abuse is financial fraud detection. Keep the purpose narrow: if the output is used to permanently deny service to a customer based on a profile, review it against Art. 5 and GDPR.
We supply suspicious-activity data to the police. Are we high-risk?
Filing statutory reports is not operating a system “on behalf of” law enforcement. Running analytics at the request of an authority to assess individuals’ offending risk can be. Get a documented legal view for that use.
Does the AI Act require explainability for fraud blocks?
Not as a high-risk duty, since the system is minimal-risk. GDPR Art. 22 and payment-services rules require meaningful information and a route to human review when a block has significant effects.
This page is general information about Regulation (EU) 2024/1689, updated 2026-09-17. It is not legal advice; classifications depend on the exact intended purpose of a system. Deadlines reflect the Digital Omnibus adopted in June 2026.