Auto F&I Fraud: Forged Pay Stubs in Dealer Financing

A buyer walks onto a subprime lot on a Saturday afternoon. The income on the credit app is $3,200 a month — not enough to clear the lender’s 50% DTI threshold on the SUV they want. The F&I manager asks for two recent pay stubs and a bank statement showing reserves. The buyer emails them over by Sunday morning. Gross monthly income on the stubs: $5,800. The bank statement shows a healthy running balance with consistent direct deposits. The deal is structured, the contract signed, the keys handed over on a spot delivery. The dealer submits the contract through Dealertrack on Monday.

Six weeks later the captive lender flags the loan. The employer has no record of the buyer at that pay rate. The bank statement was edited — running balance figures were typed over the originals before upload. The unwind notice goes to the dealer. The car is 800 miles away with a buyer who has already missed the first payment.

This pattern accounts for a substantial share of document fraud loss in US consumer lending. The National Automobile Dealers Association and PointPredictive put annual exposure on auto F&I fraud at well over $7B, with subprime and near-prime credit tiers carrying most of the loss. Sophisticated synthetic-identity operations exist on the higher-loss end, but the bulk of the volume is straightforward: a real PDF from an ADP or Gusto portal, opened in a consumer editor, with a few numbers typed over.

Why the captive lender carries the loss

Indirect auto lending puts the lender one party away from the document. The dealership’s F&I office collects the stip docs — pay stubs, bank statements, proof of residence, sometimes a utility bill — and forwards them through Dealertrack, RouteOne, or DealerSocket. The dealer’s incentive is to close the deal and move the unit off the lot. The lender’s incentive is to verify the income figure that supports the DTI calculation underwriting just relied on.

Those two incentives diverge sharply on a marginal credit application. A dealer F&I manager who pushes back on a buyer’s stip doc loses the deal to the dealership across the street that doesn’t. The lender that bought the contract is left to discover the alteration weeks later, when the buyer misses a payment and the verification call to the employer comes back wrong.

Spot deliveries make the math worse. When the vehicle leaves the lot before the lender’s final approval — standard practice on subprime tiers in most US states — an unwind requires the dealer to recover the car, refund the down payment, and absorb the depreciation. Many dealers swallow the loss instead and push the contract through to fund. The lender finds out only when the loan starts performing badly.

The point in the workflow where the structural forensics check belongs is at stip-doc receipt, before the credit decision is finalized and before the funding wire goes out. Not at the dealership — at the lender, the moment the PDF lands in the indirect lending platform’s queue.

What buyers actually edit

Three patterns cover the vast majority of forged auto stip docs.

Gross income inflation on pay stubs. The buyer downloads a real pay stub from their employer’s ADP, Gusto, Paychex, or Workday portal. They open it in Adobe Acrobat, a free online editor, or sometimes in Excel via a PDF-to-XLSX converter and then re-export. They overtype the gross-pay and year-to-date figures. They do not recalculate the net pay, the tax withholdings, or the YTD totals from prior periods — the math no longer ties, but no underwriter doing a visual review notices because the numbers individually look plausible. This single edit lifts the credit app from declined to approved on a marginal DTI.

Running balance inflation on bank statements. Same pattern. The borrower pulls a real PDF from their bank’s online portal, opens it, and types over the running balance column. They may also add a fictitious deposit line or remove an overdraft row. The transactions don’t reconcile if anyone adds them up, but a 12-page statement with hundreds of rows rarely gets that scrutiny in F&I. The mechanics are the same ones covered in bank statement fraud in lending and the KYC PDF blind spot.

Address forgery on proof-of-residence documents. A utility bill or bank statement is altered to show an address the buyer doesn’t actually live at — usually to qualify for a lender’s geographic eligibility, garaging requirements for insurance, or to defeat skip-tracing if the loan defaults. The edit is typically just the address block, replaced or overlaid with a new text object.

None of these alterations are technically difficult. The free version of the most popular online PDF editor handles all three in under a minute. The fraud doesn’t require a forger’s skill — it requires a borrower who knows the lender will accept whatever PDF the dealer forwards.

Where the visible page hides the edit

A spot check on the rendered PDF tells you almost nothing. The font is the employer’s real payroll font, because it came from a real pay stub. The logo is the bank’s real logo. The layout is correct. Visual review catches sloppy fraud — misaligned columns, the wrong typeface, a logo blurred from being re-rasterized. It doesn’t catch the borrower who opened a legitimate document in a mainstream editor and typed over three numbers.

