Business Email Compromise in 2026: How AI-Generated BEC Is Outpacing Defences

Something worth paying attention to happened in the FBI’s 2025 Internet Crime Report, released on 6 April 2026. The headline numbers are familiar: business email compromise accounted for $3.046 billion in reported losses, the second-largest crime category behind investment fraud, across 24,768 complaints. That is broadly consistent with 2024, when BEC cost victims roughly $2.77 billion. What changed is buried deeper in the report. For the first time, the FBI separately tracked AI-involved cybercrime and found approximately 22,000 complaints tied to AI, totalling $893 million in losses. Of that, around $30 million was specifically attributed to AI-assisted BEC.

That $30 million figure is the interesting one, and not for the reason it’s being quoted in most coverage. $30 million against $3 billion in total BEC losses looks small. It isn’t. It’s almost certainly a severe undercount — victims report what they can see, and when an attacker uses a language model to draft a believable invoice-change email, the victim has no way of knowing. They just see an email. The FBI’s own AI category likely captures only the cases where the AI fingerprint was obvious enough for the victim to flag it: a voice that sounded cloned, a video call that looked rendered, a text message that couldn’t be explained otherwise. Everything else goes into the general BEC column.

Which leads to the real story. A decade into organised awareness training, a half-decade into enterprise DMARC rollouts, and two years into mandatory MFA for most cloud services, BEC losses are not falling. They are climbing. Something in the threat model has shifted, and it is not what most marketing copy suggests.

The shift is not about volume, it is about context

The standard narrative is that attackers now use AI to write more phishing emails, faster. That narrative is partly true and almost entirely beside the point. The useful question is what specifically is succeeding that wasn’t before.

Three patterns show up consistently in incident data from the past eighteen months, and they have relatively little to do with email volume.

The first is thread-aware impersonation. Traditional BEC is external: a look-alike domain, a spoofed header, a new thread into the victim’s inbox asking for an urgent wire. The defensive signals are obvious — new sender, unfamiliar domain, unusual request. The current pattern inverts all of this. The attacker compromises a real mailbox — a supplier’s, a partner’s, sometimes the victim’s own colleague’s — through credential theft or an adversary-in-the-middle phishing kit. They then read the existing thread history, learn how the two parties talk to each other, and join an ongoing conversation at exactly the moment a payment is being discussed. There is no new domain. There is no unusual sender. There is only a small, contextually appropriate request to update the bank details on an invoice everyone has already agreed to pay. Every external signal that traditional email security relies on is absent.

The second is AI-assisted fluency in the target’s dialect. Phishing emails used to leak their origin through small linguistic tells — a slightly formal register where the real sender would be casual, the wrong preposition, a British spelling from an American executive. Large language models have collapsed that tell. Feed the model a compromised mailbox’s sent folder and it will produce output that matches the sender’s tone, their sign-off, their shorthand, their quirks of punctuation. Teams that have run this experiment internally report that detection by linguistic intuition alone has gone from unreliable to essentially unusable.

The third, and the one that most changes the defensive calculus, is the compression of attack dwell time. The pre-AI BEC attack involved a human operator reading mailboxes, choosing a moment, drafting a believable message, sending it, waiting. The steps are the same now, but each of them has collapsed from hours to seconds. An attacker with a compromised mailbox and an automation pipeline can move from initial access to fraudulent payment request in the time it takes the legitimate user to break for coffee. The defender’s assumption that there will be a reaction window — a chance to notice something odd and intervene — is dissolving.

These are not speculative trends. They are visible in Microsoft’s own reporting on ongoing AiTM phishing-to-BEC campaigns, in Darktrace’s threat research, and in the case narratives that make it into IC3’s public reports. The question is what to do about it.

What is still working, and what is not

It’s fashionable in vendor marketing to claim that everything old is broken and everything new must be bought immediately. That isn’t honest. Most of the traditional BEC controls still reduce risk — they just no longer reduce it enough to be sufficient on their own.

