Utility Bill PDFs: The File Check Address-Proof Steps Skip

The proof-of-address step in most onboarding flows takes a PDF the applicant chose, uploaded from a device the applicant controls. Your address-validation service checks the address. Your KYC or IDV provider checks the person. OCR reads the name, the address and the bill date off the page. Every one of those steps assumes the PDF is still the file the provider issued.

This article is for the onboarding operations lead or compliance analyst who owns the POA step at a neobank, broker, crypto exchange or payments lender. Lender onboarding teams with the same step can read it too. It covers where a file check on a utility bill PDF fits, what each verdict should do at that step, and what the check cannot tell you. For the detection scope on this document type, see the utility bill tamper-detection page.

What the address-proof step checks, and what it assumes

Short answer: a typical proof-of-address (POA) step confirms that the address on the bill matches the address the applicant typed, that the name matches the verified identity, and that the bill is recent enough. It assumes the PDF it is reading is the file the provider issued. A structural file check tests that assumption: was this PDF changed after it was created?

Many firms accept a recent utility bill as one form of proof of address. The bill usually travels from the provider to the applicant’s inbox or online account, then to the applicant’s phone or laptop, then to your upload form. Every hop after the first is in the applicant’s hands.

Where utility bill PDFs enter the flow

A utility bill reaches your POA step through one of a few routes, and the route matters when you decide what to do with a result:

• Applicant upload in the app or web flow. The most common route. The file is whatever the applicant saved or downloaded: the provider’s PDF, a scan of a paper bill, or a phone photo converted to PDF.
• Intake through a partner portal or API. A broker, introducer or embedded-finance partner forwards documents on the applicant’s behalf. One more party has handled the file.
• Analyst review after a referral. An application lands in a manual queue for another reason, and the analyst opens the bill. This is often the first time anyone looks at it closely.

The bank-statement step sees the same routes, and the bank-statement counterpart to this article covers that document. The POA step differs in two ways that change how you act on a result.

First, the applicant can usually swap the document. POA policies often accept more than one document type, so there is a natural remedy when a bill can’t be relied on: ask for a different proof of address. That can be a fresh copy downloaded from the provider’s portal rather than a scan or photo, or another document type your policy accepts. Check that file too. Second, many legitimate bills reach operations as scans or photos, not as the provider’s original PDF. Expect inconclusive to be a routine result at this step, and plan for it.

Which check answers which question

Each check in the POA step answers a different question. The layered model of KYC and document forensics explains why these are separate layers; at the POA step they line up like this:

The fourth row is the one flows often leave empty. HTPBE? uses structural PDF analysis to answer it: it reads the file’s structure and history, not the text on the page. HTPBE? is not KYC, identity verification or address verification.

What each verdict means at the address-proof step

Decide what each result does before the first file goes through, and write it into the POA procedure. A verdict is one input to review. Never make it the sole basis for declining an applicant or closing an account.

For inconclusive, usage_caution.recommended_action is request_from_issuer. At the POA step the nearest practical form is a copy downloaded fresh from the provider’s portal, or another document your policy accepts. The applicant still handles that file, so it gets its own check.

A modified result is not a finding of fraud either: a changed file is not, on its own, proof that anyone acted dishonestly. The result tells the analyst which files need closer review before the address can be relied on, and the reason is attached to the case. Give the applicant a chance to explain or to send another document before any decision is made.

Before you finalise the procedure, check it against your own legal and compliance obligations on adverse action and automated decision-making, including GDPR Article 22 where it applies.

Adding the check to the step

Submit the bill at the point where it is stored. The applicant uploads the file, your system makes it available at a URL that can be downloaded without authentication, and you submit it to POST /api/v1/analyze. A utility bill carries a name and an address, so don’t leave it in a permanently public location: if your storage supports it, use a short-lived link that expires once the check has run, an unguessable path and a neutral file name, since the file name is stored with the result – the same applies to any original_filename you send. Files up to 10 MB are accepted. The call returns a check ID; the result endpoint returns the verdict.

Route on these fields (an excerpt of the result; message and the other fields are omitted):

{
  "status": "inconclusive",
  "status_reason": "scanned_document",
  "modification_markers": [],
  "usage_caution": {
    "safe_for_automated_adverse_decision": false,
    "recommended_action": "request_from_issuer"
  }
}

• status is the verdict; modified takes priority over everything else.
• status_reason appears only on inconclusive and tells you why – for example, that the file is a scan. Use it to word the request for an alternative document. The exception is analysis_incomplete, which describes the check rather than the file: submit the same file again once, and if the result repeats, treat the file as unverified rather than clean.
• usage_caution is on every result. safe_for_automated_adverse_decision is always false; recommended_action is route_to_human_review, request_from_issuer or no_action.

On modified, modification_markers lists named public IDs for what was found, such as HTPBE_MULTIPLE_REVISION_LAYERS, each describing a finding that the file was changed after it was created. Attach them to the case so the analyst sees the reason, not just the verdict. The API documentation covers authentication and the full response.

What the file check does not touch

Outside the file check: the address, the resident and the issuer. HTPBE? does not read the name, address, dates or amounts on the bill, does not confirm that anyone lives at the address, and does not contact the utility provider or confirm that the bill exists in its records.

The other limits:

• Content that was false from the start. A document whose details were wrong when it was first produced carries no evidence of a later edit, because nothing was changed afterwards. And some deliberately forged files show no structural sign of editing. intact means no modification was detected, not that the document is genuine.
• Scans and photos. These can never be confirmed intact. Unless they show signs of editing, they come back inconclusive. That says nothing bad about the applicant.
• Intent. modified means the file was changed. It does not say who changed it or why.

Frequently asked questions

Does an intact result confirm the applicant lives at the address?

No. HTPBE? checks the PDF file, not the address, the resident or the provider named on the bill. An intact result means no structural evidence of modification was found in the file. Whether the address exists and whether the applicant lives there are questions for your address-validation service and your KYC checks, which still run as normal.

Is an inconclusive result a reason to reject the applicant?

No. An inconclusive result means HTPBE? cannot confirm the file as an untouched original – a reason for manual review, not proof of fraud. Scanned and photographed copies can never be confirmed intact, so at the proof-of-address step this result is routine. The default next step is to ask for an alternative proof of address or a fresh copy from the provider’s portal, and to check that file too.

Does HTPBE? replace our address-validation or KYC vendor?

No. HTPBE? is not KYC, identity verification or address verification. It answers one separate question – was this PDF changed after it was created – and sits beside the vendors you already use. Your address-validation service still checks the address, and your KYC or IDV provider still checks the person.

Try it on your own address-proof files

Run a handful of the utility bill PDFs your team already reviewed and see where the verdicts fall before you write them into the procedure. Create an account to run them; after any welcome credits on the account, checks are paid from credits or a plan (see pricing).