The $36M WhatsApp fraud is a warning: BEC has left the inbox

Why fraudsters are abandoning email

Email fraud hasn't disappeared — but the economics of attacking via email have shifted significantly against attackers. The security stack that most mid-market companies now operate is genuinely better than it was three years ago: DMARC and DKIM enforcement, AI-powered secure email gateways, BEC detection models trained on millions of attack samples. Microsoft disrupted the Tycoon2FA phishing-as-a-service platform in Q1 2026, a network that had been powering credential-theft campaigns at industrial scale. The infrastructure fraudsters relied on is under active pressure.

So they adapted.

WhatsApp, Teams, Signal, and Telegram offer attackers something email no longer reliably provides: a channel with no security layer. There is no DMARC equivalent for WhatsApp. There is no Secure Email Gateway inspecting your Teams DMs. There is no BEC detection model watching your Signal conversations. When a fraudster impersonates your CFO in an email, there is a real chance your email security platform flags it. When they impersonate your CFO over WhatsApp, that message lands directly in the employee's pocket — unscanned, unfiltered, indistinguishable from a legitimate executive reaching out.

This is not an accident. It is deliberate channel selection.

How a messaging-app payment fraud actually works

The $36M WhatsApp attack is sophisticated in execution but simple in structure. Understanding the anatomy makes it harder to fall for.

Stage one: reconnaissance

Before any message is sent, the attacker has done significant research. LinkedIn reveals the organizational hierarchy — who reports to whom, who handles payments, who the CFO is. Prior email compromise (whether from a phishing attack on the target or on a vendor weeks earlier) provides insider context: real names, real project names, real vendor relationships. The attacker knows enough to sound like an insider because they've read the insiders' mail.

Stage two: channel selection and impersonation

The attacker creates a WhatsApp account with the executive's name and, often, their profile photo scraped from LinkedIn or the company website. They message the target — typically someone in AP or treasury — directly. The impersonation doesn't need to be technically sophisticated. It just needs to be plausible for 90 seconds.

Stage three: urgency and authority

The message combines two of the most reliable social engineering levers: executive authority (“this is coming directly from the CEO”) and time pressure (“this needs to happen before close of business”). Both short-circuit the instinct to verify. The employee isn't thinking “is this legitimate?” — they're thinking “how do I execute this without causing a problem for the CEO.”

Trustmi's 2026 fraud report found that 59% of successful attacks now use multiple tactics simultaneously — combining email, social engineering, and messaging-app contact to create a reinforcing pressure environment. The WhatsApp message often isn't the only attack vector. It's the closer. See how multi-tactic attacks bypass AP controls.

What your AP team should do right now

The controls that protect against email BEC do not protect against messaging-app fraud. You need a different layer, and it starts with policy before it starts with technology.

Establish a zero-tolerance channel policy for payment instructions

No payment request, bank account change, or wire authorization is valid if it arrives via WhatsApp, Teams, Signal, or any messaging platform. This is not a guideline — it is a hard rule, communicated in writing, with explicit acknowledgment from everyone with payment authority. The AP team needs cover to push back on a “CEO message” — and a clear written policy gives them that cover.

Route all payment changes through a single, auditable channel

Every request to initiate a new payment or change existing vendor bank details must enter through your AP ticketing system or official email workflow. If it didn't come through that channel, it doesn't get processed. The rule applies regardless of who appears to be asking. See the full vendor bank change verification protocol.

Require out-of-band voice verification for unusual requests

If a payment request arrives through any channel and it's unusual — a new vendor, a changed bank account, an amount outside normal range, an urgent timeline — call the requestor back on a number from your internal directory, not a number provided in the message. This single step would have prevented the $36M WhatsApp fraud.

The control that works regardless of attack channel

Your email security stack protects the email channel. Your BEC detection tools monitor your email environment. Neither of them sees the WhatsApp message that just arrived on your AP manager's phone.

Pre-payment verification — confirming bank account details against a live, verified vendor registry before every payment goes out — is the control that doesn't depend on knowing how the fraud arrived. Whether the fraudulent payment instruction came through email, a spoofed phone call, or a WhatsApp impersonation of your CFO, the fraudulent bank account still has to show up in the payment. That's where the fraud dies.

The $36M WhatsApp fraud succeeded because the payment was processed before anyone checked whether the destination account had ever been associated with the supposed vendor. It wouldn't have mattered how convincing the WhatsApp message was if that check had been in place.

This is the same principle that underlies NACHA's 2026 fraud monitoring requirements — verify before the payment leaves, not after. Bank-level monitoring catches some of what gets through. Pre-payment vendor verification stops it before it gets to the bank at all.