Business email compromise: stop payment fraud by phone

Business email compromise is a payments fraud that happens to arrive by email. The message is the delivery route; the target is a transfer, and the loss is usually a single wire that leaves in the ordinary course of business, approved by someone doing their job carefully.

That is what makes it different from the rest of the email threat. There is often no attachment, no link and no malicious code, so nothing for a filter to catch. What arrives is a request that looks like the requests your finance team handles every week.

This page is written for the people who have to stop it: what the requests look like from the receiving end, the controls that actually work, and what to do in the first hours after a payment has gone.

What to take away

One control prevents most lossesverify every payment change by voice, on a number you already held.
The rule has to bind the owner, or it protects nobody.
If money has gone, the first hour decides whether any of it comes back. Call the bank before anything else.

What your staff will actually see

What the message looks like	Who it appears to come from	What it asks for
CEO fraud (executive impersonation)	The CEO or another senior executive, from a lookalike domain or a compromised mailbox	An urgent, confidential wire, often with "I am in a meeting and cannot take calls"
Supplier invoice fraud	A known supplier, from a lookalike domain or a compromised mailbox	Payment to new bank details, often on an invoice that looks real
Payroll diversion	HR, payroll, or a colleague	A change to direct-deposit details for salary
Attorney or real-estate impersonation	A lawyer, title company, or real-estate agent	A last-minute wire for a closing, with changed account details
Thread hijacking	A genuine contact whose mailbox is compromised	A reply inside an existing thread that changes bank details or asks for a payment

BEC request patterns

What arrives

Bank detail update: Known supplier
Urgent transfer: Senior person
Payroll deposit change: Employee
Closing or settlement funds: Transaction party
Tax or ID documents: Senior management or HR
Invoice remittance line: Compromised supplier mailbox

Appears to come from

Bank detail update: Redirect future payments
Urgent transfer: Speed, discretion, exception
Payroll deposit change: Redirect one person's pay
Closing or settlement funds: Large one-off payment
Tax or ID documents: Records enabling later fraud
Invoice remittance line: Payment matching real invoice

What it asks for

Bank detail update
Urgent transfer
Payroll deposit change
Closing or settlement funds
Tax or ID documents
Invoice remittance line

In the table above, the last row is the hardest version. When the request genuinely comes from a compromised mailbox inside a real supplier, every signal a person is trained to check will pass.

Why it works on careful people

It uses your legitimate process rather than defeating it. There is a real supplier, a real invoice, a real project and a real deadline. The request fits the flow of work already in progress.

It arrives with authority or with urgency, and usually both, which compresses the space in which somebody would normally pause. It exploits the fact that questioning a senior person's instruction has a social cost that questioning a stranger's does not.

And technically, it is often clean. A message with no payload cannot be detected as malicious content, and a message sent from a genuine account of a genuine business partner is not a forgery at all.

The control that stops it

Write one rule and apply it without exception.

Voice verification rule

Change to bank details, first payment to new payee, or urgent bypass request?

Yes

Call back on a number you already held

Proceed through the normal process

Any change to bank details, any first payment to a new payee, and any urgent request that bypasses the normal process is confirmed by voice, on a number you already held before the request arrived.

Never a number in the message. Never a number in the signature block. Never a number on the attached document or the updated invoice. The number comes from the signed contract, a previously verified invoice, or the switchboard you already had on file.

Two conditions make it work, and both are usually where it fails.

It binds everyone, including the owner. The rule's entire purpose is to let the newest person in accounts say "I will call you back on the number we hold" to the most senior person in the company without it being an act of insubordination. If it carries an exception for seniority or for urgency, it has an exception for precisely the circumstances a fraudster will construct.

People have practiced it. Say out loud, in advance, that a call-back is expected and welcome. Then have someone senior deliberately trigger one, so that the first time it happens is not the day it matters.

Controls around the payee file

The vendor master file is where the money actually gets redirected, so treat changes to it as a controlled process rather than an administrative task.

Payee file controls

Never change bank details on email alone
Require request, independent call, second approval
Log who requested, verified, approved and when
Separate payee changer from payment releaser
Use supplier portals and confirm through portal
Two approvals above a set payment threshold
Ask your bank what outgoing payment controls exist

Treat the vendor master file as a controlled record. The controls that matter are:

One named owner for the vendor master file, with changes logged.
A standard change request that records the source of the new bank details.
Independent verification of every bank-detail change by voice, on a held number.
A second approver for any new payee or change to an existing payee.
A freeze on changes during the approval or payment run.
A periodic review of the payee list against active suppliers and contracts.
Removal of leavers' access, plus a review of delegated mailbox rights and standing approvals.

What to watch for

Detection here is mostly about mailboxes and reconciliation rather than about email content.

Detection watchlist

New mailbox rules and forwarding
Sign-in anomalies and impossible travel
Lookalike domains close to yours
Supplier statements reconciled to payments
Payroll deposit changes reviewed each cycle

A bank-detail change on an existing supplier, especially just before a payment run.
A payment request that arrives outside the normal thread or from a free webmail address.
A display name you know attached to an address that is one character different.
Mailbox rules, forwarding, or delegated access you did not create.
A supplier or customer who says they did not send a message, or a payment reconciled to an unexpected account.

Underneath all of this sits account security, which is what stops the mailbox compromise that makes the convincing version possible. Use multi-factor authentication (MFA) on every mailbox and finance system, and publish SPF, DKIM and DMARC records for your domain so a lookalike domain or a spoofed sender is easier to spot. That sequence is set out in security foundations.

The first hours after a payment goes out

Speed is the only thing that helps. Work in this order.

First hours after payment

Call your bank immediately for a recall
Ask your bank to contact receiving bank
Report to FBI IC3 promptly and completely
Contact counterparty on a known number
Preserve messages, headers and approval trail
Secure accountspasswords, sessions, rules
Tell your insurer

Call your bank immediatelyand ask for a recall of the payment. Use the fraud line, say the words wire fraud or payment fraud, and ask for the bank's recall deadline and a case number. Do it before you investigate anything. Recovery chances fall sharply with time.
Ask your bank to contact the receiving bank.You cannot do this yourself, and it is the step that can get funds frozen at the other end.
Report it.In the United States, file a complaint with the FBI's Internet Crime Complaint Center (IC3) at IC3's business email compromise guidance. Ask for the complaint to be routed to the IC3's Recovery Asset Team, which works with financial institutions on funds frozen in transit, and ask your bank whether it has initiated the Financial Fraud Kill Chain. Report promptly and completely; both mechanisms depend on early, accurate details.
Contact the counterparty through a known channel.If the request appeared to come from a supplier, call them on your held number. Their mailbox may be compromised and they may not know.
Preserve evidence.Keep the original messages with their headers, the payment records and the approval trail. Do not delete the mailbox contents or reset accounts in a way that destroys logs before someone competent has looked.
Secure the accounts.Reset passwords, revoke active sessions, check registered authentication methods, and remove mailbox rules, forwarding and delegated access that you did not create.
Tell your insurer.Policies frequently have short notification windows, and cover for funds transferred by a deceived employee is often treated separately from other losses.
Check for the second payment.These frauds usually attempt more than one, and the follow-up arrives while everyone is dealing with the first.

What not to do

Do not reply to the message to test it. Do not negotiate or engage. Do not rely on the finance team spotting a well-made request, because that expectation is what the fraud is built around.

And do not punish the person who made the payment. They followed a process that allowed it. The process is what you fix, and a team that fears blame will delay telling you, which costs far more than the mistake did.

For general guidance written for small organizations, the Federal Trade Commission's small business cybersecurity material is a reasonable free starting point. What applies to your own situation, including any notification obligations, is a question for your advisers.

Common questions

Would email filtering have stopped it?

Often not. A message with no link and no attachment, sent from a genuine account, carries nothing for a filter to act on. Filtering reduces volume; process decides what happens to the message that gets through.

A supplier says our invoice was never paid. What now?

Treat it as a suspected redirection immediately. Check which account the payment went to, whether the details were changed and when, and who approved the change. Then follow the first-hours sequence, because time is the variable that matters.

We are very small. Do we need two approvers?

Some form of second look, yes, even if it is the owner making a call. The control that matters is not headcount, it is that the person who changes payee details is not the only person involved in releasing money to them.

How do we handle a genuinely urgent payment?

By having a defined fast route that still includes the call-back, agreed in advance and known to everyone. Urgency should change the speed of the process, never the existence of the verification step.