Wire Fraud Prevention for Financial Firms: Stopping Payment-Change BEC

Wire fraud prevention for financial firms rests on one rule. No bank account gets added or changed because an email said so. Verify every change by calling a number you already had, then have a second person approve the payment.

Payment-change fraud doesn't need malware or a ransom note. It needs one convincing email, sent at the right moment, to the one person allowed to update where the money goes. A vendor "switched banks." A client wants this quarter's distribution sent to a new account. The request looks routine, and that's the whole trick.

Financial firms sit on both sides of it. Your own payables can be redirected, and so can the money you move for clients. The fix is mostly process, a callback rule and a second approver, backed by a few email controls and a plan for the first hours after a bad wire. It's part of Consilien's work on IT services for financial firms, and the regulatory side lives in our financial services IT compliance guide.

Key Takeaways

• BEC cost U.S. victims $3.05 billion in 2025 across 24,768 complaints, per the FBI.
• Treat every new or changed payment instruction as unverified until someone calls a number you already had on file.
• Never verify on a call the requester started, and never with the phone number in their email.
• First payment to a new account gets a second approver and a short hold.
• If a wire goes out wrong, call your bank and file at ic3.gov within hours, not days.

What is payment-change BEC?

Payment-change BEC is business email compromise where the attacker doesn't ask for new money. They redirect money you were already going to send by changing the bank account on file, usually through a hacked or spoofed email from a vendor, a client, or someone inside your own firm.

The FBI's 2025 IC3 annual report logged 24,768 BEC complaints and $3,046,598,558 in losses last year, up from $2.77 billion in 2024. Only investment fraud cost victims more. And that only counts the victims who reported.

It isn't rare inside finance departments, either. The AFP's 2026 Payments Fraud and Control Survey, fielded in January 2026 among 465 treasury practitioners, found that 74% of organizations were affected by BEC in 2025.

Nacha, the body that runs the ACH network (the bank-to-bank system behind direct deposit and most vendor payments), now has a formal term for this. Its rules define False Pretenses as a payment induced by someone misrepresenting their identity, their authority to act for someone else, or "the ownership of an account to be credited." Nacha says outright that the definition covers "Business Email Compromise (BEC), vendor impersonation, payroll impersonation, and other payee impersonations."

Why do financial firms get hit from two directions?

Because they move two kinds of money. There's the firm's own money (rent, software, payroll, vendors) and there's client money, which a wealth manager, broker-dealer, or accounting firm with bill-pay authority sends out on someone else's instruction. Each has its own attack.

FINRA's 2026 Annual Regulatory Oversight Report names the second pattern directly. It lists account impersonation as "threat actors using stolen customer information in combination with a compromised or spoofed email address to initiate actions, often a third-party wire transfer request, from the customer's account."

FinCEN flagged the executive version years ago. In its 2019 BEC advisory, it found that roughly half of all BEC fraud targeting financial institutions came through emails impersonating the CEO or president, a choice it said was meant "to discourage employees receiving the fraudulent payment instructions from challenging or confirming the order." The same advisory noted that fraudulent vendor and client invoices tend to involve larger amounts than CEO fraud, since the payments being hijacked were big and recurring to begin with.

How does a payment-change attack actually unfold?

Quietly, for weeks, and then in one afternoon. The attacker usually spends days or weeks inside a real mailbox reading invoices and learning who approves what, then sends one well-timed request. By the time anyone notices, the money has typically moved through a second and third account.

That inbox rule step is common enough that Microsoft publishes a playbook for it. Its guidance on suspicious inbox manipulation rules explains that attackers "might create rules that hide incoming mail in the compromised mailbox," which is how the real vendor's "we never changed our bank" reply ends up in a folder nobody opens.

The "Watch" row is where firms get beaten. There's no tool that reliably catches an attacker reading email they're allowed to read, because to Microsoft 365 they look like the account owner. The control that still works at that point is a person picking up a phone.

What should happen before money goes to a new account?

A short, written workflow that applies to every change, with no exceptions for seniority or urgency. Someone outside the email thread confirms the change by phone, a second person approves the first payment, and the record shows who did what.

1. Freeze the request. Any email that adds a payee, changes bank details, or redirects a disbursement goes into a pending state, and nobody updates the vendor master file or the custodian instructions from the email itself.
2. Call a number you already had, from the signed vendor setup form, the CRM, or the client agreement. Never the email, its signature block, or an attached letter. Ask the person to read the routing and account numbers back to you instead of reading them out yourself.
3. A second person approves the first payment. Whoever verified the change can't be the one who releases the money. In a five-person office that might mean the owner and the bookkeeper. Fine.
4. Hold it one to two business days. That gap gives the real vendor or client time to notice, and it costs almost nothing.
5. Log who called, which number, when, and who approved. Six months from now, when an auditor or your insurer asks, that log is the only evidence the control ran.

Step 2 is where people slip. The client is a friend, the vendor has been paid monthly for six years, the partner is standing right there. FINRA's effective practices for broker-dealers point the same way. FINRA tells firms to review "wire requests to third-party accounts," especially accounts the customer has never paid before.

How strict should verification be for each request?

Not every request needs the same treatment. Match the check to the risk.

The partner row tends to start arguments. It shouldn't. If the managing partner really did send that request, a two-minute call costs them nothing, and if they didn't, it's the call that saved the firm.

Isn't a callback enough on its own?

It used to be closer to enough. Voice cloning changed that. A callback still works if you place the call to a number you already trusted, but any call the requester starts, or any number they supplied, can now put a convincing fake on the line.

