Wire Fraud Controls Every Finance Team Should Have
Stop corporate wire fraud with dual authorization above a stated threshold, out-of-band verification of every banking detail change, and a rule that urgency triggers more checking, not less. Most schemes are business email compromise or vendor payment redirection, and they work because a convincing request looks routine enough to process without a second check.
The controls that stop this aren't exotic. They're specific, boring, repeatable steps that most companies simply haven't formalized yet.
Vendors Covered in this Article
Disclosure: We may earn a commission if you buy through some links on this page. It doesn't change what we recommend.
The two fraud patterns that account for most losses
Business email compromise impersonates an executive or a trusted contact and asks for an urgent wire, usually with pressure to skip the normal process because of some time-sensitive reason. Vendor payment redirection impersonates an existing vendor and asks to update banking details for an upcoming invoice payment, which is harder to catch because the invoice itself is often real, only the destination account has changed.
Knowing which pattern you're looking at changes the verification step: an urgent executive request needs identity verification, while a banking-detail change needs vendor verification through a channel the fraudster doesn't control.
How do you require dual authorization above a stated threshold?
Set a dollar threshold above which no single person, regardless of title, can approve and send a wire alone, and configure your bank's actual permission settings to enforce it, not just a policy document. "No exceptions" has to be a real rule; a fraud scheme that impersonates the CEO specifically counts on someone making an exception for the CEO.
Make sure the second approver is someone who genuinely reviews the request rather than a rubber-stamp approval that exists only to satisfy the dual-control requirement on paper.
How do you verify a banking detail change out of band?
Any request to change a vendor's or an employee's payment banking details should be confirmed through a phone call to a known, previously verified number, never a number provided in the same email making the request. This single step defeats the vendor payment redirection scheme almost entirely, since the fraudster controls the email thread but not a phone number you already had on file before the request came in.
Build this into the actual workflow, not just guidance in a policy document that people forget under time pressure. A checklist step in whatever tool processes the payment change is more reliable than a rule someone has to remember.
Treat urgency itself as a red flag, not a reason to move faster
Fraud schemes are built around urgency because urgency is what gets people to skip a verification step. Train your team to treat "this needs to happen right now, don't wait for the usual process" as the signal to slow down and verify, not speed up, especially when the request also asks to bypass a normal control.
This is a cultural point as much as a procedural one: someone on your team needs to feel safe pausing an urgent-looking request from a senior executive without fear of being seen as obstructive, and that only happens if leadership has explicitly said so.
Run a real test, not just a training slide
A short, internal simulated phishing or fraud-request test, run periodically and treated as a learning exercise rather than a punishment, tells you far more about whether your controls actually work than a policy document does. If someone clicks or processes the simulated request, that's information about where the gap is, not a reason to discipline them.
BILL and similar payment platforms build approval workflows and payment controls directly into the sending process, which is a more durable place to enforce dual authorization than relying on everyone remembering a policy.
A pattern worth watching: the second request
A common escalation in these schemes is a follow-up message a day or two after an initial, smaller test request succeeds, asking for a larger amount now that trust has been established. Treat a second, larger request from the same contact as its own independent event requiring its own full verification, rather than assuming the first request's approval covers it. Fraud schemes are often deliberately structured this way, starting small specifically to get a control to relax before the real target amount is requested.
These controls block most of the schemes described above:
- Dual authorization above a stated dollar threshold, enforced in the bank's permission settings, with no exception for any title.
- Phone confirmation of any banking detail change using a known, previously verified number, never one from the request itself.
- A rule that urgency, or a request to skip the normal process, triggers extra verification instead of faster processing.
- Periodic simulated fraud requests, run as learning exercises rather than as a reason to discipline anyone.
- Independent verification of any follow-up request, even from a contact whose earlier request was approved.
What Good Looks Like
Good wire fraud prevention means no payment or banking-detail change above your threshold moves without both dual approval and an out-of-band verification call to a number you already had on file.
Building The Capability (5-Stage Skill Ladder)
How to Get Started
Disclosure: We may earn a commission if you buy through some links on this page. It doesn't change what we recommend.
Frequently Asked Questions
What should we do immediately if we suspect a wire was sent to a fraudulent account?
Contact your bank immediately to request a recall, since banks can sometimes intercept a wire before it fully settles, though success isn't guaranteed and speed matters enormously. Also file a report with the FBI's Internet Crime Complaint Center and your bank's fraud department, since early reporting occasionally helps recovery efforts.
Is dual authorization enough on its own, or do we still need out-of-band verification?
You need both. Dual authorization catches a fraudulent request if the second approver is genuinely scrutinizing it, but a sophisticated scheme can fool two people if neither independently verifies the underlying request through a separate channel. The two controls catch different failure modes.
How do we verify a vendor's identity if we've never spoken to them by phone before?
Use a publicly listed number from the vendor's own website or a previous, unrelated communication, not any number provided in the request you're trying to verify. If no independently sourced number exists, treat that as a reason for extra caution rather than proceeding anyway.
About the numbers
This guide doesn't quote a sourced benchmark. Figures in it are estimates or general guidance, so check them against your own numbers.
Related Guides
What to Do in the First 48 Hours After a Round Wires In
A concrete allocation protocol for the first days after a venture round closes, so a large wire doesn't sit in a single account longer than it should.
Setting Real Spend Limits on Corporate Charge Cards
How to set per-card limits, receipt capture and approval rules for corporate charge cards so spend actually matches budget instead of surprising you monthly.
Getting Cash Out of a Country With Currency Controls
How currency controls in emerging markets restrict moving profits home, and the practical steps that actually get approved repatriation moving.
ACH, Wire or RTP: Which Payment Rail to Use for Each Payment
Choose between ACH, wires and real-time payments by speed, cost, finality and fraud risk, with a guide for payroll, vendors, refunds and large transfers.
How to Retire Petty Cash Without Losing Control of Small Purchases
A step-by-step plan for replacing a petty cash box with single-use virtual cards, without losing the spend controls a cash box gave you by accident.
What a Series B Treasury Audit Actually Checks
The specific documents and controls a treasury audit checks at Series B, and how to prepare so the review doesn't surface gaps you could have fixed earlier.