Fraud Scoring Isn't High-Risk Under the AI Act. Credit Scoring Is

Most payments companies use models to decide things about people: whether a transaction looks fraudulent, whether to challenge it, whether to route it one way or another. The EU AI Act treats some of those decisions as high-risk and some not, and the line sits in a place payments teams should look at before 2 December 2027, the date the Digital Omnibus set for Annex III obligations. I’m not a lawyer, and what follows is my reading of three secondary sources, not of the regulation text itself.

The line as the sources describe it

Annex III, point 5(b), covers AI systems used to evaluate the creditworthiness of natural persons or to establish their credit score. According to both TrustSphere and X Consulting, it expressly excludes systems used to detect financial fraud. X Consulting’s FAQ answers the obvious question: a fraud detection system is “not automatically” high-risk. Point 5(c), which X Consulting also cites, covers risk assessment and pricing for life and health insurance. X Consulting adds that organisations assessing creditworthiness face an Article 27 fundamental rights impact assessment, which I haven’t read in the text.

TrustSphere makes a point I think matters more than the headline. Anti-money-laundering transaction monitoring and sanctions screening are not named in Annex III, and it describes the boundary for blended credit and AML models as open, with no financial-crime guidance published as of 21 October 2026. Cooley, which I read for dates, lists credit and insurance as the financial areas affected and doesn’t discuss the fraud carve-out, so I’d call that an omission, not a disagreement.

Where I’d expect it to get blurry

Card-payment fraud scoring sits on the excluded side as I read it: the purpose is to detect fraud, not to decide whether someone gets credit. The places I’d look harder are the ones where one score does two jobs.

If a consumer-facing score decides whether someone is offered instalments or pay-later terms at checkout, I would read that as creditworthiness whatever the vendor calls it. If a risk score built to catch fraud is also reused to decide limits or terms, the purpose is no longer only fraud detection, and I don’t know how a regulator would treat that. The sources I read don’t settle it either, which is TrustSphere’s point about blended models.

Providers and merchants may also not agree on who is responsible. A payment orchestration layer that passes along a vendor’s risk score to a merchant is in a different position from the vendor that built the score and the merchant that acts on it. The Act has separate duties for providers and deployers, and I haven’t found guidance on how those split in a multi-party payment flow.

What I’d ask vendors and internal teams

I’d ask three things. What is each model’s documented purpose, in one sentence? Is any output used for something other than the purpose written down? And who in the chain would say they are the provider?

The answers matter more than the label on the product. I covered a version of this principle in What ‘Should Have Known’ Means for a Payment Processor: regulators tend to read what a system is used for, not what it was sold as.

I’d also want a person to review declines that a model drives where the customer can’t see why, but that is my preference and not something I found in the Act for fraud systems.