The case everyone cites is Arup. In January 2024, a Hong Kong-based finance employee at the engineering firm was talked into 15 wire transfers totaling HK$200 million, about $25.6 million, after a video call where the CFO and several colleagues were all deepfakes. Arup confirmed to police "that fake voices and images were used."

The FBI is seeing it in BEC specifically. Its 2025 report says voice cloning "can also be used to request wire payment," and that businesses reported over $30 million in losses to BEC scams involving AI last year. That's small next to $3 billion. It won't stay small.

So the callback rule needs two refinements. First, your side places the call, every time, to a number that predates the request. Second, agree on something that can't be scraped from LinkedIn or a voicemail greeting, like a verbal passphrase for clients who wire often, or a question about the last transaction. A cloned voice can say anything. It can't know what the real person never posted.

Which technical controls back up the verification process?

The ones that make an attacker's first two stages harder, getting into a mailbox and hiding inside it. None of them replaces the callback. They shrink the number of convincing fake requests that reach a person in the first place.

The DMARC row trips firms up. It protects your domain from being forged (our DMARC, SPF, and DKIM guide covers the setup). It does nothing when the attacker is sending from your vendor's real, hacked mailbox, which is exactly the payment-change scenario. Firms that set up DMARC and consider BEC handled are guarding the wrong door.

If you want a managed version of the email side, Consilien's email security services cover impersonation filtering, DMARC enforcement, and response when an account is compromised. Our Microsoft 365 email security guide and our walkthrough of Conditional Access policies cover what you can switch on yourself.

What do Nacha, FINRA, and the SEC now expect?

Written, risk-based controls on payment changes, reviewed at least yearly. Nacha's 2026 rules now require them of any business that originates ACH payments, and FINRA and the SEC expect broker-dealers and advisers to verify disbursement requests and notify customers fast after a breach.

• Nacha Phase 2. Since June 22, 2026, every non-consumer ACH Originator, regardless of volume, has had to keep risk-based processes "reasonably intended to identify Entries that are suspected of being unauthorized or authorized under False Pretenses," and review them at least annually. If your firm runs payroll or pays vendors by ACH, that's you. Nacha even names the obvious example, "change controls regarding payment information and instructions for vendor and payroll payments."
• Phase 1, effective March 20, 2026, covered banks and very large originators, those above 6 million entries in 2023.
• FINRA keeps cyber-enabled fraud, account takeover, and deepfakes on its 2026 oversight list, and expects firms to "verify signatures associated with third-party accounts if funds are requested to be sent to or from those outside accounts."
• The SEC's amended Regulation S-P requires covered firms to notify affected customers no later than 30 days after learning of unauthorized access to their information. Larger entities had to comply by December 3, 2025, smaller ones by June 3, 2026.

None of these rules shifts the loss if a wire goes out. Nacha says its rule doesn't change who's liable under the Uniform Commercial Code. They're the bar your process gets measured against afterward. Accounting and tax firms answer to the FTC Safeguards Rule instead, which our compliance guide covers. Building a compliance program is separate work from the IT controls here, and Consilien runs it as its own engagement.

What should you do in the first hours after a fraudulent wire?

Call your bank's fraud line and ask for a recall, then file a complaint at ic3.gov with the full transaction details. Speed decides most outcomes. Money that's still in the first receiving account can often be frozen, and every hour gives the attacker time to move it again.

The FBI runs a program built for this. Its Recovery Asset Team uses the Financial Fraud Kill Chain to ask receiving banks to freeze funds. In 2025, according to the IC3 annual report, it worked 3,900 incidents involving $1.16 billion in attempted theft and froze $679 million, a 58% success rate. In one case from the report, a couple wired more than $449,000 for a home closing after an email impersonating their attorneys, and once the FBI got involved the receiving bank confirmed "the full amount was still in the account and on hold."

The FBI's instruction is plain. "Regardless of the amount lost, file a complaint." There's a persistent belief that small losses aren't worth reporting. File anyway.

Then, in roughly this order:

• Call your bank's fraud department, not your relationship manager's cell, and ask for a recall and any indemnity paperwork they need.
• File at ic3.gov with the amount, date, sending and receiving banks, and account numbers.
• Reset the password and revoke active sessions on any mailbox involved, then check it for inbox and forwarding rules.
• Preserve the email with its full headers. Don't delete the thread.
• Call your cyber insurance carrier before you hire anyone, since many policies require their approved breach counsel and forensics firm.
• If client data may have been exposed, start the Reg S-P or Safeguards Rule notice clock now, with counsel.

A written incident response plan turns that list into names and phone numbers before you need them. Without one, the first hour goes to figuring out who's supposed to call the bank.

Who needs a formal program, and who's mostly covered?

Any financial firm that pays vendors by wire or ACH, or moves client money on instruction, needs the written workflow above. The tooling around it scales with size. A firm that never moves client funds and pays everything through a bill-pay platform with built-in payee verification already has much of this done.

That last group is real. If your custodian requires its own verbal confirmation on every third-party disbursement and your payables run through a platform that won't release a first payment to a changed account without an independent check, your job shrinks to training and the email controls. Don't buy a second system to duplicate one you already have.

For everyone else, here's the order Consilien, a managed IT and cybersecurity provider for businesses nationwide, would suggest. Start with the one-page workflow, then the inbox rule alerts, then a security awareness training program that runs a fake payment-change request against your own AP and client service teams. You'll learn more from one simulated "we changed banks" email than from a year of generic phishing tests.

If you're weighing whether to handle this in-house or hand it to a provider, our guide to managed IT costs for financial services firms gives realistic ranges, and our ranking of the best MSPs for financial services compares providers that work with advisers and accounting firms. When you're ready to pressure-test your own process, speak to a financial services IT expert at Consilien.