The evidence lives in the file’s structural layer. When the editing software saves the PDF, it leaves a fingerprint — the software writes its own name into the producer field, appends an incremental update to the cross-reference table, and sets a new modification timestamp that doesn’t match the creation timestamp the original payroll system wrote. None of this is visible on the rendered page. All of it is reliably checkable in the underlying bytes.

If you want a quick look on a sample file before reading further, the free PDF authenticity check on the home page runs the same forensic analysis on any PDF up to 10 MB and returns the verdict in seconds. It’s the same engine that runs behind the API — useful for spot-testing the kind of stip docs your portfolio actually sees.

What structural forensics catches on auto stip docs

A few categories of structural evidence cover most editing patterns.

Generator identity mismatch. ADP, Gusto, Paychex, and Workday all generate pay stub PDFs from server-side rendering engines that identify themselves in the producer and creator fields. The major retail banks do the same with statements. When the producer field on a pay stub claimed to be from ADP shows the name of a consumer PDF editor instead, the document was opened and re-saved somewhere between the payroll portal and the dealer’s inbox. The corresponding public marker in the API is HTPBE_TOOL_VS_STRUCTURE_MISMATCH.

Incremental update layers. A PDF saved fresh from a payroll or banking system typically has a single revision layer. Every time the file is opened and re-saved in an editor, the editor appends an incremental update — a new cross-reference table and the modified objects, written after the original end-of-file marker. Multiple revision layers on a stip doc claiming to be a fresh portal export are strong evidence that the file passed through additional save events after it left the originating system. The marker is not, on its own, proof of malicious editing: some enterprise pipelines legitimately re-save PDFs — document management systems that strip embedded JavaScript, e-signature platforms that append signature objects, scan-to-PDF appliances that re-emit with metadata cleanup — and these produce additional layers in the normal course of business. Interpretation depends on the claimed origin: a fresh ADP export should not have three revision layers; a contract that went through DocuSign and an OCR pass legitimately will. The public marker is HTPBE_MULTIPLE_REVISION_LAYERS.

Date disagreement. A clean export has its creation date and modification date within seconds of each other — the payroll system writes both at generation time. A document edited after export shows a gap between the two timestamps, often days. The public marker is HTPBE_DATES_DISAGREE. The size of the gap, the relationship to the credit application date, and the day-of-week pattern are all usable signals downstream.

Selective identity editing. A more deliberate forger strips or rewrites the producer string to hide the editing tool. When the metadata layer shows partial overwrites — some fields edited, others left intact — the structural inconsistency is itself the signal. The public marker is HTPBE_SELECTIVE_IDENTITY_EDIT.

Multiple markers firing on the same document compound confidence. A pay stub with HTPBE_TOOL_VS_STRUCTURE_MISMATCH plus HTPBE_MULTIPLE_REVISION_LAYERS plus a four-day HTPBE_DATES_DISAGREE, claimed to be a direct ADP portal export, is hard to reconcile with any benign workflow — the combination is what tightens the conclusion, not any single marker on its own.

What an API response looks like on a forged pay stub

A representative HTPBE? response on an ADP pay stub where the buyer inflated gross monthly income from $3,200 to $5,800 using a free online editor:

{
  "id": "ck_8a1f2c4e-3b7d-4e8f-91a2-6c0d5e9f7b3a",
  "status": "modified",
  "modification_confidence": "high",
  "modification_markers": [
    "HTPBE_TOOL_VS_STRUCTURE_MISMATCH",
    "HTPBE_MULTIPLE_REVISION_LAYERS",
    "HTPBE_DATES_DISAGREE"
  ],
  "creator": "ADP Payroll",
  "producer": "iLovePDF",
  "xref_count": 3,
  "has_digital_signature": false,
  "creation_date": 1750636800,
  "modification_date": 1750982400
}

The creator field is the original payroll system. The producer field is a consumer online editor that has no place in any documented payroll distribution pipeline. Three revision layers indicate the original generation plus two subsequent saves. The modification timestamp trails the creation timestamp by four days — the borrower received the legitimate stub on a Wednesday and edited it on the following Sunday before sending it to the F&I office.

The verdict is modified with high confidence. In practice that is a queue-routing signal, not a decision: the credit risk team can hold the application for manual review, request a fresh stub pulled directly from the employer’s portal in a verified session, or escalate to a payroll-API or Work Number lookup. How aggressively a modified verdict is acted on belongs to the lender’s credit policy — it depends on tier, deal size, and the existing manual-review capacity. The forensic check produces evidence; the policy decides what to do with it.

