Wire fraud detection is the set of checks a bank runs on an outgoing wire before release to find payments that should not go: orders sent by someone who took over a client's account, and genuine orders that a deceived client sent to a fraudster's account. The second kind, business email compromise, is the hard one, because every credential and approval on the order is real. Detecting it means looking past the payment to the instruction behind it and to the client's history with the payee. That is the test to apply to any tool, and it is the work Botminds' Wire Fraud Prevention was built for: agents compare each held wire with the client's history, read the email or document behind a new instruction and prepare a callback to a number of known origin, and two people decide. The twelve questions below separate tools that score payments from tools that produce evidence a wire room can act on before the cutoff.
Where this guide shows the solution at work, the data are a fictional sample bank's: Corvane National Bank, which on the afternoon of Thursday 22 October had sent 4,912 outgoing wires and held 248 for review. Product results are sample data or design targets, never a customer's measured results.
Twelve questions for any wire fraud detection tool, and why each matters
- Does it read where a new instruction came from, or only the payment?
In business email compromise the payment is genuine; the forged email or letter is the evidence.
- Does it compare the payee with this client's own history, field by field?
A payee whose bank changed after a year of payments to the same account is a finding; "unusual" is not.
- Does every finding cite its source?
An operator signs against evidence, and an examiner tests it. A bare score helps neither.
- Where does the callback number come from, and can it ever be the one in the instruction?
A callback to the fraudster's number confirms the fraud.
- Can any automated part release, stop or return a wire?
If yes, its errors become payments. Release should need two named people.
- Does it enforce maker-checker, authority tiers and no self-approval?
Dual control fails when the checker signs without evidence or checks their own decision.
- Will its record prove you followed the agreed security procedure?
Under UCC 4A-202(b) the bank carries that proof. Can the record be edited?
- Does it hold beneficiary and template changes, not only wires?
Fraudsters change the template so the next payment needs no forgery at all.
- Does it work to each rail's cutoff, and on Sundays and holidays once Fedwire runs 22x6?
A held wire that misses review at 4:50 p.m. goes out unchecked or misses the day.
- Does it see across clients?
One new bank in two clients' held wires on the same afternoon is a pattern no single wire shows.
- Does it keep confidential wording out of client messages?
SAR confidentiality rules forbid revealing that a SAR exists; a draft that says "SAR" is a breach waiting to happen.
- Can you test it on your own past held wires before you sign?
Count holds, callbacks and confirmed attempts by rule, on your data, not a vendor's average.
How does wire fraud detection work?
Wire fraud detection works by holding wires that meet the bank's rules and putting evidence about them in front of a reviewer before release. Tools differ in what the rules look at and what evidence they produce. Most fall somewhere between two designs: one scores each payment for how unusual it looks, the other explains what changed and where the new details came from.
Two designs of wire fraud detection, and what each gives the reviewer
Score-based: The payment: amount, timing, destination, against patterns across many customers
Evidence-based: The payment and the instruction behind it, against this client's own history with this payee
Score-based: A risk score and reason codes
Evidence-based: What changed, field by field, with the source of each old and new value, and the email or document read
Score-based: A genuine client paying a genuine-looking amount to a domestic account can score low
Evidence-based: A changed account for a known payee is flagged whatever the amount
Score-based: Usually outside the tool
Evidence-based: Prepared: a number of known origin and a script
Score-based: Score and disposition
Evidence-based: Evidence, call, proposal and both names, enough to prove the procedure was followed
Neither design is wrong. Scoring finds account takeover and mule activity well, because those frauds change the shape of payments. It struggles with vendor impersonation, where the client pays its usual supplier its usual amount and only the account number differs. A bank that already scores wires should ask whether its tool also answers the evidence questions; one that is choosing should know which fraud it is buying for. The Federal Reserve Financial Services risk officer survey, which says of itself that it is not independent research and carries a ±6% margin, lists among its respondents' own fixes for wire losses "Callbacks and PIN authorization codes mandatory".
Does it read where the instruction came from?
Ask the vendor to show you, on a real example, the email behind a changed instruction as its tool displays it. A tool that cannot see the email can only guess at the commonest kind of wire fraud. Look for the headers, the Reply-To, the sending domain's age, the authentication results, the thread the message sits in and the metadata of any attached document.
Then ask how it compares domains. In the sample wire, the forged supplier email came from kesslersteeI.com, with a capital I in place of a lower-case l; the two are indistinguishable on screen. The solution shows the difference as two characters with their code points, and flags sender domains younger than the bank's setting, 30 days at the sample bank. A vendor who says "we use AI to read emails" should be able to show that level of detail, and say what its agent may not do: in this solution the reader never opens links outside a sandbox and never contacts anyone.
Does it compare the beneficiary with the client's own history?
The most valuable comparison is the narrowest: this client, this payee, every earlier payment. Industry-wide patterns tell you what is unusual for banks; the client's history tells you what is unusual for this relationship. In the sample wire, Brightwater had paid its supplier 11 times since 2021, always to the same account at Quillfield Bank, in amounts from $41,200 to $312,900. Today's $286,400.00 sat inside that range. Only the bank and account had changed.
What changed: one held wire against the client's last 11 payments to that supplier
Ask too what the tool does when it cannot answer. In this solution a check whose source does not respond is marked partial and run again, and the payment history agent never calls an account verified on amount alone.
Who dials the callback, and to which number?
The right answer is: a person dials, to a number the bank held before the instruction arrived. Ask the vendor where its tool gets callback numbers, whether it shows the source and date of each, and whether it can ever offer a number that came with the request. In this solution the callback agent takes numbers only from the beneficiary master, the onboarding file or the signed treasury agreement, strikes any number that came with the instruction, and writes a script that never reads the new account out. How a callback should be run, step by step, is set out separately.
Ask about name checks as well, and do not confuse them with callbacks. The Federal Reserve Banks now offer a Payee Name Verification service that lets an institution check an intended payee's name against a routing and account number before it pays. A name check answers whether an account belongs to a name; a callback answers whether the payee sent the change. They are complements.
Can wire fraud detection work in real time, and after 22x6?
Detection is "real time" only if review finishes before the cutoff. Ask how the tool orders held wires: by arrival, by risk, or by the cutoff each must meet. In the solution each held wire sits on a runway to its rail's cutoff, and the coordinator alerts the supervisor 30 minutes before a cutoff and the wire operations manager at 15. In the sample month, no held wire missed a cutoff.
Then ask about the hours. The Federal Reserve plans to run Fedwire 22 hours a day, Sunday to Friday, including weekday holidays, from 2028 or 2029, and its final notice records commenters' warnings that fraud risk is often higher at weekends and on holidays. Participation in the new hours is optional, but a bank that opts in will need its detection, callbacks and second names on Sundays too. What the Fedwire cutoff and the 22x6 change mean for staffing is covered in its own guide.
Does wire fraud software integrate with Fedwire?
Not directly, and it should not need to. Fraud review sits upstream of Fedwire, in the bank's payments hub, which connects to Fedwire through the Federal Reserve's FedLine solutions. Ask the vendor which systems it reads and writes: in this solution, the payments hub (outgoing wires and holds, the Fedwire, CHIPS and SWIFT gateways), the treasury management portal, the payment history and beneficiary master, the email security gateway, the recorded phone line, and case management and core banking.
Two Fedwire dates matter for any tool that reads wire messages. Fedwire moved to the ISO 20022 message standard on 14 July 2025, and the Federal Reserve has rescheduled to November 2027 the Fedwire release that brings the hybrid postal address format, so address fields will change again. Ask whether the vendor reads the ISO 20022 fields natively and has a plan for that release.
What does wire fraud detection cost?
We found no published, independent benchmark for what banks pay for wire fraud detection, and the payments-fraud request for information the OCC, the Federal Reserve and the FDIC issued in June 2025 noted that payments fraud data are gathered piecemeal, without common standards. The honest way to price a tool is from your own numbers.
Pricing a wire fraud detection tool from your own wire room
Review time
held wires needing a callback × minutes saved per wire × loaded cost per minute
Botminds estimates about 65 minutes by hand and 15 with the agents for one such wire; measure your own
Wire operations manager
Attempts stopped
attempts the tool holds that your current rules would release × average amount
Mostly your clients' money, not the bank's liability; count it as relationship value and avoided disputes
Head of payments, with fraud
Cutoffs kept
genuine held wires that would otherwise miss the day × the client cost of a day's delay
A missed closing or payroll is a complaint even when no fraud occurred
Treasury management
Cost of the tool
licence + integration + the staff time the calls still take
Callbacks stay human; the tool shortens the work around them, not the calls
Finance
What the sample bank saw, and what the design aims for
58
attempts stopped before release in the sample month, 1 to 21 October
$13.6M
the value of those 58 attempts, on fictional sample data
95%
of attempted wire-fraud dollars stopped before release: the design target
Where Wire Fraud Prevention fits, and where it does not
Wire Fraud Prevention is built for the held-wire decision on outgoing wires: finding what changed, reading where it came from, preparing the callback, and recording a release or stop with two names. It is not a payments hub, an email security product or a sanctions screen, and a buyer should know the boundaries before the demo.
Where the solution fits, and what it leaves to other systems
| Need | Wire Fraud Prevention | Where it sits instead |
|---|---|---|
| Held outgoing wires: what changed, the email behind it, the callback | Yes: the core of the solution | — |
| Beneficiary and template changes | Yes: held with a callback and two names | — |
| Consumer wires with scam signals | Prepares questions for the conversation; never refuses a wire on its own | The customer decides; the bank's policy governs any hold |
| Client message after a stop; fraud case and BSA referral draft | Yes, each approved by people; it never files a SAR | The BSA team decides on filing |
| Recall and tracing after a wire has left | Drafts the recall for a confirmed fraud | Wire Recall Management and Wire Inquiry and Payment Tracking |
| Sanctions screening of wires | No | Payment Sanctions Screening |
| Blocking phishing email before it reaches staff | No: it reads email the client acted on, through the gateway | The bank's and the client's email security |
| Incoming wires to mule accounts; ACH credits | No | Money Mule Detection; ACH Fraud Monitoring |
Two more boundaries matter in a contract. The agents never release, stop or return a wire, so the solution adds evidence to the bank's existing decision rights rather than taking them over. And every rule, threshold and agent version is a setting the wire operations manager signs, so the bank's procedures remain the bank's. Related solutions: Wire Recall Management, Payment Sanctions Screening and Money Mule Detection.
How to test a vendor on your own held wires
Test before you sign, on wires whose outcome you already know. Take a sample of past held wires and callbacks, including every confirmed attempt you can find and a larger number of genuine wires, run them through the tool, and count by rule: how many it would hold, how many callbacks it would ask for, how many confirmed attempts it would catch, and how many genuine wires it would hold for nothing. Botminds offers to run Wire Fraud Prevention on exactly that kind of sample.
Look at the screens as well as the counts. For three or four of the confirmed attempts, ask the vendor to walk you through what the operator and the checker would have seen, and whether the record would satisfy your counsel under UCC 4A-202(b). Check one client message for confidential wording: the SAR rules forbid disclosing anything that would show a SAR exists, and in this solution SAR, referral and case wording is blocked on client views and checked before every message.
The client told in plain words, checked before it goes
A tool that passes those tests on your own wires will pass them in production; one that needs your data to be "cleaned" first will not. The split between agents and people is the question to end on: ask every vendor to show you, in the product, the button that releases a wire, and who is allowed to press it. To see the solution's answers, start from Wire Fraud Prevention.
Questions people ask
What is the best wire fraud detection software?
The best tool is the one that catches the fraud your wire room actually sees, on your own data, before your cutoffs. For business email compromise that means reading the instruction's origin, comparing the payee with the client's history and preparing a callback to a number of known origin; for account takeover, behavioural signals matter more. Test candidates on your past held wires rather than ranking them on a vendor's claims.
What should wire fraud software check on every held wire?
At minimum: whether the payee's bank details differ from the client's earlier payments to that payee, whether this is a first payment to the payee, whether the amount is far outside the client's range with that payee, where any new instruction came from, and whether a callback to a number of known origin has been made and recorded.
Can wire fraud detection stop wires automatically?
It can hold them automatically; releasing or stopping should take people. Holding is reversible and buys time; a stop or a release moves or keeps a client's money and should carry two names and a reason. In Wire Fraud Prevention no agent can release, stop or return a wire.
How long does it take to deploy wire fraud detection?
It depends on how many systems the tool must read. Plan for the payments hub, the treasury portal, the beneficiary master, email headers and the phone recording system, plus the time to write your callback rules and authority tiers as settings. A test on past held wires can start before every live connection is in place.
Do regulators require wire fraud detection software?
No rule requires a particular tool. Banks are expected to manage fraud risk, report suspicious activity, including attempted transactions, and follow the security procedures they agree with customers. The OCC, the Federal Reserve and the FDIC asked in June 2025 what more they should do about payments fraud; that request for information has not led to a rule.