Originally published at htpbe.tech. The version on htpbe.tech stays in sync with the latest detection algorithm — refer to it for the canonical text.
A supplier you already pay sends an email: their bank has changed, please update the remittance details. Attached is a PDF on bank letterhead — an “updated banking details” confirmation, or a voided check, or a signed account-verification letter. Your AP analyst calls the number on file, the contact confirms, the change goes into the vendor master. Three weeks later the real supplier asks where their money went. It went to the fraudster’s account, and the PDF that authorized the change was edited after the bank issued it.
This is vendor bank account change fraud, and it sits in a blind spot that callback procedures do not cover. The controls every AP team runs — phone confirmation, email approval, a second signer — test whether the request is plausible. None of them test whether the document attached to the request was modified after it was created. HTPBE reads the submitted PDF’s structure and returns a verdict on exactly that question.
This is not BEC invoice fraud — it’s the vendor master
It is worth separating two frauds that get lumped together, because the document, the moment of attack, and the control gap are different.
Business email compromise invoice fraud targets a single payment. The fraudster intercepts or spoofs a real invoice, swaps the remittance bank account in the PDF, and sends it through a compromised or look-alike email thread. The damage is one invoice. We cover that case in detail in BEC invoice fraud detection and the broader invoice fraud in accounts payable playbook.
Vendor bank account change fraud is upstream of any invoice. It targets the vendor master record itself. Instead of editing one invoice, the fraudster changes the standing bank details attached to a supplier, so that every future payment to that vendor — this month’s and next year’s — routes to the attacker. The supporting document is not an invoice. It is a bank-issued confirmation: a letter from the supplier’s bank, a voided check, an account-ownership letter, a SEPA or ACH mandate. One forged PDF can redirect a payment relationship worth millions over its lifetime.
Same forensic question (was this PDF edited after issue?), different document and different point in the workflow. Treat them as two checks at two gates: one at invoice intake, one at any vendor bank-detail change.
The economics make the vendor-master version the more dangerous of the two. A redirected invoice loses you one payment, and the discrepancy often surfaces fast — the supplier chases the unpaid invoice within the payment cycle. A redirected vendor master loses you every payment until someone notices, and the discrepancy can hide for months, because the legitimate supplier keeps invoicing and you keep paying — just to the wrong account. By the time the real vendor escalates a string of “missing” payments, several cycles of money may already be gone and unrecoverable. The forged bank letter at the change gate is a higher-leverage target for the fraudster, which is exactly why it deserves a dedicated check.
Why AP controls miss the forged bank letter
Standard vendor-change controls are built around social-engineering resistance, and they are good at it:
- Callback verification — call the supplier on a number from the master record, not from the request email.
- Email confirmation — require written sign-off from a known contact.
- Dual approval — a second person authorizes the master-data change.
- Change-notification holds — freeze the first payment after any bank-detail change for a cooling-off window.
Every one of these evaluates the request. Did a believable person ask, through a believable channel, with a believable reason? A determined fraudster can pass all four. Compromised supplier inboxes mean the callback reaches a number the attacker controls. Spoofed look-alike domains satisfy the email check. And the attached bank letter is, to the human eye, perfect: real letterhead, real account-holder name, a plausible new account number, a signature, a date.
What no control in that list does is open the PDF and ask how it was built. The analyst reads the document; they do not examine the file structure underneath it. That structure is where the edit lives. A genuine bank confirmation comes out of the bank’s own system — a core-banking platform, a statement generator, an institutional document service. A forged one is a real bank letter that someone opened in a desktop or online PDF editor, changed the account number on, and re-saved. The save operation rewrites the file in ways the bank’s system never would, and those changes survive email and stay in the bytes you receive.
There is a reason this gap is structural rather than a training problem you can fix with a sharper analyst. A human reviewer is matching the document against business context: is this a supplier we know, is the contact someone we recognize, does the new account look like a normal account. All of that lives at the content level — the words and numbers on the page. The evidence of tampering does not live on the page. It lives in the file’s internal structure: which software wrote it, how many times it was saved, and what its internal timestamps say about when it was made versus when it was last changed. You cannot see that by reading the letter more carefully, because it is not in the letter. It is underneath the letter, and reading it requires parsing the PDF’s structure — which is exactly what an automated check does and a manual review cannot.
What the fraudster changes, and what it leaves behind
The visible change is small: an account number, a sort code or routing number, sometimes the account-holder name. Visually it is indistinguishable from the genuine field. The act of making that change, though, leaves structural evidence inside the PDF. Described in plain terms, without a how-to:
The software that generated the file stops matching the issuer. Every PDF records which software produced it. A bank’s confirmation letter carries the fingerprint of the bank’s institutional system. When a fraudster opens that letter in a consumer or online editor and saves it, the file now carries the editor’s identity instead of — or alongside — the bank’s. An institutional bank letter that reports it was last saved by a free online PDF tool did not come from the bank that way.
The document gains an edit history it should not have. A PDF issued once by an automated system is a single clean generation. Editing and re-saving appends a new revision layer to the file; the file now records that it was created, then changed, then saved again. Multiple revision layers on a document that claims to be a freshly issued bank confirmation mean it was reopened and altered after issue.
Internal timestamps disagree. A document carries an internal record of when it was created and when it was last modified. On a genuine one-shot bank letter these are effectively the same moment. When the modification record postdates the creation record, the file is telling you it was edited after it was made — on a bank confirmation, after the bank issued it.
A signed letter shows changes after signing, or a missing signature. Some bank confirmations carry a digital signature. If the content was altered after that signature was applied, the file records that the signed region no longer matches what is on the page. In other cases the original carried a signature that the fraudster’s save operation stripped, leaving the residue of a signature that was removed.
The account number itself was overlaid. Sometimes the fraudster does not rebuild the page — they patch a single field, dropping a new account number on top of the original using a desktop editor. That targeted character-level overlay is a different fingerprint from a full re-save, and it points straight at the field that was changed.
None of these require the original document. HTPBE compares the submitted file against how genuinely issued institutional documents are constructed — not against a copy you do not have.
What the API returns on a forged bank-change letter
HTPBE is a two-step call. You POST the PDF’s URL to /v1/analyze and get back an id; you GET /v1/result/{id} for the verdict. The result is a flat object — a status, the named modification_markers, and a modification_confidence of certain, high, or none. There is no numeric risk score; the markers name what was found.
Here is a representative result on a vendor bank-change letter. The supplier’s genuine bank confirmation was opened in a desktop editor, the IBAN was swapped to an attacker-controlled account, and the file was re-saved before being attached to the change request:
{
"id": "ck_4f2a9c1e-7b3d-4e8a-91c2-0d6e5f8a7b34",
"status": "modified",
"modification_confidence": "certain",
"modification_markers": [
"HTPBE_DATES_DISAGREE",
"HTPBE_EDITING_TOOL_FINGERPRINT",
"HTPBE_MULTIPLE_REVISION_LAYERS",
"HTPBE_CHARACTER_OVERLAY_EDIT"
],
"creator": "Institutional Banking Platform",
"producer": "Desktop PDF Editor",
"has_digital_signature": false,
"creation_date": 1755302400,
"modification_date": 1755734400
}
Read it in business terms. HTPBE_DATES_DISAGREE — the file’s own modification timestamp postdates its creation timestamp; the letter was edited five days after it was made. This is the strongest marker present, and it produces certain confidence: the document is internally inconsistent about its own age in a way that a one-shot bank letter never is. HTPBE_EDITING_TOOL_FINGERPRINT — the file carries the fingerprint of a known desktop PDF editing tool, which has no place in a bank’s issuance pipeline. HTPBE_MULTIPLE_REVISION_LAYERS — the document was generated, then modified, then saved again, rather than issued once and untouched. HTPBE_CHARACTER_OVERLAY_EDIT — a targeted character-level overlay sits on the page, the signature of a single field patched rather than the whole document rebuilt.
The verdict is modified with certain confidence. In practice that is a routing signal: hold the vendor-change request, do not commit it to the master, and escalate to a verified out-of-band confirmation with the bank or the supplier’s known finance contact — through a channel the fraudster cannot have compromised. The forensic check produces evidence; your vendor-management policy decides the action.
Other documents in the same workflow throw different combinations. A signed account-verification letter altered after signing surfaces HTPBE_POST_SIGNATURE_EDIT; one whose signature was stripped surfaces HTPBE_SIGNATURE_REMOVED. A letter whose institutional generator identity was deliberately spoofed to look like it came from the bank surfaces HTPBE_PRODUCER_IDENTITY_FORGED. You route on the verdict, not on memorizing which marker means what.
What inconclusive means here — and why it is still useful
A third verdict matters as much as modified. If the submitted PDF was built in consumer software — written in Word, exported from a browser, printed to PDF — HTPBE returns inconclusive. The file was assembled by a tool that does not preserve the structural history needed to prove the document is intact. That is not a detector failure. It is information.
For a vendor bank-detail change, inconclusive is a red flag in itself, because of what you expected. A real bank does not send your supplier’s confirmation as a Word document or a print-to-PDF. If you asked for a bank-issued confirmation of a new account and the file comes back inconclusive because it was produced in a word processor, the document is not what it claims to be — regardless of whether anyone tampered with it afterward. Treat inconclusive on a document that should be institutionally issued the same way you treat a missing document: insufficient to authorize a change. Route it to the same manual-verification queue as modified, for a different reason.
intact is the only verdict that lets a bank-change request proceed on the document’s own merits — and even then your callback and dual-approval controls still apply. HTPBE removes one specific failure mode (a forged or tampered file passing as genuine); it does not replace the rest of your process.
Honest limits: what this check does not do
Structural PDF forensics answers one question — was this file modified after it was created, and does its construction match a genuine institutional issuer? It is decisive on that question and silent on others. Be clear about the boundary:
-
It does not validate the account. HTPBE cannot tell you whether the IBAN on an
intactletter actually belongs to your supplier. A document can be structurally pristine and still name the wrong account if the fraud happened before the PDF was generated. Confirmation-of-payee and bank-account-verification services answer that question; HTPBE answers a different one. Run both. -
It does not catch a born-forged document. If a fraudster builds a fake bank letter from scratch in a tool that issues clean, single-generation files — never editing an original — there is no post-creation edit to detect. The file may be entirely fabricated yet structurally consistent. That is why
inconclusivematters: a fabricated letter built in consumer software lands there, and a fabricated letter that claims an institutional origin it cannot back up surfaces an identity-forgery marker. But a clean synthetic letter is the boundary of what structural analysis sees, and we say so plainly. - It does not verify content truth. HTPBE does not read the letter and decide whether the sort code is real or the signatory is authorized. It checks the file’s integrity, not the facts it asserts.
The value is that the largest category in practice — a real bank document edited to swap an account number — is exactly what structural forensics catches cold, and it is exactly the category callbacks and dual approval cannot see.
Integrating the check into vendor onboarding and change requests
The check belongs at two gates: new-supplier onboarding (when the first bank details are captured) and any subsequent bank-detail change request. In both cases the trigger is the same — a supporting document arrives that will authorize where money goes. Run the check before the change touches the vendor master.
Three steps:
- Capture the document at intake. When a supplier-onboarding form or a bank-change request comes in with a PDF, store the file and obtain a URL the API can fetch.
- Call HTPBE before committing the change. One synchronous analyze-and-result call per document. Gate the master-data update on the verdict.
-
Route on the verdict.
modifiedandinconclusivego to a manual-verification hold;intactproceeds into your existing callback and dual-approval flow.
import requests
API = "https://api.htpbe.tech/v1"
HEADERS = {"Authorization": f"Bearer {HTPBE_API_KEY}"}
def check_bank_change_doc(pdf_url: str, vendor_id: str) -> dict:
# Step 1: submit the PDF for analysis
submit = requests.post(
f"{API}/analyze",
headers=HEADERS,
json={"url": pdf_url},
timeout=15,
)
submit.raise_for_status()
check_id = submit.json()["id"]
# Step 2: retrieve the verdict
result = requests.get(
f"{API}/result/{check_id}",
headers=HEADERS,
timeout=15,
).json()
# Persist the check_id against the vendor record for audit
log_vendor_change_check(vendor_id, check_id, result["status"])
status = result["status"]
if status == "modified":
hold_bank_change(vendor_id, result["modification_markers"])
elif status == "inconclusive":
# Bank confirmation should be institutionally issued, not built in
# consumer software — treat as insufficient to authorize a change.
hold_bank_change(vendor_id, ["non_institutional_origin"])
# status == "intact": continue into callback + dual-approval flow
return result
Store the id against the vendor master record. If a payment to that supplier is later disputed or clawed back, the forensic report is retrievable as a permanent audit trail showing exactly which structural signals triggered — or did not trigger — the hold. That record matters for internal investigation, for insurance claims on a fraudulent-payment loss, and for any dispute with the bank.
The full request and response reference, error codes, and the test scenarios that return synthetic deterministic results are on the API page. The broader accounts-payable workflow — where this check sits alongside invoice intake and altered expense-receipt detection — is laid out on the accounts-payable use-case page. Volume pricing for vendor-management platforms and shared-service centers processing thousands of onboarding and change documents a month is on the pricing page.
Who should run this check
If you own vendor master data, supplier onboarding, or procurement fraud controls, this is your gap. The personas who feel it most directly:
- Accounts payable and shared-service leads who process supplier bank-detail changes and have watched a callback-verified change still turn out to be fraud.
- Procurement and vendor-management teams standing up onboarding for new suppliers, where the first bank details are captured from a document you have no prior record of.
- Finance fraud and controls functions building a defense-in-depth program around payments — structural document forensics is the layer that sits under callbacks and dual approval, checking the artifact those controls trust.
- Developers on procure-to-pay, vendor-management, or onboarding platforms who want to embed a per-document integrity check at the bank-detail gate. The API is self-serve: a key, two calls, a verdict.
Callbacks confirm that someone asked for the change. Dual approval confirms that two people signed off. Neither confirms that the bank letter authorizing the new account was not edited after the bank issued it. That last question is the one a forged-PDF fraudster is counting on you not to ask — and it is the one HTPBE answers from the file’s own bytes.