Integration at stip-doc intake

The check belongs at the moment the indirect lending platform receives the stip docs from the dealer, before the credit decision is finalized and before any funding instruction is generated. One synchronous call per document.

import requests

def check_stip_doc(pdf_url: str, application_id: str) -> dict:
    response = requests.post(
        "https://api.htpbe.tech/v1/analyze",
        headers={"Authorization": f"Bearer {HTPBE_API_KEY}"},
        json={"url": pdf_url},
        timeout=15,
    )
    response.raise_for_status()
    result = response.json()

    # Store the check_id against the application for audit trail
    log_forensic_check(application_id, result["id"], result["status"])

    if result["status"] == "modified" and result["modification_confidence"] == "high":
        route_to_manual_review(application_id, result["modification_markers"])
    elif result["status"] == "inconclusive":
        flag_for_secondary_verification(application_id)

    return result

The response is synchronous for most documents under 10 MB. Store the id against the application record — if the loan later goes bad and the originating documents are reviewed, the forensic report is retrievable as a permanent audit trail showing exactly which structural signals triggered the hold. That matters for both internal credit committee review and for any chargeback or repurchase dispute with the dealer.

Full reference documentation and the test scenarios for synthetic responses are at the API page. Volume pricing for indirect lending platforms with stip-doc volume in the tens of thousands per month is on the pricing page.

Calibrating for production: false positives, queue volume, funding speed

The realistic question for a Director of Fraud Operations is not whether the check detects edits — it is what happens to throughput, funding speed, and the manual-review queue once the check is live in production. A few patterns to plan for.

Base-rate planning assumptions. A reasonable planning band for the share of stip docs that return modified with high confidence is roughly 4–12% on subprime tiers and 1–3% on prime, with another 8–15% landing in inconclusive — dominated by scan-to-PDF, mobile-camera-wrapped JPEGs, and re-emits through DMS middleware rather than malicious editing. These are modelling assumptions for capacity sizing, not industry benchmarks; the actual distribution is portfolio-specific. Running the check against a recent funded sample before turning it on is the only way to calibrate accurately for a given book.

Manual-review queue impact. If structural verdicts are wired straight to a hold queue, an indirect platform processing 12,000 stip docs a month at subprime concentration would, under the planning band above, add roughly 480–1,400 modified and 960–1,800 inconclusive documents per month into manual review — a non-trivial operational load. Teams generally tier the response: modified with multiple markers and an institutional-claimed origin routes to hold; a lone HTPBE_MULTIPLE_REVISION_LAYERS with no corroborating marker routes to a lighter check or soft-flag for portfolio monitoring; inconclusive is logged for audit and used alongside the existing income-verification stack.

Funding-speed impact. The API call adds 1–4 seconds per document on typical stip-doc sizes — on a three-document deal, sub-15-second added latency on the synchronous path. In most indirect workflows this is unlikely to be the binding SLA constraint. The bottleneck is review-desk capacity on held deals, not the API itself; that is the number to size during rollout.

Tier-dependent precision. Marker precision is not uniform across portfolios. On prime tiers, where the underlying fraud rate is low, a larger share of modified verdicts come from legitimate re-emits (payroll vendor changes, bank app re-issues, DMS re-saves). On subprime the inverse holds — positive predictive value is higher because the prior on intentional editing is higher. A hold-everything rule applied uniformly will reject more legitimate prime deals than it catches subprime fraud; the credit policy should tier with the portfolio.

Rescanned and re-emitted documents. A buyer who prints a real pay stub, scans it back to PDF on an office MFP or a phone scanning app, and submits the scan produces a document with no editing fingerprint and no institutional origin signal. Verdict is inconclusive. This pattern is common in markets where digital portal access is uneven, and benign — the document is real, just laundered through paper. Treating inconclusive on a claimed-institutional source as an automatic decline produces high false-positive rates and disparate-impact exposure. Route to secondary verification, not decline.

Mobile-upload workflows. Buyers increasingly send stip docs from a phone — either exported from the payroll app and uploaded through the F&I portal, or photographed and wrapped in a PDF. The first case looks structurally identical to a desktop export and the check runs normally. The second case is the screenshot-wrapped pattern: inconclusive, secondary verification rather than auto-decline. A planning assumption of 5–10% of subprime mobile-channel stip docs landing in this bucket is a reasonable starting point until production data refines it.

