Your CFO gets an email from a long-time vendor: "We've updated our bank details. Please use the new account for the outstanding $47,000 invoice." The email comes from the right domain. It references a real invoice number. The AP clerk processes the change and sends the payment. Three weeks later, the real vendor calls asking where the money is.

That is business email compromise (BEC), and in 2025 it cost organizations $3,046,598,558 across 24,768 complaints, according to the FBI's IC3 annual report. Only investment fraud took more money. AP teams are the primary target because they control the one thing attackers want: outgoing payments.

One number from that report should shape your entire control design. 86% of BEC losses moved by wire transfer or ACH — a higher concentration in a single rail than any other crime type IC3 tracks. BEC is not a diffuse threat. It is an attack on one specific step in your process: the moment payment instructions are set or changed.

Why AP teams are the bullseye

BEC is not a technology problem. It is a process problem that exploits how AP teams work.

Attackers study your payment patterns before they strike. They compromise a vendor's email account, or spoof one convincingly, then wait for an active invoice thread. When they see a payment coming due, they insert themselves into the conversation with a simple request: change the bank details.

This works because AP teams are trained to be responsive. When a vendor asks for something, the default is to help. And the request — updating banking information — happens legitimately all the time.

The threat is also getting better written. IC3 logged 22,364 complaints in 2025 carrying an artificial-intelligence descriptor, accounting for $893 million in losses. The practical consequence for AP is that the old detection advice has expired. Awkward phrasing and broken grammar are no longer reliable signals. You cannot train your way to safety by teaching people to spot bad English.

The five BEC playbooks that target AP

1. Vendor bank detail change

The most common and most expensive. Attackers compromise a vendor's email or create a lookalike domain (think @acme-corp.com vs @acme-c0rp.com), then request updated payment routing. The AP team processes the change because it came from a "trusted" source.

Why it works: Bank detail changes are routine. AP teams process them regularly without suspicion.

2. CEO/CFO impersonation

An urgent email from the CEO to the controller: "I need a wire transfer of $125,000 processed today for a confidential acquisition. Do not discuss this with anyone." The email uses the CEO's name, signature, and sometimes a spoofed reply-to address.

Why it works: Authority pressure plus urgency bypasses normal approval workflows.

3. Conversation hijacking

Attackers gain access to a real email thread about an active transaction. They reply in-thread, matching the tone and style of previous messages, with modified payment instructions. Since the thread is legitimate, email filters do not flag it.

Why it works: The context is real. Only the payment details are fake.

4. Vendor portal credential theft

Phishing emails direct AP staff to fake vendor portals that harvest login credentials. Once inside, attackers can modify legitimate vendor records, including banking information, directly in your system.

Why it works: The change happens inside your own platform, so it looks like an authorized update.

5. Invoice duplication with modified details

Attackers send a duplicate of a real invoice — same vendor, same amounts, same PO number — but with different bank routing information. If duplicate detection is weak, both the real and fraudulent invoices get paid.

Why it works: The invoice itself is nearly identical to a legitimate one your team expects to receive.

The controls that actually stop BEC

BEC prevention is not about buying a single tool. It is about layering controls so that no single failure results in a fraudulent payment.

Out-of-band verification for bank changes

This is the single most effective control. When any vendor requests a change to banking details, verify it through a different communication channel. Call the vendor using a phone number from your records, not the one in the email. Use a known contact, not the person who sent the request.

Implementation: Create a policy that zero bank detail changes are processed on email alone. No exceptions. Not for the CEO, not for your biggest vendor, not for "urgent" requests.

Automated verification of the account itself

Calling the vendor confirms you are talking to a human you know. It does not confirm the account number belongs to them. Modern treasury practice adds a machine check on the account before it is ever paid:

Account ownership validation. Third-party validation services confirm that the account number and routing number belong to the legal entity named on your vendor master, catching the case where a real contact was socially engineered into sending a mule account.
Name matching. Compare the account holder name returned by validation against your vendor's registered legal name, not the trading name on the invoice. Mismatches are the highest-yield alert in the whole stack.
Micro-deposit confirmation. Slower, but it proves control of the account rather than mere knowledge of its number. Worth the delay for first payments to a new vendor.
Account status and reachability checks. Confirm the account is open and can receive the rail you plan to use, which also removes a chunk of ordinary payment failures.

Run these at two moments: when a vendor is onboarded, and again on every change to banking details. A validation that only runs at onboarding misses the exact event BEC exploits. Our guide to vendor bank account verification covers the operational detail.

Dual authorization, and where the approval happens

No single person should be able to both change vendor bank details and approve a payment to that vendor. Separation means an attacker has to compromise two people instead of one.

But dual authorization only helps if the second approval happens somewhere attackers cannot reach. An approval that lives in an email thread inherits every weakness of email: it can be spoofed, hijacked mid-thread, or forwarded from a compromised mailbox. Moving authorization into an authenticated workspace such as Slack changes the security properties. The approver is a verified identity in your directory rather than a display name, the request appears in a channel with a durable record, and the approval is bound to the specific record it authorizes rather than to a reply-to address.

That is the practical version of the principle: do not ask people to approve payments in the same medium the attacker controls. Pair it with strong AP internal controls and a clear segregation of duties framework.

Email authentication (DMARC, SPF, DKIM)

