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 borrower needs $40,000 for a down payment and does not have it. A relative steps in to gift the funds, so the file gets a gift letter: signed, naming the donor, stating the amount, and confirming no repayment is expected. To prove the money is real, the borrower also supplies the donor’s bank statement showing the funds are available, and their own statement showing the deposit arriving. The paper trail closes. The processor checks the box and the loan moves toward approval.
Every step here was done correctly. And the down payment could still come from a source that disqualifies the loan.
The reason sits in one document almost nobody examines closely: the donor’s bank statement. It belongs to a third party the lender has no relationship with, never onboarded, and cannot call without going through the borrower. It is the single least-scrutinized PDF in a mortgage file — and it is easy to alter, either to manufacture funds that were never seasoned or to hide a donor who is not allowed to give a gift at all.
That blind spot is what makes mortgage gift letter fraud so durable: the rest of the file gets verified closely, and the one document that proves where the money came from gets the least scrutiny. This article walks through how underwriters actually verify down-payment sourcing today, exactly where that process breaks on an altered donor-statement or asset-letter PDF, and the structural forensic layer that closes the gap. It is written for mortgage underwriting and lending-risk operations teams, with a short integration section at the end for the people who wire it in. It is the sourcing-side companion to our piece on altered paystubs and W-2s — same blind spot, the other side of the file.
Why Down-Payment Sourcing Exists at All
Lenders care intensely about where a down payment comes from for two reasons that have nothing to do with whether the borrower can afford the house.
The first is money laundering. A down payment is one of the largest cash movements an ordinary person makes, and an unexplained lump sum is exactly the kind of transaction anti-money-laundering rules exist to catch. Sourcing proves the money has a lawful, documented origin.
The second is loan integrity. Mortgage programs cap how much of a down payment can be a gift and who is allowed to give one. Conventional loans permit gifts from family but strictly prohibit gifts from any party with a financial interest in the transaction — the seller, the listing or buyer’s agent, the builder. The reason is simple: a “gift” from the seller is not a gift. It is a hidden price reduction or kickback that inflates the recorded sale price and the loan against it. That distorts the loan-to-value ratio that the entire loan is priced on, and it is fraud against whoever buys the loan on the secondary market.
So sourcing is not box-ticking. It keeps the recorded purchase price honest and the funds clean — which is exactly why the documents that prove it are worth attacking.
How Underwriters Verify Down-Payment Sourcing Today
Sourcing is one of the more disciplined corners of underwriting, and no single document carries it. Underwriters stack several controls and look for them to agree.
Require a compliant gift letter. The gift letter is the foundation. It names the donor, states the relationship to the borrower, specifies the exact amount, gives the property address, and certifies in writing that the money is a true gift with no expectation of repayment. A complete letter establishes the claim; it does not, on its own, prove the claim.
Source the donor’s funds. The donor must show they actually had the money to give. The lender asks for the donor’s bank statement evidencing the funds before the transfer — the donor’s ability to gift is not assumed, it is documented.
Trace the paper trail end to end. This is the heart of sourcing. The underwriter follows the money as a chain: funds leaving the donor’s account, then the same amount arriving in the borrower’s account or at closing. A wire confirmation, a copy of the gift check with the matching debit, and the deposit on the borrower’s statement should match in amount and timing. A gift that appears in the borrower’s account with no matching withdrawal from the donor is a broken trail and gets flagged.
Season and source large deposits. Underwriters examine the borrower’s own statements for large or unusual deposits. Funds that have stayed in the account for the program’s seasoning window — typically two or three monthly statement cycles — are considered the borrower’s own and need no further sourcing. A large deposit that appears recently and without explanation must be documented, or it cannot be counted toward the down payment. Seasoning is the lender’s defense against money that was added at the last minute from an undocumented source.
Confirm the donor where the program demands it. For some programs and some amounts, the lender confirms the donor’s identity and, critically, that the donor is not a prohibited party with an interest in the sale.
Each of these is a real, valuable control, and stacked together they catch a great deal: missing letters, broken trails, unseasoned lump sums, gifts that do not reconcile. The question is not whether the process works. It is what it was built to verify — and where the donor’s uploaded PDF slips between the controls.
The Gap: Sourcing Verifies Plausibility, Not File Integrity
Read that control list again and notice the common thread. Every check confirms whether the numbers and the trail are internally consistent: does the donor’s balance cover the gift, does the debit match the deposit, has the money seasoned long enough? These are content checks. They ask, “Could this trail have happened?”
None of them ask the other question: “Was this PDF edited after the bank produced it?”
That is the gap a careful forger lives in, and the donor statement is the softest target in the file. The lender has a relationship with the borrower — it onboarded them, ran identity checks, and has their accounts on record. It has no relationship with the donor. The donor exists in the file only as a name on a letter and a PDF the borrower uploaded on their behalf. The lender cannot independently pull the donor’s statement from the donor’s bank; it receives whatever the borrower hands over. And because a gift is, by design, a one-time event from someone outside the transaction, there is no baseline of earlier donor documents to compare against. The donor statement is a single, unanchored PDF from a party no one verified.
Two attacks follow directly from that, and both defeat content checks completely.
Manufacturing seasoned funds. The borrower has the money, but it arrived too recently to count — a recent lump sum from a source they would rather not document, or funds that simply have not cleared the seasoning window. They download a real statement, open it in an editor, and adjust the dates or the opening balance so the funds appear to have been present for the full seasoning period. The trail now reconciles. The deposit math works. The seasoning check passes — against a date that was typed in.
Hiding an ineligible donor. The funds genuinely came from a prohibited party — the seller covering the buyer’s down payment to push the deal through, or an agent or builder doing the same. The borrower instead produces a gift letter and a donor statement in the name of an eligible donor, a cooperative relative, and edits the account holder name, the balance, or the transaction lines so the laundered source disappears behind a permitted one. The paper trail now shows a clean family gift. The real origin — the one that disqualifies the loan and distorts the price — is edited out of the PDF.
In both cases the forger had every advantage. They started from a real bank statement on the bank’s real template, in the right fonts. They could adjust the edited figures to be internally consistent — a balance that covers the gift, a date inside the seasoning window, a debit that matches the borrower’s deposit. On screen, an edited number looks exactly like an original one: the editor renders it in the same font at the same position. A patient forger produces a donor statement that passes every sourcing check on the list, because the content was tuned specifically to pass those checks.
And the usual backstops do not reach here. KYC and identity platforms confirm who the borrower is — ID match, watchlist, liveness — not whether a third party’s uploaded statement was altered. A Verification of Deposit can confirm the borrower’s accounts at the source, but the donor is not the lender’s customer, so there is no equivalent automated lookup against the donor’s bank. The fake asset letter and the altered donor statement sit precisely in the space where the source-of-truth checks have no reach and the content checks cannot see the edit.
The Missing Layer: Structural File Forensics
A PDF is not a flat picture. It is a structured file that carries an internal record of how it was built and saved — when it was created, what software produced it, whether it holds a digital signature, and how many times it was written to disk. When someone opens a bank’s original statement and saves an edit, that act leaves traces in the file’s structure, no matter how plausible the visible balance and dates are.
Structural forensics reads that internal record and returns a verdict. It never judges whether a $40,000 balance is a believable amount for a donor to hold, or whether a deposit date falls inside the seasoning window — that is the underwriter’s job and the content layer’s job. It judges whether the file’s own construction is consistent with a clean, single-pass export from a bank’s statement system, or whether it bears the marks of having been opened and re-saved in an editing tool after the fact.
HTPBE is a self-serve API that performs exactly this analysis. You send it a PDF; it returns one of three verdicts plus a list of named markers describing what it found. It is not a KYC or identity vendor and was never meant to be one. It does not replace the gift-letter requirement, the paper trail, or the seasoning rule — those are sound controls and you should keep all of them. It answers a single, narrow question that those controls never ask: was this file altered after it was created?
The three verdicts
-
intact— no evidence of post-creation modification, and the file looks like a genuine institutional export. The structural layer found nothing to flag. -
modified— the file carries forensic evidence that it was changed after it was first generated. This is the case that matters most for fraud: a donor statement that should be a clean bank export but instead shows the fingerprints of an editing session. -
inconclusive— the file was produced by consumer software, an online editor, or a scanner, so there is no institutional baseline to check integrity against. This is not a pass. It is a routing signal, and in sourcing verification it is frequently the most useful verdict of all (more on that below).
What it actually catches — in plain terms
Without turning this into a how-to for forgers, here is the kind of structural evidence the analysis surfaces, described as outcomes rather than recipes:
-
Editing-tool fingerprints. Genuine bank statements are produced by the bank’s server-side statement system. When a donor statement instead carries the signature of a consumer PDF editor or an online conversion service, that origin is inconsistent with a real banking pipeline. The marker
HTPBE_EDITING_TOOL_FINGERPRINTflags this. -
Disagreeing internal timestamps. In a clean export, the internal creation and modification timestamps match. When they contradict each other — the file claims one creation moment but was last written later — that gap is recorded in the file structure even though it is invisible on the page.
HTPBE_DATES_DISAGREEcovers this. It is especially relevant when seasoning dates are exactly what a forger would want to move. -
Multiple revision layers. Each time a PDF is edited and saved, the change is appended as a new layer on top of the original. A statement that should have been generated in a single pass but instead shows several stacked write sessions reveals that it was modified after creation. The marker is
HTPBE_MULTIPLE_REVISION_LAYERS. -
A spoofed institutional producer. Some tools try to disguise their involvement by rewriting the file’s stated generator to impersonate a legitimate banking or institutional system. When that producer identity has been forged to mask the real origin, the analysis flags it with
HTPBE_PRODUCER_IDENTITY_FORGED. -
Tampering around a digital signature. Where a statement or asset letter is digitally signed, the analysis detects content changed after signing (
HTPBE_POST_SIGNATURE_EDIT) or a signature stripped off entirely (HTPBE_SIGNATURE_REMOVED). These are among the most conclusive signals there are.
None of these depend on the visible numbers being implausible. A perfectly reconciled donor balance, a deposit date neatly inside the seasoning window, an account holder name that matches the gift letter — all of it can sit inside a file that was edited, and the edit is what gets caught.
Want to see it on a real document? You can drop a donor bank statement or an asset letter into the free check on this site and get a verdict in a few seconds — no account needed. It’s the same engine the API runs, and it’s a fast way to check a single suspicious sourcing document before you decide whether to wire it into your intake.
What inconclusive Means in a Sourcing Context
The inconclusive verdict is the one that confuses people, so it is worth being precise — and in sourcing it carries unusual weight.
inconclusive means the file was created in software anyone can use to build a document from scratch — Word, Excel, an online editor, a scanner. Because there is no institutional baseline, the structural layer cannot say whether the content was tampered with. It is telling you, honestly, “I cannot verify integrity here.”
The power of that verdict comes from context — specifically, where the document claims to come from.
A donor’s bank statement claims to come from a bank. Banks generate statements on server-side systems, and a genuine statement from one should look like an institutional export. So if a borrower hands you a donor statement claiming to be from a major retail bank, and the analysis returns inconclusive because the file was actually built in a word processor or run through an online editor, the verdict is doing real work: a real statement from that bank would not look like that. That mismatch is a reason to escalate — ask for a fresh statement pulled directly by the donor, or for the wire confirmation from the donor’s bank — not to accept the file and count the funds.
The asset letter case is even sharper. A “verification of funds” or asset letter that purports to be issued on bank letterhead but returns inconclusive because it was assembled in consumer software is, structurally, a consumer-software document wearing a bank’s logo — a fake asset letter caught at the file layer.
The same inconclusive verdict on a statement from a small credit union that genuinely exports through generic software is routine. The verdict is identical; the action depends on whether the claimed source is supposed to produce institutional files. Used this way, inconclusive is not a dead end — it is often the signal to fall back to the source-of-truth step that the document was standing in for.
Honest Limits — What This Layer Cannot Catch
Structural forensics is a powerful additional control, not a fraud oracle. Two scenarios sit outside its reach, and a serious underwriting team should know them.
Documents fabricated entirely from scratch in institutional-looking software. If a forger does not edit a real statement but instead builds a fake one from zero using tooling that emits clean, single-pass, institutional-looking output, there is no “original” to compare against and no editing event to detect. The file may look clean structurally because, structurally, it is a clean single-pass file — it just contains invented balances and invented transaction lines. This is exactly where the paper trail and source-of-truth steps remain the right controls: a wire confirmation pulled from the donor’s bank, or asking the donor to produce a statement through the bank’s own portal in front of a loan officer, corroborates the funds against a source the borrower never touched. The structural layer’s strength is the far more common case — editing a real document — not fabrication from nothing.
Legitimately consumer-generated sourcing documents. Some small institutions really do export statements through generic office software, and some donor records legitimately come from a basic banking platform. For those, inconclusive is the correct and expected verdict, and reading it as guilt would generate false positives. The signal only carries weight when the claimed source has an institutional baseline to deviate from.
Being upfront about these limits is the point. The structural layer is designed to slot alongside your existing sourcing process — catching the altered-PDF case that the gift letter, the paper trail, and the seasoning rule cannot see — not to be a single switch that decides loans on its own. It is additive. The existing controls keep doing what they do well; this catches the one thing they were never built to see.
Wiring It Into Your Sourcing Workflow
For teams that decide the structural layer belongs in their intake, integration is deliberately small. The pattern is three steps.
1. Analyze the uploaded document. When a borrower uploads a donor bank statement, an asset letter, or their own statement for seasoning, send its URL to the analyze endpoint. There is no numeric risk score to interpret — you get a verdict and named markers.
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/sourcing/loan-7821-donor-statement.pdf"}'
The response is just the check ID:
{ "id": "506a6b1b-1360-48a2-b389-abb346f85d04" }
2. Fetch the verdict. Retrieve the result by ID. The response is a flat object — the two fields your policy cares about are status and modification_markers.
curl https://api.htpbe.tech/v1/result/506a6b1b-1360-48a2-b389-abb346f85d04 \
-H "Authorization: Bearer YOUR_API_KEY"
{
"status": "modified",
"modification_markers": ["HTPBE_EDITING_TOOL_FINGERPRINT", "HTPBE_DATES_DISAGREE"],
"modification_confidence": "certain"
}
3. Route on the verdict. Wire the three outcomes into your existing sourcing queue rather than auto-deciding on any single marker:
-
modified→ route to manual review and require a source-of-truth confirmation before the funds count — a wire confirmation pulled from the donor’s bank, or a fresh statement produced through the bank’s own portal. For the most conclusive markers, such as a post-signature edit, reject. -
inconclusive→ branch on the claimed source. A consumer-software origin on a statement or asset letter claimed to be from a major bank is worth escalating; the same verdict from a small institution that genuinely exports through basic software is routine. -
intact→ no structural evidence of alteration; proceed with your normal sourcing verification.
Store the check ID against the loan file. If a credit decision is ever disputed or audited, or a loan is challenged for repurchase, the forensic result stays available as a permanent record showing exactly which structural signals fired — useful for both compliance and repurchase defense.
Who Should Add This Layer
If you run underwriting or fraud operations at a mortgage lender, and a meaningful share of your files involve gift funds, donor statements, or seasoned large deposits — especially where the donor is a third party you have no way to verify at the source — this is the gap in your stack worth closing. Your underwriters are already sourcing funds well: requiring the letter, tracing the trail, enforcing seasoning. What they cannot see, by design, is whether the donor’s PDF was edited after the bank produced it. That blind spot is exactly where the manufactured-seasoning and hidden-donor frauds operate, and it is exactly what a structural layer covers.
For the donor and asset-letter side of this specifically, our fake asset letter detection use case goes deeper on the document type. For the income side of the same mortgage file — altered paystubs and W-2s — see the forensic layer mortgage underwriting misses. When you’re ready to put a verdict behind your sourcing intake, create an account and the self-serve API is documented end-to-end with test keys you can wire up before you spend a credit.
