Document tampering & synthetic-document fraud detection (bank statements, payslips, invoices)

Lenders, landlords, insurers and accounts-payable teams accept PDFs and photos as proof of income, balances or debts. Editing such a file or generating one from scratch with an image model now takes minutes. Document-forensics AI inspects the file itself (structure, metadata, fonts, pixels), checks the content for internal and cross-document consistency, and returns an explained trust score so that humans only review the suspicious minority.

Problem & value

• Today: staff eyeball documents or rely on OCR/extraction that reads whatever is on the page (see DOC-017, DOC-001). Extraction proves nothing about authenticity: an edited payslip is parsed just as cleanly as a genuine one.
• Threat shift: AppZen reported that the share of AI-generated fakes among flagged expense receipts rose from 0 % in March 2025 to 70.8 % by mid-May 2026, overtaking template-based fakes; an Emburse survey of 2,000 US/UK workers found 34 % admitted using AI to create a fake receipt, and a separate study cited in the same article found 32 % of finance professionals said they could not recognise one [1]. Both are vendor/commissioned data from flagged submissions, not neutral population statistics. Inscribe states AI-generated document fraud grew about fourfold between its April 2025 detector launch and June 2026 (vendor claim) [2]. A European survey by Finovox and Selvitys (8,000 respondents, 8 countries) reports 11 % of UK respondents admitting to having falsified a document [4].
• AI value: faster review (Inscribe cites 72 seconds per document versus ~10 minutes manual, a vendor figure [2]), consistent checks, detection of reused templates across a customer base, evidence for disputes. Independent, peer-reviewed accuracy figures for commercial products are essentially absent; treat vendor accuracy claims (e.g. "99.2 %", "99.7 %") as unverified until tested on your own documents [3][5].

Variants

• Lending & income verification: bank statements, payslips, tax assessments (DOC-017 extracts, this case authenticates).
• KYB / supplier onboarding: company extracts, bank letters, certificates (see DOC-019 for quality certificates).
• Accounts payable: forged or altered invoices, changed IBANs, fake supplier documents (ANOM-009, DOC-001).
• Expense management: AI-generated or reused receipts (DOC-002, ANOM-009).
• Insurance claims: invoices, repair estimates, medical bills (ANOM-003).
• Tenancy / real estate: proof of income for rental applications; also employers verifying certificates.
• Merged variant — financial-document forensics: detecting tampered or AI-generated financial documents is the same pipeline as above (sweep duplicate merged here).
• Private use: limited; individuals can check an invoice or rental document with free metadata tools, but there is no consumer product category.
• Out of scope: identity documents/passports and liveness (ANOM-014); marking and detecting AI-generated media in general (ANOM-015).

How it works

1. intake (upload / email / API / mobile capture)
2. file triage (type, hash, duplicate/near-duplicate lookup across the customer base)
3. file forensics (PDF structure, incremental updates, producer/creator, XMP/EXIF, fonts, embedded fragments)
4. pixel forensics for scans/photos (re-compression, splicing, copy-move, noise inconsistencies; AI-generation classifier)
5. content extraction (OCR / VLM
6. structured fields)
7. consistency checks (running balance, totals, VAT, IBAN checksum, payslip net/gross/tax logic, date logic)
8. cross-document & external checks (statement vs payslip vs tax form; issuer template match; company register, VAT ID)
9. scoring (rules + ML ensemble, 0–100 trust score with reasons)
10. routing: pass | enhanced review | request original / open-banking data | reject
11. analyst review screen with highlighted regions; feedback loop to the model

• Layers are complementary. Metadata can be scrubbed and a screenshot of a forgery has clean metadata, so pixel and content checks are needed; content checks alone miss a clean fake with correct maths [5][6].
• Template and network signals: matching against known-good issuer layouts and against documents seen before (shared "fraud-kit" templates) is a strong signal that single-file analysis cannot give [2][3].
• Human-in-the-loop: a score is a triage signal, never a verdict about a person. Rejection or accusation requires an analyst and a way for the applicant to supply an original (e.g. via bank access).

