How to Prove the Wire Instructions Came From You, Unchanged

The question the payer cannot answer

A buyer's inbox, the week of closing. A PDF of wire instructions on the title company's letterhead, from a sender that looks right. Two days later a second email, same letterhead, same file name, politely noting that the account has changed. Which one is real? The honest answer is that nothing in either email can tell her. Headers can be forged, letterhead is a picture, a PDF is editable, and both messages are equally confident.

The FBI's Internet Crime Complaint Center recorded 2.77 billion dollars in business email compromise losses in 2024. The playbook behind most of that figure is the same: a payment instruction altered somewhere between the organization that issued it and the person who pays. Capital call notices, closing funds, settlement details, a supplier's "updated" bank details.

What the payer needs to know is whether these exact instructions came from the firm she is paying, and whether anything in them has changed since. Call-back procedures try to answer that with a phone call. This guide is about answering it with evidence the document carries itself, and then with a record that shows who received what, and when.

• FBI IC3 2024 report The source of the loss figure.

What "came from you" has to mean

It is four claims, and each needs its own evidence.

First, your organization issued these exact bytes. The whole file, not the letterhead and not the figures someone reads out. Second, it issued them at or before a fixed time, so a replacement produced later cannot claim to be the original. Third, it delivered them to a named person, not to whoever happened to reach an inbox. Fourth, that person received that version, and anyone holding a copy can check it without having to ask you.

They need separating because each attack goes after one of them. A tampered attachment attacks the first. A backdated replacement attacks the second. A look-alike sender attacks the third. "We never received that version" attacks the fourth. A control that covers one claim and not the others leaves a gap exactly where the next fraud will sit.

Why the usual signals do not settle it

Email authentication, SPF, DKIM and DMARC, proves which domain a message passed through. It says nothing about the attachment, it is lost the moment the message is forwarded, and a message from a compromised mailbox passes every check because it really did come from that domain.

A PDF's metadata is text anyone can edit; the creation date, the author, the producer, all of it rewrites in one command. A visible signature block is a picture. A real digital signature inside the PDF would help, but almost no payment instruction carries one, and the fake arrives as a fresh PDF that nobody compares with anything.

Call-backs are necessary and you should keep them. But a call-back confirms a conversation, not a document. The person on the phone usually reads the same numbers from the same editable PDF, and nothing of the call survives as a record that both sides can check later. Keep the call-back. Give it something exact to confirm.

• How to tell if a PDF has been edited or backdated What forensic inspection can and cannot show.

Step one: fix the document at the moment you issue it

Before the instructions leave your firm, take their fingerprint. The SHA-256 of the file is computed on your side, in the browser or in your own code, and only that hash is sent to Invoance. It is signed with your organization's Ed25519 key, written to an append-only ledger with the server's time, and published on a proof page that shows which organization issued it and whether that organization's domain is verified.

That one record settles the first two claims. The hash fixes the exact bytes: change one digit of an account number and the file hashes differently, as the figure shows. The signature ties those bytes to your organization. The ledger time fixes that they existed by that moment. And the proof page lets anyone drop a copy and see match or no match, with no account and nothing uploaded.

The anchor is made from the dashboard, from the API, or now from Claude or ChatGPT through the Invoance connector. What it does not yet settle is who received the file.

• Document Anchor The record behind the fingerprint.

Step two: deliver it to a named person, not to an inbox

An Evidence Room is a room per fund, deal, matter or client, and it is where the instructions go instead of into an email attachment. Add the file and your browser fingerprints it, which is the anchor from step one, then encrypts it before upload. Invoance holds the encrypted copy and no key that opens it. Name the recipient. She gets her own link. When she opens it she asks for a 6-digit code, which goes to the address you named, and she needs no account. A forwarded link opens nothing on its own, because the code goes to her inbox and nobody else's. Her device decrypts the file, hashes it again and compares it with your fingerprint before the file is saved. If it does not match, it is not saved.

This covers the third and fourth claims. The instructions were delivered to a named person, and the version she holds was checked against yours on her own device, not on your say-so. A recipient who comes back can save a passkey and skip the code, and a room can require a passkey, so a code alone never opens it. That matters, because the emailed code is only as strong as that inbox.

• Introducing Evidence Rooms The product in full: policies, the signed log, pricing.
• How Evidence Rooms work The mechanism, step by step.

Step three: keep the record both sides can check

Every step in the room is a signed entry: room created, file added, recipient added, link opened, file downloaded, access refused, access revoked, policy changed. Each entry takes the next sequence number, carries the hash of the entry before it and is signed with your organization's key, and the database refuses updates and deletes on the log. A gap or a changed entry shows.

The room exports as an evidence package: every entry with its signature, every file fingerprint with its ledger anchor, the recipients and your public key, with instructions for checking it without Invoance. A third party (the payer's bank, the other side's lawyer, an insurer) opens the package, checks each signature and the chain against your public key, hashes the copy they hold and compares. No account, no call to you, no trust in anyone's memory of what was sent.

When the fake arrives

Meridian Title & Escrow issues closing wire instructions on 3 March through a room, with the buyer, Priya Halvorsen, as the named recipient. The log records the file added with its fingerprint, her link opened at 14:12, the code sent, the download, and her device confirming the match.

On 10 March an email in Meridian's name reaches her with the same letterhead and the same file name. The account number ends in 9038 instead of 4471. She, or her lawyer, or the bank, drops the attachment on the file's proof page: no match. The room log shows what Meridian actually sent and when she opened it, each entry signed. The email has no entry anywhere, because it never passed through anything that signs.

The call-back now has a specific question. Not "are these your instructions?", which invites a yes, but "the instructions I was sent through your room end in 4471 and this email says 9038." That is a question a fraudster cannot talk around.

What this does not do

It does not move money, hold funds or check bank accounts. Invoance does not know whether an account belongs to the beneficiary; it knows whether the document in front of the payer is the one you issued. Your approval and call-back controls stay, now applied to a document that has already been checked.

The emailed code is as strong as the recipient's inbox; a saved passkey, or a room that requires one, closes that gap. A country allow list on a room is a control and an audit signal, not a guarantee, since a VPN changes where a request appears to come from. Anyone who can open a file can copy it or photograph the screen. And the browser does the fingerprinting and encryption with the page code Invoance serves, so the claim is that Invoance stores no keys and no readable files, not that reading is impossible.

Set it up before the next closing

Make it a rule that no payment instruction leaves the firm without a fingerprint, and anchor it at issue, not after. Send instructions through a room to named recipients instead of as attachments. Tell recipients, in the engagement letter and in the first email, that instructions only arrive through the room and that any copy can be checked on the proof page. Keep the call-back on the known number, and confirm the fingerprint during it. Export the evidence package at close and keep it with the file.

Evidence Rooms is included from Growth and is its own plan on Developer and Builder. Open your first room from the dashboard:

https://app.invoance.com/dashboard/rooms

• Evidence Rooms Who it is for, what it holds, what it never holds.
• Verify a file Drop any copy on the public proof page.