Industry AnalysisBy the PhishSheriff team · March 2025 · 9 min read

BEC in Financial Services: The Wire Fraud Playbook Attackers Use

Business email compromise aimed at treasury teams, finance controllers and executives tends to follow a recognisable sequence. This piece walks through the common stages and the controls and exercises that help finance teams resist them.

Key points

The common BEC sequence: research, impersonation, pressure
Why trained, phishing-aware teams can still approve fraudulent payments
How a follow-up phone call is used to reinforce the request
Why regulators increasingly expect evidence, not just training records

On this page

BEC is not phishing, and that matters

Business email compromise is often grouped with phishing, and the confusion causes real gaps. Credential phishing wants a click; BEC wants a decision. A typical BEC message contains no link, no attachment and no malware, nothing for a secure email gateway to inspect. It is a plain request that says, in effect, “I am your CFO and I need this payment made today.” The attack surface is the judgement of the small group of people with authority over money.

That is why financial services teams are attractive targets. Treasury, correspondent banking and controller teams make high-value transfers as routine work, and faster payment rails can make a fraudulent transfer hard to recover. Yet many awareness programmes still focus most of their simulations on link-clicking, which BEC rarely uses.

Stage one: research

Serious BEC attempts begin with research, and much of the material is public. Professional networking sites suggest the organisation chart: who runs treasury, who reports to the CFO, who has just joined accounts payable. Press releases and filings suggest timing: an acquisition, a new banking relationship, a quarter-end. Vendor relationships appear in case studies, job adverts and technical records. Our guide to spear phishing shows how this research turns into a targeted message.

Email infrastructure is part of that research. An unenforced DMARC policy tells an attacker they may be able to send as your exact domain. Where enforcement prevents that, they look for weaker subdomains or register lookalike domains. New lookalike registrations, and mail records appearing on them, can be an early sign that a campaign is being prepared.

Stage two: impersonation

With the research done, the attacker chooses how to impersonate. The cheapest option is display-name spoofing, such as “Priya Sharma, CFO” on a free webmail address, which still works on mobile clients that hide the address. Next is the lookalike domain, one character off. The most damaging is genuine account compromise: a real vendor or executive mailbox taken over, from which the request arrives with valid authentication and real thread history.

The vendor-compromise pattern, in which the attacker waits in a supplier’s mailbox for a real invoice thread and then replies that “our bank details have changed”, is among the hardest to detect because the technical signals look legitimate. The defence is procedural: verify any change of bank details through a known phone number, with no exceptions, including for senior executives. Simulation helps make that procedure a habit.

Stage three: pressure, and the phone call

The final stage is engineered urgency: the payment must go today, the deal is confidential, the executive is boarding a flight and cannot be reached. Each element is designed to disable a control. Urgency defeats deliberation, confidentiality removes the second pair of eyes, and unavailability blocks verification. Trained finance staff can often resist the email alone; a follow-up call is designed to tip the balance.

Voice cloning makes that call more convincing. Public audio of an executive, such as an earnings call or a conference talk, can be used to imitate their voice. Rehearsing the combined email-and-call pattern in a controlled exercise gives finance teams a chance to practise refusing and verifying before they face it for real.

Why phishing-aware organisations still lose payments

Post-incident reviews of BEC often find that the people involved had been trained. They knew about phishing and had completed their annual module. The problem was a category error: they were watching for suspicious links and attachments, and the BEC request contained neither. The warning sign was the request itself departing from process. Why social engineering works explains the authority and urgency cues behind these decisions.

Effective defence pairs role-specific exercises with firm process controls: dual authorisation for payments above a threshold, mandatory call-backs for changes of beneficiary, and a rule that no level of seniority exempts a request from verification. The value of a BEC exercise is often not “who clicked” but “which approval step was skipped when the request said urgent”.

The regulatory dimension

Regulators increasingly treat payment fraud and social engineering as matters of accountability. Frameworks applicable to Indian financial institutions, such as the RBI’s cyber security directions and SEBI’s Cybersecurity and Cyber Resilience Framework, expect regulated entities to manage these risks and to train staff; PCI DSS 4.0 includes security awareness requirements for organisations that handle card data. Check the specific obligations that apply to your organisation with your compliance team.

A recurring theme is evidence: running training is not enough on its own; organisations are expected to show what they did and how they acted on the results. Simulation records, reporting data and follow-up activity can support that evidence. They support a compliance programme; they do not establish compliance by themselves.