Wire Fraud in Real-Estate Closings: Forged Escrow and Title PDFs

The scenario below is a composite illustration built from publicly documented patterns of real-estate wire fraud. It is not a customer incident, and no real transaction, party or institution is depicted.

Two days before closing, the buyer gets an email. It is the thread they have been on for six weeks, with the same subject line and the same signature block. Attached is a PDF: wire instructions on the title company’s letterhead, with the settlement statement reference, the file number, the escrow officer’s name, and a routing and account number for a $312,000 transfer.

The buyer wires the money. A week later the escrow officer asks where the funds are.

This is one of the most-documented document frauds in American real estate, and the response to it has been almost entirely procedural: call to confirm, never trust emailed instructions, use a secure portal. Keep those controls. But they all evaluate the request — who asked, through which channel, with what urgency. None of them evaluate the file. This article is about the file: what an altered closing document leaves behind in its own structure, what a title or escrow operation can automate at intake, and the variant of this fraud where there is nothing structural to find.

The broader map of real-estate document fraud — deed and title forgery, fake powers of attorney, altered purchase agreements — is covered separately. This piece stays on the closing table.

What the FBI Data Actually Says

This fraud is a business email compromise, and BEC is the category the FBI tracks it under. In 2022 the Internet Crime Complaint Center recorded 21,832 BEC complaints with adjusted losses over $2.7 billion, and the report names the real-estate sector among the scheme’s established targets.

Two things that figure does not tell you. It covers all BEC-driven wire fraud, not closings specifically. And nothing in the report separates losses that ran through a forged PDF from instructions simply pasted into an email body. Treat it as the scale of the surrounding problem, not as a measurement of document forgery — the argument here rests on the mechanism below, not on the size of that number. A related caution: IC3’s separate “Real Estate” category is frequently quoted for this fraud and does not fit it, covering investment, rental and timeshare losses rather than diverted closing wires. We compile figures across verticals in our document fraud statistics breakdown.

More useful than either number is a tactic the same report flags. IC3 describes an increasingly prevalent tactic of BEC actors spoofing legitimate business phone numbers to confirm fraudulent banking details — victims report calling a title company or realtor on a known number, and only later discovering that the number had been spoofed. That is the out-of-band callback, the control this entire industry leans on, being defeated on purpose.

Two Frauds That Look Identical in the Inbox

The recipient cannot tell these apart. Structurally they could not be more different, and confusing them is how vendors end up overpromising.

Variant A — the intercepted original. The attacker has access to a mailbox somewhere in the transaction: the buyer’s, the agent’s, the escrow officer’s, the lender’s. They pull the genuine wire instruction the title company issued, open it in an editor, replace the account and routing numbers, save, and send it on from the compromised account or a spoofed reply. The document is real. One field is not.

Variant B — the fabricated impersonation. The attacker never touches the genuine document. They register a look-alike domain, rebuild a plausible wire-instruction letter from scratch using the title company’s public branding, and send it fresh. Nothing was altered, because nothing genuine was involved.

Structural PDF forensics is where Variant A is most likely to be caught, and it is largely silent on Variant B. Neither half of that is a guarantee, and the boundary is set out below. That asymmetry is the honest core of this article. First, why Variant A survives the controls meant to stop it.

Why Closing Controls Do Not See the File

The standard defenses at a closing are good at what they were designed for:

• Out-of-band callback — the buyer calls the escrow officer on a number from an earlier document, not from the email.
• Wire-fraud advisories — the “we will never change wire instructions by email” notice, signed at engagement.
• Secure portals — instructions delivered through an authenticated channel rather than as an attachment.
• Dual authorization on the disbursement side.

Each one tests whether the instruction is plausible and whether the person asking is who they claim to be. A determined attacker gets past all four often enough for the losses to keep accumulating: compromised mailboxes make the callback ring a number the attacker supplies, portal credentials get phished, and a buyer who has never closed before does not know what is unusual.

None of these controls opens the PDF and asks how it was built. And a sharper reviewer cannot close that gap. A reviewer reads the page: the right file number, the letterhead, the escrow officer’s name spelled correctly. That is the content layer — the words and numbers rendered on the page. The evidence that a field was changed after issue is not on the page. It is in the file underneath: which software wrote the bytes, how many times the file was saved, and what its internal timestamps say about when it was created versus when it was last written to. You cannot read that more carefully. It is not in the letter.

Closing timelines make it worse. Wire instructions arrive inside a compressed window where every party is trying to fund on schedule, and asking to slow down for verification carries a real cost. Fraudsters pick that window deliberately.