These three protocols verify that incoming emails actually come from the domains they claim. DMARC alone blocks the simplest spoofing attacks, where an attacker sends email with a forged "From" address.

The gap: Email authentication stops domain spoofing but does nothing against compromised accounts. If an attacker is sending from the real vendor's actual mailbox, DMARC passes. That is why verification controls matter more than technical filters.

AP automation as a control layer

Here is what most BEC prevention guides miss: AP automation is not just about efficiency. It is a fraud control.

When invoices flow through an automated system, every change is logged. Bank detail modifications trigger approval workflows. Invoice matching catches phantom invoices. Audit trails record who changed what and when.

Manual AP processes are BEC-friendly because changes happen in email threads, spreadsheets, and phone calls with no centralized record. Automated systems create friction — the good kind — that forces verification before payment.

The wire security checklist

Print this. Run it before any payment to a new account, and before any payment following a bank detail change.

Was the change request received by email or from a portal login? Treat both as unverified.
Have you called the vendor on a number from your own records, not from the request?
Did you speak to a known contact, not the requester?
Does the account holder name match the vendor's registered legal name?
Has account ownership validation been run against the new details?
Is this the vendor's first payment to this account? If so, has a micro-deposit or equivalent confirmed control?
Has a second authorized person approved the change, in a system that is not email?
Is the change logged with timestamp, approver identity, and the reason recorded?
Does the payment amount and timing match an expected invoice and PO?
If the request carried urgency or secrecy, has it been escalated rather than accelerated?

A "no" on any of items 2 through 8 stops the payment. Urgency is not an override. In practice, manufactured urgency is the single most reliable indicator that something is wrong.

Training that goes beyond "be careful"

Generic security awareness training does not stop BEC. AP-specific training does. Your team needs to practice with scenarios that match their actual workflow:

A vendor email requesting bank detail changes mid-payment cycle
A CFO requesting an urgent wire transfer on a Friday afternoon
An invoice that matches a real PO but has slightly different routing numbers

Run tabletop exercises quarterly. Measure response time and accuracy. The goal is not awareness. It is muscle memory.

What to do if you suspect a BEC attack

Speed matters more than certainty. Report on suspicion, not on confirmation.

In 2025 the IC3 Recovery Asset Team ran its Financial Fraud Kill Chain on 3,900 incidents covering $1.16 billion in attempted theft, and froze $679 million of it — a 58% success rate. That recovery rate exists only for victims who report quickly enough for the chain to be initiated.

Contact your bank immediately and request a recall of the funds, along with any indemnification documents they require. Know in advance what your institution will and will not do, because policies differ.
File a complaint at ic3.gov regardless of the amount, including full transaction details.
Preserve all email evidence, including full headers, not just the message body.
Notify the real vendor so they can secure their compromised accounts.
Review all recent bank detail changes across your vendor master for other compromised records.

Practical takeaways

BEC prevention comes down to four principles: verify outside the channel, validate the account itself, separate duties, and approve somewhere email cannot reach.

Start with the highest-impact change: mandatory out-of-band verification for every bank detail modification, backed by automated account validation. Those two together block the overwhelming majority of BEC payment fraud, because they attack the 86% of losses that move by wire and ACH at the exact point the instructions change. Then layer on dual authorization outside email, DMARC, and automated invoice processing that logs every change.

The companies that lose millions to BEC are not careless. They are busy, understaffed, and running AP processes designed for a world where vendor emails could be trusted. That world no longer exists.

FAQ

How much do BEC attacks cost businesses each year?

According to the FBI's IC3 2025 annual report, business email compromise caused $3,046,598,558 in losses across 24,768 reported complaints, making it the second-costliest internet crime after investment fraud. The real figure is higher because many incidents go unreported. The most useful detail for AP teams is the transaction mix: 86% of BEC losses moved by wire transfer or ACH, which means controls concentrated on payment instruction changes address the overwhelming majority of exposure.

What is the most effective way to prevent BEC attacks in accounts payable?

Out-of-band verification combined with automated account validation. When a vendor requests a change to bank details, call them on a number from your own records rather than the one in the request, and separately run account ownership validation to confirm the account belongs to the vendor's registered legal entity. The call proves you are talking to the right people; the validation proves the account is theirs. Add dual authorization performed outside email, and no bank detail change should ever be processed on an email request alone.

Why does approving payments in Slack reduce BEC risk compared to email?

Because email is the medium the attacker already controls. A BEC attack works by spoofing a sender, hijacking a real thread, or sending from a genuinely compromised mailbox, and an approval that happens in that same channel inherits all three weaknesses. An approval in an authenticated workspace is tied to a verified directory identity rather than a display name, is bound to the specific payment record rather than to a reply address, and leaves a durable log that cannot be quietly deleted from a mailbox. The approval step stops being a message and becomes a control.

How do BEC attacks target accounts payable specifically?

BEC attackers target AP teams because they control outgoing payments. The most common tactic is vendor impersonation: attackers compromise a vendor's email account or create a lookalike domain, then request updated bank routing for an active invoice. Because AP teams process bank detail changes routinely, the request does not trigger suspicion. Attackers increasingly use AI to draft these messages, so the old advice about spotting poor grammar no longer holds — IC3 recorded 22,364 AI-related complaints in 2025 accounting for $893 million in losses.

The CFO's Guide to Preventing Business Email Compromise (BEC) in Accounts Payable