KYC vs Document Forensics: Two Separate Layers of Fraud Defence

Three different tools get asked to answer one question – ‘can we trust this application?’ – and each one answers a different question. KYC and identity verification (IDV) check the person. OCR and document extraction read what a document says. Document forensics checks what happened to the file. A lending or onboarding stack that treats these as one capability has a gap, and the gap is where edited PDFs get through.

This page is the reference for that distinction. It defines the three layers, gives a decision guide for which you need when, and links to the deeper articles on each part of the problem. HTPBE? is a document-forensics API. It is not a KYC or IDV product, and this article says where that boundary sits.

The Three Layers, Defined

Two notes on the table. First, vendor categories are not clean: some identity platforms ship a document-fraud module (Bynn is one), and some extraction platforms ship a fraud module (Ocrolus and Veryfi both do). Having a module is not the same as the layer being the product’s centre of gravity, and the comparison pages below take each vendor one at a time. Second, the table describes what each layer is built to answer, not a ranking. A good KYC platform is good at its question. It was never asked this one.

What KYC and IDV actually check

KYC platforms are built to answer one question: is this person who they claim to be? The usual building blocks are liveness detection, face match against the submitted ID, analysis of the identity document itself (layout, fonts, security features of the issuing jurisdiction), and watchlist or sanctions screening. When an applicant clears KYC, that is a meaningful answer: a real person, matching a plausible ID.

It says nothing about the bank statement they uploaded afterwards. The detailed walkthrough is in KYC PDF Blind Spot: Bank Statement Fraud Your Stack Misses.

What OCR and extraction actually check

Extraction tools turn a document into data: the account holder’s name, the closing balance, the transaction list. That is essential for underwriting automation. But extraction reads the page as rendered. An edited balance extracts as cleanly as an original one, because on the page they look the same. Where an extraction vendor also offers a fraud module, the Ocrolus comparison and the Veryfi comparison cover how that differs from a forensic check. For the reasoning behind the split, see Ocrolus Alternative: A Self-Serve PDF Tamper Detection API.

What document forensics actually checks

Forensics asks a question about the file, not the page: was this PDF modified after it was created, and does the software that produced it fit what the document claims to be? A bank statement generated by an institution’s own systems carries a different file history from one that was opened, changed and re-saved in a consumer tool. The page can look identical in both cases. The file does not.

The signal is the file’s own record of what happened to it.

Why the Gap Exists: One Attack, Three Layers

The standard bank-statement attack looks like this. An applicant downloads their real statement from their bank. The template is genuine, the account number is real, their name is on it. They change a balance in an editor or spreadsheet, export a PDF, and upload it.

• KYC / IDV: the applicant’s identity is real and was proven live. Cleared, correctly.
• OCR / extraction: the new balance is read and passed downstream as data. Extracted, correctly.
• Forensics: the file does not look like something produced by a bank’s systems, or carries evidence of being saved again after creation. Flagged.

Only the third layer sees the edit, because only the third layer reads the file. Two worked responses follow.

Two abridged responses show the shape. Fields are trimmed for length.

Case 1: Re-exported through an online editor

{
  "id": "5d1f0a62-8c3e-4b7a-9e21-0f4a6c8d2b17",
  "status": "inconclusive",
  "status_reason": "online_editor_origin",
  "producer": "Online PDF Editor",
  "has_incremental_updates": false,
  "has_digital_signature": false,
  "modification_markers": [],
  "usage_caution": {
    "safe_for_automated_adverse_decision": false,
    "recommended_action": "request_from_issuer"
  }
}

The verdict is inconclusive, not modified: HTPBE? cannot see what the original values were, so it does not claim an edit it cannot show. It reports that the file came out of an online editor and says what to do next: ask the issuer for the document. Whether such a source is expected for the document in front of you is the reader’s call. For a statement that should have come from an institution, it is a reason to request it another way. The full treatment of this verdict is in bank statement fraud in lending, and the sibling article KYC PDF Blind Spot walks through the spreadsheet-export variant.

Case 2: Edited and saved again

{
  "id": "c7e94b30-2a15-4f68-b3d9-61a0e5f8742c",
  "status": "modified",
  "modification_confidence": "certain",
  "producer": "Adobe Acrobat Pro 2024",
  "has_incremental_updates": true,
  "modification_markers": ["HTPBE_MULTIPLE_REVISION_LAYERS", "HTPBE_DATES_DISAGREE"],
  "usage_caution": {
    "safe_for_automated_adverse_decision": false,
    "recommended_action": "route_to_human_review"
  }
}

