Deepfake CFO Calls Are Approving Wires. Your Callback Policy Is Obsolete.

In January 2024, attackers executed a deepfake scam against Arup, leading to 15 fraudulent transfers totaling $25.6 million in a single day (Source: Forbes, https://www.forbes.com/sites/rashishrivastava/2024/02/04/arup-deepfake-scam-25-million-hong-kong/). A finance worker on a video call with what he believed were his CFO and colleagues authorized the wires himself. He followed policy. The policy failed because every voice and face on that call was synthetic.

That single incident is the end of an era in AP controls. The out-of-band phone callback, the verbal password with a known supplier contact, the "let me hop on a quick Zoom to confirm" step, all of these are built on an assumption that no longer holds: that a human voice on a trusted channel is proof of a human on the other end.

It isn't. And every controller reading this needs to accept that the callback is not a hardened control anymore. It is an attack surface.

The Frame: Verification at the Approval Step Has Been Broken

Here is the mental model worth internalizing. AP controls operate on two planes.

The first plane is the approval workflow. Invoice comes in, gets coded, gets routed, gets approved, someone verifies the bank instructions, payment gets released. Every control at this plane depends on human judgment applied to information humans can perceive: an email, a phone call, a signed document, a video conference.

The second plane is the payment rail itself. This is the actual movement of money against pre-validated instructions tied to a specific supplier record, on a specific network, with specific counterparty confirmations.

For twenty years, AP security has been almost entirely a plane-one game. We layered controls on top of judgment: dual approval, out-of-band callback, positive pay, vendor master change reviews. Every one of those controls asks a human to look at something and decide if it's real.

Synthetic media collapses plane one. When the attacker can produce a video call with your CFO's face, your CEO's voice, and your treasurer's mannerisms, the human judgment layer isn't a control anymore. It's a rubber stamp attached to whatever the attacker feeds it.

The only durable answer is to move verification off plane one entirely and onto plane two. Verification has to live at the rail, tied to bank data the fraudster never touches.

Why Callbacks Became the Attack Vector

Voice cloning fraud rose 680% in a single year (Source: Pindrop, https://www.pindrop.com/2025-voice-intelligence-security-report). That's the underlying economics. What used to require a skilled social engineer with hours of preparation now requires a laptop and a public earnings call recording.

Meanwhile, BEC continues to be the most prevalent form of payments fraud, affecting roughly three-quarters of organizations (Source: 2026 AFP Payments Fraud and Control Survey, https://www.afponline.org/publications-data-tools/reports/survey-research-economic-data/payments-fraud). BEC isn't going away. It's evolving. The email compromise is now the setup, not the payload. The email plants the invoice or the payment change request. The deepfake call closes it.

The controller's callback used to sever that chain. You'd hang up on the email, dial the supplier contact you had on file, confirm the change verbally, and move on. That worked because voices were hard to fake and phone numbers were hard to hijack at scale.

Neither of those is true anymore. The attacker either clones the voice on the number you have, or spoofs the number entirely and clones the voice you expect. Either way, the callback confirms the fraud instead of blocking it.

Here is the uncomfortable truth: if your fraud policy still reads "confirm all bank instruction changes via a known phone number," your policy is written for a threat model that no longer applies.

The Playbook: Move Verification to the Rail

Rebuilding the control means separating three things that most AP teams collapse together: the request to change payment instructions, the validation of the new instructions, and the release of the payment.

In a callback-based world, all three happen inside the approval workflow, gated by human judgment. In a rail-based world, only the request lives there. Validation and release move to systems the attacker cannot socially engineer.

Here is the operational sequence.

Step one: treat every payment instruction change as a supplier onboarding event, not an approval task. A supplier's bank account change is not a minor edit to a vendor master row. It is the creation of a new payment channel. That should trigger the same validation you'd run on a brand-new supplier: bank account ownership verification against the supplier's legal entity, tax ID match, address confirmation through independent data sources. If your vendor master change process is faster than your onboarding process, you have the risk model inverted.

Step two: pre-validate supplier bank data before payment day, not on payment day. The window between "instructions changed" and "payment released" is where fraud lives. Compress that window by validating banking data continuously against network-level sources rather than at the moment of urgency. When a payment run happens, the validation is already weeks old and independently confirmed. There is nothing for the fake CFO call to accelerate.

Step three: route payments through channels where the supplier's identity is bound to the payment method itself. This is where virtual card payments and network-validated ACH change the math. A virtual card issued to a specific supplier for a specific invoice cannot be redirected by a phone call, because the payment method itself carries the counterparty binding. Even if an attacker somehow triggered the payment, the funds route to the pre-validated merchant of record, not to a mule account.

Step four: eliminate the out-of-band callback as your primary verification for high-risk changes. Keep it as a courtesy touchpoint if you want, but stop treating it as a control. Replace it with rail-level confirmation: the supplier confirms the change through a portal tied to their existing authenticated identity, or through a network confirmation flow that doesn't route through any human channel an attacker can spoof.

What Doesn't Work Anymore

A few controls that used to be table stakes need to be honestly reassessed.

Video verification. Deepfake video is now good enough that a controller under time pressure cannot reliably distinguish it. Asking someone to "hop on a quick video to confirm" is theater.

Voice biometrics on inbound calls. If the attacker can clone a voice well enough to fool a human, voice biometrics running in a call center are not far behind. This is an arms race the defender loses on cost.

"Known phone number" callbacks. Number spoofing plus voice cloning defeats this end-to-end. The number you dial can be routed to the attacker, and the voice that answers can be the one you expect.

Email confirmation of bank changes. BEC compromises the mailbox. The confirmation email is coming from the attacker sitting inside the supplier's own domain. This has been broken for years and yet it's still in policies.

None of these are worthless. They add friction. But none of them can be your last line of defense.

Where Finexio Sits in This Model

The reason Finexio built its platform around pre-validated supplier payment data, network-issued virtual cards through J.P. Morgan Chase, and orchestrated payment flows across Mastercard and Visa rails is precisely this shift. When verification lives at the rail, the CFO deepfake doesn't have a target.

The Finexio Shield $2M fraud guarantee exists because we believe the rail-level model is defensible enough to underwrite. That's not a marketing claim. It's a stance about where the industry has to move. If your fraud controls still depend on a human confirming a voice on a phone, you are running an outdated threat model against a current attacker.

Our supplier management approach binds banking data to the supplier's authenticated identity long before the payment run. Our payment operations layer routes each payment through the method with the strongest counterparty binding available. The result is that the verification question isn't asked at the moment of release, when the attacker is loudest. It's already been answered, cryptographically, weeks earlier.

What Controllers Should Do in the Next 90 Days

Three concrete actions.

Audit your bank instruction change process against synthetic media threats. Sit in a room with your AP lead and your CISO and walk through the exact sequence. If any step relies on "we called them back and confirmed," you have work to do. Document which steps a deepfake defeats. Then rebuild those steps.

Segment your supplier base by verification quality, not by spend. Your highest-risk suppliers are not your largest ones. They are the ones whose banking data hasn't been independently revalidated in the last twelve months. That's your target list for rail-level onboarding.

Shift new-supplier onboarding and any bank change event onto a validation flow that doesn't touch the phone system. Portal-based, network-confirmed, tied to independent identity data. The phone stays for relationship. It leaves the control path.

FAQ

Q: Are we saying phone callbacks should be eliminated entirely?

No. They still have value as a relationship touchpoint and as a soft signal. What has to change is treating them as the authoritative control. If a callback is the only thing standing between a fraudulent instruction and a released payment, the control has already failed.

Q: How does virtual card payment actually prevent deepfake-initiated fraud?

A virtual card is issued to a specific merchant of record with controls on amount, timing, and acceptance. Even if an attacker somehow triggered issuance, the funds cannot be redirected to an attacker-controlled account, because the card can only be accepted by the pre-validated merchant. The counterparty binding is inside the payment method itself, not in a workflow step that a human can be tricked into approving.

Q: What about smaller suppliers who can't participate in portal-based onboarding?

Rail-level verification doesn't require the supplier to have sophisticated technology. It requires the payment orchestrator to have independent data sources that confirm supplier identity and banking without asking the supplier to do more work. That's exactly the problem AP payments as a service is built to solve.

Rebuilding the Control Layer

The callback isn't dying because it's a bad idea. It's dying because the assumption underneath it, that human perception of a voice or a face is reliable evidence of identity, no longer holds.

The controllers who get ahead of this will treat the next twelve months as a rebuild, not a policy tweak. Move verification to the rail. Bind banking data to identity before payment day. Route through methods with counterparty binding. Stop asking humans to catch what humans can no longer catch.

To pressure-test your current AP fraud controls against synthetic media threats and map a rail-level verification model onto your existing workflow, Book a Consultation with the Finexio team.

Sources

- Forbes: https://www.forbes.com/sites/rashishrivastava/2024/02/04/arup-deepfake-scam-25-million-hong-kong/ - Pindrop: https://www.pindrop.com/2025-voice-intelligence-security-report - 2026 AFP Payments Fraud and Control Survey: https://www.afponline.org/publications-data-tools/reports/survey-research-economic-data/payments-fraud