What is deepfake CEO fraud, and why is it so hard to stop?
Deepfake CEO fraud is a payment scam in which attackers use AI-cloned voice or video of a senior executive to authorize an urgent, out-of-policy transfer. It is business email compromise (BEC) upgraded with synthetic media. In 2024, engineering firm Arup publicly confirmed that an employee paid out about HK$200 million (roughly US$25 million) after a deepfaked video call.
- ▸Cloning is cheap and fast. Minutes of conference footage or podcast audio can produce a convincing voice or video likeness.
- ▸The manipulation script is old. Urgency, secrecy, authority, and a "confidential deal" cover story still do the work; the deepfake just removes the victim's last doubt.
- ▸The trend is real even if the numbers are noisy. Public threat reporting through 2024-2025 described voice phishing (vishing) rising steeply versus 2023, with some vendor telemetry citing increases near tenfold. Treat specific multipliers as directional and verify against the primary report.
Why do detection tools alone fail to stop deepfake payment fraud?
Detection alone fails because you cannot reliably tell a good fake from a real executive in real time, and the decision you are protecting, moving money, is binary. Liveness and deepfake-detection tools help at the margin, but any controls program that depends on a human spotting the fake will eventually lose.
- ▸Detection is an arms race you do not control. Generation quality improves faster than consumer-grade detection, and attackers test against the same detectors you buy.
- ▸The failure is procedural, not perceptual. The loss happens because one person can approve a large, novel transfer under pressure, not because they "should have noticed."
- ▸Design out the single point of failure. The durable fix is a workflow that stays safe even when the request is perfectly convincing. We cover this mindset in Deepfake Fraud Is a Process Problem, Not a Detection Problem.
How do you design a payment-approval workflow that survives a convincing fake?
Design the workflow so that no single channel, and no single person, can release funds. Assume the request, email, call, or video, is fake, and require verification through an independent path plus a second authorizer. The goal is to make the attacker's convincing performance irrelevant to the outcome.
Core principles:
- ▸Separate the request from the approval. The channel that asks for the payment must never be the channel that confirms it.
- ▸Bind approvals to identity, not to a voice. Use accounts and hardware authenticators, not "it sounded like the CFO."
- ▸Make exceptions loud. Any bypass of the standard flow should page a named approver and generate an audit record, never a quiet override.
- ▸Default to friction on change. New payees, changed bank details, and unusual amounts should be slow by design.
What is out-of-band verification, and how should it work?
Out-of-band verification means confirming a payment through a separate, pre-established channel from the one that requested it. If the instruction arrives by video call, you confirm by calling the executive back on a known internal number, never a number or link supplied inside the request itself.
- ▸Use pre-verified contact paths. Maintain an internal directory of approver phone numbers; ignore callback numbers offered during the request.
- ▸Confirm the transaction details, not just the person. Read back payee, IBAN, and amount; a real executive can confirm specifics an attacker improvised.
- ▸Never let the requester choose the channel. "Just confirm on WhatsApp" is a red flag by design, and your policy should name it as one.
- ▸Layer in Verification of Payee (VoP). Under the EU Instant Payments Regulation, payee-name-to-account checks are becoming standard; use them to catch mismatched beneficiaries. See Verification of Payee and e-KYC: Fraud at Real-Time Speed.
How do dual control and callback tokens close the gap?
Dual control requires two authorized people to release a payment above a threshold, using separate credentials, so a single compromised or coerced person cannot move funds alone. Callback tokens add a rotated, out-of-band shared secret that a genuine approver can produce and an impersonator cannot.
- ▸Enforce true segregation of duties. The initiator and approver must be different identities, ideally on different devices, with maker-checker enforced in the payment system, not on the honor system.
- ▸Bind approval to phishing-resistant MFA. Require FIDO2/WebAuthn hardware keys (for example YubiKeys) for high-value approvals so a stolen password or SMS code is useless.
- ▸Use rotating callback tokens for verbal confirmations. A short code held only by finance leadership, changed on a schedule, lets a real approver prove identity on a callback; a deepfake cannot recite it.
- ▸Cap and delay. Apply per-transaction and daily limits, plus a cooling-off delay on the first payment to any new beneficiary.
Which payment changes deserve the strictest controls?
The highest-risk events are new beneficiaries, changed bank details, and any transfer that breaks a pattern, new country, unusual amount, off-hours, or flagged "urgent and confidential." These deserve mandatory out-of-band verification and dual approval, no exceptions, regardless of who appears to be asking.
- ▸Supplier bank-detail changes are a favorite BEC vector; verify every one through a known supplier contact, not the reply-to address.
- ▸First payment to a new payee should trigger a hold and a callback.
- ▸Threshold and velocity anomalies, amounts above a set limit, or several transfers in quick succession, should route to enhanced review.
- ▸CxO-initiated urgent transfers should get more scrutiny, not less; seniority is exactly what the attacker is impersonating.
How do you train people without relying on them to spot the fake?
Train people to follow the process, not to detect deepfakes. The message is simple: certain payment events always require a callback and a second approver, and no amount of executive urgency changes that. You are giving staff permission to slow down, not asking them to become forensic analysts.
- ▸Give employees an explicit right to verify. Publish that "the CEO will never be angry that you followed the callback rule."
- ▸Rehearse the script. Staff should know exactly what to say when pressured to skip verification.
- ▸Run realistic simulations. Include voice and video social-engineering scenarios in your program, not just email phishing tests.
- ▸Reward the catch. Recognize employees who halt a suspicious transfer, even when it turns out legitimate.
How do you test the workflow before an attacker does?
Test it the way you would test a backup: by trying to break it. Run tabletop exercises and authorized social-engineering assessments that specifically attempt a deepfake- or vishing-driven transfer, then measure whether your controls actually stopped the money, not whether people merely felt suspicious.
- ▸Tabletop the exact scenario. Walk finance, treasury, and leadership through a deepfake CFO call and find where the process bends.
- ▸Commission authorized red-team tests of the payment path, including pretext calls; see Initial Access: Authorized Social Engineering and Physical Red Teaming.
- ▸Wire the workflow into incident response. A caught attempt should trigger a documented playbook, as in Incident Response Playbooks That Teams Actually Use.
- ▸Measure and iterate. Track time-to-verify, exception rates, and simulation outcomes; fix the steps people keep skipping.
How TuniCyberLabs helps
TuniCyberLabs designs and stress-tests payment-approval controls that assume the request is fake: out-of-band verification, maker-checker with phishing-resistant MFA, rotating callback tokens, and beneficiary-change safeguards wired into your finance systems and incident-response playbooks. We validate them with tabletop exercises and authorized social-engineering tests, then hand you evidence auditors accept.
Book a payment-fraud resilience review at /contact to pressure-test your approval workflow before someone else does.