# The Forged Document Problem AI Made Worse, and the Detection Desk That Answers It

*October 22, 2026 · 6 min read · Ramkumar Venkataraman*

> A paystub edited in a browser tab used to need a steady hand. Now it needs a prompt. The volume of altered and fully synthetic income and asset documents hitting mortgage intake is rising because the tools to make them got free and good, and the human eye that used to catch the clumsy ones is no match for the clean ones. What a document-authenticity agent actually checks beyond reading the numbers, why the detection model is itself governed under SR 11-7, and where catching a forgery becomes a SAR obligation rather than a decline.

## The Day the Fakes Got Clean

For most of the history of mortgage, a forged paystub was a human artifact. Someone opened the PDF, fought the font, nudged a number, and left evidence: a misaligned column, a tax that no longer foots, a date that fell on a Sunday. A processor who had seen ten thousand real paystubs caught the clumsy ones by feel, and the clumsy ones were most of them.

That era is over, and it ended because the tools to produce a clean fake stopped requiring skill. A borrower, or a broker helping a borrower, can now generate a paystub or a bank statement that fonts correctly, foots correctly, and carries a plausible deposit history, in less time than it takes to describe the fraud. The clumsy fakes still arrive, and now the clean ones arrive alongside them, and the clean ones pass the human review that was the last line of defense. This is a document-authenticity problem that got materially worse in the span of a couple of years, and the mortgage fraud post we wrote earlier was explicit that [most origination fraud is not a forged document](/blog/ai-mortgage-fraud-detection-origination-misrepresentation-fincen-red-flags). That is still true for the pattern-level fraud it covered. The forged document, as a category, is the one that changed.

## Why Reading the Numbers Is Not Checking the Document

An extraction agent that reads a paystub tells you what the document says. It does not tell you whether the document is real, and those are different questions answered by different machinery. A synthetic paystub reads perfectly, because the whole point of a synthetic paystub is that the numbers are internally consistent. If your defense is "the income extracts cleanly and clears the ratio," you have no defense against the clean fake, because the clean fake is designed to clear exactly that check.

Authenticity is a separate inspection, and it looks at the artifact rather than the content. The document's own file structure carries history: a PDF produced by a payroll processor has a creation fingerprint, a software producer tag, and an object structure that differs from a PDF that was opened and re-saved from an editor. A statement downloaded from a bank's portal has properties that a statement assembled by hand does not. None of this is visible when you read the numbers, and all of it is evidence about whether the document is what it claims to be.

So the authenticity agent runs checks the extraction agent never does. It reads the file's metadata and producer chain for signs of editing after the fact. It checks internal arithmetic that a forger often forgets, so that the net pay reconciles to gross minus the itemized deductions and the year-to-date figures are consistent with the pay period and the pay date. It compares the document against other documents in the same file, because a forger building a paystub in isolation rarely keeps the employer name, address, and pay frequency consistent with the verification of employment and the application. The file is a system, and a document fabricated outside that system leaves seams where it meets the rest of it.

## The Cross-Document Check Is the One That Works

Single-document forensics catches the sloppy fakes, and the clean fakes defeat single-document forensics by construction, so the detection that actually holds up is cross-document and cross-source. The one record a borrower cannot easily forge is the one they do not control.

We build the authenticity agent to resolve claims against sources the borrower does not author. The deposits on a bank statement should correspond to the net pay on the paystubs, in amount and cadence, so a paystub that says one thing and a deposit history that says another is a contradiction the agent surfaces even when each document is individually clean. Employment on the paystub should match an independent verification of employment rather than a number the borrower typed. [Asset sourcing](/blog/verification-of-assets-large-deposit-sourcing-ai-underwriting-fannie-bsa) that traces a large deposit to a documented origin is harder to fake than a statement that merely shows the balance. The agent's strongest signal is not any one document's internal consistency, it is the agreement or disagreement across documents and against outside sources, because fabricating a self-consistent single document is now easy and fabricating a self-consistent whole file against independent verification is still hard.