Data preparation

The raw material is the documents themselves: bank statements, payslips and invoices arriving as PDFs, scans and phone photos by e-mail, customer portal or paper. In an SMB they sit in mailboxes, the DMS or ERP attachments and file shares. Typical gaps: the original file is lost because someone printed and rescanned it (which destroys the metadata the forensics rely on), duplicates under different names, no reference set of genuine issuer templates, and no labelled examples of confirmed forgeries. Preparation steps: (1) capture documents in their original digital form and keep the unaltered file next to any processed copy; (2) build a small reference library of genuine templates per issuer (bank, payroll software, key suppliers) and master data for VAT numbers and IBANs, see PREP-016 and PREP-005; (3) collect confirmed fraud and clean cases as test set, see PREP-018 and PREP-020; (4) run OCR where only scans exist, see PREP-006 and DOC-014; (5) define who may see applicant documents and for how long they are kept, see PREP-024 and PREP-025. Tools: the forensics service itself, Paperless-ngx or a DMS for intake, a spreadsheet for the reference set. Expect roughly 25 to 35 percent of the effort in data preparation, mostly in intake discipline and the reference set rather than in model work.

Implementation paths

Which path for whom

• smb (A): Mature EU-based document-forensics services exist with API or UI at usage-based prices, and the check (is this PDF genuine?) is a standard process.
• enterprise (B): Banks, insurers and large finance teams must wire the trust score into onboarding, claims or AP workflows and own systems, so a cloud-API build on top of a forensics service fits best.
• developer (B): Combining forensics APIs, OCR and rule checks into a product is an integration task on cloud APIs.
• public (C): Authorities handle applicant documents that are personal data and need sovereignty, so open-source PDF-structure and OCR tooling on own or sovereign EU infrastructure is preferable.

Path A — Buy (recommended for most organisations)

• Document-forensics specialists: Resistant AI (Prague, CZ — EU; API/UI, 500+ checks claimed, integrates with Google Document AI, ABBYY, Camunda; SOC 2 Type 2) [3]; Finovox (European startup active in FR/LU/BE/ES, expanding to UK — EU) [4]; Inscribe (US; bank-statement and payslip detector, trust score, cross-document checks; data hosting not stated on product page) [2]; Veryfi (US; "Fake Document Detective" via API) [5]; AppZen and similar expense-audit platforms for receipts [1]. Also offered inside some KYC/lending suites.
• Choose A when: you have a regular flow of third-party documents and no fraud-data-science team. Test with your own real and known-forged samples; insist on published false-positive rates, EU data residency and a DPA.

Path B — Build on cloud APIs

• Content layer: Azure AI Document Intelligence, Google Document AI, AWS Textract or a frontier VLM (Claude, Gemini, GPT, Mistral — EU regions/providers) for extraction and contradiction finding (e.g. "does opening balance + credits − debits equal closing balance on every page?").
• Forensics layer: Veryfi or Resistant AI API for file/pixel forensics [3][5]; own deterministic checks (PDF structure, producer strings) with open libraries.
• Orchestration: n8n/Power Automate/custom service, scoring in a rules engine. VLMs are good at semantic inconsistencies but are not reliable pixel-level forensic detectors; do not use "ask the LLM if this is fake" as the only control.

Path C — Self-host (open source)

• File forensics: pikepdf/qpdf (MPL-2.0) for PDF object and metadata inspection [7], ExifTool, pdfminer/PyMuPDF for fonts and text layers; deterministic rules for incremental updates, producer/creator mismatches, hidden layers.
• Content & maths: Docling or PaddleOCR-VL for parsing, an open VLM (Qwen-VL family) via vLLM for field extraction; plain code for balance/VAT/IBAN checks.
• Pixel forensics (research models): TruFor (CVPR 2023; localisation map + integrity score) is the reference open implementation but its licence is non-commercial [8]; other academic detectors (DocTamper-style document-tampering models) generalise poorly to new generators — check licences and benchmark on your data.
• Scoring: gradient boosting (LightGBM/XGBoost) over the signals plus rules. Hardware: HW2 (one 24–32 GB GPU) is enough; many checks run on CPU.
• Choose C when: documents are highly sensitive (payroll, health), data must stay on-premises, or volume makes per-document pricing expensive.