DMARC with a reject policy is still the first and cheapest thing any organisation should have in place. It doesn’t stop a compromised legitimate mailbox, but it eliminates a large category of cousin-domain spoofing that attackers still use when mailbox compromise isn’t available. The depressing finding from audit work is that a meaningful share of UK small businesses still run DMARC in p=none monitoring mode or don’t have it deployed at all. If that describes your organisation, this is not a sophisticated AI problem. This is an unlocked door.

MFA on email accounts still blocks the single most common path to mailbox compromise: credential stuffing against usernames pulled from breach corpuses. The catch is that MFA alone is no longer enough. AiTM phishing kits — the ones that proxy the legitimate login page in real time and steal the session token rather than the password — defeat most SMS and app-push MFA. Phishing-resistant MFA using FIDO2 hardware keys or passkeys closes this gap. Push-with-number-matching or conditional access policies that factor in device health and sign-in location reduce it substantially. Plain SMS codes in 2026 are security theatre.

Anti-impersonation policies in Microsoft 365 and Google Workspace, configured to cover named executives, finance personnel, and regular payment counterparties, still catch a useful fraction of external impersonation attempts. The value falls sharply once the attack uses a compromised legitimate account — the impersonation filter can’t flag a message from a real, authenticated sender — but it remains worth configuring.

What is no longer working well enough to rely on, despite a decade of emphasis, is training-based human detection. This is a specific, defensible claim: the research shows training still helps, but the rate of improvement is being overtaken by the rate at which AI-assisted attacks are becoming indistinguishable from legitimate communication. A 2026 survey reported that 86% of organisations have already encountered at least one AI-assisted phishing or social engineering incident. Expecting an employee to spot a contextually appropriate, linguistically accurate, thread-continuous invoice change request is asking them to do something most security professionals would also fail at if tested fairly.

The honest conclusion from the past two years of data is that training reduces the proportion of successful attacks, but the absolute number of successful attacks is rising because attackers are launching more of them, more cheaply, and with higher base success rates. Training is necessary. It is not close to sufficient.

The control that actually works: out-of-band verification

There is one control that keeps appearing in incident post-mortems as the thing that would have, and sometimes did, prevent the loss. It is not technically sophisticated. It is a policy that every payment-instruction change — new bank details, new beneficiary name, new routing information, changes to a regular invoice’s payee — must be verified through a channel different from the one that delivered the request, using a phone number established in advance, not a number supplied in the request itself.

The reason this works against AI-assisted BEC is that it doesn’t try to beat the attacker at the email layer at all. It moves the trust decision to a channel the attacker hasn’t compromised. Even a thread-aware attack from a compromised supplier mailbox fails when the finance team phones the supplier’s known number and the supplier’s genuine staff say no, we didn’t ask for a bank change.

The reason it often isn’t implemented, or is implemented and then bypassed under operational pressure, is that it creates friction. Small finance teams, processing dozens of invoices a week from suppliers they trust, find callback policies irritating. Attackers know this. The most effective BEC campaigns deliberately target the end of the working day, the start of a public holiday period, or moments when the usual approver is travelling — exactly the times when friction gets waived in the name of getting things done.

Organisations that have survived an attempted fraud and debriefed honestly tend to converge on three operational rules:

1. Callback verification applies to all changes of payment instruction, without exception, regardless of trust level, amount, or urgency.
2. The callback number is pulled from a trusted internal source — CRM, contract file, previous verified communication — never from the email, letterhead, or signature block that accompanied the change request.
3. Verification is logged. The logging is as much for the person doing the verification as for later audit: it creates a moment of deliberate thought that the attacker is counting on the team skipping.

The third rule sounds bureaucratic. It is actually the one that most reliably changes behaviour.

Where technology does help, and where vendor marketing overreaches

