Ransomware gets the board’s attention. Business email compromise gets the money. The FBI’s IC3 reports have shown BEC losses in the billions every single year, consistently ahead of ransomware. That pattern hasn’t changed in a decade. No malware. No exploit. An email that looks correct, a payment instruction that changed, and a wire that left on a Tuesday afternoon.
I’ve watched this play out at institutions with real security programs. EDR deployed, MFA everywhere, a clean exam file. None of it mattered, because nothing in that stack sits between an accounts payable clerk and a convincing request to update a vendor’s routing number.
Why your security stack doesn’t see it
BEC is not a technical attack, so technical controls mostly watch it go by. The email often comes from a real, compromised account at a real vendor. It passes email security controls like SPF and DKIM because it is, technically, legitimate mail. There’s no attachment to detonate and no link to scan. The payload is a sentence: “We’ve changed banks. Here’s the new account for the invoice due Friday.”
Your filters were built to catch malicious infrastructure. This attack rents legitimate infrastructure and targets your process instead.
The control is a phone call
The thing that stops BEC costs almost nothing: out-of-band verification of any change to payment instructions, using a number you already had on file. Not the number in the email signature. Not a number the requester helpfully provides. The one from the original contract or your vendor master file.
That’s it. That’s the control. A callback on every payment-instruction change, plus dual approval on wires above a threshold you set deliberately instead of inheriting from whoever set it in 2014.
Most banks have this written down somewhere. Far fewer can show me evidence it happens every time, under deadline pressure, when the request comes from someone who sounds like the CFO and says the wire has to go today. Urgency is the exploit. The entire attack is engineered to make the verification step feel like the thing you can skip just this once.
Test the process, not the people
Phishing simulations won’t tell you if you’re exposed here. Test the actual workflow instead. Have someone internal submit a vendor banking change through the normal channel and watch what happens. Does anyone call the number on file? Does the change go live first and get reviewed later? Does the wire limit trigger a second approver, or does the second approver rubber-stamp from their phone?
Run it once and you’ll know more about your BEC exposure than any product demo will ever tell you. Examiners are increasingly asking about payment fraud controls in exactly these terms, and “we have email security” is not an answer that survives the follow-up question.
Where to start this quarter
Pull your last twelve months of vendor payment-instruction changes and check how many have documented callback verification. That number is your real control coverage, and it’s usually a lot lower than the policy implies. Then set the wire threshold for dual approval on purpose, verify the vendor master file has current phone numbers, and make the callback a required field in the workflow instead of a step in a PDF.
None of this requires new budget. It requires deciding that the boring control is the one that matters, because the attackers already have.
If you want a second set of eyes on your payment fraud controls before someone else tests them for you, book a call: https://cal.com/vaughn-cyber-group
