FCA Document Fraud Detection UK: Closing the Gap Your KYC Stack Leaves Open

A mortgage broker in Manchester submits a loan application. The P60 looks correct — HMRC logo, employer name, National Insurance number, tax year. The payslips match. The bank statements show a salary credited every 28 days. The applicant passes identity proofing. The income picture is coherent.

The P60 had been opened in a browser-based PDF editor. The annual earnings figure was increased by £12,000 and the file was re-exported before upload. The original HMRC producer signature is gone. The file now declares, in its own binary structure, that it was last written by a consumer web tool. No one in the origination workflow checked that declaration.

This is not a new attack. It is the most common form of document fraud at UK lender onboarding in 2026 — and it is largely invisible to the compliance tools firms are already running.

The UK Document Fraud Landscape

The following document types are common fraud vectors in UK mortgage, unsecured lending, and challenger bank onboarding workflows:

P60 and P45. HMRC-standardised employer-issued documents confirming annual earnings and deductions. Generated by payroll software — Sage, Xero, IRIS, BrightPay, Moorepay — each of which leaves a consistent structural fingerprint in the PDF it produces. Fraudsters alter the gross earnings field, the employer name, or the tax year. The template remains authentic; the numbers do not.

Payslips. Monthly documents from the same payroll systems. Modification targets include gross salary, net pay, and employer name. Unlike P60s, payslips are not standardised in format, which makes visual template checks harder — but the software fingerprint is just as reliable a signal.

UK bank statements. Retail bank statements from Barclays, HSBC, Lloyds, NatWest, Santander, Halifax, and the challenger banks (Starling, Monzo, Revolut) are generated by core banking platforms, not by consumer software. A real Barclays PDF statement carries a structural signature consistent with institutional document generation. A statement opened in Microsoft Excel and re-exported does not.

HMRC Employment History letters and SA302s. Tax year overviews and self-assessment returns downloaded from the Government Gateway portal. Self-employed applicants submit these in place of payslips. The same modification risk applies: download the real document, alter the income figure, re-export.

Right-to-work documents and sponsor licence supporting documents. Now a growing concern for FCA-regulated employers subject to Home Office right-to-work obligations and the Points-Based Immigration System. Biometric Residence Permits, share codes, and supporting payroll evidence all pass through document intake workflows that were not designed to detect file-level tampering.

CIFAS reported a 17% year-on-year increase in first-party fraud cases in the UK in 2024, with income inflation via document modification accounting for a significant share of application fraud in the lending segment. ActionFraud data shows that financial fraud affecting UK consumers and businesses now exceeds £2.3 billion annually.

FCA Expectations on Document Integrity

The Financial Conduct Authority does not publish a prescriptive checklist of controls for document fraud detection. Its requirements are clear: under SYSC 6.1 (systems and controls against financial crime), CONC 5.2 (responsible lending), and the Consumer Duty (PS22/9), firms must have proportionate, demonstrable controls on the information they use to make lending decisions.

PS21/3, the FCA’s Policy Statement on the Strong Customer Authentication extension and associated guidance on consumer credit, reinforced the principle that identity proofing at onboarding is a necessary but not sufficient control. The FCA’s broader financial crime guidance under FCG 3.2 explicitly names document fraud — fabricated or altered supporting documents — as a risk that firms must assess and mitigate.

In supervisory practice, the FCA’s approach to document fraud controls is part of the same framework that covers anti-money laundering and Counter-Terrorist Financing (CTF) obligations under the Money Laundering, Terrorist Financing and Transfer of Funds Regulations 2017 (MLRs). Customer Due Diligence (CDD) requires checking not just who a customer is, but that the information they provide is reliable.

A firm that processes thousands of income document submissions monthly with no file-level integrity check is, in the FCA’s terms, operating with a gap in its proportionate controls. If a supervisory review surfaces that the firm accepted altered P60s without any structural fraud detection layer, the question is not whether that is a problem — it is whether the firm knew and what it did about it.

Document forensics generates an audit trail. Every HTPBE? check returns a unique check ID and a structured JSON response that can be stored alongside the application record. If the FCA asks how a lending decision was made and what document integrity controls were applied, the answer is retrievable, timestamped, and specific.

The Gap That Identity Proofing Does Not Fill

UK lenders typically run two fraud detection layers before decisioning:

Identity fraud detection — platforms like Onfido, Jumio, Yoti, and iDenfy confirm that the person submitting the application is who they claim to be. Liveness detection, biometric matching, document template validation against known passports and driving licences. These platforms are highly effective at the problem they are designed to solve.

