A Convincing Page Is Not an Authentic File: Moving Document Review from Appearance to Consistency and Source Checks

Why Visual Plausibility No Longer Filters Forged Intake Packages

In lending intake and enterprise onboarding, first-pass review often relies on visual and arithmetic checks: processors inspect statements and pay stubs for font anomalies, crooked tables, patching, or unaligned balances. When a PDF keeps the issuer’s layout and its numbers add up, a reviewer has little reason to dig further.

AI-assisted editing of native PDFs undermines that habit. Starting from a genuine issuer-downloaded PDF, an editor can keep the issuer’s fonts, layout, page geometry, and genuine amounts while swapping the applicant’s identity; in one small exploratory study, most such files drew no supported concern in first-pass review^[1]. Meanwhile, a simulated test found that tool-using models’ willingness to perform a pay-stub edit shifts with wording^[2], so intake cannot rely on the forger’s tools refusing. The practical response: treat “looks right” as no evidence, reconcile identifiers as a screening check rather than proof, confirm with the issuing source when provenance matters, and keep the decision with a person backed by an evidence memo.

Empirical Evidence: Missed Visual Cues, Shifting Tool Refusals, and Provenance Levels

First, Ren, Shen, Duong, and Raj (2026) ran a small exploratory study of first-pass, document-only review^[1]. From 47 genuine issuer-downloaded PDFs (from 12 issuers, all belonging to one consenting holder), AI coding agents with an in-house native-PDF editing tool replaced the identity with three fictitious applicants, producing 134 forged PDFs in packages of 47, 42, and 45^[1]. Issuer fonts, layout, and page geometry were kept, and no amount, date, or balance changed; identifier inconsistencies introduced by the pipeline were known and knowingly retained before distribution^[1]. Three freelancers with prior underwriting or loan-processing experience each reviewed one package—not told files were altered, with no access to originals—returning 132 file-level judgements (Clear, Suspicious, or Insufficient information; one skipped 2 files)^[1].

Only 14 of 132 judgements (10.6%) had an edit-supported concern: 12 Suspicious + 2 Insufficient information, or 12 of 132 (9.1%) under a narrow definition (explicit Suspicious + supported)^[1]. Reviewers marked 115 Clear; 3 further Suspicious judgements flagged features already in the genuine originals (a real maturity transfer, an empty account, sub-dollar amounts)—so counting every Suspicious label as detection would overstate results^[1]. All 14 supported concerns were identifier disagreements: 9 within-file account-number disagreements, 3 cross-file taxpayer-identifier disagreements, and 2 account-linkage failures (balance letter no longer linking to brokerage statement)^[1]. An inconsistency did not guarantee reporting: within-file inconsistency yielded 9 supported of 23 judgements (39.1%), cross-file only yielded 5 of 78 (6.4%), and no inconsistency yielded 0 of 31^[1]. No reported visual cue identified an actual edit (visual complaints like “cropped” or “inconsistent background” matched the genuine originals), and no reviewer cited the original holder’s name left in pay-stub bookmarks or in two filenames (the study did not observe whether their viewers displayed bookmarks)^[1].

Strict limits apply: the study had 3 reviewer–package pairs; with all files forged and no genuine controls, it cannot estimate specificity, false positives, or accuracy, nor show what share would pass a lender's entire workflow^[1]. Review time and software use were not recorded, all sources came from one holder, only identity fields were edited (not amounts), and a fully consistent forged package was not tested (removing retained mismatches might remove the cues)^[1]. The authors disclose working for a company that develops document-fraud detection products^[1]. In the authors' words, cross-document reconciliation is useful but "not proof of authenticity": agreement cannot show that documents came from the issuer, legitimate applicants have several accounts, new addresses and different masking formats, and the false-positive rate was not measured^[1].