There is a category of tools marketed as “AI-powered BEC protection” that is doing genuinely useful work, and a category that is mostly rebranded gateway filtering. The distinction is worth making because the buying decision matters.

Useful capabilities worth looking for include behavioural analysis of email at the tenant level — models that learn what normal communication between two parties looks like and flag anomalies like an unusual request type from a known sender, a message sent from an unusual geography, or a sudden change in communication cadence. Abnormal Security and, increasingly, Microsoft Defender for Office 365’s post-SEG capabilities are examples. These tools can spot a thread-aware attack because they notice that the communication pattern changed, even if the content looks legitimate.

Also useful: real-time detection of AiTM phishing sessions at the identity layer, typically via conditional access policies that examine token replay patterns, impossible-travel sign-ins, and session anomalies. This is identity security more than email security, but it is where a large share of BEC compromise now actually gets caught, and it is frequently missed in buying discussions because finance teams are looking at email vendors.

Less useful, despite the branding: tools that advertise AI-based content analysis but are really running sentiment and keyword filtering with a generative-AI wrapper. The marketing copy for these is often better than the product. Ask vendors for detection metrics on AiTM and thread-continuation scenarios specifically — the subset they perform worst on — rather than on isolated spoofing attempts.

We cover the comparison between the main enterprise platforms in our email security platform comparison, which goes through the architectural differences between traditional secure email gateways and the API-based post-SEG approach. The short version: the architecture matters more than the AI branding.

The deepfake layer: voice and video

Pure-email BEC is increasingly being combined with a secondary channel — a voice call, a Teams meeting, a WhatsApp voice note — that corroborates the email request. The combination is significantly more effective than either channel alone, because most organisations’ verification policies treat a voice confirmation as trust-building rather than as additional attack surface.

The standout case, now well-documented, is the early-2024 Hong Kong incident in which a finance clerk at the UK engineering firm Arup joined a Teams meeting populated entirely by deepfaked senior executives and, over the course of the meeting, authorised transfers totalling roughly $25 million. That case was exceptional in its losses but not in its method. The method — use voice or video to bypass callback verification by simulating the callback itself — is now commodified. We go into the voice-cloning attack surface in detail in our separate deepfake voice fraud coverage, including the specific controls that reduce the risk.

The short version, relevant here, is that out-of-band verification only works if the out-of-band channel is genuinely independent. A phone number pulled from a compromised email signature is not an independent channel. A video call initiated from a link in a suspect email is not an independent channel. Callback verification against a pre-established phone number, on an organisation’s known main line, remains one of the few controls that the deepfake layer struggles to defeat — and it remains an operational discipline problem more than a technology problem.

What has shifted for small and mid-sized businesses specifically

Enterprise-scale organisations have security teams and the budget to layer all of the above. The BEC loss distribution suggests a different story for the mid-market and smaller. The 1,760% increase in BEC volume since generative AI became widely available, reported by Hoxhunt, is concentrated on attacks that used to be uneconomic against smaller targets — attacks that required human effort to craft and were therefore reserved for high-value enterprise victims. AI has collapsed the per-attack cost to the point where a thread-aware impersonation of a £40,000 supplier invoice is worth the attacker’s time.

The practical consequence for UK SMBs is that the threat model of five years ago — “we’re too small to be targeted specifically” — is no longer accurate. Targeted attacks are now economic against businesses with a £2m annual turnover, and the defensive gap is most acute at this tier because these organisations typically run Microsoft 365 Business Standard or Business Premium with minimal additional configuration, no dedicated security staff, and a managed IT provider whose security remit is undefined.

For this segment, the priority list is narrower and clearer:

• Turn on MFA everywhere, move off SMS codes, and push toward authenticator-app or passkey methods.
• Configure DMARC with a reject policy on the primary domain and test it.
• Turn on anti-impersonation policies in Microsoft Defender for Office 365 or the equivalent in Google Workspace.
• Define a written callback-verification policy covering every payment-detail change, without exception, and make the finance team’s adherence to it the subject of an annual tabletop exercise.
• Retain the Unified Audit Log for at least 90 days — the default retention is shorter and frequently insufficient for incident investigation.

