Fake Document Checker: How to Test a Suspect File

What a fake document checker can tell from a file, how to read its verdict and score, and what to check before uploading sensitive documents.
Dean Uata

TL;DR: A fake document checker, or PDF document fraud detection tool, examines a file for signs that it was edited after creation, generated from scratch, or reused, and it should show the evidence behind its verdict. Cotality estimated that 1 in 119 mortgage applications carried indications of fraud in Q2 2026; at that rate, a detector that is right 95% of the time on both clean and fake files would raise about six false alarms for each fake it catches. A checker tests the file, so the issuer or another outside source still has to confirm the facts on the page.

What a Checker Can Determine From the File Alone

A fake document checker reads the file underneath the page: how it was produced, what happened to it afterward, and whether its structure fits the institution named on it. Good tools separate two production classes. Edited-after-creation starts as a genuine file, and someone later changes a balance, a name, or a date. Generated-from-scratch never existed at the issuer, so the file has no genuine original underneath it.

An edited file raises the question of which value moved. A generated file raises the question of whether the issuer ever produced anything for this customer. Document fraud detection usually comes down to six questions, each with a limit.

QuestionWhat the file can showWhat stays open
Production methodThe class of software that wrote the fileWho operated that software, and why
Timestamp trailRecorded creation, modification, and save historyWhether the clock behind those dates was right
Issuer matchingWhether the structure fits known samples from that issuerWhether the issuer produced this particular copy
ConsistencyWhether totals, dates, and repeated values agreeWhether figures that agree are true
Model artifactsTraces of generation in images and page constructionText-only files with no image layer to examine
Recycled patternsReuse of a file or layout across submissionsThe first appearance of a template

Input quality sets the ceiling. A fake document detection app that works from a phone photo receives pixels, so it loses the production history and signatures a native PDF carries. Screenshots and original PDFs support different checks, and a tool should say which ones it could run.

What the Verdict and Evidence Should Look Like

A usable verdict tells a reviewer what happened to the file, where, and how sure the tool can be. A bare "likely fraudulent" gives an analyst nothing to put in a case note. A result worth acting on contains:

  • A class of finding: edited after creation, generated from scratch, reused, no anomalies found, or not enough evidence to assess.
  • The location of the finding, down to the page and the field, with the reason it was raised.
  • A list of the checks that ran and the checks the format made impossible.
  • A statement of whether the finding touches a value that matters to the decision, such as an income figure or an account holder's name.
  • A file fingerprint and a run date, so the result can be tied to the exact bytes reviewed.

Wording matters as much as content. Guidance from the Scientific Working Group on Digital Evidence, written for image examiners, makes a point that carries over to PDFs: a thorough examination can find manipulation unlikely, because a negative cannot be proven. "No anomalies found" is an accurate result. "Authentic" claims more than a file can support. Any tool's output can be measured against what explainable document forensics should give an examiner.

How to Read a Score

A score ranks files by how strongly a model reacted to them. A 90 is not automatically a 90% chance of fraud. The same SWGDE guidance says results should not be reported as a numerical probability without a proper scientific foundation, so a reviewer should ask whether the vendor has calibrated its scale and on which document types.

Base rates do the most damage to intuition. Cotality's 2026 fraud report puts indications of fraud at about 1 in 119 US mortgage applications for Q2 2026. That figure covers applications rather than individual files, so treat it as an illustration. Take 119 files containing one fake and a hypothetical detector that correctly handles 95% of fakes and 95% of clean files. The detector probably flags the one fake and about six clean files. Roughly 14% of its flags are real, even though its accuracy sounds excellent.

Three working rules follow. A high score sends a file to review; on its own it does not support a rejection. A low score means the tool found little, which is different from clearance on a material decision. Thresholds belong to the team, set against its own labeled files, because a score tuned on one portfolio can behave differently on another. Scores from two tools are not comparable.

What a Checker Cannot Determine

File forensics answers how a document came to exist. It cannot establish that the event described on the page happened. A pay stub can be an unaltered export from a payroll system and still describe a job that a shell employer invented. An invoice can be untouched and bill for goods that never shipped. A genuine statement can belong to someone other than the applicant, which is why verification and fraud detection fail in different places.

