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 cash buyer makes an offer on a $1.4M property. The listing agent asks for proof of funds before presenting it to the seller. Within the hour a PDF lands in the inbox: a Fidelity brokerage statement, account ending in 4471, total account value $1,612,408.22, statement period ending last month. The letterhead is right, the asset breakdown looks plausible, the page footer carries the usual disclosure boilerplate. The agent forwards it to the seller’s side, the offer gets accepted, and escrow opens.
The statement was real once. It belonged to the buyer, it showed a balance of $161,240.82, and it was for a period eight months earlier. Someone opened it in a desktop PDF editor, added a digit to the total, shifted the decimal, and bumped the statement date forward. Nobody called Fidelity. Nobody could have reconciled the number against the institution in real time anyway — brokerages do not answer balance-confirmation calls for third parties.
This is the asset-side version of bank-statement fraud, and it is just as invisible to the human eye. The difference between $161K and $1.6M is one keystroke and a decimal point. This article is about the brokerage-statement proof-of-funds PDF as a single-point-of-failure document in mortgage underwriting, real-estate transactions, and escrow — and the structural PDF layer that catches the edit when no live reconciliation exists.
Why Proof of Funds Is the Soft Target
Bank-statement fraud gets the attention because lenders process bank statements at volume and the patterns are well documented. Proof of funds via a brokerage or investment-account statement sits in a quieter corner, and that is exactly why it gets exploited.
No real-time reconciliation. A lender can sometimes pull a bank statement through an aggregator like Plaid and compare it against a direct-from-bank feed. Brokerage proof of funds is almost never wired that way. Fidelity, Schwab, Vanguard, Morgan Stanley, and the rest do not offer a public balance-confirmation line for a third-party agent or underwriter. The PDF the borrower hands over is the entire evidentiary record. There is nothing to reconcile it against in the moment.
High stakes, weak controls. A forged proof of funds on a residential purchase or a jumbo-loan reserve requirement can move a transaction worth seven figures. Yet the control is usually one person looking at the letterhead and the headline number. The stakes justify a deep check; the day-to-day reality is a quick glance.
The document is easy to obtain and easy to edit. Anyone with a real brokerage account can download a genuine statement. From there, the edit is trivial: open it in a consumer PDF editor, type over the balance, change the date. The hard part of forgery — making the letterhead and layout look right — is already done by the institution. The fraudster only has to change the numbers that matter.
The pattern shows up across the whole asset-verification surface. The same dynamic drives gift-letter and asset-letter fraud in mortgage files and the broader landscape of PDF fraud in real-estate transactions. The crypto world sees its own version in the proof-of-funds letter sent to OTC desks — that one is a private-bank attestation letter for a wallet-funding trade. Brokerage proof of funds is the mortgage-and-escrow version, where the underlying document is an investment-account statement rather than a letter, and where there is no issuer hotline to call.
What the Fraudster Actually Changes
To understand what structural detection can and cannot catch, it helps to be precise about what gets altered. On a brokerage proof-of-funds statement the edits cluster in a few predictable places.
The total account value. The headline number that the buyer or borrower needs to clear a threshold. $161,240.82 becomes $1,612,408.22. The forger types the new figure over the old one, and a careful forger also patches the per-holding line items so the totals add up.
The statement date or period. A statement from eight months ago becomes a statement from last month, because most underwriting and escrow rules require the proof of funds to be recent — typically within 30 to 60 days.
The account holder name, occasionally. When a statement borrowed from a friend or relative gets repurposed, the name on the account is changed to match the applicant.
Every one of these is a content change made to a file the institution already generated. The brokerage created a clean PDF; the fraudster modified it after the fact. That after-the-fact modification is what leaves a structural trace — and what HTPBE reads.
What the Edit Leaves Behind
A brokerage statement is generated by an institutional, server-side document pipeline. The brokerage runs a controlled toolchain — the kind of high-volume PDF generator that produces millions of statements a month — and the output has a consistent internal shape: a single write session, one cross-reference table, a producer string that matches the institution’s known generator, and creation and modification timestamps that agree because the file was written once and never touched again.
When a fraudster opens that file in a consumer desktop editor and types over the balance, the shape changes. The edit is not a content change in a database that re-renders cleanly. It is a byte-level patch placed on top of an already-finished PDF. That patch is visible in the file’s structure.
Date Disagreement
A statement that was generated once carries a creation timestamp and a modification timestamp that match. When the file is reopened and saved in an editor weeks or months later, the modification timestamp moves forward while the creation timestamp stays put. HTPBE surfaces this as HTPBE_DATES_DISAGREE. Because a clean institutional statement is written in a single pass, a modification date that postdates the creation date is a direct signal that the file was edited after the brokerage produced it. This marker carries certain confidence — it is one of the few signals strong enough that the verdict does not depend on any other evidence.
Revision Layers
A PDF can be saved incrementally: each save appends a new revision layer on top of the previous bytes rather than rewriting the whole file. A statement straight from a brokerage has one layer. An edited one shows multiple. HTPBE reports this as HTPBE_MULTIPLE_REVISION_LAYERS — the document was modified after creation, and the layers record it.
Editing-Tool Fingerprints
Consumer PDF editors and online tools — the kind used to type over a balance — leave fingerprints in the file: characteristic producer strings, object-layout conventions, metadata residue. When a document that claims to come from a brokerage carries the fingerprint of a desktop or online editing tool, the two identities contradict each other. HTPBE flags this as HTPBE_EDITING_TOOL_FINGERPRINT.
Producer Identity Forgery
A more careful forger edits the file and then rewrites the producer string to read like the institution’s real generator, hoping to hide the editing tool. But the underlying structural fingerprints of the editing software — font-embedding patterns, object-stream layout, default metadata residue — often do not match the spoofed identity. HTPBE detects the contradiction as HTPBE_PRODUCER_IDENTITY_FORGED.
Overlay Edits on the Balance
When a forger types a new number directly over the old one in a desktop editor, the editor frequently lays the replacement glyphs down as a targeted overlay on top of the original content stream rather than rebuilding the page. HTPBE reads this as HTPBE_CHARACTER_OVERLAY_EDIT or, at finer resolution, HTPBE_GLYPH_LEVEL_EDIT — the localized character-level patch that turns $161K into $1.6M.
A representative verdict on an altered statement returns several of these at once:
{
"id": "ck_7d2e9a1f-3b4c-4e8d-a1f2-6c9b0d3e8a7f",
"status": "modified",
"modification_confidence": "certain",
"modification_markers": [
"HTPBE_DATES_DISAGREE",
"HTPBE_MULTIPLE_REVISION_LAYERS",
"HTPBE_EDITING_TOOL_FINGERPRINT",
"HTPBE_CHARACTER_OVERLAY_EDIT"
],
"creator": "Adobe Acrobat Pro 24.2",
"producer": "Adobe Acrobat Pro 24.2",
"xref_count": 3,
"has_digital_signature": false,
"creation_date": 1715731200,
"modification_date": 1721260800
}
The verdict is modified. The confidence is certain because HTPBE_DATES_DISAGREE fired. The escrow officer or underwriter does not need to interpret a numeric risk score — HTPBE returns no score. It returns a verdict and the named markers behind it.
What inconclusive Means at a Proof-of-Funds Gate
Not every fraudulent proof of funds is an edited real statement. A growing share are built from scratch: a fraudster recreates a brokerage layout in a general-purpose PDF library, fills in a fake balance, and exports a clean file with no editing history. There is nothing to flag structurally because nothing about the structure is wrong — one write session, consistent dates, no overlay.
A file like that returns inconclusive, and in this market that verdict is not a shrug — it is a signal. Brokerages do not produce account statements with general-purpose consumer or programmatic PDF tools. When a document claiming to be a Fidelity or Schwab statement comes back inconclusive because it was produced by software that no brokerage statement pipeline uses, the correct routing is the same as for modified: do not accept the document at face value.
The practical rule for an underwriting or escrow workflow:
-
modified— the file was edited after the brokerage issued it. Reject the document and request a statement delivered another way (a direct download the borrower screen-shares, or a verification-of-deposit equivalent). -
inconclusive— the file was not produced by an institutional statement pipeline. If you expected a real brokerage statement and the file was built in consumer or programmatic software, treat it as unverified and escalate. -
intact— the file is structurally consistent with a single-pass institutional generation. This reduces structural-fraud risk but does not by itself confirm the balance is real. More on that boundary below.
This mirrors the logic lenders already apply to bank statements. The way lenders verify bank statements treats the structural layer as a filter that decides which documents deserve a closer manual look, not as a final authority on the dollar figure.
The Honest Boundary: Structure, Not Balance
HTPBE reads the file. It does not read the account.
This distinction is the most important thing to understand before integrating structural tamper detection into a proof-of-funds workflow. HTPBE determines whether the submitted PDF was modified after the brokerage issued it — the bytes, the revision layers, the tool fingerprints, the date agreement. It does not verify that the balance is plausible, that the account exists, or that the holdings are real. Those are content-layer and issuer-database questions, and they belong to a different product category entirely.
Three things HTPBE explicitly does not claim to do:
Confirm the balance is real. A statement can be structurally intact and still report a number that no longer reflects the account. HTPBE does not connect to Fidelity, Schwab, or Vanguard. It has no view of the account.
Catch a flawless born-synthetic forgery. If a forger builds a brokerage statement from scratch with a clean toolchain, internally consistent metadata, plausible geometry, and no editing history, there is no structural anomaly to flag — the file is structurally a brand-new document, and HTPBE will return
inconclusive(because the producer is not an institutional brokerage pipeline) rather thanmodified. The wrongness lives in the content, not the structure. In a proof-of-funds context thatinconclusiveis still actionable, but it is not the same as catching a content-level lie.Replace direct verification. Where a true verification-of-assets channel exists — a borrower-authorized read-only feed, or a verification-of-deposit form returned by the institution — that channel is the best source of truth for the dollar figure. Structural detection is the fast filter that runs on every document and tells you which ones to escalate. It is not a substitute for institutional confirmation at the highest stakes.
Being explicit about this boundary is not a weakness of the approach — it is what makes it trustworthy. Structural forensics catches the most common and most economical fraud (editing a real statement) reliably and at scale, and it flags the suspicious-origin cases honestly. It does not overpromise on the content layer, because that would create false confidence and let a clean born-synthetic forgery through.
Integrating the Check Into Underwriting and Escrow
The structural check drops into the proof-of-funds intake before a human reviews the document. Three steps:
- The proof-of-funds PDF arrives — uploaded to a borrower portal, attached to an escrow email, or dropped into the underwriting queue.
- Your system POSTs the file URL to the HTPBE API and receives a check ID, then retrieves the verdict.
-
modifiedorinconclusiveroutes the document to manual review or a request for re-submission via a verified channel;intactproceeds to the normal underwriting checks.
Submitting a file is a single POST:
curl -X POST https://api.htpbe.tech/v1/analyze \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"url": "https://your-storage.example.com/pof/applicant-3318.pdf"}'
That returns a check ID. Retrieve the verdict with a GET:
curl https://api.htpbe.tech/v1/result/ck_7d2e9a1f-3b4c-4e8d-a1f2-6c9b0d3e8a7f \
-H "Authorization: Bearer YOUR_API_KEY"
The response is flat: status (one of intact, modified, inconclusive), modification_markers (the named structural signals), and modification_confidence (certain, high, or none). No numeric score to calibrate, no model to tune. A minimal routing rule in your pipeline:
import requests
def screen_proof_of_funds(file_url, api_key):
headers = {"Authorization": f"Bearer {api_key}"}
submit = requests.post(
"https://api.htpbe.tech/v1/analyze",
headers=headers,
json={"url": file_url},
)
check_id = submit.json()["id"]
result = requests.get(
f"https://api.htpbe.tech/v1/result/{check_id}",
headers=headers,
).json()
if result["status"] == "modified":
return "REJECT_TAMPERED" # file edited after issuance
if result["status"] == "inconclusive":
return "ESCALATE_UNVERIFIED" # not an institutional statement pipeline
return "PROCEED" # structurally intact
For most mortgage and escrow operations the proof-of-funds volume is small — dozens to a few hundred documents a month per branch or team — which puts the cost of structural screening far below the loss exposure on a single accepted forgery. The API reference documents the full response schema, and pricing scales with monthly check volume. The mortgage use-case page covers where structural screening fits alongside the rest of the underwriting stack.
Who Should Read This
Mortgage underwriters and underwriting-operations leads who accept brokerage or investment-account statements as proof of reserves or proof of funds. Real-estate brokers and transaction coordinators who collect proof of funds before presenting a cash offer to a seller. Escrow and title officers who hold proof of funds in the transaction file. Fraud and risk leads at lenders and proptech platforms building document-intake pipelines.
If your proof-of-funds control today is a person looking at a letterhead and a headline number, the structural layer is the piece that catches the edited statement before it reaches that person — and flags the suspicious-origin file honestly, without pretending to confirm a balance it cannot see.
FAQ
Can HTPBE tell me whether the brokerage balance is real?
No. HTPBE reads the structure of the submitted PDF — whether it was modified after the brokerage issued it. It does not connect to Fidelity, Schwab, Vanguard, or any institution, and it does not assess whether the dollar figure is plausible or current. Confirming the balance itself requires a direct verification-of-assets channel, which is a different category of tool.
What if the statement was rebuilt from scratch instead of edited?
A statement generated cleanly by a general-purpose PDF library has no editing history to flag, so it returns inconclusive rather than modified — because the producer is not an institutional brokerage statement pipeline. In a proof-of-funds context that inconclusive is itself actionable: a real Fidelity or Schwab statement does not come out of consumer PDF software. HTPBE does not claim to catch a flawless born-synthetic forgery on content grounds; it flags the suspicious structural origin and routes the file to review.
How is this different from a KYC or identity platform?
KYC and identity platforms confirm that the person is who they claim to be. They do not analyze whether a submitted PDF was tampered with after issuance. An applicant can pass identity verification and still hand over an edited brokerage statement. HTPBE operates on the file itself, independent of who submitted it.
Is a missing digital signature on a brokerage statement a fraud signal?
No. Brokerages overwhelmingly issue statements without a qualified digital signature, so its absence is normal. When a real digital signature is present, HTPBE verifies it and surfaces any post-signature edits via HTPBE_POST_SIGNATURE_EDIT. The absence of a signature is not, on its own, a red flag in this vertical.
Does HTPBE see the dollar amount or the account holder’s name?
No. HTPBE analyzes the structural layer — metadata, cross-reference tables, producer chain, content streams, font and image embedding. It does not parse the balance on the page or attempt to identify the account holder. The verdict is structural; the underwriting decision stays with your team.
