Evaluating Inscribe for underwriting documents? An edited bank statement clears intake because the income figure looks right – not because the file was checked
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 is an untouched original or was modified after issuance. HTPBE? provides that structural check as a self-serve REST API.
HTPBE? analyzes the structural layer of the PDF file – how it was built and what happened to it afterwards. We don’t do cash-flow analytics or income source-of-truth confirmation 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.
Fit and limits
When HTPBE? fits next to Inscribe – and when it does not
HTPBE? fits when your engineers want to add one question to an existing intake – was this PDF edited or fabricated after issuance? – and get the answer from a single API call, without a sales process. It suits teams that already read income and transaction data some other way and want a file-level check in front of the underwriter, on bank statements, pay stubs, W-2s and similar documents.
It does not fit when you need one vendor for the whole document workflow. Inscribe is described as an agentic risk platform with cash-flow and income analytics on top of document-fraud detection; HTPBE? does not do any of that. A platform with a sales-led evaluation can also be the right shape for a large team that wants onboarding and a managed rollout.
The two can sit in the same pipeline. HTPBE? takes a PDF URL and returns a verdict with named markers, so it does not depend on which platform reads the content of the same file.
Limits of a structural check
- It reports modification, not intent. A flagged file is a reason to ask for the document another way, not a finding about the applicant.
- It does not read the figures on the page, classify income or analyse cash flow.
- It does not confirm identity.
- A printed and re-scanned document loses its original file structure. The result reports a scanned origin; it cannot tell what was altered before printing.
- A document built from scratch with the same software a bank or payroll engine uses may carry no trace of editing.
- Some files return an inconclusive verdict instead of a confident one.
What this looks like
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. 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. HTPBE? does not clear it as an original, however closely it copies an ADP or Gusto layout: with nothing indicating later editing it returns INCONCLUSIVE and goes to manual review; with evidence of editing or fabrication, MODIFIED.
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 edit leaves traces in the file that a genuine IRS e-file export does not carry, and HTPBE? returns MODIFIED.
How HTPBE? is positioned
Why the current lending document intake misses this
Cash-flow analytics reads the transactions. It does not check whether the file carrying them is an untouched original.
OCR, Open Banking, and income source-of-truth checks 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 is an untouched original or was edited after download. OCR extraction (AWS Textract, Ocrolus, FormFree) reads what is printed – it cannot detect edits saved after issuance. Identity proofing (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.
Comparison
Why teams pick HTPBE?
A self-serve structural tamper-detection API versus a managed ML document-fraud platform – different shapes for a lending intake.
| Feature | HTPBE? | ML document-fraud platforms (e.g. Inscribe) |
|---|---|---|
| Deployment model | Self-serve REST API – sign up, get a key, ship today | Managed platform with onboarding and account setup |
| Pricing | Public – listed on /pricing | Sales-led – no public price list |
| Onboarding | No sales call – free test keys on every plan | Sales-led evaluation and procurement |
| Method | Structural file forensics – how the file was built and what happened to it afterwards | Blend of metadata, forensic, semantic and perceptual analysis, plus cash-flow and income analytics |
| What it answers | Was this PDF edited or fabricated after issuance? | Broad document intelligence across the application |
| Scope | Focused structural-forensics primitive | Bundled document-fraud and analytics suite |
Document types
PDFs we analyze for lending and fintech workflows
Every type listed below is analyzed at the structural file layer – not the rendered image.
What HTPBE? checks
Detection capabilities
Deterministic structural signals. No probabilistic scores, no model training.
A copied layout earns nothing
A bank statement or pay stub saved as PDF from Word, Excel or LibreOffice does not come back INTACT, however closely it copies a bank or payroll layout. With no sign of later editing it returns INCONCLUSIVE for manual review; with evidence of editing or fabrication, MODIFIED.
Post-issuance edit detection
Edits saved into a real PDF (changed amounts, balances, dates) leave structural evidence behind. HTPBE? flags it as MODIFIED at high confidence even when the visual layout looks pristine.
Character overlay on the original
Changing a balance or a transaction row on an existing statement leaves a structural trace. HTPBE? flags it without reading the figures – it never looks at the numbers on the page.
Signature tamper detection
Many tax forms (W-2, 1099) and employer letters carry digital signatures. HTPBE? detects edits made after signing and flags signatures that were removed, both surfaced as MODIFIED at certain confidence.
Pasted-element detection
HTPBE? detects logos, signatures and headers lifted from another document and pasted in.
Redaction completeness check
Some applicants redact an account number or personal field by covering it with a black box. HTPBE? flags redactions where the covered text is still present and recoverable in the file.
Share with engineering
Wire this into your intake pipeline in under a day
Two API calls – one POST to submit the PDF, one GET to retrieve the verdict. Forward this page to your engineering team; the full API reference, quotas, and copy-paste examples in cURL, JavaScript, Python, PHP, Go, and Ruby are one click away.
Pricing
Self-serve plans, no sales call
All plans include the same forensic checks. Pick the quota that matches your monthly document volume.
manualStarter
30 credits/mo
Manual spot-checks and integration testing
most commonGrowth
350 credits/mo
Active document processing pipelines
high volumePro
1,500 credits/mo
High-volume automation and API integrations
Enterprise (unlimited, on-premise available) — see full pricing
API key on signup. Free test environment on every plan. No card required.
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 checked 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
FAQ
Frequently asked questions
Is HTPBE? a direct feature replacement for Inscribe?
How do you compare on price?
Does HTPBE? work in US lending workflows specifically?
inconclusive – not intact – and goes to manual review. The verdict is modified when the file itself carries evidence of editing or fabrication.Can we evaluate before committing?
When should we stay with Inscribe rather than add HTPBE?
Can HTPBE? run alongside Inscribe or another platform?
Does HTPBE? return a risk score?
What does HTPBE? not catch?
Secure your workflow
Create your account – check PDFs on the web or with an API key, both ready on signup.
No sales call. Cancel any time.