What an Altered Wire Instruction Leaves Behind

A title company’s wire instruction is an institutional document. It comes out of a settlement platform, a document-assembly system, or a closing-package generator — an issuance pipeline that emits the document to the parties and does not take it back for editing. Editing that file afterwards changes how it is constructed, in ways that normally survive ordinary email delivery. One caveat before you deploy: some corporate mail gateways sanitize or rebuild PDF attachments in transit, which changes how the file is constructed and can itself produce a finding. That is a benign source of disagreement, and one more reason a finding is a prompt to re-confirm rather than a conclusion. In outcome terms:

The software that wrote the file stops matching the issuer. Every PDF records the software that produced it — a genuine closing document carries the fingerprint of the settlement platform that generated it. Reopen it in a desktop or browser-based editor and save, and the file carries that editor’s identity instead of — or alongside — the original. A wire instruction that reports it was last written by a consumer PDF tool did not leave the title company that way — though the re-save could equally have happened at any innocent hop between issuer and inbox, which is why this is a reason to re-confirm, not to conclude.

The document gains an edit history it should not have. Reopening a PDF and saving it appends a further revision layer. A wire instruction that records having been created, then changed, then saved again was reopened after issue — by someone, at some point in its handling; the file records the fact of the edit, not its author.

Internal timestamps disagree. A PDF carries its own record of when it was made and when it was last modified. When the modification record postdates creation, the file is stating that it was written to after it was made.

A signed or sealed document shows work after the seal. Some closing packages carry a digital signature. If content changed after that signature was applied, the file records that the sealed region no longer matches the page. A stripped signature leaves its own residue.

A changed value on the page leaves its own trace. When a number or a line of text on an issued document is altered after the fact, the file acquires a structural trace of that alteration — and the report names that finding directly.

None of this requires the original document for comparison. The submitted file is measured against how genuinely issued institutional documents are constructed, not against a copy the recipient does not have.

What the API Returns on an Altered Closing Document

HTPBE? is a two-step call: POST the PDF’s URL to /v1/analyze for an id, then 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.

An illustrative result — synthetic and abridged to the relevant fields, not taken from a customer file — on a wire instruction whose account number was swapped in a desktop editor before being forwarded:

{
  "id": "9c1e4f2a-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": "Settlement Document Platform",
  "producer": "Desktop PDF Editor",
  "has_digital_signature": false,
  "creation_date": 1789689600,
  "modification_date": 1789948800,
  "usage_caution": {
    "safe_for_automated_adverse_decision": false,
    "recommended_action": "route_to_human_review",
    "message": "Structural evidence of post-creation modification was found. Route this document to a human reviewer before any decision — do not use this verdict as the sole basis for an automatic adverse decision against a person."
  }
}

Read in business terms: the file’s own modification timestamp postdates its creation timestamp; it carries the fingerprint of a desktop editing tool that has no place in a settlement platform’s issuance pipeline; it records more than one generation; and it carries the trace of a targeted character-level edit to the page.

The usage_caution block is part of the contract, not documentation garnish. A structural verdict describes the file, not the person who sent it. modified means this specific PDF was written to after it was created — it does not establish who did it, whether they intended fraud, or that anyone in the transaction is a criminal. A compromised mailbox means the sender is frequently a victim too. The correct action is to stop the wire and re-confirm through a channel the attacker cannot have touched, not to accuse a party.

inconclusive deserves the same discipline. It means the file does not carry the structural history needed to confirm integrity either way — many everyday documents are produced by ordinary desktop and office software that simply does not leave that history behind. That is not a detector failure and it is not guilt.

What inconclusive should trigger depends on what the document was supposed to be, and the two cases in a closing file are genuinely different. On an inbound issuer document — a wire instruction, a payoff letter — it is informative, because a settlement platform is not normally producing those with everyday desktop software; there, inconclusive is a reason to request a fresh copy from the issuer. On a returned signing package, inconclusive is closer to expected, and no issuer is holding a cleaner original to send you.

Worth knowing before you wire the branch: the API returns request_from_issuer on every inconclusive — it reads the file, not your workflow. Which of the two cases applies is the integrator’s call, so carry the document class into the branch yourself. There the verdict simply means this file cannot be cleared structurally, so confirm it the way you already confirm signings — with the signing agent and the executed originals — rather than chasing a re-issue that does not exist.

The Forgery With No Edit to Find