Path D — Custom training

Worth it for large lenders/insurers with their own labelled fraud history: train a document-level classifier or fine-tune a small VLM on confirmed forgeries plus genuine documents from the same issuers, and refresh continually because generators and fraud kits change. Needs thousands of labelled genuine documents per issuer type and a few hundred confirmed fakes (augment with synthetic tampering, but validate on real cases). Unlabelled-genuine-only training (anomaly detection against issuer templates) is an alternative when fakes are rare.

State of the art (2026)

• From template fakes to generated fakes: image and document generators now produce plausible receipts, payslips and statements, with correct layout, fonts and arithmetic, which defeats classic "does the math add up" and many template checks [1][5].
• Multi-signal ensembles dominate commercial products: metadata/revision history, font and template analysis, pixel analysis, LLM-based contradiction checks, cross-document comparison, external corroboration, plus a network effect over very large document corpora; output is a 0–100 trust score with plain-language reasons [2][3].
• Provenance as a complement: C2PA Content Credentials and signed documents (e.g. eIDAS-qualified seals, e-invoice XML, bank-issued signed statements or open-banking data) prove authenticity cheaply where available [9]; for most uploaded PDFs/photos no such provenance exists, so forensics remains necessary. Better still, avoid the document: fetch the data directly from the source (PSD2 account information, payroll APIs, structured e-invoices).
• Limits and failure modes: no public independent benchmark covers commercial products; vendor accuracy claims lack published test sets and false-positive rates [3]. Detectors trained on one generator degrade on new ones; screenshots and print-scan cycles launder traces; legitimate documents (re-exported, merged or edited by the issuer's own software, scanned by staff) cause false positives, and thin-file or non-standard applicants are most affected. Attackers can probe a visible score, so show reasons to analysts, not to applicants.

Shared resources & combinations

• Same stack as extraction: DOC-017, DOC-001, DOC-002, DOC-004, DOC-014 — one parsing/VLM service (HW2/HW3) feeds both extraction and consistency checks.
• Neighbours with clear boundaries: ANOM-014 (identity documents and liveness, uses face-biometrics), ANOM-015 (AI-generated media marking/detection in general, C2PA tooling), DOC-019 (certificate and quality-document verification).
• Downstream fraud analytics: ANOM-009 (expense/procurement fraud — receives the authenticity score as a feature), ANOM-003 (claims), ANOM-006 (ledger anomalies), ANOM-016 (sanctions screening on names found in documents).
• Shared building blocks: tabular-ml/anomaly-detection scoring, a case-management and analyst-review UI, a document-hash and template database, workflow engine (AGENT-002-style back-office automation).

Effort, cost & KPIs

• Path A: days to a few weeks (API/UI integration plus a pilot on your own samples). Pricing is usually per document and mostly unpublished.
• Path B: 1–3 months to combine extraction, forensics API and rules; cost driven by volume and review headcount.
• Path C: 2–5 months; one GPU server, a maintained rule set and labelled test data; ongoing upkeep as generators change.
• Path D: 6+ months with a data-science team and a feedback loop.
• KPIs: fraud-capture rate on a labelled test set, false-positive rate and review burden (share of documents escalated), review time per document, confirmed fraud loss avoided, share of cases switched to source-verified data, applicant complaint/appeal rate and overturn rate.

People & change

Involve management (budget, risk appetite) and the department lead (fraud, credit or AP process owner) first, then IT and IT security for integration and handling of sensitive uploads, and the DPO before the pilot: applicant documents are personal data, so check the legal basis, sign an AVV with any forensics provider (Art. 28 GDPR) and run a DPIA where the check feeds decisions about people (Art. 35 GDPR). Works council: depends. The tool analyses customer documents, not staff, so no co-determination under §87(1) no. 6 BetrVG as long as it does not log analysts' individual performance; if it does (case-handling statistics per person), or if employees' own payslips are checked, the council must agree. Inform it in good time anyway under §90(1) no. 3 BetrVG, since work processes change. In the public sector the staff council (Personalrat) applies. AI literacy: support analysts with short training on what a trust score means and what false positives look like (Art. 4 AI Act, see GUIDE-006). Start with a pilot group of two or three experienced analysts, review all flags manually at first and publish hit-rate figures. Typical concern: "the tool will reject honest customers." Address it by making the score a prompt for review, never an automatic rejection, and by giving rejected applicants a way to submit originals. See GUIDE-008, GUIDE-005 and GUIDE-009.

Risks, regulation & compliance

• EU AI Act: classification depends on use. Pure fraud/forgery detection is typically minimal risk, and Annex III point 5(b) (credit scoring) explicitly excludes systems used to detect financial fraud. If the same score feeds a creditworthiness assessment, an insurance pricing decision, or access to essential public benefits, that downstream system can be high-risk (Annex III point 5). Not prohibited under Art. 5, but do not use it to infer protected traits or build social-scoring-style profiles. Art. 4 AI literacy applies [10].
• GDPR: payslips, statements and invoices of sole traders contain personal and sometimes special-category data (e.g. health insurance, union dues). Need a legal basis (typically legitimate interest or contract steps; document the balancing test), data minimisation, DPA with vendors, transfer assessment for US vendors, retention limits. Art. 22: a rejection must not rest solely on the automated score; keep a human review and let applicants contest and provide originals.
• Sector law: AML/KYC duties (AMLD, German GwG) and EBA guidelines for lenders; GoBD for invoice archiving (original must remain unaltered; keep forensic results as separate evidence); DORA for ICT third-party risk when using vendors in financial entities.
• Risks & mitigations: false accusations (human review, appeal route, wording "unable to verify" rather than "forged"); bias against non-standard documents (monitor false positives by issuer/country/channel); adversarial adaptation (rotate checks, secondary controls); vendor lock-in and opaque scores (insist on reason codes and exportable evidence); never retain uploaded documents longer than needed.

Getting started

1. Assemble 200–500 real documents of your own (genuine and, where available, confirmed or red-team forgeries made by your security team) with agreed labels.
2. Remove the cheap risk first: ask for source-verified data (open banking, payroll or e-invoice XML) for high-value decisions.
3. Pilot 2–3 Path A vendors on that sample; compare capture rate, false positives, explainability, EU hosting and DPA terms.
4. Add deterministic checks (balance maths, IBAN/VAT validation, PDF producer rules) in front of or alongside the vendor score.
5. Define routing thresholds, analyst review screen, applicant appeal path; track KPIs monthly and re-test when new generators appear.

Sources

1. Accounting Today — Use of AI receipts in expense fraud soars (AppZen, Emburse data; June 2026) — https://www.accountingtoday.com/news/use-of-ai-receipts-in-expense-fraud-soars
2. Inscribe — Fake bank statement detector — https://www.inscribe.ai/solution-explorer/fake-bank-statement-detector
3. IDP Software — Resistant AI vendor review — https://idp-software.com/vendors/resistant-ai/
4. IDTechWire — Finovox expands document fraud detection platform into the UK — https://idtechwire.com/finovox-expands-document-fraud-detection-platform-into-the-uk/
5. Veryfi — Detecting AI-generated fake bank statements (Fake Document Detective with Inscribe signals) — https://www.veryfi.com/ai-insights/detecting-ai-generated-fake-bank-statement/
6. OnGrid — Document forgery trends in 2026 (commentary on metadata scrubbing, template reuse) — https://ongrid.in/blogs/document-forgery-trends-in-2026/
7. pikepdf — https://github.com/pikepdf/pikepdf
8. TruFor (GRIP-UNINA, CVPR 2023) — https://github.com/grip-unina/TruFor
9. C2PA — Content Credentials — https://c2pa.org/
10. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj