Altered Paystubs and W-2s: The Forensic Layer Mortgage Underwriting Misses

A borrower applies for a mortgage and submits two recent paystubs and last year’s W-2. The year-to-date earnings on the paystubs track the W-2. The pay-period math reconciles. The employer name matches the application, the federal and state withholding lines look right, and the net pay flows cleanly to gross. Your processor runs the file against the underwriting checklist, finds the income fully documented, and clears it for the next stage.

Every step of that review was done correctly. And the income documents could still be inflated.

The reason is that the verification checklist confirms whether the numbers on the page are plausible. It was never built to confirm whether the PDF itself was edited after the employer’s payroll system produced it. Those are two different questions. A borrower who downloads a real paystub, opens it in an editor, and types a larger figure over the original defeats the second question entirely — while sailing through the first.

This article walks through how mortgage underwriters actually verify income today, exactly where that process breaks on a well-altered paystub or W-2, and the structural forensic layer that closes the gap. It is written for underwriting and risk operations teams at mortgage and consumer lenders, with a short integration section at the end for the people who wire it in.

How Do Mortgage Underwriters Verify Income Today

Income verification is one of the most disciplined parts of mortgage underwriting, and for good reason: income drives the debt-to-income ratio, and the DTI drives the approval. No single document carries the decision. Underwriters stack several controls and look for them to agree.

Read the paystubs against the pay cycle. The underwriter confirms gross pay, pay frequency, and year-to-date earnings, then checks that the YTD figure is consistent with the pay rate and the number of pay periods elapsed. A salaried borrower paid twice a month should show YTD earnings that match their stated salary. Numbers that do not add up across the period get flagged.

Reconcile the paystub to the W-2. Last year’s W-2 should agree with the prior pay history. Box 1 wages, the employer’s name and EIN, and the withholding lines are cross-checked against the paystubs and the application. A W-2 that disagrees with the borrower’s own pay record is a problem the underwriter is trained to catch.

Verify employment at the source. This is the strongest control, and most lenders run some version of it. A verbal or written Verification of Employment (VOE) confirms the job, the title, the pay, and the start date directly with the employer. Many lenders pull an automated VOE through a service like The Work Number, which returns employer-reported income and employment data without the borrower handing over a document at all.

Pull a tax transcript. Through a signed 4506-C authorization, the lender requests IRS tax transcripts and compares the reported income against the documents in the file. Because the transcript comes straight from the IRS rather than from the borrower, it is one of the few checks a forger cannot tune in advance.

Call the employer directly. When something doesn’t reconcile — or for self-employed and commission income — underwriters still pick up the phone, confirm the company is real, and validate the income with someone in payroll or HR.

Each of these is a genuine, valuable control. Stacked together they catch a great deal of fraud: clumsy fakes, employers that don’t exist, income that doesn’t reconcile, paystubs that contradict the transcript. The question is not whether this process works. It is what it was built to verify — and where the uploaded PDF slips between the controls.

The Gap Source-of-Truth Checks Leave Open

The Work Number and 4506-C tax transcripts are the right answer to income fraud whenever they apply, and it would be dishonest to suggest otherwise. When an employer reports into The Work Number, the lender reads income straight from the payroll provider — no borrower-supplied document is involved, so there is nothing to edit. When the IRS transcript comes back and matches, the income is corroborated by a source the borrower never touched. Keep both. HTPBE? does not replace either one.

But these source-of-truth checks have coverage and timing boundaries, and income fraud concentrates exactly at those boundaries.

• Not every employer is in The Work Number. The database is large but finite. Smaller employers, many self-employed borrowers, gig and 1099 earners, and people who recently changed jobs often are not covered — and when there is no automated record, the lender falls back to the documents the borrower uploaded.
• Tax transcripts lag and add friction. A 4506-C transcript reflects the prior tax year and can take time to come back. For a current-year income picture — this year’s raises, a new job, recent overtime — the transcript does not have the data yet, so the underwriter relies on recent paystubs to fill the gap.
• Self-employed and variable income. Commission, bonus, and self-employment income often cannot be confirmed by a single automated lookup, so the file relies more on borrower-provided documents and the underwriter’s reading of them.
• Process timing. Pre-approval and early underwriting decisions are often made on the documents in hand before every source-of-truth check has cleared, to keep the loan moving.

In every one of these cases, the lender is back to a human reviewing an uploaded paystub or W-2 PDF — the exact scenario where content checks can’t see an edit. The source-of-truth checks remove the document for the borrowers they cover. For everyone else, the document is the evidence, and its integrity goes unchecked. KYC and identity platforms do not fill this gap either: they confirm who is applying — ID match, watchlist, face check — not whether a submitted income PDF was altered.

The One Thing the Checklist Doesn’t Verify

Read the verification list again and notice the common thread: every control either confirms the numbers on the page are plausible, or reaches outside the document to a source. When the source-of-truth path is not available and the underwriter is left with the uploaded file, all that remains are content checks — and content checks ask one question: “Could a real payroll run have produced these figures?”

