How to send wire instructions to a client without enabling BEC fraud

Last Friday a title company in Phoenix wired $740,000 to an account that wasn't the seller's. The buyer got an email with new wire instructions the morning of closing, called the number in the email to "verify," spoke to someone who sounded reassuring, and sent the money. By Monday the funds were in three different banks in two countries. The seller never sent new instructions. The "verification call" went to the criminal who hijacked the email thread.

This story has played out in tens of thousands of US Business Email Compromise complaints over the last several years. The FBI's IC3 reported roughly $2.77 billion in BEC losses in 2024 alone (commonly rounded as "approaching $2.8 billion"). Real estate, legal settlements, and M&A closings consistently rank among the highest-loss verticals year over year. If your team sends wire instructions as PDF attachments to client emails — and almost every team does — you are one compromised inbox away from being the next case study.

This post is about what to do instead. Not "verify by phone" — that advice is older than the problem and is exactly what failed in Phoenix. A tool-based control that fits inside the workflow your closers, paralegals, and finance ops already run every day.

Why "call to verify" stopped working around 2019

The conventional advice in every fraud-awareness training deck is some variant of: "When you receive wire instructions by email, call the sender at a known-good phone number to verify the account and routing numbers before initiating the wire."

This advice was correct in 2010. It started failing around 2015. By 2019 it was the dominant pattern in successful BEC losses, not the defense against them.

Three reasons it stopped working:

• The attacker is in the thread. Modern BEC is rarely a spoofed email from outside. It's a real message from a real compromised mailbox — the seller's attorney, the listing agent, the M&A advisor's analyst. The attacker has been reading the thread for two weeks. They know everyone's name, the closing date, the loan officer's nickname for the buyer.
• "Known-good phone number" is a phrase, not a control. The buyer looks at the email signature for the phone number. The attacker edited the signature. Or the buyer Googles the firm — and the attacker bought a sponsored ad with a number that rings their burner. Or the buyer calls the legitimate number, gets voicemail, and the attacker calls back from a spoofed caller-ID minutes later.
• The wire instructions ARE the credential. Once the routing number and account number land in the recipient's inbox, the recipient treats them as the source of truth. Even if they call to verify, they read THE NUMBERS BACK from the email. The attacker says "yes, those are correct." Of course they are — the attacker put them there.

The phone-verification control assumes the channel is independent. Email and phone aren't independent anymore. A compromised mailbox and a spoofed phone number live on the same side of the trust boundary.

What the workflow actually needs

A control that closes BEC isn't "be more careful." It's a structural property of how the instructions get from sender to recipient. Four properties, all of them have to hold:

1. The instructions never sit unencrypted in an email inbox. Inboxes get breached. Drafts folders get scraped. Anything that lives in cleartext in someone's Outlook is exposed forever to whoever owns the password (or the OAuth token, or the IMAP grant a forgotten app still holds).
2. The recipient has to actively prove they're the right person to view the instructions. Not "they have the email." Email forwarding rules are how attackers harvest these threads in the first place. The recipient identity needs to be bound to the access event, not to the inbox the link landed in.
3. The instructions self-destruct after the recipient reads them. Once the wire is queued, the document has no further purpose. Leaving it in three different inboxes (sender, recipient, CC compliance) creates a perpetual attack surface.
4. There has to be evidence the instructions were viewed exactly once, by the intended party, at a recorded time. When something goes wrong — and it will, eventually — the partner, the bank, and the insurer all need to know who saw what when.

Notice what's NOT on this list: "verify by phone." That control can still exist as defense-in-depth, but the workflow shouldn't depend on it. If the workflow depends on a phone call to the right number being made by a non-distracted human, the workflow is broken.

The right test for a wire-instructions control isn't "does it prevent every attack." It's "does it remove the email inbox from the trust boundary." Once you've done that, the rest of the threat model collapses into things you can actually measure.

The tool-based control: client-side encrypted self-destructing links

The shape of the fix is a link, not an attachment. But not any link — a link with four specific properties:

The PDF (or text block, or signed Word doc) gets encrypted in the sender's browser before it leaves their machine. The decryption key lives in the URL itself — in the part of the URL that browsers don't send back to web servers. The sender pastes the link into the email; the email body contains the link, not the document. The recipient clicks the link, the recipient's browser decrypts the document in-memory, the recipient reads it, and the link is dead.

This pattern is what tools in the zero-knowledge architecture category provide. CIPH4 is one such tool; there are competitors. What matters for the wire-instructions workflow specifically is the combination of features that make it fit:

• Recipient identity binding (Teams and Enterprise). The sender configures the link so the recipient has to click a magic-link sent to a specific email — the legitimate one on file — before the share can be fetched. An attacker reading the thread from a forwarded copy can't view the instructions because they can't intercept the magic-link verification.
• One-view destruction. The link destroys after the first successful view. If a second party (a forwarded attacker, a curious paralegal, a compromised second device) hits the link after the recipient has viewed it, they get a destroyed-link page.
• Time expiry up to the system 7-day ceiling. Wire instructions for a Tuesday close get an expiry that lands before the close — on Teams plans, pick from 1h/24h/7d windows; calendar-date expiry to a specific datetime is an Enterprise upgrade. After that, the link is dead regardless of whether anyone clicked it. No "I forgot we sent that" exposure.
• A receipt the bank, the title company, and the insurer can verify independently. When the closing officer needs to prove to the underwriter that the instructions reached the buyer and not a man-in-the-middle, the verifiable Proof-of-Deletion Receipt (CIPH4 Enterprise) is the artifact that does it.

