BEC Awareness for Finance Teams: AP and Treasury Guide

Business email compromise succeeds when a finance employee makes a payment the business would never knowingly approve, usually because a convincing message arrived in a familiar thread and the process let one person act on it. The FBI's Internet Crime Complaint Center (IC3) recorded 24,768 BEC complaints and about $3.05 billion in losses in its 2025 report, the second largest loss category after investment fraud. This guide is for finance leaders, accounts payable (AP), treasury and payroll managers and the security and awareness teams who support them. It covers the BEC patterns that reach finance, what each finance role must know, the verification steps to build into the payment process, how to run role-based training and drills, and how to measure whether it is working. Domain authentication and mailbox hardening are covered in the Email Identity and BEC Guide; this page is about the people and the process.

Key takeaways

Training must be tied to the payment process. Generic phishing awareness does not stop a bank detail change that arrives from a real supplier's compromised mailbox; a mandatory callback to a number already on file does.
Every finance role sees a different attack. AP sees supplier bank changes, treasury sees urgent executive transfers, payroll sees employee direct deposit changes, and executive assistants see gift card and confidential deal requests. Train each on its own scenarios.
Email is no longer the only channel. IC3 defines BEC as including compromise of phone numbers and virtual meeting applications, and the Arup case moved from a message to a deepfake video call. The verification rule must apply whatever the channel.
Speed of reporting decides recovery. The FBI Recovery Asset Team froze about $679 million through the Financial Fraud Kill Chain in 2025. Staff who report a suspected fraudulent payment in minutes, not days, give the bank a chance to recall it.
Measure behaviour, not course completion. Track callback compliance on bank detail changes, time to report, and drill outcomes for finance staff, alongside completion rates.

How BEC reaches finance teams

BEC is fraud carried out through legitimate looking business communication. The FBI describes three enabling methods: spoofed or lookalike addresses and websites, targeted spearphishing to learn about real transactions, and malware or account compromise that lets criminals read billing threads and time their requests. The patterns below account for most of what finance staff will see.

Pattern	Who it targets	What it looks like	Control that breaks it
Supplier bank detail change	AP, vendor master team	A known supplier asks to update remittance details, often with a letter on headed paper, sometimes from the supplier's real compromised mailbox	Callback to a contact number already held, independent of the request; second-person approval of the change
Fake or altered invoice	AP	An invoice in an existing thread with different bank details, or a new supplier onboarding with a W-9 or equivalent form and an urgent first payment	Three-way match against purchase order and receipt; no payment to new suppliers until onboarding checks complete
Executive impersonation	Treasury, finance managers	The CEO or CFO asks for an urgent, confidential transfer for an acquisition or settlement, often outside hours and with instructions not to discuss it	Rule that no executive can waive dual approval; verification through a known number or in person
Payroll diversion	Payroll, HR	An employee asks to change direct deposit details just before a pay run	Changes only through the HR self-service portal with MFA; notification to the employee's existing contact details
Gift card request	Executive assistants, office managers	A senior person asks for gift cards and the codes by reply	Policy that gift cards are never bought on an email or message instruction
Lawyer or adviser impersonation	Treasury, legal, M&A teams	A message claiming to be from external counsel or an auditor about a time-sensitive transaction	Verification with the adviser through contact details on the engagement letter
Voice or video deepfake	Finance staff with payment authority	A call or video meeting in which a known executive appears to confirm the request	Callback on a separate channel initiated by the employee; code words or approval in the payment system itself

Two facts change how these should be taught. First, the message often comes from a genuine account: once a supplier mailbox is compromised, SPF, DKIM and DMARC all pass. In the TruffleNet BEC attack, stolen AWS keys were used to send DKIM-signed vendor onboarding invoices requesting a $50,000 ACH payment through Amazon SES. Second, attackers who control a mailbox use inbox rules to hide replies (ATT&CK T1564.008 Email Hiding Rules) and forwarding rules to watch the thread (T1114.003 Email Forwarding Rule), so the real party may never see the fraud in progress. Staff should be told that a "legitimate sender" is not proof of a legitimate request.

What each finance role needs to know

Role-based training (NIST CSF 2.0 PR.AT-02, SP 800-53 AT-3) works when it is short, specific and built from the decisions each person makes. A one-page card per role is more useful than a long module.

