Deepfake Impersonation Defense for Approvals and Payments
Added September 2026
Require a check through a separate, trusted channel before acting on voice, video, or message requests to move money, change payment details, or grant access. Do not accept a familiar voice or face as proof of identity.
Objective
Stop fraud in which AI-generated voices, videos, or messages impersonate executives, suppliers, or colleagues to approve payments or gain access.
Maturity Levels
Initial
Staff act on phone or video requests from recognized executives without further checks. Voice is treated as proof of identity.
Developing
Deepfake awareness is part of security training, but there is no required verification step and high-value requests are handled case by case.
Defined
Written rules require verification through a separate trusted channel for payments, changes to payment details, and access requests above set thresholds. Voice and video alone cannot authorize them.
Managed
Compliance with the rules is tested with simulated deepfake requests. Attempted impersonation incidents are logged, reported, and used to adjust thresholds.
Optimizing
Approval workflows enforce verification in the system itself, so a request cannot proceed without it. Rules are reviewed as attack costs fall and new impersonation methods appear.
Evidence Requirements
What an auditor or assessor would expect to see for this control.
- —Policy defining covered requests, thresholds, and the required out-of-band verification method
- —Approval workflow configuration showing verification is enforced for covered requests
- —Help desk procedure preventing credential or MFA resets based on voice alone
- —Results of simulated deepfake request tests for the past 12 months, by team
- —Incident register entries for attempted impersonation, including failed attempts
Implementation Notes
Why human judgment is no longer enough
A September 2026 survey found 41% of CISOs had faced deepfake voice attacks. Research the same month showed AI cut the cost of targeted phishing by about 95%. Many existing controls rely on staff noticing something is wrong. Cloned voices and live video fakes now defeat that check. The fix is procedural: the request channel must never be the verification channel.
Key steps
- Define covered requests. At minimum: payments over a set threshold, any change to supplier or employee bank details, urgent requests to bypass normal approval, and requests for credentials or access resets.
- Out-of-band verification. Confirm covered requests through a separate channel the requester did not supply. For example, call back on a number from the internal directory or supplier master file, never one given in the request.
- Voice and video are not authentication. State this in policy. A familiar voice or face on a call confirms nothing on its own.
- Code words or approval systems for executives. For senior leaders who approve high-value actions, use a pre-agreed challenge or require approval inside a system with its own login.
- Protect the reset path. Help desks must not reset passwords or MFA (multi-factor authentication) on the strength of a phone call alone, because attackers target that step.
- Test it. Run simulated deepfake requests against treasury, accounts payable, HR, and the help desk. Record who followed the procedure.
Reporting
Log every attempted impersonation, including failed ones, in the incident register. Some regulators and insurers now ask about deepfake controls directly.
Example Implementation
Manufacturer whose accounts payable team received a cloned-voice call from the 'CFO'
Payment Request Verification Rule (Treasury and AP)
Covered: any payment over $25,000, any change to supplier bank details, and any request marked urgent that skips the normal approver. Verification: call back using the number in the HR directory or supplier master file. Never use a number, link, or meeting invite supplied with the request. Not accepted as proof: a recognized voice, a video call, an email from the correct address, or a message on a messaging app.
Test results, Q3 2026: 12 simulated deepfake calls. 11 were verified by callback and refused. One analyst processed a bank detail change after a video call; that team repeated training and the change screen now requires a callback reference number.