What this does not catch

Structural forensics detects modifications to existing documents. Two scenarios fall outside its scope and produce inconclusive rather than modified.

Synthetic stubs built from scratch. A synthetic-identity fraud ring with the operational sophistication to build a fake pay stub from a blank template in the same software a payroll system uses will produce a document with no editing fingerprint. The structural layer will look consistent because there is no prior structure being overwritten. This is rare relative to the volume of opportunistic borrower edits, but it does happen on the higher-loss tiers. The control for this pattern is direct employer verification — The Work Number, a payroll API integration, or a callback — not structural document analysis.

Screenshot-wrapped pay stubs. A buyer who screenshots a pay stub on their phone and wraps the JPEG inside a PDF using a mobile app produces a single-image PDF. The structural layer shows a JPEG inside a thin PDF wrapper with no editing history because there is no editable text layer to edit. Verdict on this pattern is inconclusive, not modified — the document carries no structural evidence of alteration, but it also carries no structural evidence of institutional origin. In an auto-lending context, an inconclusive verdict on a stub claimed to be from ADP or Gusto is itself a signal worth escalating, because legitimate payroll portals emit institutional PDFs, not phone-camera JPEGs.

Treat the verdict as one signal among several. A modified verdict with high confidence and multiple markers is a strong control. An inconclusive verdict on a document claimed to come from a known institutional source is a softer control that warrants a secondary check — either fresh portal capture in a verified session, or an employer/bank API confirmation. An intact verdict means the structural layer is consistent with the claimed origin and does not by itself prove the income figures are real.

Who should run this check

Captive lenders — Ally, Capital One Auto, Santander Consumer USA, GM Financial, Chrysler Capital, Toyota Financial, Ford Credit — carry direct exposure on the contracts they fund through indirect dealer channels. Independent and specialty auto lenders — Westlake Financial, Exeter Finance, Credit Acceptance, Lendbuzz — sit in the same workflow, often with higher subprime concentration and higher loss-given-default. Direct-to-consumer auto fintechs — Carvana’s captive financing arm, AutoFi, Tresl — collect stip docs digitally from the consumer, which removes the dealer-as-intermediary problem but doesn’t remove the consumer-as-editor problem.

For all of these, the relevant reader is the Head of Credit Risk, Director of Fraud Operations, or the VP of Originations who owns the credit policy DTI thresholds are calculated against. The dealer is structurally the wrong place to install this control — their economics reward closed deals, and a forensic check that adds friction to a marginal application directly opposes their incentive. The lender carries the loss; the lender is where the check needs to live. For the broader workflow view, see PDF fraud detection in loan origination and the document fraud detection fintech workflow.

Frequently Asked Questions

Why doesn’t the dealer catch the forged pay stub?

The dealer’s F&I office isn’t resourced to verify income forensically — their incentive is to close the deal. On a marginal credit tier, a dealer who refuses a borderline stip doc loses the contract to a competitor. Auto lenders that wait for the dealer to filter forgeries end up funding them. The check belongs at the lender, not the dealership.

What’s the difference between this and The Work Number or a payroll API?

The Work Number and payroll APIs verify the income figure directly with the employer. They’re the strongest control when they cover the borrower’s employer — but coverage is partial, response times can exceed the deal cycle on a spot delivery, and integration cost is non-trivial. Structural PDF forensics runs in seconds on every submitted document regardless of employer coverage, and answers a different question: not “is the income real” but “was the document altered after the payroll system generated it”. The two layers are complementary.

Can structural forensics catch a synthetic-identity fraud ring building stubs from scratch?

Partially. A stub built in the same rendering pipeline a real payroll system uses, with consistent metadata, will return intact because there is no structural evidence of post-creation editing. Synthetic-identity fraud at that level of operational sophistication needs an employer verification layer (The Work Number, payroll API) or out-of-band employer confirmation. Structural forensics catches the much larger volume of opportunistic edits to genuine PDFs — the long tail that synthetic-ID detection isn’t built for.

Does this work for indirect platforms that receive PDFs from Dealertrack or RouteOne?

Yes. The forensics check operates on the PDF itself, regardless of how it reached the lender’s queue. Whether the document came from Dealertrack, RouteOne, DealerSocket, an internal upload portal, or a direct email from the dealer, the structural signals in the file are the same. The integration point is wherever the stip doc lands in the lender’s system before the credit decision is finalized.