The workflow, end to end

Here's how a Phoenix title company that processed the same 740K closing the right way would have done it.

The escrow officer drafts the wire instructions PDF as they always do. Instead of attaching to an email, they drop the PDF into the encryption tool, set:

• Recipient: the buyer's email of record (the one used for the loan application, not whatever appeared in the most recent email thread).
• Expiry: a 24-hour or 48-hour window landing before Tuesday's close (or a specific Tuesday 5pm cutoff if the org is on Enterprise with calendar-date expiry).
• View cap: 1.
• Recipient identity verification: required (Teams or Enterprise — the magic-link gate).

They paste the resulting link into the email. The email itself is plain text: "Wire instructions for Tuesday's close are at the link below. The link will ask you to verify your email before showing the document. If you have any questions, my direct line is (480) 555-XXXX."

The buyer clicks the link. The page asks for their email. They type it. A magic link arrives in their inbox. They click it. The PDF decrypts and renders in their browser. They read the routing and account numbers. They initiate the wire from their bank's portal. The link self-destructs on close.

What changed:

• The PDF was never in either inbox as a readable file.
• The recipient identity binding means a forwarding-rule attacker can't view it.
• The view-once destruction means a second viewer gets a dead link, which is a strong signal something went wrong.
• The closing officer has a tamper-evident Proof-of-Deletion Receipt (Enterprise) — anchored to the chain row that captured the view and the destruction — showing exactly when the buyer viewed the instructions, from what region, and whether anyone tried a second view.

Total added time to the workflow: ~90 seconds for the closer, ~60 seconds for the buyer. Total reduction in BEC attack surface: substantial, because the attack pattern doesn't have a path through this control.

What this doesn't replace

A wire-instructions control isn't a complete BEC program. The other pieces matter too:

• Bank-side dual-control on outgoing wires above a threshold. This is what catches the case where the buyer's bank credentials got phished and the attacker initiates the wire directly. The link control prevents the document interception; the bank dual-control prevents the wire authorization.
• Continuing fraud awareness training. Buyers still need to know that any change to wire instructions late in a transaction is a red flag. A "we updated the account number" email arriving the morning of close is almost always fraud, encrypted link or not.
• Inbox monitoring on the sender side. If a closing officer's mailbox is compromised, the attacker can send a new encrypted link with their own account number. Detecting and responding to inbox compromise — forwarding rule audits, anomalous-login alerts, MFA enforcement — is the upstream control. Firms in the legal industry specifically often layer this with a separate "wire instructions never change after the first send" policy: any second link from the same sender for the same transaction triggers a phone callback to a number on the engagement letter, not on the email.
• Incident-response readiness for the case where someone wires the wrong place anyway. The first 72 hours after a misdirected wire determine whether the funds come back. Banks can sometimes reverse a wire if the receiving institution is notified before the funds are withdrawn. The incident response playbook for legal teams covers what to do when prevention fails.

The encrypted link control is the highest-leverage single change. It doesn't have to be the only change.

What about compliance and procurement

Title companies, law firms, and corporate finance teams all sit inside regulatory frameworks that ask hard questions about how sensitive financial data moves. The procurement reviewer at the buyer's commercial bank will ask:

• "How do you confirm only the intended recipient viewed the document?" — answer: recipient-identity verification on the link, plus the verifiable receipt artifact.
• "What happens to the document after the recipient reads it?" — answer: the database flips the drop to a burned state (no further bytes served), then the ciphertext is physically purged from blob storage on a short defense-in-depth delay; on Enterprise, the receipt records the destruction.
• "Can you prove to our auditor that the document wasn't viewed by anyone else?" — answer: the tamper-evident audit log records every view and every failed view-attempt, and the verifiable receipt lets the auditor confirm the chain independently.
• "What's your data-residency posture?" — answer: ciphertext only, the recipient's key never reaches our server, so the question of where the bytes physically sit is materially less load-bearing than it is for cleartext SaaS.

These are the same questions compliance buyers ask in healthcare and financial services, and the same architectural answers apply. The reason zero-knowledge tools fit cleanly into these procurement reviews is that the underlying claim — "we cannot read your data even if subpoenaed, even if breached, even if asked" — is a structural property, not a marketing one.

What to do next

If you send wire instructions today: identify the single highest-value transaction in your firm's next 30 days. Move that one transaction's wire instructions to an encrypted link with recipient identity binding and view-once destruction. Measure the friction. If it's tolerable — and at 90 seconds it usually is — make it the standard for every transaction above your firm's loss-tolerance threshold.

If you're evaluating tools for this workflow specifically, the features that matter are recipient identity binding, view-once destruction, calendar-date expiry, and a verifiable receipt. Anything that ships those four properties is in the consideration set; anything that doesn't isn't a serious answer to BEC.