Open Banking — platforms like TrueLayer, Yapily, and Plaid pull transaction data directly from the applicant’s bank account via the account information API. The data is reliable because it comes directly from the bank, not from a document the applicant submitted.

What neither layer addresses is the question of whether the PDF documents submitted alongside the application — P60, payslip, HMRC letter — are structurally intact.

Identity fraud detection confirms the person is real. Open Banking confirms the bank account is real and shows its transaction history. Neither tells you whether the payslip PDF was modified before upload.

This matters because Open Banking is not universally available in UK lending. It covers current accounts, but not all income sources map cleanly to bank account transactions. Self-employed income, investment returns, rental income, HMRC benefit payments, and multiple-employer scenarios all require document submission alongside Open Banking data — or instead of it. The PDF layer does not disappear because Open Banking exists.

The structural fraud detection layer answers the question the other tools do not ask: was this specific PDF file modified after it was created, and by what software?

How Structural Forensics Reads UK Document Signatures

The detection mechanism is not optical character recognition or template matching. It reads the binary structure of the PDF file itself — the metadata fields, xref table, and object stream that the generating software wrote into the file when it was first created.

HMRC payroll documents (P60, P45, P11D) are generated by HMRC-certified payroll software. Sage Payroll, Xero Payroll, IRIS Payroll, BrightPay, and similar platforms each produce PDFs with a characteristic Producer field and structural signature. A P60 generated by Sage Payroll has a different internal fingerprint from one generated by Xero. Both have a different fingerprint from one re-exported by an online editing tool.

When a fraudster downloads a real P60 from their Xero portal and modifies the earnings figure in iLovePDF, the resulting file carries two signatures: Xero’s original Creator string in the first xref revision, and iLovePDF’s Producer string in the second. The xref_count increases from 1 to 2. The modification_date is later than the creation_date by the time the edit took. The document’s own structure declares what happened.

UK bank statements carry institutional fingerprints specific to the bank and its document generation pipeline. A Monzo statement has a different structural signature from a Barclays statement, which has a different signature from a Lloyds statement. What they share is that none of them are generated by Microsoft Excel, Google Docs, or PDF24. When a bank statement comes back with producer: "Microsoft Excel", there is no legitimate explanation for that in the context of a bank-generated document.

A representative API response for a modified P60:

{
  "id": "c7e1f204-a3d9-41bc-b882-9c3d5f8a1e27",
  "status": "modified",
  "creator": "Xero Payroll",
  "producer": "iLovePDF",
  "creation_date": 1740700800,
  "modification_date": 1741132800,
  "origin": { "type": "consumer_software", "software": "iLovePDF" },
  "xref_count": 2,
  "has_incremental_updates": true,
  "has_digital_signature": false,
  "signature_removed": false,
  "modification_markers": [
    "Known PDF editing tool detected",
    "Different creation and modification dates",
    "Creator and producer mismatch"
  ]
}

The creator shows Xero Payroll — the software that originally generated the document. The producer shows iLovePDF — the tool used to re-save it after modification. The xref_count of 2 confirms two save events. The modification_date is five days after creation_date. No legitimate payroll workflow produces this combination.

For a bank statement produced by Microsoft Excel, the verdict is inconclusive rather than modified. The distinction matters:

{
  "id": "d4b9e371-82fa-4c8e-a991-7b2c3d4e5f6a",
  "status": "inconclusive",
  "status_reason": "consumer_software_origin",
  "creator": null,
  "producer": "Microsoft Excel",
  "creation_date": 1741305600,
  "modification_date": 1741305600,
  "origin": { "type": "consumer_software", "software": "Microsoft Excel" },
  "xref_count": 1,
  "has_incremental_updates": false,
  "modification_markers": []
}

inconclusive does not mean the analysis failed. It means HTPBE? cannot prove that a specific edit was made — but it can prove that the document was produced by consumer software, not by a banking system. A bank statement cannot legitimately have producer: "Microsoft Excel". For triage purposes, treat this verdict the same as modified: the document requires alternative fraud detection before it can be used in a lending decision.

Right-to-Work and Sponsor Licence Documents

For FCA-regulated firms that are also licensed sponsors under the UK’s Points-Based Immigration System, document fraud extends beyond income source-of-truth check into the right-to-work layer.