The file itself records changes after creation, and the response names them. A reviewer looking at the rendered page sees a normal statement. Note usage_caution on both: a modified verdict routes the case to a person, it does not decline the applicant on its own.

Which Do You Need, and When?

The short version: if the evidence in your decision is a person, you need KYC. If the evidence is a PDF someone sent you, you need a forensic check on the PDF. Most lending and onboarding flows have both.

The Layered Stack

Layers 2 and 4 are independent and can run in parallel; neither depends on the other. The order of 2 before 3 is the one that matters: run the file check before extraction, so a flagged document is routed to review before its numbers become trusted data. Whether you run forensics before or after KYC is a cost and workflow choice for your team, not a technical constraint.

No layer is redundant. An applicant who clears KYC can still submit a statement that fails forensics, and an identity that fails KYC never needed its statement read.

Where It Fits in Your Integration

After an applicant uploads a document and before it enters underwriting, send its URL to the PDF forensics API:

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.com/applicant-docs/bank-statement.pdf"}'

Route on status, then on status_reason and usage_caution.recommended_action:

• status: "modified" → manual fraud review. The response always carries safe_for_automated_adverse_decision: false; do not decline automatically
• status: "inconclusive" → branch on status_reason (consumer_software_origin, online_editor_origin, scanned_document, unverifiable_metadata, filled_form_origin, fill_sign_origin). If the origin is not what you expect for the document, request it from the issuer through another channel
• status: "intact" → continue to the standard queue, bearing in mind that intact is not proof of authenticity (see the scope section below)

Plans and per-check options are on the pricing page. For a mortgage or lending intake, the lending, mortgage and customer onboarding pages cover document-by-document patterns, and fake bank statement detection covers the single most common case.

Honest Scope: What HTPBE? Is Not

• HTPBE? is not KYC or IDV. It does not check identity, liveness, faces, ID documents or watchlists. It does not replace a KYC provider and does not claim to.
• HTPBE? does not read or judge content. It does not tell you whether a balance is plausible, whether an employer exists, or whether a number is true.
• intact is not proof of authenticity. It means the file shows no sign of modification. A document fabricated from scratch has no earlier version to differ from, and a file’s history says nothing about whether its contents were honest.
• inconclusive is a routing signal. It means the file comes from an origin class for which an integrity check does not apply (consumer software, an online editor, a scan, unverifiable metadata or a filled form), with the reason in status_reason. Whether that origin is acceptable for your document is your decision.
• Scans and printed copies carry no file history. HTPBE? reports the origin as scanned, which is useful when a document should not be a scan, but it cannot say what was altered before scanning.
• HTPBE? reports the fact of an edit, not intent. A flagged file is a reason to look closer, not a finding about the applicant.

These limits are why the stack has layers. Forensics narrows one specific, high-volume gap – the edited PDF that passes visual and OCR review – and leaves identity, content and source-of-truth questions to the tools built for them.

Go Deeper: The Rest of the Cluster

The KYC gap and bank statements

• KYC PDF Blind Spot: Bank Statement Fraud Your Stack Misses – what KYC checks and what it never sees
• Bank Statement Fraud in Lending: What Gets Altered and How to Catch It – the lender’s view, with the inconclusive policy
• How Lenders Verify Bank Statements – the manual checklist and the layer it misses
• Do Mortgage Underwriters Verify Bank Statements? – the mortgage-specific version
• How to Spot a Fake Bank Statement – the reviewer’s guide

Same attack, other intake flows

• Fake Tax Return Transcripts in Lending
• Auto Finance: Pay Stub and Bank Statement Fraud
• Rental Fraud and Bank Statement PDFs
• Tenant Screening Bank Statement Fraud for SaaS
• Vendor Bank-Change Fraud in Supplier Onboarding

Choosing a vendor

• Inscribe alternative and the longer comparison
• Ocrolus alternative and the longer comparison
• Resistant AI alternative
• Bynn alternative
• Veryfi alternative
• Fortiro alternative
• Snappt alternative

If you are ready to add the file layer to an existing flow, start with the API; pricing lists what each plan includes.

For the engineering detail of the file layer, the REST quickstart lists the error contract and a smoke test you can run with a test key, and the HR diploma guide shows how the file check sits next to issuer verification in a hiring flow.