If your AI flags a document as fraudulent and a person loses a loan over it, can you explain why? Not “the model scored it 0.87.” I mean the actual reason: this font does not match the issuing bank’s specification, this metadata field says the file was edited in a graphics tool, this balance does not reconcile across pages.
That gap, between a score and a reason, is about to become a legal problem for a lot of companies. The EU AI Act starts to bite, and the way most fraud tools work today sits on the wrong side of it.
At VerifyPDF, we have spent years building document forensics that explain themselves. Not because a regulation told us to, but because a fraud flag nobody can defend is useless to a reviewer and dangerous in front of a court. The regulation is now catching up to that view. So let me walk through what the law actually says, what it does not say and why explainable AI fraud detection is quietly becoming a compliance asset rather than a nice-to-have.
What the EU AI Act actually classifies as high-risk
First, the part everyone gets wrong. People assume any AI touching a credit decision is automatically “high-risk” under the Act. That is half true, and the missing half matters enormously for fraud teams.
The AI Act takes a risk-based approach. Most obligations land on systems the Act calls high-risk, and Annex III lists which use cases qualify. Point 5(b) is the relevant one for lenders:
“AI systems intended to be used 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”
Read that exception again, because it is doing a lot of work. Credit scoring AI is high-risk. Fraud detection AI is carved out. Recital 58 of the Regulation confirms it: systems used “for the purpose of detecting fraud in the offering of financial services” should not be considered high-risk.
So a document forensics engine like ours, on its own, is not a high-risk system under the Act. Neither is a transaction-monitoring tool or an AML screening model. The Luxembourg regulator pointed out that firms keep misclassifying their own AML and fraud tools as high-risk when the law explicitly excludes them.
You might read all this and think: great, we are off the hook, no transparency obligations apply to our fraud score. That would be exactly the wrong conclusion. Here is why.
Why your fraud score still lands inside a high-risk decision
A fraud flag does not exist in a vacuum. It feeds a decision. And that decision is very often high-risk.
Picture the chain. A mortgage applicant uploads bank statements. Your fraud tool scores them. That score flows into the creditworthiness assessment, which is the high-risk system under Annex III 5(b). The lender declines the application, partly because the documents were flagged. The applicant just lost access to housing finance based, in part, on an AI output.
The fraud tool was exempt. The decision it shaped was not. And that is where the obligations reattach.
Article 86 of the AI Act gives any affected person a right to explanation. The text is specific:
“Any affected person subject to a decision which is taken by the deployer on the basis of the output from a high-risk AI system listed in Annex III… shall have the right to obtain from the deployer clear and meaningful explanations of the role of the AI system in the decision-making procedure and the main elements of the decision taken.”
Now put yourself in the lender’s seat. A declined applicant exercises that right. The lender has to give “clear and meaningful explanations of the main elements of the decision.” If one of those main elements was a fraud flag, the lender needs to explain it. And they can only explain it if the fraud tool gave them something explainable in the first place.
A black-box that returns 0.87 with no reason leaves the lender holding a decision they cannot defend. The carve-out protected the fraud vendor, not the customer who deployed it. In our experience, that is the part the procurement conversation usually misses.
There is a quieter point too. Existing EU law already constrains automated decisions. Article 22 of the GDPR has, since 2018, given people the right not to be subject to purely automated decisions with legal or similarly significant effects, with safeguards including the right to contest. A loan rejection clears that bar easily. The AI Act did not invent contestability. It sharpened a principle that was already there.
A black-box fraud score is a compliance liability
Let me be blunt about why we keep harping on this. A fraud score with no reasoning attached creates three problems at once, and all three are getting more expensive.
- You cannot contest what you cannot explain. When an applicant disputes a flag, “the algorithm said so” is not an answer a regulator or an ombudsman accepts. Without a concrete reason, every dispute escalates and every escalation costs you time and credibility.
- You cannot audit a number. Under the high-risk regime, deployers have to keep records and demonstrate due diligence. We covered the documentation pressure this creates for financial institutions in our piece on DORA compliance and document verification. A score in a log proves nothing. A score with linked evidence proves you had a basis.
- You cannot find your own false positives. If the model is opaque even to you, you have no way to learn why it flagged a legitimate document. So you keep declining good customers and you never quite know why. That is a business problem long before it is a legal one.
There is also the discrimination angle, and it is not theoretical. Recital 58 worries openly that credit AI “may perpetuate historical patterns of discrimination.” A fraud model that flags documents using opaque statistical correlations can quietly encode bias, flagging applicants from certain countries or backgrounds at higher rates, and nobody would be able to see it. An evidence-linked approach is structurally harder to abuse this way, because the flag points at the document, not at the applicant.
Let me make it concrete with a quick scenario. Say a lender, we will call them NordLeen, runs a consumer loan desk. An applicant submits payslips and a bank statement. A black-box fraud model returns a 0.91 risk score and the application is declined. The applicant complains to the national authority and exercises the Article 86 right. NordLeen’s compliance team pulls the file and finds… a number. No reason, no anomaly, nothing to point at. They cannot show the decision was justified, and they cannot show it was not discriminatory either. The vendor’s exemption did nothing for them.
Now run the same scenario with explainable forensics. The file shows the payslip’s font was substituted in a graphics editor and the net pay did not match the deposit on the bank statement. NordLeen can give the applicant a clear, document-level reason. If the applicant has an innocent explanation, say they re-exported the PDF through a third-party banking app, the conversation resolves on the merits instead of on the algorithm’s authority. Same regulation, opposite outcome and the only variable was whether the fraud tool could explain itself.
What explainable document forensics actually looks like
So what is the alternative to a mystery number? Concrete, document-level evidence that a human can read and a regulator can follow.
When we flag a document at VerifyPDF, the result is not a vibe. It is a list of specific findings tied to the file itself:
- The metadata shows the file was last modified in an image editor, not generated by banking software.
- The embedded font in the transaction table does not match the issuing institution’s known specification.
- The running balance does not reconcile between page two and page three.
- A creation timestamp predates a transaction date inside the same statement.
- The template structure deviates from thousands of genuine statements we have processed from that bank.
Each of those is a fact about the PDF. A reviewer can look at it, understand it and act on it. A compliance officer can put it in a file. If a customer contests the decision, the lender can point at the exact anomaly rather than waving at a model. This is the difference between document forensics and a guess, and it is why we have always argued that OCR alone cannot detect fraud. Reading the text is not the same as proving the document is real.
This is also why we never treated explainability as a feature to bolt on later. A fraud finding that cannot be inspected is not really a finding. It is an accusation with no evidence behind it. We have written before about how this plays out against human reviewers in AI fraud detection versus manual checks, and the punchline holds: the machine wins not by being more confident, but by showing its work at a level the human eye cannot reach.
The timeline, and an honest note about it
Here is where I have to be careful, because the dates are genuinely in motion and anyone telling you they are settled is overselling.
The AI Act entered into force on 1 August 2024 and applies in phases. Prohibited practices and AI literacy rules kicked in February 2025. General-purpose AI obligations followed in August 2025. High-risk obligations for standalone Annex III systems, which includes credit scoring, were originally set to apply from 2 August 2026, per the official implementation timeline.
But in November 2025 the Commission published a “Digital Omnibus” package, and on 7 May 2026 the Council and Parliament reached a provisional agreement to push the standalone high-risk deadline to 2 December 2027, with product-embedded systems moving to August 2028. Those changes only take legal effect once formally adopted and published in the Official Journal, which is expected before August 2026. So treat 2027 as the likely direction of travel, not a fixed date carved in stone. If the timeline matters to your planning, check the current status rather than trusting any blog post, including this one.
What does not change with the date shuffle is the direction. The transparency obligations on high-risk systems in Article 13 require that they be “designed and developed in such a way as to ensure that their operation is sufficiently transparent to enable deployers to interpret a system’s output and use it appropriately.” Recital 27 defines transparency itself as traceability and explainability. The Act is not asking for a slogan. It is asking for systems whose outputs a human can actually interpret. A deadline can slip. That requirement is not going away.
And remember, the AI Act sits on top of obligations that already exist. The EU’s anti-money laundering rules already push lenders to verify, not just trust, the documents they receive, as we covered in the EU AML document verification rules for lenders. Explainable verification serves both regimes at once.
Questions to ask before you buy a fraud tool
If you are a risk or compliance lead choosing a document verification vendor in 2026, the procurement checklist has shifted. The old question was “what is your detection rate?” The new one is “can I defend a flag?” A few questions worth putting in front of any vendor:
- When you flag a document, do I get the specific reason, or just a score? If the answer is a score with no underlying findings, walk away. You will inherit every dispute with nothing to stand on.
- Can a non-technical reviewer read the finding? “Font mismatch on the transaction table” is something a loan officer understands. A feature-importance chart is not.
- Does the result give me an audit trail I can keep? Under the high-risk regime, deployers have to demonstrate due diligence, so a timestamped record of what was found and why is worth more than the verdict alone.
- How do you avoid flagging legitimate documents for the wrong reasons? A vendor that cannot answer this for their own model cannot help you answer it for a regulator.
None of these questions are about the technology being clever. They are about whether the output survives contact with a complaint. That is the bar the AI Act is steadily raising, and it is a sensible bar regardless of what the law says.
Build for the explanation, not just the score
The companies that will sail through the next few years are the ones treating explainability as the point, not the paperwork. If your fraud detection produces evidence a reviewer can read and a regulator can follow, the AI Act’s transparency push is a tailwind. If it produces a number nobody can defend, every dispute, audit and access-to-credit complaint becomes a small crisis.
That is the whole reason VerifyPDF returns specific findings instead of a bare score. We tell you the font is wrong, the metadata is suspicious, the balance does not add up, and we tell you in seconds. So when an applicant asks why they were declined, or a regulator asks how you decided, you have a real answer.
Want to see what an explainable fraud result looks like on your own documents? Try the free document check and watch the evidence come back, or get in touch if you want it wired into your decisioning through our API. Because “the model said so” was never going to hold up. Now there is a regulation that agrees.