Here is the limit, stated plainly, because a title or escrow operation deciding whether to deploy this needs it before the sales pitch, not after.

Variant B — the wire instruction fabricated from scratch on a look-alike domain — contains no post-creation modification, because nothing was modified. The attacker built a new document. Structural analysis asks “was this file written to after it was created?” and on a fabricated file the truthful answer is no. A synthetic document can be entirely fraudulent and carry no evidence of alteration, because there was none.

Fabrication is a real and separate attack; this check does not cover it, and no amount of structural analysis will change that. We would rather say so than let anyone deploy this believing it closes the whole attack surface. What partially covers it is the inconclusive route described above: a document that should have been institutionally issued but cannot be confirmed as such is a reason to go back to the issuer for a fresh copy, whatever produced the file in front of you.

Two further boundaries worth stating in the same breath:

• It does not verify the parties. HTPBE? performs structural PDF tamper detection. It does not verify identity, confirm that a sender is the escrow officer they claim to be, or check issuer records. Those are different products answering different questions.
• It does not validate the account. An intact wire instruction is not confirmation that the routing and account numbers belong to the title company. Account-verification and confirmation-of-payee services answer that; this does not.

Which is why the callback stays. Structural forensics removes one specific failure mode — an edited genuine document passing as untouched — from a stack that still needs the rest of its layers.

Where the Check Fits in a Closing Workflow

For a title agency, escrow operation, or closing platform, the useful placement is where a document enters the file from outside your own system:

1. Inbound wire instructions and payoff letters — lender payoff statements, seller wire instructions, HOA and municipal payoff documents. These arrive from third parties and authorize where money goes.
2. Returned closing packages — signed documents coming back from a remote signing or a mobile notary, before they are recorded or disbursed against.
3. Any document supporting a change to disbursement instructions — the highest-leverage gate in the workflow.

Run the check before funds move, and store the check id and the full response payload against the file number. Results stay retrievable from the API for up to three years (see the privacy notice), so keep your own copy rather than relying on retrieval — real-estate disputes outlive that window. Whether such a record is accepted as evidence in any proceeding or claim is a matter for your counsel and your insurer.

import os
import requests

API = "https://api.htpbe.tech/v1"
HEADERS = {"Authorization": f"Bearer {os.environ['HTPBE_API_KEY']}"}

def check_closing_document(pdf_url: str, file_number: str, document_class: str) -> dict:
    submit = requests.post(
        f"{API}/analyze",
        headers=HEADERS,
        json={"url": pdf_url},
        timeout=15,
    )
    submit.raise_for_status()

    result = requests.get(
        f"{API}/result/{submit.json()['id']}",
        headers=HEADERS,
        timeout=15,
    ).json()

    # Persist against the escrow file for audit, whatever the verdict.
    log_closing_check(file_number, result["id"], result["status"])

    action = result["usage_caution"]["recommended_action"]
    if action == "route_to_human_review":
        # Pause the wire and open a review task — a person decides, not this branch.
        queue_for_human_review(file_number, result["modification_markers"])
    elif action == "request_from_issuer":
        # Not a finding against anyone. The API returns this for every
        # `inconclusive`, so route on the document class you already know:
        # an inbound issuer document can be re-requested; a returned signing
        # package cannot, and goes to the signing agent instead.
        hold_for_confirmation(file_number, document_class)

    return result

Branching on recommended_action rather than on status keeps the guardrail in the code path: modified opens a human review task, inconclusive routes into a class-aware confirmation hold, and neither branch reaches a decision about a buyer or seller on its own — a person does.

The full request and response reference, error codes, and the test-key scenarios that return deterministic synthetic results are on the API page — you can wire the integration against a test key before a live document ever touches it. Volume pricing for title agencies and closing platforms running whole packages through the check is on the pricing page. If your exposure sits on the asset side rather than the disbursement side, the companion piece on forged proof-of-funds statements covers that document.

Who Should Run This

If you disburse other people’s money against documents that arrived by email, the gap is yours. In practice that is escrow and settlement officers who know a callback-verified instruction can still turn out fraudulent; title agency operations leads standing up intake controls across branches; and engineering teams on closing, e-signing, and settlement platforms who want a per-document integrity check at the disbursement gate.

A callback done properly — known number, account digits read back — is a strong control, and nothing here replaces it. But it is strong only when it is done properly, and it is the step most likely to be skipped or subverted in the last forty-eight hours before funding. Whether the attachment is the file the title company issued is a different question, answerable from the file’s own bytes in two API calls — before the money moves rather than after.