Identity Passed, Statement Edited: What Your KYC Flow Does Not Check

Picture a loan application at a digital lender. The applicant scans their passport, takes a selfie, and the KYC provider returns approved in under a minute. Name, date of birth and document number all match. Liveness passes. The identity is real, and it belongs to the person on the other end.

Then the application asks for proof of income, and the applicant uploads three months of bank statements as a PDF. The statement is genuine in every visible way except one: before uploading, they opened the file, changed a closing balance from $2,400 to $24,000 and saved it again.

The KYC result is still green. It was never about this file.

This is written for the product or risk owner of an onboarding flow at a neobank or digital lender, and the decision is where in the flow a statement gets checked and what each verdict triggers. The lending-operations view, with the three origination stages compared, is in PDF fraud detection in loan origination.

Two Different Questions on One Application

An application carries two kinds of evidence, and they are checked by different things.

• Who is applying. The ID document, the selfie, the watchlist screening. This is what KYC platforms such as Onfido, Jumio, iDenfy or Ondato are built for, and they do it well.
• What the applicant claims about their finances. The statement, the pay stub, the tax return. These are files the applicant chose, prepared and uploaded.

A KYC pass answers the first. It says nothing about whether the second was altered after the bank produced it. The identity is verified; the PDF attached to it is simply taken at face value. For the general version of this argument, see KYC vs document forensics. This article stays on one concrete flow.

Walkthrough: Where the Edit Slips Through

Here is a typical onboarding sequence for an unsecured loan, with what each step actually looks at.

Step 3 is where most flows have a gap. The statement is read for its content (income, average balance, overdraft days) and passed on. Nothing asks whether the file itself is what the bank issued. A forged balance on a real template looks like a real statement to a template check and to a human reviewer, which is why visual review fails against this kind of edit.

Step 4 is the control most teams lean on, and it is a good one. But it is optional for the applicant, and it is reasonable to expect that an applicant who alters a statement will choose the PDF route.

Where to Add a File Check

A file check answers a narrow question: does this PDF show structural evidence of having been changed after it was created, and did it come from consumer software, an online editor or a scan? Whether that origin fits the bank the statement names is the reviewer’s step; HTPBE? does not read what the document claims to be.

Directly after upload, before parsing and before the open-banking offer. Run it as soon as the file lands in your storage, so the result is on the record before anyone relies on the figures. It also lets the result steer the next step: a flagged statement is a reason to require the account link rather than merely offer it.

A resubmitted or replaced statement is a new file and gets its own check; keep the earlier result on the application record so the history stays visible. The order relative to identity proofing matters less than the fact that both run before a human relies on the statement.

The call itself is one request to the HTPBE? API:

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.example.com/statements/application-4417.pdf"}'

Store the returned check ID against the application so a later dispute has something to point to. For lender-specific intake patterns, see pre-underwriting PDF checks in loan origination and the lending use case.

What to Do on Each Verdict

HTPBE? returns one of three verdicts. Decide the action for each in advance, so the outcome is a rule and not a judgement call at the moment of review.

• intact. No structural evidence of modification, and the file did not originate from consumer software, an online editor or a scan. Continue to normal underwriting. This is a statement about the file, not about the figures in it (see the limits below).
• modified. The file was changed after it was created. Route to manual review, and obtain the statement from a source the applicant does not control. Do not simply ask the applicant to upload it again: they control both copies, so a second upload proves nothing.
• inconclusive. Nothing proves an edit, but the file came from consumer software, an online editor or a scan, or could not be tied to an institutional export. Read status_reason together with the issuer the statement names. If a large bank’s statement arrives with a consumer or scan origin, corroborate it through the open-banking link, a bank portal login or a statement requested from the bank. If the issuer is a small credit union or a neobank, where consumer-style exports are normal, the same verdict is routine and needs no escalation on its own. See what inconclusive means in lending for the longer discussion.

Two further rules are worth writing down. A flagged result opens a review; it is not by itself a decision to decline, and any adverse action should rest on the reviewed evidence. And a clean KYC result must never override a flagged file, since the two answer different questions.

What the Change Does to Your Funnel

The figures below are illustrative, to show the arithmetic; replace them with your own. Take a lender with 10,000 applications started in a month, of which 7,000 pass the identity step and 4,200 upload a statement as a PDF (the rest link an account through open banking). The file check runs on those 4,200 statements.

We do not claim a typical share. It depends on your channels and applicants, and on how you route inconclusive: if every inconclusive goes to manual review, the share is higher than if consumer-style exports from small institutions are released on the other evidence. Measure it on a few weeks of real applications before it affects a single decision, running the check in a mode where the result is recorded but not acted on.

Three numbers to track after launch

1. Review rate – the share of checked statements routed to a person, split by verdict and by status_reason. A rising inconclusive share on one institution usually means a routing rule needs a per-issuer exception, not that applicants changed.
2. Re-source outcomes – of the files you re-sourced from the bank or the open-banking link, how many matched the uploaded version and how many did not. This is the figure that tells you whether the check is finding something real.
3. Added time to the applicant journey – the delay the flow adds for applicants who were flagged, and how many abandoned.

Questions for Your KYC Vendor and for This Layer

Asking vendors where their coverage ends is cheaper than discovering it. Before you decide that an identity platform already covers statements, ask:

• Does the platform test the structure of the PDFs an applicant uploads, or only read their content?
• If it reads content, what happens when the content is correct and the file was edited?
• What does it return for a scanned or photographed document, and what do you do with that result?
• Can it be run on a file that arrives outside the identity session, such as an e-mailed attachment?

For the file layer, the matching questions are the ones in the limits section below: it says nothing about the person or the income, and it names its reasons when it cannot decide.

Honest Limits

A file check is one layer, and it is worth being exact about what it does not do.

• It is not income verification. intact means the PDF shows no signs of being altered. It does not confirm that the balance is the applicant’s real balance, that the income recurs, or that the account is theirs. A statement can be unedited and still say less than the whole truth.
• It is not identity verification. HTPBE? is not a KYC or IDV product and does not replace one. It does not look at people or ID documents.
• A clean result is not proof. No file-level check catches every alteration, so intact lowers risk and does not remove it.
• Scans and files with no usable history are reported as such, with the cause in status_reason. HTPBE? cannot say what the content was before. The general list of limits is in KYC vs document forensics.

This is why the corroborating source matters. Where the applicant’s bank is supported and they consent, transaction data from open banking is a stronger basis for an income decision than any PDF, because there is no file in the loop to alter. The sensible stack uses the file check to decide when the PDF cannot be trusted, and open-banking or bank-sourced data to answer the income question itself. How lenders verify bank statements covers where open banking runs out of coverage.

Applying It

If you run onboarding for a lender, neobank or any product that takes a statement as supporting evidence, the change is small: one call after upload, one rule per verdict, and a requirement that flagged cases be re-sourced from the bank. The same intake works for other financial documents (pay stubs, tax returns, business statements) because it reads the file, not the document type; the customer onboarding use case and the bank statement detection page show the flow for each. Plans and per-check pricing are on the pricing page.

Related FAQ: Can a PDF be modified without detection?