None of them ask the other question: “Was this file edited after payroll generated it?”

That is the gap a careful forger lives in. Consider the most common income-document fraud in lending:

1. The borrower downloads their real paystub PDF from their employer’s payroll portal — ADP, Workday, Paychex, Gusto.
2. They open it in a desktop or online PDF editor.
3. They type a higher gross over the original, adjust the year-to-date line to match, and recompute the net so the math reconciles.
4. They re-save and upload it as their income documentation.

The result is a document built on the employer’s real template, in the right fonts, with the payroll provider’s real layout — and, critically, the forger had every chance to make the edited numbers internally consistent. They can raise the gross and adjust YTD so the period math still works. They can pick a figure that supports the DTI they need without tipping into the implausible. A patient borrower produces a file that passes every content check on the underwriter’s list, because the content was tuned specifically to pass those checks.

Fabricated W-2s work the same way. A borrower starts from a real W-2 or a template, edits Box 1 wages and the withholding lines, and exports a clean-looking form. On screen, an edited figure looks exactly like an original one — the editor renders it in the same font, at the same position. The human eye has nothing to catch.

This is why income-document fraud is so persistent. One widely cited industry study found that roughly one in ten paystubs submitted to lenders as proof of income is fake, and other lenders report the share running as high as one in five. Tools to generate a fake paystub are openly marketed online for a few dollars, and the average fabricated stub takes only a few minutes to produce — some sites even offer phone confirmation when a lender calls to verify. These documents are easy to obtain, simple to edit, and — once edited carefully — invisible to a process designed to verify content rather than file integrity.

The Missing Layer: Structural File Forensics

A PDF is not a flat picture. It is a structured file that carries an internal record of how it was built and saved — when it was created, what software produced it, whether it holds a digital signature, and how many times it was written to disk. When someone opens a payroll system’s original PDF and saves an edit, that act leaves traces in the file’s structure, no matter how plausible the visible numbers are.

Structural forensics reads that internal record and returns a verdict. It never judges whether a $9,000 monthly gross is a believable salary — that’s the underwriter’s job and the content layer’s job. It judges whether the file’s own construction is consistent with a clean, single-pass export from a payroll system, or whether it bears the marks of having been opened and re-saved in an editing tool after the fact.

HTPBE? is a self-serve API that performs exactly this analysis. You send it a PDF; it returns one of three verdicts plus a list of named markers describing what it found. It is not a KYC or identity vendor and was never meant to be one — it answers a single, narrow question: was this file altered after it was created?

The three verdicts

• intact — no evidence of post-creation modification, and the file looks like a genuine institutional export. The structural layer found nothing to flag.
• modified — the file carries forensic evidence that it was changed after it was first generated. This is the case that matters most for fraud: a paystub that should be a clean payroll export but instead shows the fingerprints of an editing session.
• inconclusive — the file was produced by consumer software, an online editor, or a scanner, so there is no institutional baseline to check integrity against. This is not a pass. It is a routing signal, and in income verification it is often the most useful verdict of all (more on that below).

What it actually catches — in plain terms

Without turning this into a how-to for forgers, here is the kind of structural evidence the analysis surfaces, described as outcomes rather than recipes:

• Editing-tool fingerprints. Genuine paystubs and W-2s are produced by server-side payroll systems. When a file instead carries the signature of a consumer PDF editor or an online conversion service, that origin is inconsistent with a real payroll pipeline. The marker HTPBE_EDITING_TOOL_FINGERPRINT flags this.
• Disagreeing internal timestamps. A clean export’s creation and modification timestamps line up. When they contradict each other — the file claims to have been created on one date but was last written days later — that gap is recorded in the file structure even though it is invisible on the page. HTPBE_DATES_DISAGREE covers this.
• Multiple revision layers. Each time a PDF is edited and saved, the change is appended as a new layer on top of the original. A document that should have been generated in a single pass but instead shows several stacked write sessions reveals that it was modified after creation. The marker is HTPBE_MULTIPLE_REVISION_LAYERS.
• A spoofed institutional producer. Some tools try to disguise their involvement by rewriting the file’s stated generator to impersonate a legitimate payroll or institutional system. When that producer identity has been forged to mask the real origin, the analysis flags it with HTPBE_PRODUCER_IDENTITY_FORGED.
• Tampering around a digital signature. Where an income document is digitally signed, the analysis detects content changed after signing (HTPBE_POST_SIGNATURE_EDIT) or a signature stripped off entirely (HTPBE_SIGNATURE_REMOVED). These are among the most conclusive signals there are.

None of these depend on the visible numbers being implausible. A perfectly reconciled, perfectly tidy inflated gross still sits inside a file that was edited — and the edit is what gets caught.

Want to see it on a real document? You can drop a paystub or W-2 into the free check on this site and get a verdict in a few seconds — no account needed. It’s the same engine the API runs, and it’s a fast way to sanity-check a single suspicious income document before you decide whether to wire it into your intake.

What inconclusive Means in an Income-Verification Context

