Document fraud detection: what the pixels tell you
Short answer: document fraud detection asks two questions that get collapsed into one. Is this document genuine, and does it belong to the person presenting it. A pipeline that reads fields accurately answers neither. The strongest signals are at the image level rather than in the extracted text, which is why a system with 98% field accuracy will pass a competent forgery with high confidence.
The three kinds of document fraud
They fail differently and no single check catches all three.
A forged document. Manufactured from nothing or from a template. Quality ranges from obviously wrong to genuinely hard, and the good ones defeat visual inspection by a person.
A manipulated genuine document. A real passport or utility bill with a field altered: a date of birth, an address, an amount. This is the most common and the most dangerous, because every check that looks at document structure passes. The document is real. One region of it is not.
A genuine document belonging to someone else. Nothing wrong with the document at all. The fraud is in the presentation, and the only defence is binding the document to the person.
Most systems marketed as document fraud detection software address the first well, the second poorly and the third not at all. The same is true of the best fraud detection software in adjacent categories, because the third is not really a document problem at all, because the third is a biometric problem wearing a document problem’s clothes.
Why extraction accuracy tells you nothing
Worth stating directly because it is the assumption most builds are made on.
An extraction pipeline reads what is in front of it. Present it with a document where the date of birth has been altered in an image editor and it will read the altered date, confidently and correctly, because the altered date is genuinely what the pixels say.
Field accuracy measures whether you read the document right. Fraud detection asks whether the document is right. They are orthogonal, and a high score on the first is frequently mistaken for evidence about the second.
This is why detecting fraudulent documents belongs in the pipeline as a parallel signal rather than as a downstream consumer of extracted text. An AI-powered document fraud detection layer that only sees the text your extractor produced has been handed the forgery’s own account of itself.
The image-level signals that actually work
Manipulation leaves traces that survive in the file even when the result looks clean.
Compression inconsistency. A JPEG recompresses in eight-by-eight blocks. Paste a region in and save again and that region carries a different compression history from its surroundings. It is invisible to the eye and measurable.
Noise discontinuity. Every sensor produces characteristic noise. A region sourced elsewhere, or synthesised, has different noise statistics from the rest of the image.
Font and spacing irregularity. Altered text rarely matches the original glyph rendering exactly. Character spacing, baseline alignment and stroke weight in the edited region drift from the document’s own norm, and the comparison to make is against the rest of that document rather than against a reference font.
Metadata. Editing software frequently leaves its name in the file. Trivially stripped, and worth checking anyway because a surprising share of attempts do not bother.
Recapture artefacts. A photograph of a screen carries moiré patterns, screen-door structure and reflections. A photocopy loses the security features a genuine document has. Both indicate the original was never presented.
None of these is conclusive alone, and any document fraud detection system presenting one as a verdict is overreaching. Together they form a score, and the score belongs in front of a reviewer as evidence rather than being collapsed into a pass or fail.
Document-specific checks
Alongside the pixels, the document itself supplies structure to verify.
Machine-readable zones on passports and many ID cards carry check digits, and the MRZ has to agree with the printed fields above it. Disagreement is close to conclusive, and checking it is cheap.
Document numbers frequently carry checksums. Expiry and issue dates have to be internally consistent and consistent with the holder’s stated age. Security features — holograms, microprint, guilloche patterns, optically variable ink — appear in known places for known document types, which is only checkable if you classified the document first.
That last point is the argument for classification before verification. You cannot check a passport’s security features without knowing which country issued it, and running every check against every document type is both slow and noisy.
Binding the document to the person
This is the half that document analysis cannot reach.
The mechanism is a face match between the document portrait and a live capture, with a liveness check confirming the capture is a person rather than a photograph, a screen or a generated video. Both parts are necessary. A face match alone is defeated by holding up a photograph of the document’s owner.
Liveness has become the contested ground as generated video has improved. Passive liveness infers from a single capture; active liveness asks the user to do something. Active is harder to defeat and costs you completion rate, which is a real trade rather than a technicality, and the right setting depends on what a false accept costs you.
This is where KYC fraud detection differs from fraud detection elsewhere in a business: an application fraud detection model scoring behaviour cannot tell you whether the passport was real, and a document check cannot tell you whether the applicant is who they claim. Both are needed and they are separate systems. The full onboarding sequence is covered in the KYC onboarding process.
Thresholds are a business decision
Every document fraud detection system produces scores, and someone has to decide what score rejects.
Set it tight and you reject genuine customers, which is a revenue cost that is invisible because rejected applicants do not complain — they go elsewhere. Set it loose and fraud passes, which is a direct loss and, in regulated contexts, a regulatory one.
The right method is unglamorous. Measure both error directions separately on a labelled sample of your own submissions, including known-fraudulent ones if you have them. Plot the trade. Then choose the point where the expected cost of a false accept equals the expected cost of a false reject, at your fraud rate and your customer value.
That calculation belongs to your risk function rather than to your engineers, and the most useful thing a build can do is expose the dial rather than pick a number and hide it.
Three-tier routing, not a binary
Systems that output accept or reject force a choice nobody has enough information to make, and fraud detection automation is frequently sold in exactly that shape.
Three lanes work better. Clear acceptance for submissions where everything agrees. Clear rejection for the small set with conclusive evidence, a failed MRZ checksum or a detected screen recapture. And a review lane for everything between, where a person sees the document, the flagged regions highlighted in place, and the specific signals that fired.
That middle lane is where your fraud team earns its value, and its size is the number to manage. Too large and you have built a queue; too small and you are making automated decisions on weak evidence.
What to measure
False accept rate on known fraud, which requires keeping and labelling the cases you caught. Most teams discard them.
False reject rate on confirmed-genuine applicants, measured through the appeals path. If you have no appeals path you have no way to learn this, and you are probably rejecting more good customers than you think.
Review lane volume and disposition time, which is your operating cost.
Signal-level precision. Which individual checks fire on confirmed fraud versus on genuine documents. Some will turn out to be noise on your document mix, and retiring them is how the review lane shrinks.
Build or buy
Buy a document fraud detection API when your document mix is common, your volumes are moderate, and per-check pricing is comfortable. Vendor coverage across hundreds of document types with maintained security-feature libraries is genuinely hard to replicate, and forgery patterns change in ways that need continuous maintenance.
Build when per-check pricing dominates at your volume, when your document mix is unusual and vendor performance is poor on exactly what you see most, when documents cannot leave your infrastructure, or when your risk logic is specific enough that you keep fighting the vendor’s verdict. The comparison is in KYC verification: build vs buy.
The common middle path is buying the authenticity checks and building the decision layer, so the thresholds, the routing and the audit trail stay yours.
The takeaway
Document fraud detection is three separate problems and your extraction accuracy addresses none of them. The signal is in compression, noise and spacing rather than in the text; classification has to come first so the right structural checks can run; binding the document to a person needs a face match with liveness; and the thresholds are a risk decision that should be visible rather than buried. Route into three lanes, keep your caught fraud as labelled data, and measure both error directions on your own submissions.
EpochC builds KYC and KYB automation with authenticity scoring alongside extraction, on the intelligent document processing services underneath. See the KYC OCR automation case study — EUR 40,000 a year removed at 98% field accuracy — or start a project.