Callback verification is the only anti-fraud control that does not care how convincing the request sounded. That matters now because the request will sound perfect. In January 2024 an engineering firm lost 25.6 million dollars when a finance employee joined a video call on which every other participant was synthetic and approved fifteen transfers in a day. Voice phishing volumes have climbed sharply since, and the losses on incidents carrying confirmed synthetic audio or video run several times higher than on text-only fraud. We build these controls into finance teams for a living, and the firms that stay out of trouble are not the ones who can spot a fake. They are the ones who never had to.
The Five Rules Worth Writing Down This Week
A callback policy fits on one page. These five lines are the ones that do the work.
- Call back on the number you already hold, never one supplied in the request. This single sentence defeats the entire attack class.
- No payment detail changes by any channel without a callback. Bank changes are where the money actually moves, more often than novel urgent transfers.
- Two people, always, above your threshold. One approves, a different person verifies, and neither can do both.
- Seniority is not an override. The rule exists precisely for requests that appear to come from the top, which is why it must bind the top.
- Test it on a real Tuesday. A control nobody has rehearsed fails on the day it is used, and finance staff need permission to use it before they need it.
Our overview of the deepfake threats small businesses actually face covers the attack side. This is about the procedure.
Why Callback Verification Beats Every Detection Control
Callback verification works because it does not attempt to judge whether what you are seeing or hearing is real, which is the judgement that synthetic media has made unwinnable. Every detection approach is in an arms race, and the defender’s side of that race requires constant investment to stay level. A callback sidesteps it. You are not asking whether the voice on this call is your chief executive. You are ending the call and dialing the number you already hold for your chief executive, which routes to a device the attacker does not have. The authority moves to a channel they cannot reach, and the sophistication of the impersonation becomes irrelevant. Our note on fraud strategy for finance and technology leaders puts this alongside the other controls worth funding.
The Number Must Come From Your Records, Not the Request
The entire control collapses if the callback number arrives with the request, which is exactly why sophisticated attempts supply one helpfully. A convincing message often includes a line explaining that the sender is traveling and reachable on a temporary number, or that the usual line is down. That sentence is the attack. Dial what is in your records: the number in your finance system, the vendor contract, the directory. If you genuinely do not hold one, that is the finding, and the transaction waits until you obtain one through a channel independent of the request. The reasonable objection is that this reads as paranoid in a business where people change phones and travel constantly. It does, and the answer is to keep the records current rather than to loosen the rule, because a stale directory is the condition that makes a helpfully-supplied number feel reasonable.
Out of Band Means a Genuinely Different Channel
Verifying an email request by replying to that email, or confirming a call through a chat message in the same compromised account, is not verification, and it is the most common way this control is implemented badly. If the original request came by email, verify by voice on a known number. If it came by voice, verify in writing to a known address, or in person where that is available. The point is that the attacker must have compromised two independent channels rather than one, which is a substantially higher bar. There is a fair argument that a determined attacker with mailbox access can intercept a written confirmation too, and that is true, which is why voice on a known number is the stronger default. Our account of stopping an email account compromise quickly shows what mailbox-level access lets somebody do to a conversation in progress.
Where the Money Actually Leaves
Most firms write their policy around urgent transfer requests and leave the larger hole open, which is the quiet change to payment details on a legitimate invoice. The urgent wire is dramatic and it is the scenario everyone imagines. The change of bank details is boring, arrives as a routine administrative update, is processed by somebody junior, and takes money from every subsequent payment to that vendor rather than from one transaction. It also tends to go unnoticed for a full payment cycle, which puts it beyond the window where a bank can readily recall funds. Our piece on how SMBs lose money to cyber-enabled fraud without noticing covers the slow versions of this.
Treat a Bank Detail Change as a Transaction
Any change to stored payment details deserves the same callback and dual approval you apply to a payment above your threshold, because the change authorizes every future payment rather than one. Put it in the policy explicitly, since staff reasonably read a policy about approving payments as being about payments. Record who verified it, when, and against which number. That record is what an insurer will ask for, and it is also what lets you establish afterward whether the compromise happened at your end or your vendor’s. The counterargument from operations teams is that vendors change banks legitimately, the callbacks add days to routine administration, and suppliers get irritated being asked to confirm their own paperwork. All true. The cost is a phone call against a loss that recurs monthly until somebody notices, and in our experience vendors who have been defrauded themselves are the most understanding about it.
Set the Threshold Where It Will Be Followed
A threshold low enough to catch meaningful fraud and high enough that staff are not calling about every routine invoice is what makes the policy survive its first busy month. Set it too high and the attacker simply requests an amount below it, which they will discover by trying. Set it too low and the control becomes a formality that people rubber-stamp, which is worse than not having it because it produces a record suggesting verification happened. Look at your actual payment distribution rather than picking a round number, and place the threshold where the volume of calls is sustainable for the staff who will make them. Review it after a quarter with the people doing the calling rather than in a management meeting, because they are the only ones who know whether it is working.
Making the Rule Stick Under Pressure
The rule fails in the moment it matters unless staff have been explicitly told they will not be penalized for applying it to a senior person. Every version of this fraud manufactures urgency and authority together, because that combination is what suppresses verification. A junior finance employee who has never been told otherwise will reasonably assume that making the chief executive wait fifteen minutes is a career risk. That assumption is the vulnerability, and no amount of policy writing removes it. It needs a statement from leadership, made publicly rather than in a document, that verifying a request from any person at any level is expected behavior and that nobody will be criticized for it.
Give It a Name and a Script
A control with a name and a sentence to say is used far more often than one that exists only as a policy paragraph, because the hard part is not knowing the rule but interrupting somebody senior. Give staff the exact wording: this is over our callback threshold, so I will confirm on the number we hold and come straight back to you. That sentence is polite, procedural, and impersonal, and it lets somebody junior apply the control without feeling they are accusing anyone. Rehearse it once in a team meeting. The objection is that scripting sounds patronizing to experienced staff, and some will find it so. Our experience is that the people who find it patronizing were never the ones who would have hesitated, and the script exists for everybody else.
Rehearse With a Real Test, Then Tell People It Happened
A test request that walks the full path tells you whether the control exists in practice, and it is the only way to find out before an attacker does. Have a leader send a plausible out-of-hours payment request through an unusual channel and see what happens. Note whether anyone called back, how long it took, whether they used the stored number, and whether a second person was involved. Then tell the whole team that it was a test, what happened, and what changes. The important half is the second one. A test used to identify who failed produces staff who hide mistakes, which is precisely the culture in which a real incident goes unreported for a week. Our business continuity work treats rehearsal the same way, and for the same reason: an untested plan is a document rather than a capability.
Do Not Route Verification Through a Channel You Do Not Control
Where the callback lands matters, so check whether your phone system would actually deliver that call to the person rather than to whatever is currently forwarding. Modern telephony makes forwarding, voicemail transcription, and softphone registration easy to change, and an attacker who has reached an account may have changed them. Confirm that the stored number reaches a device rather than a service, and treat an unexpected voicemail as an unverified request rather than a completed check. Our explainer on how business voice systems work covers where forwarding rules typically live. The reasonable pushback is that this is getting elaborate for a phone call, and for most firms the basic version is enough. It matters specifically where an email account has already been compromised, because that is the case where the attacker has had the access needed to prepare the phone path too, and our email security guide covers closing that door first.
Frequently Asked Questions
Does callback verification work against a deepfake video call?
Yes, because it does not depend on judging the call. You end it and dial the number you already hold, which reaches a device the attacker does not control. What was on screen becomes irrelevant.
What if the request genuinely is urgent?
A real urgent request survives a five-minute callback without harm. An attacker’s does not, which is why manufactured urgency is a standard feature of these attempts rather than a coincidence.
Should the rule apply to the owner or chief executive?
Especially to them. Impersonating the most senior person is the whole technique, so a rule that exempts seniority exempts exactly the scenario it exists for.
How do we handle a vendor who changes bank details legitimately?
Treat it as a transaction requiring callback and dual approval, using a number from your contract or finance records rather than from the request. Record who verified it and when.
Is a written confirmation enough instead of a call?
Only if it goes to an address you already hold and the original request came by a different channel. Replying to the request itself verifies nothing, since the attacker controls that thread.
Who You Are Taking This Advice From
Mindcore writes and tests payment controls with finance teams at businesses where the same three people approve everything and nobody has a dedicated fraud function. We set thresholds against real payment distributions, script the awkward sentence, run the test request, and sit in the debrief afterward, and the guidance above comes from those rehearsals rather than from an incident report. Matt Rosenthal, who leads Mindcore, keeps the firm focused on controls that hold when the person applying them is tired and being rushed, which for fraud means one rule people can recite rather than a policy they would have to look up. You know your payment process. Our job is to make sure one phone call sits in front of the money.
Your Next Move on Payment Fraud
Write the one page this week rather than commissioning a policy review. Name the threshold, name the two roles, and state plainly that the callback number comes from your records and never from the request. Add the line about payment detail changes, because that is where the money quietly goes and most policies leave it out. Then do the part that actually matters: have a leader say out loud, to the finance team, that verifying them personally is expected and will never be held against anyone. Run one test request in the next month and debrief it as a process finding rather than a performance review. None of this needs a budget, a product, or a project plan, which is unusual for a control that removes an entire attack class. The firms losing money to this are not losing it because they lacked detection technology, they are losing it because nobody felt able to make the call. If you want help setting the threshold and running the first test, book a free strategy call and we will start with your payment process.
