When a vendor asks to update their bank account details, many finance teams know what comes next: the callback. Someone calls a number on file, confirms the request, and approves the change.
It feels like a strong control because it takes verification outside the channel where the request originated. But modern attackers have learned to manipulate the information that callback depends on before the call ever happens. That means an AP employee can follow the callback procedure exactly and still approve fraud.
Here’s how it happens.
What Is a Callback Procedure?
A callback procedure verifies a payment request through a channel the request did not arrive on. An email asks for a bank account change, so instead of replying to it, someone picks up the phone and calls the vendor on a number already in the system.
The FBI’s Internet Crime Complaint Center, financial regulators, and payment security organizations all recommend it as a foundational control. That recommendation rests on one assumption: the number in the system is the vendor’s. A patient attacker knows the procedure as well as the AP team running it, which makes that number a target rather than a safeguard.
An Attack That Started With a Contact Update
On episode 62 of Unspoken Security, Trustmi CEO Shai Gabay shared a real attack that exposed a gap in one of the most established payment controls: the callback. The attackers knew the enterprise required a callback to verify bank account changes, so they started somewhere with far less scrutiny: the vendor’s contact information.
They registered a lookalike domain, replicated the supplier’s website with their own contact details, and paid to push it to the top of Google and into AI-generated search results. Then they hijacked the email conversation with what looked like a routine update: Our main contact has left the company. Here are the new details. Here is the site. The contact information was updated. Only two emails later did the request to change the bank account arrive.
AP followed procedure. The employee went to the vendor master data in the ERP, pulled the phone number on file, and called it. What she couldn’t see was that the number had already been changed. The callback went straight to the attackers.
Going outside the ERP might not have helped either. As host AJ Nash explained, you could do your due diligence and still end up with multiple seemingly independent sources “all telling me that this contact info is valid.”
That’s the gap Gabay pointed to: “You have so many different people doing part of the process, but no one is connecting the dots.” The bank change had a strict control around it. The earlier contact change did not. By the time the callback happened, the information that control depended on had already changed.
It’s a game of telephone across the payment process, except the information isn’t getting lost along the way. An attacker changes it upstream, and everyone downstream acts on it as if it can be trusted.
Where the Callback Procedure Breaks Down
The attack above exposes a bigger problem with callbacks: the phone call is only one part of the verification process. The number has to be trustworthy, the person making the call has to follow the procedure, and the information confirmed on the call has to make sense in the context of everything that happened before it.
Modern attacks can exploit any one of those dependencies.
1. Calling the Wrong Number
When an employee receives a fraudulent bank account change request, and the callback number they use is the one included in that same message, the call goes to the attacker. The fraudster confirms the change and the fraud proceeds without any alarm.
This sounds like an obvious mistake, but it happens constantly. Overwhelmed employees default to the most convenient contact information available. Without a system that enforces the use of pre-verified, independently stored contact details, the callback is only as secure as the email it is trying to check.
And as the case above shows, even using a number stored in the ERP may not be enough. The attackers may have changed the vendor’s contact information earlier.
2. Time Pressure and the Urgency Problem
Finance teams work with deadlines and fraudsters have studied this reality carefully. They time their requests to coincide with month-end closings, quarter-end payment runs, and other high-volume periods when AP teams are stretched.
Their messaging usually creates urgency. For instance, a CFO requests an urgent wire before a deal closes, or a supplier claims they need the account updated before today’s payment runs. When an employee is handling hundreds of invoices in a payment run, the callback can become a box to check rather than a genuine verification step.
3. AI Voice Cloning
AI voice cloning technology can now produce a highly convincing replica of a specific person’s voice using only a few seconds of audio. Executives, finance directors, and vendor contacts who appear in public recordings, company videos, or earnings calls all provide the raw material attackers need.
An employee who calls the correct stored number and hears what sounds exactly like their vendor confirming a bank account change may have no reliable way to distinguish the real voice from a synthesized one.
4. Isolation from the Broader Payment Context
A callback does not always answer the questions that would reveal whether fraud is in progress because the person making the call may only see one part of a much longer sequence. A contact change may have happened weeks earlier, another employee may have updated the vendor record, and unusual activity may have appeared somewhere else entirely.
This is especially difficult in enterprise organizations, where different people and teams handle different parts of the payment process. Each action can look legitimate on its own, while the sequence tells a very different story.
What a More Reliable Approach to Verification Looks Like
The solution to unreliable manual callbacks is to build verification into a system rather than leaving it as a human step. But verification also becomes more reliable when it is evaluated in context. Like bank account validation and other established payment controls, a callback can tell you something important without telling you whether the full request can be trusted.
A verification framework that actually holds up against modern enterprise payment fraud combines the following:
1. Establish a Policy for Contact Changes
Organizations tend to have strict procedures for bank account changes, but changes to vendor contact information often receive far less scrutiny. As Gabay put it, “Everyone has a very strict process when it comes to changing bank account information. But what happens if I just ask you to update your contact details? What is that policy? I can assure you, in most organizations, there are no strict policies.”
That gap matters because the phone number or email address being changed today may become the trusted information used to verify a bank change later. Establish a clear policy for contact changes, including who can make or approve them, how new information should be verified, and how the change is documented.
2. Watch for Contact + Bank Changes
A contact update may be completely legitimate, and so may a bank account change. But when there is a contact and bank change within a few months, the sequence deserves more scrutiny. It’s a common attack technique we’ve seen used over the past few years, and it should be monitored carefully.
That history should also be visible to the person performing the verification. In the attack above, the AP employee saw a phone number in the ERP and had every reason to believe it was trustworthy. What they couldn’t see was that someone else had changed it before the bank account request arrived.
3. Use AI to Add Behavioral Context
Established controls such as callbacks and bank validation remain important, but each evaluates a specific part of the request. A callback can confirm that someone approved a change, while bank validation can confirm information about the receiving account. Neither necessarily tells you whether what is happening makes sense for that vendor.
AI can add that context by continuously evaluating how a vendor normally communicates, who typically makes requests, how often banking or contact information changes, and what its usual payment activity looks like. When something falls outside those established patterns, organizations have another signal to consider alongside the results of their existing controls rather than relying on any one check in isolation.
4. Connect the Full Context
Modern payment fraud often unfolds across multiple interactions, systems, and people. A contact update may happen first, followed weeks later by a bank account change. The email conversation may contain other unusual activity, while the ERP contains changes made by someone else entirely. By the time the payment reaches the person responsible for verification, no single system or control necessarily shows the full sequence.
AI can help connect those signals across email, vendor records, ERP activity, and the payment workflow so that verification happens with the history behind the request in view. A callback may confirm the change and the bank account may validate, but those results mean something different when the surrounding context shows that the vendor’s contact information recently changed, its behavior shifted, or other unusual activity preceded the request.
Building a Verification Process That Matches The Threat
The callback procedure, as a concept, is sound. As a manual, human-dependent, isolated process, it is not sufficient for the current threat environment.
Modern payment fraud attackers study billing relationships, understand AP workflows, and know what callbacks look like and when they are most likely to be rushed or skipped. They also have access to AI tools that make it easier to manipulate the information and interactions those procedures depend on.
The World Economic Forum now ranks cyber-enabled fraud as the top concern for CEOs globally, ahead of ransomware. Fraud tactics have evolved beyond the manual controls designed for an earlier era. The answer is not to abandon those controls, but to give them the context needed to determine whether what they are confirming can actually be trusted.
Behavioral AI-powered security 
Protection on day one 
10-15x ROI 