The output is not a verdict of fraud. It is an authenticity finding with the specific anomaly named and the documents it sits between cited, scored for confidence, and routed the way every other finding routes: above the lender's threshold it clears, below it the file goes to a human as a named exception with the conflicting evidence attached. The agent flags. A person decides what the flag means, because the distance between an anomaly and an accusation is a judgment with consequences for a borrower, and that judgment stays human.

## Why the Detector Is a Model Under Governance

A fraud detector is a model, and a fraud detector has two ways to be wrong that a lender has to govern deliberately. It can miss a real forgery, which is the risk everyone thinks about, and it can flag a genuine document as suspect, which is the risk that quietly harms real borrowers and is the one that produces fair-lending exposure if the false positives land unevenly. Both error rates are properties of the model, and we treat the detector as a model under [SR 11-7](/blog/model-risk-management-ai-agents-sr-11-7-nist-rmf) for exactly that reason.

That means the detector's performance is measured and documented on both kinds of error, the confidence threshold that decides what routes to a human is a governed control the lender owns rather than a dial an engineer turns, and the thing is monitored for drift, because forgery techniques move and a detector tuned to last year's fakes decays. A detection model that is never re-measured is a control that is slowly turning off, and the only way to know is to have built the measurement in from the start. The same confidence-scoring discipline that governs [document classification and extraction](/blog/mortgage-document-classification-extraction-ai-model-governance-confidence-thresholds) governs authenticity, because an authenticity score a reviewer cannot see is not a control, it is a guess the system made and hid.

## Where a Decline Becomes a Filing Obligation

Catching a forgery is not only a credit decision, and the lender that treats it as only a credit decision misses a legal duty. Many mortgage lenders and originators are subject to an anti-money-laundering program and suspicious-activity reporting requirement under the FinCEN rule at [31 CFR 1029](https://www.ecfr.gov/current/title-31/subtitle-B/chapter-X/part-1029), and a fabricated income or asset document is a textbook basis for a suspicious-activity report. Separately, the Red Flags Rule at [12 CFR 1022 subpart J](https://www.ecfr.gov/current/title-12/chapter-X/part-1022/subpart-J) requires covered institutions to have a program to detect and respond to patterns and practices that indicate identity theft, and a document whose identity markers do not reconcile can be one of those red flags.

So when the agent surfaces a document that appears fabricated, two paths open, not one. There is the credit path, where the file is declined or conditioned, and there is the regulatory path, where the facts may require a SAR and where the lender's identity-theft program may require a response. The agent does not file the SAR and does not make the legal determination, because those belong to the lender's BSA officer and its program. What the agent does is make sure a fabricated document is not quietly resolved as a plain decline that closes the file and files nothing, because that is how a reporting obligation gets missed, and the missed filing is a finding of its own, separate from the fraud.

## The Data-Handling Line, Because This Is the Most Sensitive File There Is

An authenticity desk reads Social Security numbers, account numbers, and full income and asset histories, which puts it squarely inside the [GLBA Safeguards Rule](https://www.ecfr.gov/current/title-16/chapter-I/subchapter-C/part-314). The agent's access to that data is scoped, logged, and encrypted, the detection model is never trained on the lender's customer data in a way that leaks it, and the vendor relationship sits inside the lender's third-party risk program rather than beside it. A fraud detector that itself handles data carelessly has traded one exposure for another.

## The Honest Read

The forged document was a solved problem when forgery took skill, and it is an unsolved problem now that it takes a prompt, which means the control that relied on the human eye needs rebuilding rather than tuning. The rebuild is not a better reader of numbers, because the clean fake is designed to read well. It is a separate authenticity inspection that checks the artifact, reconciles the file against itself, and resolves claims against sources the borrower does not control, governed as the model it is and wired to the filing obligations a fabricated document can trigger. We built this as a distinct desk at Sei rather than a feature of extraction, because the question "what does this document say" and the question "is this document real" are different questions, and the second one is the one that got harder.

---

_Source: [https://seiright.com/blog/ai-document-fraud-detection-synthetic-altered-paystubs-bank-statements-red-flags-rule](https://seiright.com/blog/ai-document-fraud-detection-synthetic-altered-paystubs-bank-statements-red-flags-rule) · Sei AI_