Only an independent source can confirm the underlying fact: the bank for a balance, the employer or payroll provider for income, the carrier for a shipment, the provider for treatment. The reviewer should reach that source through contact details found separately, never through a number or link printed on the document.

A checker can show that a file changed, but intent is hard to read from bytes, and a clerk correcting a typo and a fraudster changing a balance can leave similar traces. A clean result can also be wrong, because SWGDE acknowledges that some image manipulations may not be detectable with available tools. The remaining uncertainty belongs in the record.

What to Look For Before Uploading Sensitive Files

A suspect bank statement or pay stub holds someone else's account numbers, address, and income, so the upload is a data-sharing decision in its own right. Free tools and browser apps deserve the same scrutiny as paid ones. Before any customer file goes in, a team should get written answers to these questions:

  • Retention: how long are the file, its extracted text, and the report kept, and does deletion reach logs and backups?
  • Training use: do the terms state that uploads and outputs are excluded from model training, or do they rely on broad language about improving the service?
  • Access: which staff and subprocessors can open a file, is it encrypted in transit and at rest, and is access logged?
  • Change: how will the vendor give notice if any of those terms move?

The last question has regulatory weight. FTC staff warned in February 2024 that quietly rewriting terms to permit AI training may be unfair or deceptive. Institutions covered by the FTC Safeguards Rule must also oversee service providers by selecting capable ones, requiring safeguards by contract, and periodically assessing them. Compliance should confirm which safeguarding rules apply to the institution.

Redacting first is a poor workaround. Any edit changes the file, so the checker ends up examining the redaction, and text that looks removed can remain recoverable inside a PDF. Where the answers are missing, restrict testing to non-sensitive samples.

What to Do With a Suspect File

  1. Preserve the original. Store an untouched copy, record its SHA-256 hash, and work only from a duplicate.
  2. Clear the upload against the retention, training, and access questions above.
  3. Run a baseline: a known-genuine file of the same type from the same issuer.
  4. Test the tool itself. Run a genuine file that was legitimately re-saved and see whether the tool reports a re-save or calls it a forgery.
  5. Run the native suspect file, unprinted and unconverted. The Watchdoc playground is one way to see a verdict with its evidence.
  6. Read the finding before the number, including the class and the field affected.
  7. Confirm the facts with the issuer or another independent source.
  8. Record the file hash, the finding, the outside confirmation, and who decided, then follow the team's SOP to clear, challenge, or escalate.

A request for a fresh export sent directly from the issuer's portal is a fair next step when a finding remains unexplained. A genuine customer can usually produce one.

Where Sphinx Fits

Watchdoc runs six checks on a file: production method, timestamp trail, issuer matching, consistency, model artifacts, and recycled patterns. Sphinx prepares the evidence and a traceable recommendation, and the team keeps final approval. That approval matters: Sphinx's published 94.3% correct verdict still leaves 5.7% of verdicts wrong. Clean files clear in under 28 seconds, and pricing is $0.45 per document with no seats or platform fee. Watchdoc examines the file. It does not verify a person's face or connect to bank accounts, so independent confirmation stays with the team. The free playground covers 50 documents with no card required, and the upload questions above apply to it as they would to any other tool.

Frequently Asked Questions

Can a fake document checker prove a document is fake?

A checker can show that a file was altered after creation or could not have come from the claimed issuer, which is strong evidence. It cannot read intent, and it cannot prove that a clean-looking file is genuine. Treat the result as evidence to confirm with the issuer.

How accurate is a PDF document fraud detection tool?

Accuracy depends on document type, file quality, and how common fraud is in the population tested. A team should test a tool on its own known-genuine and known-altered files. Even a high accuracy rate can produce more false alarms than true finds when fraud is rare.

Is it safe to upload a bank statement to an online document checker?

Safety depends on the tool's retention period, training terms, access controls, and contract. A team should get written answers on each point before uploading customer data, and use non-sensitive samples until it has them.

Does a fake document detection app work on photos?

Partly. A photo or screenshot removes the file's production history, fonts, and digital signatures, so checks that depend on those signals cannot run. Reuse detection and some image-based checks can still work, and the result should state which checks were unavailable.

What should a team do when a checker finds nothing wrong?

The team should treat the result as one input. For a material decision, it should still confirm key facts with the issuer or another independent source, because an unaltered file can still describe something untrue.