It's Friday afternoon. An email arrives from your CEO — right name, right display photo, right tone. An acquisition is closing over the weekend; a wire needs to go out before markets open Monday. The email references the deal your team has been working on for three months. It even uses the name of the law firm handling the transaction. Everything about it looks legitimate. The sender is not.
Business Email Compromise (BEC) is the highest-grossing cybercrime category globally — responsible for more financial losses than ransomware, data theft, and payment card fraud combined. The FBI's Internet Crime Complaint Center (IC3) has tracked over $55 billion in cumulative global losses since 2013, a figure widely considered an undercount given how rarely BEC is reported externally. The attacks keep accelerating — not because attackers have found a new technical exploit, but because AI has given them something more powerful: flawless, contextually accurate, personally targeted language at scale.
There are no malware attachments. No unusual links. No grammatical tells. The attack surface is email — the most trusted tool in the enterprise. And the vulnerability being targeted is not a misconfigured system. It is the way professional trust normally works.
Key insightBEC does not exploit failure. It exploits the normal, functional operation of trust — employees acting on instructions from their CEO because they should, approving supplier payments because that is their job.
Why the standard playbook has stopped working
The security industry's response has been consistent: implement DMARC, DKIM, and SPF to block spoofed domains; deploy an email gateway with BEC detection; run annual training on wire fraud red flags; and establish a "call back on a known number" procedure for unusual payment requests. Each of these has genuine value. None of them addresses what BEC has become.
The standard playbook was designed for 2018 BEC — the crude, grammatically imperfect impersonation email that flagged itself. Today's BEC is different in kind, not degree. It references real projects. It matches the CEO's writing style, reconstructed from LinkedIn posts, press releases, and prior email threads. It arrives the day of a board meeting the target knows is happening, at the moment when a wire request from the executive team would be plausible. It passes SPF, DKIM, and DMARC checks — because it was sent from a legitimate-looking domain registered three weeks ago, or from a real account that was compromised last month.
A training module from three months ago cannot tell someone whether the email in front of them right now was written by a human or an AI. That is the gap the playbook leaves open.
| What flagged BEC in 2018 | What defines BEC in 2026 |
|---|---|
| Grammatical errors and awkward phrasing | Language indistinguishable from legitimate communication |
| Spoofed domains with obvious misspellings | Legitimate sends from compromised accounts or aged lookalike domains |
| Generic "urgent wire transfer" requests | Context-specific requests timed to real business events |
| Unknown senders claiming authority | Known personas, correct writing style, real project references |
Key insightDefending against BEC is not an awareness problem. It is a signal problem — making the invisible signals visible at the exact moment a decision is being made.
What actually changes outcomes
At Mungo Labs, we're building the intelligence layer that operates at the moment of decision — not in a training session months earlier. When that Friday-afternoon wire request arrives, the employee sees something specific: "This email was sent from a domain registered 48 hours ago. The CEO's known address is different. Verify by phone before acting." Three seconds to read. Plain language. Enough to change the outcome. The attack was precision-engineered to be convincing — the defence has to be equally precise.
Where to start
Whatever tools your organisation uses, three adjustments are worth making now. First, enforce dual authorisation for high-value wire transfers as a technical control — not a policy that can be overridden by an urgent email. Second, normalise out-of-band verification for all unusual payment requests as standard operating procedure, not a signal that something is suspicious; senior leaders have to model this publicly or it will not hold. Third, stop measuring BEC risk in training completion rates. Measure whether your financial controls hold under realistic pressure. Run the scenario. Find out before an attacker does.
We're thinking about BEC defence differently at Mungo Labs — and we'd love to compare notes. Come see what we're building.
Schedule a Discovery Call →