On this page
The checklist everyone agrees on
Read the wire fraud guidance from a community bank, a title insurer, a payments vendor and a legal software company in one sitting and you will find the same list. Keep account and routing numbers out of email. Call back on a number from your own records, never the one in the request. Require one person to receive instructions and another to release funds. Treat any change of account as fraud until proven otherwise. Refuse requests from free-mail addresses and chat apps. Turn on multi-factor authentication for every mailbox that touches payments. Write the policy down, train people on it and keep a log of each wire.
Every item on that list is worth keeping. This post is not an argument against any of them.
It is an argument about what they look at. Sort the list by the thing each control actually checks and you get mailboxes, domains, phone numbers, people and approvers. The payer, at the moment of sending, acts on a document: a PDF of wire instructions, a capital call notice, a supplier's letter with new bank details. No item on the standard list checks that document.
What each control actually checks
Channel controls check the route. A secure email portal or an encrypted message protects the file in transit, but the file inside is whatever was put there. If the sender's own mailbox, or the document folder it draws from, is the thing that was compromised, the portal delivers the altered file safely.
Domain rules check the sender's address. Refusing gmail.com and WhatsApp stops the crudest attempts. A message sent from a real but compromised company mailbox passes, because it really did come from that domain. SPF, DKIM and DMARC say the same thing in cryptographic form: this message passed through that domain's servers. They say nothing about the attachment, and they are lost when the message is forwarded.
Call-backs check the person. Calling a known number confirms that you are speaking to the firm you mean to pay. What happens next is usually a conversation about numbers: the payer reads digits from the copy they received, the issuer reads digits from the file they sent, or more often someone simply confirms "yes, we sent instructions on Tuesday". Each side is checking its own copy.
Dual approval checks the approver. A second person looks at the same request and the same PDF. If the PDF is wrong, two careful people approve it.
The change rule checks for a change. It catches the attack everyone has heard of: a second email, a week later, announcing a new account. It is the right instinct and the most important single red flag on the list.
The fake that passes every check
Business email compromise usually starts with access to a mailbox somewhere in the transaction, followed by weeks of quiet reading. The attacker learns who sends what, how the instructions look and when the money moves. The patient version does not send a second email announcing a change. It replaces the attachment in the first one.
Follow that through the list. The instructions arrive from the real domain, through the usual channel, so the channel and domain rules pass. There is no change of account to notice, because this is the first set the payer has seen. The call-back goes to the right number, from the right records, and reaches the right person, who confirms truthfully that instructions went out on Tuesday. The second approver approves a request that has been called back. The log records a verification that verified everything except the file.
The fault is not with the people. They did what the policy asked. The policy simply never asked anyone to compare the file the payer held with the file the issuer sent.
Add the control that checks the document
Checking the document means two things. The issuer fixes the exact file at the moment it is issued, and the payer can compare their copy with it without asking anyone.
The first part is a fingerprint. Before the instructions leave, the issuer's browser computes the SHA-256 of the file and sends only that hash to Invoance, where it is signed with the organization's Ed25519 key and written to an append-only ledger with the time. Change one digit of the account number and the file hashes differently. The record has a public proof page: anyone can drop a copy on it and see match or no match, with no account and nothing uploaded.
The second part is delivery. In an Evidence Room the issuer names each recipient. The file is fingerprinted and encrypted in the browser before upload, so Invoance holds the encrypted copy and no key that opens it. The recipient opens their own link with a 6-digit code sent to the address the issuer named, with no account, and their device decrypts the file, hashes it again and compares it with the issuer's fingerprint before saving it. A forwarded link opens nothing on its own.
Now the fake from the last section has somewhere to fail. A swapped attachment does not match the fingerprint the issuer anchored, and an email that never went through the room has no entry in its log.
Wire instruction controls
0 of 10 in placeGive the call-back something exact to confirm
Keep the call-back. Change what it confirms.
Before the call, the payer drops the instructions they hold on the file's proof page, which shows the issuing organization, whether its domain is verified and the fingerprint it anchored. If it does not match, there is nothing to discuss on the phone except how the wrong file arrived. If it matches, the call is short: the payer reads the beneficiary name and the full account number aloud, digit by digit, and the issuer confirms them against the file they sent through the room.
Compare that with "are these your instructions?", which invites a yes from anyone who wants the money. A specific question about a file both sides can check is much harder to talk around.
The same applies to the change rule. When a supplier writes to say its bank details have changed, ask for the new details through a room, or anchored with a proof link, and refuse the rest. The genuine supplier loses a minute. The fake has nothing to offer.
A wire log nobody can edit, including you
Every checklist ends with documentation: record who requested, who verified and who released each wire, and review the log. Most firms keep it in a spreadsheet or a field in the payments system. That is useful for review and weak as evidence, because whoever can write to it can also rewrite it after a loss.
Two records do better. The room's own log records each step of the delivery as a signed entry: file added, recipient added, link opened, file downloaded, access refused, access revoked. Each entry carries the next sequence number and the hash of the entry before it, and the database refuses updates and deletes. The verification and the release go in the Event Ledger, posted from the dashboard, from your own system with POST /v1/events, or from Claude or ChatGPT through the Invoance connector. Each event is hashed, signed with your organization's key and stored where it cannot be edited, with its own proof page.
Put the facts you would want in front of an auditor in the payload: the reference, who verified, which number was called and where it came from, who released, and the last four digits of the account. Leave the full account number out; the anchored file already holds it.
{
"event_type": "wire.released",
"payload": {
"reference": "PO-88412",
"beneficiary": "Halden Steel Ltd",
"account_last4": "4471",
"instructions_record": "9549c332-a52b-4f7e-9b1a-7d2e6c0f4a8b",
"proof_check": "match",
"callback_number_source": "vendor master, set 2025-03-14",
"verified_by": "j.okafor",
"released_by": "m.santos"
}
}
What this does not do
None of this moves money, holds funds or checks 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 the issuer sent. Bank-side account name checks, where your bank offers them, answer a different question and belong in the process too.
It also does not repair a compromised issuer. If an attacker can sign in to the issuer's own dashboard, they can anchor and send their own file, which is why the dashboard supports passkeys and why approval rules still matter on the issuer's side. The emailed code is as strong as the recipient's inbox; a saved passkey, or a room that requires one, closes that gap. Anyone who can open a file can copy it.
Start with the next set you send
Pick the next wire instructions, capital call or closing statement that leaves your firm and send it through a room instead of as an attachment. Tell the recipient, in the same message, that instructions only ever arrive that way and that any copy can be checked on the proof page. Keep your call-back and ask the exact question. Record the release in the Event Ledger. After one transaction you will know whether it fits your process.
The first room is free on Developer and Builder: one room at a time, 100 MB and up to ten recipients, with the same encryption, signed log and evidence package as the paid plan. Evidence Rooms is included from Growth.