Almost every serious business payment fraud, from a switched vendor bank account to a diverted closing wire to a spoofed executive request, is stopped by the same low-tech control: verifying a new or changed payee out of band before the money moves. The FBI put business email compromise at $3.046 billion in 2025, with 86 percent of the money moving by wire or ACH1, and the AFP found 76 percent of organizations faced attempted or actual payments fraud3, yet the single defense that reliably beats these attacks is a phone call made the right way. The problem is that most guidance stops at the words "call to verify" without saying which number, what to ask, or when, which is exactly where the control fails. This is the practical version: the one rule that makes a callback work, the script to use on the call, the red flags that should trigger verification every time, and the checklist to run before any payment to a new or changed payee. It is the how behind the advice on every other page of this site.
Why out-of-band verification is the whole defense
It is worth being precise about why one phone call defeats a multi-billion-dollar crime, because understanding the mechanism is what makes people actually do it. Business payment fraud, in almost every form, is an authorized payment sent to an account the payer was deceived into trusting. The attacker does not break into a bank or forge a signature; they convince a real, authorized employee to send a real payment to the wrong place, usually by controlling one communication channel, an email thread, and using it to supply new banking details. Because the payment is authorized, it passes every control built to catch an intruder. The deception lives entirely in that one channel.
Out-of-band verification breaks the attack by stepping outside the channel the attacker controls. If the request to change bank details arrived by email, you confirm it by voice, on a phone number the attacker never touched, with a person you can identify. The fraudster can spoof the email, mimic the writing style, and even reply convincingly from the compromised inbox, but they cannot answer the real vendor’s phone. That is the entire logic: the confirmation has to travel on a different channel than the request, because a request and its confirmation on the same compromised channel confirm nothing. Everything else in this guide is just doing that one thing correctly.
The one rule that makes a callback work
Here is the rule that separates a real verification from a theatrical one: never use contact information supplied by the request itself. When an email says the vendor’s bank details have changed and gives a number to call to confirm, that number belongs to the fraudster, and calling it means a confederate cheerfully confirms the fraudulent account. The same is true of a reply-to address, a link to a portal, or a contact added to the signature. All of it came from the channel you are trying to verify around, so none of it can verify anything. This is the single most common way a callback fails, and it fails silently, because the person feels like they verified.
Instead, reach the payee on a number you already had before the request existed: the number on the signed contract, on a prior invoice paid without incident, in your vendor master file, or on the company’s official website that you navigated to yourself. For a closing, use the number from the settlement statement or one you looked up independently, as the guide on real estate wire fraud stresses. The test is simple: if the contact information could have been placed there by whoever sent the change request, do not use it. A verification is only worth making if the channel is one the attacker had no way to touch.
The callback script: what to say and ask
A good verification call is short and specific. Identify yourself and your company, and say plainly that you are calling to verify a change to payment details before you process a payment, so the person knows what you need. Then, and this matters, ask them to read you the correct bank account and routing numbers from their records, rather than reading your numbers to them for a yes or no. Reading the numbers to someone invites an automatic "yes," and a coached fraudster will confirm anything; having them state the details independently is what actually checks them. Confirm the payee name and the reason for any change while you are there, since a legitimate vendor can explain a bank switch and a fraudster’s story tends to wobble.
Close the loop by recording who you spoke with, the number you called, and the date and time, so the verification is a fact you can produce later rather than a memory. Two things to refuse along the way: do not accept an emailed confirmation as a substitute for the call, because the email is the channel you are verifying around, and do not let urgency talk you out of the step, because manufactured urgency is a tool of the scam, not a reason to skip the check. If you cannot reach the payee on a known number, the payment waits. A held payment is an inconvenience; a sent one to a fraudster is usually unrecoverable.
The red flags that should trigger verification every time
You do not need to call the whole vendor list every week; you need to verify whenever specific triggers appear, and to treat those triggers as non-negotiable. The first and most important is any new or changed bank account, because the switched payee is the core of the crime. A first payment to a brand-new payee deserves the same treatment. So does any note of urgency or secrecy, a request to act fast, keep it confidential, or bypass a normal approval, since pressure and isolation are how the scam buys time. A change delivered by email, especially one that discourages a phone call or supplies its own number, should raise the alarm rather than lower it.
A few more are worth training the eye for: a slightly wrong sender domain or a reply address that differs from the display name; a request that arrives just before a deadline or a holiday; an invoice or amount that is close to normal but not quite; and any instruction to route a payment somewhere the relationship has never used before. None of these individually proves fraud, and legitimate changes do happen, which is the point: you do not judge whether it is fraud, you verify. The discipline is to let the trigger, not your read of the person’s tone, decide when to pick up the phone, because the whole design of these attacks is to feel completely normal.
The checklist to run before any wire
Before releasing a payment to a new or changed payee, run the same short checklist every time, regardless of who is asking or how tight the deadline is. First, confirm the payee’s bank details out of band, by calling a number you already had and having them read you the account and routing numbers. Second, hold the first payment to new or changed details until that verification is complete, with no exception for urgency. Third, make sure a named person, not just a process, has approved the payee and the amount, so the decision is attributable. Fourth, keep a record of the verification and the approval, so you can show later exactly what was checked and by whom. Only when all four are true does the payment go.
For a wire specifically, add two habits that buy back the finality: send a small test amount first where your bank and timeline allow, and confirm receipt with the payee before sending the balance; and know your reporting path in advance, so that if something is wrong you can call your bank to request a recall and report to the FBI at ic3.gov the same day, inside the narrow window where recovery is possible. The guide on wire fraud recovery covers that window. The checklist is deliberately boring, because boring and consistent is exactly what beats an attack designed to exploit the one time you were rushed.
Why callbacks fail, and how to make verification a system
If the callback is so effective, why does fraud keep succeeding? Because a manual control depends on a person remembering to apply it perfectly, every time, under exactly the conditions designed to make them skip it. A verification habit holds up on a normal Tuesday and collapses during a month-end close, a staff shortage, or a CEO-flagged "urgent and confidential" wire. It also does not survive turnover well: the discipline lives in one careful person’s head, and it leaves when they do. Attackers know this, which is why they engineer urgency and time their requests for busy periods. The one skipped callback, on the one request that was actually fraudulent, is all it takes, and that is the request most engineered to get skipped.
The fix is to stop relying on memory and make verification a required step in the payment process rather than a judgment call. That means the system itself will not release a payment to a new or changed payee until the out-of-band verification and a named approval are recorded, so the control applies identically to a two-thousand-dollar invoice and a two-hundred-thousand-dollar wire, on a quiet day and a chaotic one. The payee verification discipline is exactly this idea, turned from a habit into a standard. A control you can skip under pressure is a control an attacker will eventually beat by applying pressure; a control you cannot skip is one they cannot.
Where RankShield Financial fits
This is where RankShield Financial comes in, and the honest framing is that it does not replace the callback in this guide; it makes it a step that cannot be skipped and produces the record that a manual call does not. It is a verification and attestation layer in the payment authorization path, not a bank or a custodian of funds, and it never touches the money. Before a payment to a new or changed payee settles, it requires the payee to be verified and a named person to have approved it, and it seals a checkable record of both, so the control applies every time rather than only when someone remembers, and so you can prove afterward exactly what was verified and by whom.
The boundaries stay explicit, as everywhere on this site. RankShield enforces and records the verification; it does not read your email, it does not detect the phishing that starts the fraud, and it is a design-partner-stage product that claims no network it has not built. Its value is precisely that it converts the free, effective, easily-skipped callback into a system that holds under the pressure attacks are built to create. If you want that verification enforced in front of your payments, you can see how it works or request access. And whether or not you ever use a tool, the call itself, made on a number you already had, is the single most valuable thing anyone reading this can start doing today.
