The EU AI Act and Automated Fraud Decisions

The EU AI Act is the first broad horizontal law on artificial intelligence, and every fraud team using a model to score signups, logins or payments has asked the same question: does it apply to us, and how much? The short answer is that fraud detection gets a notable carve-out from the Act’s strictest tier, while the GDPR’s older rules on automated decisions keep applying in full. The practical answer is that both point toward the same engineering habits: decisions you can explain, and a path for a human to review them.

This is an engineering overview, not legal advice. The Act is long, its guidance is still being written, and its application depends on details of your system and role. Use this to frame the conversation with counsel.

The AI Act’s structure in one paragraph

Regulation (EU) 2024/1689 sorts AI systems by risk. A short list of practices is prohibited outright. High-risk systems, listed in Annex III and in product-safety legislation, carry the heavy obligations: risk management, data governance, technical documentation, logging, human oversight, accuracy and robustness requirements, and registration. Some systems carry transparency obligations, such as disclosing that a person is talking to a chatbot. Everything else is minimal-risk, with obligations limited mainly to AI literacy. Separately, providers of general-purpose AI models have their own duties.

The Act entered into force in August 2024 and applies in phases: prohibitions from February 2025, general-purpose model obligations from August 2025, and most high-risk obligations from August 2026, with some product-related ones later. The European Commission has since proposed adjusting parts of the high-risk timetable, so check the current status of any deadline before you plan around it.

Where fraud detection sits

Annex III lists, among high-risk uses, AI systems intended to evaluate the creditworthiness of natural persons or establish their credit score, with the exception of AI systems used for the purpose of detecting financial fraud. The exclusion is explicit. Lawmakers recognized that fraud detection protects consumers and that treating it like credit scoring would be counterproductive.

That does not mean every fraud system is automatically outside the high-risk tier. Three situations deserve a closer look.

Fraud detection that is really eligibility. If a model’s output decides whether someone can access an essential private or public service, such as public benefits, life or health insurance pricing, or credit, and fraud is only one of its inputs, the system may be assessed by what it decides rather than what it is called.

Biometrics. The Act treats remote biometric identification and certain biometric categorisation as high-risk or prohibited, and its definition of biometric data includes behavioral characteristics. Using pointer movement and typing rhythm to tell a human from a script is not identifying a person, but if you use behavioral data to recognize who someone is, get specific advice.

Your role. The Act distinguishes providers, who develop or place a system on the market, from deployers, who use it. A business using a vendor’s fraud scoring is usually a deployer. A business that builds its own model is a provider of it. The obligations differ, so be clear which you are.

For the common case, a device intelligence and risk signal used to detect bots, multi-accounting or account takeover, the system is most likely minimal-risk under the AI Act. The general duty of AI literacy, making sure staff who operate it understand it, applies broadly regardless.

The GDPR still decides most of what you must do

Fraud decisions about people almost always process personal data, so the GDPR applies whatever the AI Act says. Its Article 22 gives individuals the right not to be subject to a decision based solely on automated processing that produces legal effects or similarly significantly affects them.

Whether a fraud decision meets that bar depends on the decision. Blocking a payment, closing an account or refusing a service to someone can plausibly be a similarly significant effect. Showing a proof-of-work challenge or asking for email verification usually is not. The CJEU’s 2023 SCHUFA judgment (C-634/21) is a useful warning here: it held that a score can itself be an automated decision when a third party relies on it heavily to decide, so “we only produce a score, someone else decides” is not automatically a safe harbor.

Where Article 22 applies, solely automated decisions are allowed only on specific grounds, such as necessity for a contract, authorization by law, or explicit consent, and the controller must implement safeguards, including at least the right to obtain human intervention, to express a point of view and to contest the decision. The GDPR’s recitals mention fraud monitoring and prevention as an example of automated decision-making that Union or member-state law can authorize.

Separately, transparency duties require meaningful information about the logic involved in such decisions.

Why reason codes and review paths help with both

Neither law prescribes a specific technical design. Both reward the same properties, and they are properties you want for operational reasons anyway.

Explainable decisions. A decision that names its drivers is one you can describe to a user, defend to a regulator and debug as an engineer. Prynt’s decision object carries stable reasonCodes alongside the score, for example:

{
  "decision": "block",
  "riskScore": 82,
  "reasonCodes": ["MULTI_ACCOUNT", "RESIDENTIAL_PROXY", "INCOGNITO"]
}

“This device already holds several accounts and connected through a residential proxy” is meaningful information about the logic. “Score 82” is not. The reason codes post covers how to design them and map them to user-facing messages.

A real human review path. Route contested decisions to a person who can see the evidence, the event, its reason codes and the account history, and who has authority to reverse it. Allow lists by visitorId, linkedId, IP or country let a reviewer’s decision stick. Record the outcome; labeling it through POST /v1/outcomes as legit or fraud also feeds back into future decisions.

Graduated responses. The more of your decisions are friction rather than refusal, a challenge, a verification step, a held trial, the fewer reach the significance threshold at all. Reserve automated outright refusals for strong evidence like automation or tampering.

Records. Keep the decision, its reason codes and any human review for as long as you might need to explain it, and no longer. Prynt’s retention follows your plan, and erasure is available by visitorId or linkedId.

Data protection basics still apply

A fraud system that is minimal-risk under the AI Act can still be high-risk processing under the GDPR. A data protection impact assessment is often expected for systematic monitoring and large-scale profiling; see DPIAs for fraud detection tooling. The GDPR and device fingerprinting post covers legal basis and the ePrivacy question. Prynt honors Global Privacy Control by default, supports a consent mode, and can truncate or drop IP addresses; the privacy and trust pages describe how, and the DPA covers processing terms.

Make sure every automated refusal in your product can be explained in a sentence and reviewed by a person. That habit will serve you under whatever final shape the guidance takes.