Role	Decisions at risk	Must know	Drill to run
Accounts payable clerks	Processing invoices, entering supplier bank changes	Never use contact details from the request; callback rule; how to spot changed bank details in an existing thread	Simulated supplier bank change from a lookalike domain and from an internal test mailbox posing as a real supplier
Vendor master data team	Creating suppliers, approving detail changes	Segregation of duties between who requests and who approves a change; evidence to retain	Audit sample of recent changes for callback evidence
Treasury and payments	Releasing high-value and same-day transfers	Executive requests do not override dual approval; how to recall a payment and who to call at the bank	Tabletop: CFO "on a video call" asks for an urgent cross-border transfer
Payroll	Changing employee bank details	Only accept changes through the authenticated portal; confirm through existing contact details	Simulated direct deposit change request two days before payday
Executive assistants	Acting on executives' behalf	Executives will never ask for gift cards or secret transfers by message; how to verify	Simulated executive message from a personal-looking address
Finance leadership and executives	Setting tone, approving exceptions	Their name is the lure; they must publicly support staff who delay a payment to verify	Briefing using a real case such as Arup

For the wider programme that this sits within, see the Security Awareness and Human Risk Management Guide and the Role-Based Security Training Programme Guide.

Verification rules to build into the payment process

Awareness only holds if the process makes the safe action the normal one. These rules should be written into the finance procedures, enforced in the ERP or payment system where possible, and taught as the rules, not as advice.

Callback on every bank detail change: call the supplier or employee on a number already held in the vendor master or HR system, never one in the request. Record who called, who answered, the number and the time. The FBI and IC3 both recommend verifying changes through a secondary channel or a known number.
Dual control: the person who enters a bank detail change cannot approve it, and payments above [threshold] need two approvers in the payment system. No one, including the CEO, can waive this by message.
Cooling-off period: hold the first payment to new or changed bank details for [24 to 72 hours] or until a small confirmed test payment has been acknowledged through the known contact.
No payment on urgency alone: urgency, secrecy and pressure to bypass process are the red flags the FBI lists. Staff should be told in writing that delaying a payment to verify is always acceptable.
Bank-side checks: use payee name checks where your banking market offers them (for example Confirmation of Payee in the UK), positive pay for cheques and ACH where available, and bank alerts for new beneficiaries.
New supplier onboarding: verify a new supplier's identity, company registration and bank account ownership before the first invoice is paid, not after.
Channel-independent approval: approval lives in the payment system, not in email, chat or a call. A deepfake can join a video meeting; it cannot approve in your ERP without credentials and MFA.

For the detailed treatment of supplier bank detail fraud, see the Invoice Redirection and Supplier Bank Detail Fraud Guide, and for the executive variant, the Executive Deepfake and CEO Fraud Guide.

Running role-based training and drills

Map the payment journeys: with the finance controller, list every way money leaves the business (supplier payments, payroll, treasury transfers, card spend, refunds) and the people who can change or release each one.
Write the rules first: agree the callback, dual control and cooling-off rules with finance leadership before training on them, so the training teaches policy rather than suggestions.
Short, scenario-based sessions: 20 to 30 minutes per role, using anonymised examples from your own near misses and from public cases. Repeat at least [twice a year] and at onboarding for anyone joining finance.
Simulations that reflect the real attack: phishing simulations for finance should include bank detail change requests, fake invoices in an existing thread and executive requests, not only credential harvesting links. Coordinate with finance so that a test payment is never actually released. See the Phishing Simulation Programme Guide.
Tabletop the worst case: once a year, run a tabletop where a fraudulent transfer has been made and the team must recall it. Time how long it takes to find the bank contact and the IC3 or national reporting route.
Reward the delay: recognise staff who stopped or delayed a suspicious payment. Never discipline someone for verifying, even if the request turned out to be genuine.
Feed back: share sanitised near misses with all finance staff within days, so the training stays current with what is actually arriving.

Technical controls that back up finance staff

People are the last control, not the only one. Ask the security team to confirm these are in place for finance users.