None of this is novel. Almost all of it is free or included in existing subscriptions. The reason it doesn’t get done in most mid-market organisations is not cost. It is that nobody owns the outcome. The honest fix is to assign that ownership explicitly.

The defender’s situation, stated plainly

BEC is not a solved problem and it is not on a trajectory to be solved soon. The FBI’s 2025 numbers are the fourth consecutive year in which BEC losses have remained within a narrow band around $2.5–3 billion annually, despite measurable improvements in email authentication, MFA adoption, and awareness training across the economy. The improvements are real. The attacker capability is improving faster.

What that means for the defender is not despair, and it is not panic buying of AI-security tooling. It is a more disciplined application of the controls that still work, combined with an honest assessment of which controls have been quietly eroded by attacker capability. Out-of-band verification, phishing-resistant MFA, and behavioural detection at the tenant level are the current priority stack. Training helps but cannot be the primary line of defence. Vendor claims that their AI catches all AI-assisted attacks should be tested against specific AiTM and thread-continuation scenarios before the procurement signature, not after.

The $30 million AI-assisted BEC figure in this year’s IC3 report will keep rising. It will rise because attackers are getting better at hiding the AI fingerprint, because victims will continue to report what they can see rather than what actually happened, and because the economics of attacking mid-market organisations have permanently improved. The defenders who stay ahead of this will be the ones who stopped treating BEC as an email-filtering problem several years ago and started treating it as a payment-verification and identity-security problem. That shift, more than any specific product, is what the current threat landscape rewards.

Frequently asked questions

What is the single most effective control against AI-generated BEC? Out-of-band verification of every payment-instruction change, using a phone number established in advance from a trusted internal source, not from the email requesting the change. It is the only control that reliably defeats thread-aware attacks from compromised legitimate mailboxes, because it moves the trust decision to a channel the attacker hasn’t compromised.

Is my organisation too small to be targeted by AI-assisted BEC? Almost certainly not. The collapse in attacker cost-per-attack that generative AI produced means targeted impersonation is now economic against businesses with turnover as low as £1–2 million. The “too small to target” threat model no longer holds.

Will Microsoft Defender for Office 365 stop a thread-aware BEC attack? Partially. The standard spam and phishing filters will not, because the attack comes from a legitimate authenticated sender. The higher tiers of Defender for Office 365, combined with Entra ID Protection and properly configured conditional access policies, can catch the identity-layer compromise that typically precedes the BEC email. This requires configuration work — out-of-the-box defaults are insufficient.

Is SMS-based MFA still acceptable in 2026? For consumer accounts, it is better than nothing. For business email accounts, it should be considered a transitional state rather than a destination. Adversary-in-the-middle phishing kits defeat SMS MFA routinely, and the rollout of authenticator apps and passkeys is mature enough that there is little operational justification for remaining on SMS.

How quickly can stolen funds be recovered? The FBI’s Financial Fraud Kill Chain (FFKC) process froze approximately $679 million in fraudulent transfers in 2025, a 58% success rate. Recovery success falls sharply with time — the critical window is the first 24 to 72 hours. The UK’s Faster Payments system processes transactions within seconds, but banks have fraud recall procedures. The practical advice is to report to both the sending and receiving banks the moment fraud is suspected, before internal confirmation of every detail.

Should we buy an AI-specific BEC protection product? Evaluate it on specific attack scenarios, not on marketing claims. Ask for detection metrics against AiTM phishing and thread-continuation BEC rather than against isolated spoofing attempts. If the product’s core capability turns out to be behavioural anomaly detection at the tenant level, that is genuinely useful. If it is generative-AI-wrapped content filtering, the value is more limited and the cost often is not justified over improved configuration of existing Microsoft 365 or Google Workspace capabilities.