Home Office guidance requires employers to check that employees have the right to work before employment begins and at regular intervals for time-limited permissions. Supporting documents for sponsor licence applications — contracts of employment, payslips, evidence of salary payments — are subject to Home Office audit.

The same attack vector applies: a fraudster submits an authentic-looking contract, payslip, or salary confirmation letter that was generated by real HR or payroll software and subsequently modified. A structural integrity check at document intake catches the modification before the file is stored in the sponsor licence compliance record.

For firms processing right-to-work checks and sponsor licence renewals alongside their FCA-regulated lending activities, a single API integration covers both document types. The fraud detection logic is document-type-agnostic: it reads what software created and last saved the file, independent of what the document is presented as.

See right-to-work document fraud detection and sponsor licence document fraud detection for detailed coverage of these specific document types.

What This Approach Does Not Catch

Structural analysis is a powerful layer, but firms should understand its boundaries before implementation.

Documents created from scratch. If a fraudster builds a fake P60 from a blank template in Adobe InDesign and never starts from a real document, there is no modification history to detect. The file was never a real HMRC document. HTPBE? will report the software used to create it — InDesign is not payroll software, which is itself a signal — but it cannot flag post-creation changes that did not occur.

Modifications made within the same application. If someone opens a PDF in Adobe Acrobat Pro and alters a figure, the producer field will show Adobe Acrobat — a legitimate tool used by many organisations. The incremental update and timestamp delta are still present, and HTPBE? flags them, but the producer alone is less definitive than a consumer tool.

Scanned and re-printed documents. A document that has been printed and re-scanned loses all original metadata. HTPBE? will return origin.type: "scanned", which is itself useful — a P60 arriving as a scan from a broker workflow may warrant additional scrutiny — but the original file structure is not recoverable.

Legitimate document processing pipelines. Some broker platforms or mortgage administration systems re-process PDFs before passing them downstream. These legitimate transformations leave structural traces. Implementation should account for known intermediary tools in the workflow.

These limitations are precisely why structural forensics works best as one layer alongside identity proofing and Open Banking, not as a replacement for either.

Integration: Three Steps to an Audit-Ready Check

The HTPBE? API is a single POST request. It is a lightweight integration that fits into any existing document intake pipeline without replacing identity proofing or Open Banking. The integration point is the document intake stage: after the applicant uploads a P60, payslip, or bank statement, and before the document is passed to underwriting or stored in the CDD record.

Step 1 — upload the document to your storage layer (this step is likely already in your pipeline). The document lands in your S3-compatible storage with a publicly accessible URL.

Step 2 — send the URL to HTPBE? and receive a structured verdict in 2–5 seconds:

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/applications/p60-john-smith-2024.pdf"}'

Step 3 — route on the verdict:

• intact → document passes structural check; proceed to underwriting
• modified → post-creation modifications detected; route to manual review and request re-submission through a secure channel
• inconclusive with status_reason: "consumer_software_origin" on an institutional document type (bank statement, P60, payslip) → cannot confirm institutional provenance; request alternative sourcing (Open Banking, HMRC portal share, payroll bureau confirmation)

Store the check id alongside the application record. Every check ID is retrievable via GET /api/v1/result/{id} and constitutes a timestamped, structured audit entry demonstrating that a document integrity control was applied at onboarding.

For a Python example of batch processing across multiple document submissions per application, see the Python integration guide.

Who This Is For

HTPBE? is directly relevant to:

FCA-regulated mortgage lenders and brokers processing P60s, payslips, bank statements, and HMRC correspondence as part of income source-of-truth check. PS21/3, CONC, and Consumer Duty together require proportionate, demonstrable controls on document data integrity.

Challenger banks and digital lenders (e.g., Tide, Iwoca, Funding Circle, Zopa) running high-volume automated origination. The absence of a human underwriter reviewing documents makes the machine-readable integrity check more — not less — important. A single API call per document integrates cleanly into an automated decisioning pipeline.

UK fintech compliance teams evaluating their financial crime control framework ahead of FCA supervisory engagement. Document fraud at onboarding is within scope of the FCA’s financial crime guidance, and firms that can demonstrate a documented, systematic approach to detecting it are better positioned in supervisory reviews.

Sponsor licence holders in the FCA-regulated sector managing right-to-work checks and sponsor licence compliance documentation.

For the full UK fintech and lending use case, see the UK fintech lending document fraud detection solutions page. For P60-specific detection patterns, see fake P60 detection.

Sign up for an API key to run a test check against your own document types. Test keys are available on all plans including free and return deterministic responses without consuming quota.