Phishing-resistant MFA: for finance mailboxes, ERP and banking portals, so stolen passwords alone cannot take over a payment approver's account.
Inbound authentication and tagging: enforce DMARC on your own domains and use external sender and lookalike domain warnings. See the DMARC, SPF and DKIM Guide.
Inbox rule monitoring: alert on new forwarding and hiding rules created on finance mailboxes (unified audit log operations New-InboxRule, Set-InboxRule and UpdateInboxRules in Microsoft 365). Microsoft notes that malicious rules sync from the cloud and survive client reinstalls, so removal must happen at the mailbox.
Payment system alerts: flag payments to bank accounts changed within the last [30 days], first payments to new beneficiaries and payments to accounts in unexpected countries.
Report button: a one-click report option in the mail client and a named finance fraud contact for calls and messages.

When a payment has already gone

Finance staff should have this sequence on a card next to the payments desk.

Call your bank's fraud line immediately and ask it to recall the payment and contact the receiving bank. The FBI's guidance is to contact the financial institution immediately and request a recall.
In the US, file a complaint at ic3.gov as soon as possible, regardless of the amount; this is how the Recovery Asset Team and Financial Fraud Kill Chain are triggered. Elsewhere, use the national reporting route for fraud and your bank.
Tell the security team so the mailbox, supplier thread and any inbox rules can be investigated and credentials reset.
Preserve the emails with full headers, call logs and payment records. Do not delete the messages.
Warn the genuine supplier or executive, using known contact details, that their identity was used.

The full response is covered in the Business Email Compromise Response Playbook.

Measuring whether it works

Callback compliance: percentage of bank detail changes in a monthly sample with recorded callback evidence. Target 100 per cent.
Simulation outcomes for finance: report rate and failure rate on finance-specific scenarios, tracked per role over time.
Time to report: median time from a suspicious payment request arriving to it being reported.
Stopped attempts: number and value of fraudulent payment attempts stopped by verification, recorded as near misses.
Exceptions: number of payments released without dual approval or with a waived cooling-off period, and who approved the waiver.

Framework mapping

Area	NIST CSF 2.0	NIST SP 800-53 Rev. 5	Other
General awareness	PR.AT-01	AT-2, AT-2(3) Social Engineering and Mining	ISO/IEC 27001:2022 A.6.3
Role-based training for finance	PR.AT-02	AT-3	ATT&CK mitigation M1017 User Training
Security in HR and role design	GV.RR-04	AT-3	Segregation of duties in payment approval
Mailbox abuse detection	DE.CM-09	AU-6	ATT&CK T1114.003, T1564.008, T1534 Internal Spearphishing
Inbound phishing	DE.CM-01	SI-8	ATT&CK T1566.002; D3FEND D3-SMRA Sender MTA Reputation Analysis

Common failure patterns

Calling the number in the email: the callback rule exists but staff use the phone number in the fraudulent letter, which reaches the attacker.
Executive exemption: unwritten habits let a senior person override dual approval "just this once", which is exactly what impersonation exploits.
Training only on credential phishing: finance staff can spot a fake login page but have never practised a bank detail change from a real supplier's address.
Trusting the channel: staff accept a video call or voice note as verification. The Arup deepfake fraud began with a message from an apparent CFO and was confirmed on a video call where the other participants were deepfakes; 15 transfers totalling HK$200 million followed.
Slow reporting: staff fear blame and wait days to report, when early bank contact is what makes recall possible.
No evidence trail: callbacks happen but are not recorded, so audit cannot tell whether the control works.

Lessons from incidents

The Arup case shows that a cautious employee who initially suspected phishing was persuaded by a multi-person video call. The lesson for finance teams is that verification must be initiated by the employee through a channel they choose, and approval must live in the payment system. The TruffleNet campaign shows the other side: stolen cloud credentials let attackers send properly signed invoices, so technical email checks passed and only process controls remained.

Practitioner checklist

Write mandatory callback, dual control and cooling-off rules into finance procedures and enforce them in the payment system where possible.
Issue a one-page BEC card per finance role with its specific scenarios and the reporting contact.
Run finance-specific simulations covering bank detail changes, invoices in existing threads and executive requests.
Hold an annual tabletop for a payment that has already been made, including bank recall and IC3 or national reporting.
Enforce phishing-resistant MFA on finance mailboxes, ERP and banking portals.
Alert on new forwarding and hiding inbox rules on finance mailboxes.
Sample bank detail changes monthly for callback evidence and report the result to the finance director.
Publicly recognise staff who delay a payment to verify.

Business Email Compromise Awareness for Finance Teams Guide: Training and Controls for AP and Treasury