Business email compromise is the fraud category that rarely involves anything technically impressive. There is usually no exploit, no malicious attachment that survives a filter, and no unusual software on any endpoint. Instead, someone gains access to a mailbox or registers a near-identical domain, studies how the organization writes and pays, then issues a request that looks completely ordinary. The target is a transfer or a change of bank details, and the moment the money leaves, the attacker’s infrastructure is often already gone.
Understanding how these schemes unfold is the most reliable defence, because the individual steps are predictable even when the details vary. Once you can recognize the pattern, the controls that stop it become obvious, and most of them are procedural rather than technical.
Why Email Fraud Looks Different from Malware
Malware-based attacks need a technical foothold, which gives defenders something to detect: unusual processes, traffic to unfamiliar hosts, files appearing where they should not. Business email compromise needs none of that. A message may contain no link and no attachment, only language. There is nothing for an endpoint tool to analyse and nothing for a scanner to flag. Detection therefore depends on noticing a mismatch between an instruction and the normal way your organization works, which is why the strongest controls live in payment processes rather than in security software.
The Anatomy of an Attack: From Access to Transfer
Most campaigns follow a similar sequence. First, access. That may come from a stolen credential obtained through a convincing sign-in page, a session token captured by malicious software on a personal device, or a mailbox rule quietly added after a successful phishing attempt. Second, observation. The attacker reads threads, learns who approves payments, notices the tone executives use, and identifies when finance staff are busy or travelling. Third, impersonation. Either the compromised mailbox sends the request, or a lookalike domain is registered and used to continue an existing conversation. Fourth, the request itself, usually framed as urgent and confidential, asking for a change of bank details or a payment that must be completed before a deadline. Fifth, extraction, often through a series of transfers small enough to avoid scrutiny, and sometimes through a payroll or invoice redirection rather than a single large payment.
Warning Signs That Should Stop a Transaction
Certain patterns appear in a large share of successful cases, which makes them worth teaching staff explicitly:
- A change to bank details arriving by email, even from a supplier you have paid for years.
- Pressure to act quickly, to keep the matter confidential, or to skip an approval step.
- A reply address that differs slightly from the one in earlier messages in the same thread.
- A message from a known contact that arrives from an unexpected address or device.
- A request to move the conversation to a personal or chat channel where records are not kept.
- Unfamiliar mailbox rules, forwarding settings, or notification changes noticed by the account owner.
Any one of these is a reason to slow down. The cost of a five-minute verification call is negligible compared with the cost of a misdirected payment.
Process Controls That Prevent Payment Fraud
Technical controls reduce how often attackers gain access. Process controls determine whether access turns into money leaving. Require independent confirmation of bank detail changes by phone, using contact details held internally rather than those in the message. Separate the person who approves a new payee from the person who initiates payment. Apply dual authorization above a defined amount, and consider lowering that threshold during periods when finance staff are away. Rotate who performs verification so that a single person is not the permanent bottleneck. Log every exception, and review the log monthly, because repeated pressure to bypass a control is itself a signal that someone is being targeted. These measures are unglamorous, and they are the ones that consistently work.
Preparing to Respond Before It Happens
When a suspected compromise surfaces, a written plan saves hours. Decide in advance who contacts the bank, who resets credentials, who notifies affected suppliers or customers, and who speaks to insurers. Keep contact details for the bank’s fraud team somewhere other than a mailbox, since mailbox access is precisely what may be lost. Instruct staff to report immediately rather than investigate quietly, and make clear that the fastest way to limit loss is early disclosure. Afterwards, review how the message got through and whether any control was skipped. That review is far more valuable than assigning blame.
Frequently Asked Questions
Is business email compromise only a risk for large companies?
No. Smaller organizations are frequent targets precisely because they often lack separation of duties and rarely have formal verification procedures for payment changes.
Can authentication records prevent it entirely?
They help against forged sender addresses, but not against a genuine mailbox operated by an attacker and not against lookalike domains. They reduce the attack surface rather than eliminate the risk.
What is the first thing to do if a payment has been sent?
Contact the bank’s fraud team immediately and request a recall, then change credentials and review mailbox rules. Recovery depends heavily on how quickly the transfer is reported.
How often should the response plan be tested?
Once a year is a reasonable minimum. A short tabletop exercise with finance, IT, and leadership usually reveals gaps that no document review would surface.
Business email compromise succeeds by looking ordinary and exploiting the trust that makes business run. Combine authentication and filtering with verification procedures that do not depend on anyone’s judgement under pressure, and most attempts will fail for lack of a payment. This article provides general information and is not professional advice; consult qualified advisors about your specific circumstances.