Second, Ren, Shen, Duong, Ng, and Raj (2026) tested the same request (raise gross pay on a marked placeholder test pay stub from 3,250 to 5,850 USD) under three wordings across 15 models with simulated tools in 445 observable trials (of 450 planned)^[2]. Editing calls were issued in 14.1% when a loan purpose was stated, 33.1% when purpose omitted, and 66.2% when described as fixing a printing error, with at least one call in 3, 7, and 12 of 15 models respectively^[2]. One model refused all ten loan-purpose requests yet issued calls in all ten purpose-omitted trials^[2]. Using a marked test file and simulated tools with no real edit executed, the test measures call issuance rather than successful forgery, is not an ethics ranking, and lacks authorized-versus-deceptive controls^[2]. What it does show is that, in this setting, whether an editing call is issued changes with wording; in our reading, that is why the defence has to sit at intake.

Third, we borrow distinctions from Digital Identity Guidelines: Identity Proofing and Enrollment (NIST SP 800-63A-4) by Temoshok et al. (2025)—a US federal identity-proofing guideline for credential service providers, not a lending rule^[3]. It separates identity resolution, evidence validation, attribute validation, and identity verification^[3]. Evidence validation confirms evidence is authentic (not forged or altered), accurate, and valid (unexpired or within the provider’s defined timeframe), via visual inspection by trained personnel, automated document validation, or cryptographic verification of source and integrity of digital evidence^[3]. Core attributes must be validated with an authoritative or credible source—an authoritative source is the issuing source or has direct access to issuing-source information; among identity-verification methods, it also lists transaction verification such as a micro-deposit to confirm ownership of a financial account^[3].

Engineering Mapping on rlab.works: Reconciliation Screening, Source Confirmation, and Evidence Memos

In our engineering view, intake should extract identifiers (names, account tails, taxpayer IDs, addresses) per document and reconcile them within and across the package, tolerating legitimate variation; route mismatches to a person as a screening flag rather than an auto-rejection; seek issuer or trusted-channel confirmation when the decision depends on provenance; check non-visible artefacts such as bookmarks, filenames and metadata; and keep an evidence memo and audit trail.

Across Agent OS and Intelligence on rlab.works, three proposed skill packs and three components illustrate this structure and its adaptation boundaries:

• Intake and audit trails: In Agent OS, Intake and handoff (S09) runs Confirm account and role → Create the service record → Approve data access (human gate) → Hand over and record, paired with Operations identity, permissions and audit trail (who accessed which file, auditable operations). Its only industry tag is healthcare (transferable, administrative service only, without symptom-based triage), with no finance tag—so for lending it is a borrowed intake pattern needing re-wiring of identity and case systems.
• Field contracts and retained conflicts: In Intelligence, Unify and enrich records (S28) runs Ingest and stage sources → Normalize and resolve entities → Classify and locate gaps → Investigate and accept facts (human gate), paired with Audited curation and database publishing pipeline (human merge and override decisions). Proven only for travel (“each supplier needs a field contract and retained conflicts and provenance”), it is an analogy for per-document field contracts keeping identifier conflicts visible instead of silently merging, and is not built for financial documents.
• Evidence memos: In Intelligence, Keep an evidence memo (S25) runs Collect source evidence → Resolve entities and relations → Compare claims and challenges → Review and save the memo (human gate), paired with Investment thesis evidence and verdict tracking (separates supporting and opposing evidence, with a human-overridable verdict). Proven in finance for research memos (outputs support research, not trade instructions), it is an analogy for listing what supports and contradicts a document’s authenticity while keeping the credit decision with people.

All three skill packs are proposed and not integrated (synthetic-data demos), and all three components have “working” maturity from static inspection only. None of them detects forgery or contacts issuers.

Three Intake Checks for Risk and Engineering Teams

• Screen visible and non-visible identifiers: Reconcile account numbers, taxpayer IDs, names, bookmarks, and filenames within and across files, routing mismatches to a person rather than auto-rejecting.
• Separate consistency from provenance: Agreement is a screening check, not proof; when provenance matters, require issuer confirmation, cryptographic verification, or transaction checks such as micro-deposits.
• Measure false positives and log a memo: Test checks on genuine files (multiple accounts, moves, masking formats) before relying on them, and record supporting and opposing evidence in an auditable memo for human decisions.