The inconclusive verdict is the one that confuses people, so it is worth being precise.

inconclusive means the file was created in software that anyone can use to build a document from scratch — Word, Excel, an online editor, a scanner. Because there is no institutional baseline, the structural layer cannot say whether the content was tampered with. It is telling you, honestly, “I cannot verify integrity here.”

The power of that verdict comes from context — specifically, where the document claims to come from.

Major payroll providers generate paystubs and W-2s on server-side systems. A document that genuinely came from ADP, Workday, Paychex, or a comparable provider should look like an institutional export. So if a borrower hands you a paystub claiming to be from a large employer running a major payroll platform, and the analysis returns inconclusive because the file was actually built in a word processor or run through an online editor, the verdict is doing real work: a real paystub from that system would not look like that. That mismatch is a reason to escalate to a VOE or an employer call — not to approve the file without question.

The same inconclusive verdict on a paystub from a tiny employer who genuinely runs payroll through a spreadsheet, or a self-employed borrower’s own profit-and-loss export, is routine. The verdict is identical; the action depends on whether the claimed source is supposed to produce institutional files. Used this way, inconclusive is not a dead end — it is often the signal to fall back to the source-of-truth check the document was standing in for.

Honest Limits — What This Layer Cannot Catch

Structural forensics is a powerful additional control, not a fraud oracle. Two scenarios sit outside its reach, and a serious underwriting team should know them.

Documents fabricated entirely from scratch in the right kind of software. If a forger does not edit a real paystub but instead builds a fake one from zero using a tool that produces institutional-looking output — or uses one of the many paystub-generator sites that emit a clean single-pass PDF — there is no “original” to compare against and no editing event to detect. The file may look clean structurally because, structurally, it is a clean single-pass file; it just contains invented data. This is precisely where The Work Number, a 4506-C transcript, and a direct employer call remain the right controls: they corroborate the income against a source the borrower never touched. The structural layer’s strength is the far more common case — editing a real document — not fabrication from nothing.

Legitimately consumer-generated income documents. Some small employers really do produce paystubs through generic office software, and self-employed borrowers legitimately export their own records. For those, inconclusive is the correct and expected verdict, and reading it as guilt would generate false positives. The signal only carries weight when the claimed source has an institutional baseline to deviate from.

Being upfront about these limits is the point. The structural layer is designed to slot alongside your existing verification process — catching the altered-PDF case that content checks, The Work Number gaps, and lagging transcripts can’t see — not to be a single switch that decides loans on its own.

Wiring It Into Your Income-Verification Workflow

For teams that decide the structural layer belongs in their intake, integration is deliberately small. The pattern is three steps.

1. Analyze the uploaded document. When a borrower uploads a paystub or W-2, send its URL to the analyze endpoint. There is no numeric risk score to interpret — you get a verdict and named markers.

curl -X POST https://api.htpbe.tech/v1/analyze \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://your-storage.example.com/income/applicant-7821-paystub.pdf"}'

The response is just the check ID:

{ "id": "506a6b1b-1360-48a2-b389-abb346f85d04" }

2. Fetch the verdict. Retrieve the result by ID. The response is a flat object — the two fields your policy cares about are status and modification_markers.

curl https://api.htpbe.tech/v1/result/506a6b1b-1360-48a2-b389-abb346f85d04 \
  -H "Authorization: Bearer YOUR_API_KEY"

{
  "status": "modified",
  "modification_markers": ["HTPBE_EDITING_TOOL_FINGERPRINT", "HTPBE_DATES_DISAGREE"],
  "modification_confidence": "certain"
}

3. Route on the verdict. Wire the three outcomes into your existing review queue rather than auto-deciding on any single marker:

• modified → route to manual review, require a source-of-truth confirmation (VOE, The Work Number, or a 4506-C transcript) before the income counts, or — for the most conclusive markers like a post-signature edit — reject.
• inconclusive → branch on the claimed source. A consumer-software origin on a paystub claimed to be from a major payroll platform is worth escalating to an employer call; the same verdict from a small employer or a self-employed borrower is routine.
• intact → no structural evidence of alteration; proceed with your normal income verification.

Store the check ID against the loan file. If a credit decision is ever disputed or audited, the forensic result stays available as a permanent record showing exactly which structural signals fired — useful for both compliance and repurchase defense.

Who Should Add This Layer

If you run underwriting or fraud operations at a mortgage lender, a consumer lender, or any shop where a meaningful share of borrowers upload paystub and W-2 PDFs — especially where The Work Number doesn’t cover the employer or the income is current-year and the transcript hasn’t caught up — this is the gap in your stack worth closing. Your underwriters are already verifying income well. What they cannot see, by design, is whether the file in front of them was edited after payroll produced it. That blind spot is exactly where careful borrowers operate, and it’s exactly what a structural layer covers.

For the closely related case of altered bank statements — the other document borrowers most often edit — see how lenders verify bank statements and the forgery layer they miss. When you’re ready to put a verdict behind your income intake, the self-serve API is documented end-to-end with test keys you can wire up before you spend a credit.