An edited bank statement clears underwriting because the income figure looks right — not because the file was verified
Lenders accept bank statements, pay stubs, W-2s, and tax returns as income proof at application. Applicants edit a real document — change a balance, inflate a salary, insert a deposit — export to PDF, submit. OCR reads the numbers correctly. Cash-flow analytics processes the transactions. Neither checks whether the underlying PDF file was issued by a real bank or payroll engine, or modified after issuance. htpbe? provides that structural check as a self-serve REST API.
htpbe? analyzes the structural layer of the PDF file — producer, xref, metadata, image streams, signature chain, balance arithmetic. We don't do cash-flow analytics or income verification beyond the structural integrity of the document. Inscribe and similar platforms have broader feature sets (cash-flow, income classification, transaction enrichment) — this page describes how htpbe? fits the structural-forensics layer specifically, not a full feature audit.
One REST call, one deterministic verdict
Upload the PDF. The API returns INTACT, MODIFIED, or INCONCLUSIVE with named markers — in about three seconds.
How document fraud gets through lending intake
Three real fraud mechanics we catch at the structural PDF layer.
Bank statement edited to add fictitious deposits
Applicant downloads a Wells Fargo statement showing $800/month income. Opens it in any PDF editor, inserts three payroll deposits totalling $5,200, re-exports. The xref chain shows a second cross-reference table. The running balance breaks at the inserted transactions. OCR extracts the inflated figure correctly — but the structural layer of the file records the edit.
Pay stub fabricated in Word from scratch
No employer involved. Applicant creates a pay stub in Microsoft Word using the company logo from the web, sets gross pay to qualify for the requested loan amount, exports to PDF. Producer field shows Microsoft Word — not ADP, Paychex, Workday, or Gusto. Every real employer pay stub carries the payroll engine's producer signature.
W-2 with inflated wages
Applicant has a real W-2 but the income is too low. Opens the PDF in an editor, changes Box 1 wages, saves. The modification date is weeks after the creation date on a document that should be a single-session IRS e-file export. htpbe? flags the timestamp gap and incremental update as MODIFIED at high confidence.
How htpbe? is positioned
Why the current lending document intake misses this
Cash-flow analytics reads the transactions. It does not verify the file carrying them came from a real bank.
OCR, Open Banking, and income verification all operate on what the document says — not on whether the document was tampered with.
Plaid Income and Open Banking APIs deliver data direct from the bank — but only when the applicant connects their account. When they decline and submit a PDF instead, nothing in the standard lending stack checks whether that PDF was issued by the bank or edited after download. OCR extraction (AWS Textract, Ocrolus, FormFree) reads what is printed — it cannot detect a second xref table or a producer mismatch. Identity verification (Persona, Onfido, Alloy) confirms who the applicant is — it does not inspect the PDF they uploaded for structural fraud markers. htpbe? closes the specific gap between the applicant uploading a document and the underwriter relying on it.
Five forensic layers, one deterministic verdict
Every PDF we receive passes through the same structural pipeline — no model training, no thresholds to tune.
Metadata analysis
Creation and modification timestamps, producer and creator fields, XMP metadata — the first layer exposes basic tampering.
File structure
Xref tables, trailer chain, incremental updates. Any edit after export leaves a structural fingerprint here.
Digital signatures
Signature chain integrity and post-signature modifications produce deterministic markers. Certainty-level signal.
Content integrity
Fonts, objects, embedded content, page assembly. Multi-session edits and inserted objects are visible at this layer.
Verdict with markers
Deterministic output: INTACT / MODIFIED / INCONCLUSIVE, with named markers for every finding — suitable for audit trail.
PDFs we analyze for lending and fintech workflows
Every type listed below is analyzed at the structural file layer — not the rendered image.
Detection capabilities
Deterministic structural signals. No probabilistic scores, no model training.
Producer signature analysis
Authentic bank statements come from banking systems. Authentic pay stubs come from payroll engines (ADP, Paychex, Workday, Gusto). When the producer field shows Microsoft Word, Excel, LibreOffice, or a generator-tool fingerprint, the document was authored on a desktop — flagged.
Incremental update detection
Edits to a real PDF (changed amounts, balances, dates) leave incremental update markers in the xref chain. htpbe? flags these as MODIFIED at high confidence even when the visual layout looks pristine.
Balance arithmetic verification
Running balance is verified row-by-row across bank statements (previous balance + transaction = new balance). Edited transactions break the chain unless every dependent balance was also adjusted — a structural fraud signal independent of OCR.
Digital signature chain validation
Many tax forms (W-2, 1099) and employer letters carry digital signature chains. htpbe? validates the chain and flags invalidated or removed signatures as MODIFIED at certain confidence.
Image-stream artefact detection
Lifted-and-pasted logos, signatures, and headers leave compression and object-structure artefacts that differ from authentic embedded content. The image-stream metadata exposes paste operations.
Cross-document fingerprint analysis
When multiple "different" employer letters or bank statements from a single applicant pool share font subset prefixes, image hashes, or producer signatures, the API surfaces the shared fingerprints — useful for catching synthetic-identity rings.
An Inscribe alternative your engineers can ship today
Buyers can skip this section — developers, the integration is two HTTP calls.
Step 1 — submit the PDF
curl -X POST https://api.htpbe.tech/v1/analyze \
-H "Authorization: Bearer $HTPBE_API_KEY" \
-H "Content-Type: application/json" \
-d '{"url": "https://your-storage/applicant-bank-statement.pdf"}'Step 2 — read the verdict
{
"id": "i1n2s3c4-5r6i-7b8e-9z0a-a1b2c3d4e5f6",
"status": "modified",
"modification_confidence": "high",
"modification_markers": [
"Two cross-reference tables — incremental update",
"Modification date 11 days after creation date",
"PDF editor producer detected",
"Balance arithmetic broken at transaction #14"
],
"producer": "Adobe Acrobat Pro",
"creator": "Wells Fargo Online",
"creation_date": 1707091200,
"modification_date": 1708041600,
"has_digital_signature": false,
"xref_count": 2,
"has_incremental_updates": true
}Original came from Wells Fargo Online — institutional source. 11 days later it was opened in Adobe Acrobat Pro and re-saved, adding a second xref. Plus the running balance is broken from transaction 14 onward — the applicant inserted a transaction without adjusting dependent balances. Verdict: modified at high confidence. The applicant edited a real Wells Fargo statement after issuance.
Customer Stories
Teams that stopped document fraud
Compliance, finance, and risk teams use htpbe? to catch manipulated PDFs before they become costly mistakes.
Caught an invoice where the total had been changed by less than a thousand dollars. Without this I would have approved it without a second look.
Sarah M.
AP Manager
United States
We had three applicants in the same week with bank statements that looked completely fine. Two of them were flagged as modified. You simply cannot see this by reading the document — it is in the file structure.
Lars V.
Risk Analyst, Online Lending
Netherlands
Salary slips were coming with altered figures. We identified two problematic files before the placement was finalised.
Priya K.
HR Operations Lead
India
Since we started checking documents this way, we stopped two applications early in the process that would have been very difficult to reverse later.
Julien R.
Fraud Analyst, Fintech
France
Some applicants were sending PDFs that looked authentic but had been edited in ways not visible to the eye. We now ask for verified originals when something is flagged. Already saved us from a few bad decisions.
Marta S.
Compliance Coordinator
Spain
One invoice was caught because there was a mismatch between the document dates and structure. That particular case would have cost us significantly.
Tariq A.
Finance Manager
United Arab Emirates
Frequently asked questions
Related solutions and guides
Fintech & Lending
Full lender vertical positioning — fraud-ops angle for risk teams.
Bank Statement Fraud Detection
The primary document type in lending fraud — focused tech-page treatment.
Fake Pay Stub Detection
Pay stub fraud forensics for income verification in US lending.
Secure your workflow
Create your account — API key on signup, free test environment on every plan.
From $15/mo. No sales call. Cancel any time.