The Fake CFO: Deepfake Fraud and Payment Controls for Finance Teams

Reviewed and substantially updated: 20 October 2026. This article uses official accounts of executive impersonation fraud and distinguishes reported events from fictional training examples. Controls should be adapted to an organisation's payment systems, authority limits and jurisdiction.

A familiar face on a video call can make a payment request feel convincing. It does not establish that the instruction came from the real finance director, that the recipient account belongs to the intended party, or that the payment has been properly authorised.

AI-generated voices, video and documents add persuasive material to an established fraud pattern: impersonate someone trusted, introduce urgency or secrecy, and persuade an employee to bypass a control. Finance teams need a process that remains usable when the instruction looks genuine.

What the official Hong Kong account actually says

In a 26 June 2024 Legislative Council reply, Hong Kong's Secretary for Security described a case reported in late January 2024. A phishing email impersonated the CFO of a UK head office and invited an employee to a video conference concerning purported confidential transactions.

The employee authorised transfers to five local bank accounts, with losses of about HK$200 million. Police believed public video clips and voices had been used to generate a prerecorded conference. The official account explicitly says there was no interaction with the fraudster during it; payment instructions continued through instant messaging afterwards.

That detail corrects a common retelling of the case as a fully interactive, live AI meeting. The government account does not identify the victim company, and it is sufficient to explain the control problem without speculating about individuals or undisclosed internal procedures. It also describes a separate May 2024 CFO-impersonation case. Those incidents should not be combined into one narrative.

What AI changes about executive impersonation

The FBI's December 2024 public service announcement explains that criminals use generated text, images, audio and video to make fraud more believable. Synthetic material can remove familiar warning signs such as poor language or an obviously implausible identity.

Finance teams therefore need to distinguish three questions:

• Identity: who is actually making the request?
• Authority: does that person have permission to approve this payment through this process?
• Destination: have the beneficiary and payment details been independently verified?

Even a genuine executive can request something outside their delegated authority. Equally, a valid invoice can be paired with a substituted bank account. A single reassuring cue cannot answer all three questions.

Business email compromise also remains relevant when a scam moves between channels. The NCSC's business payment fraud guidance describes tailored impersonation emails and requests to pay a different account. Adding a voice message or video changes the presentation of that request without removing the need to verify it.

Independent verification means using a trusted route

A callback works only if the contact route is independent of the suspicious instruction. Calling the number in the new email signature, or asking the requester to provide someone who can confirm the instruction, leaves the attacker in control of the verification.

Use contact details already held in an approved company directory or supplier record, subject to appropriate access controls. If those details may have been changed or compromised, escalate and establish another trusted route. A second channel is useful because of its independence, not simply because it uses a different app.

The FBI's business email compromise guidance recommends using secondary channels to verify account-change requests, while its AI fraud advisory recommends independently obtaining contact details before calling an organisation back. In a corporate workflow, record what was confirmed, by whom, and which details were checked.

A pre-agreed phrase can be a supplementary measure, but a shared secret can be disclosed or copied. It should not become an alternative to beneficiary checks and payment approval. Similarly, moving from video to a familiar voice call does not help if both communications are controlled by the attacker.

A practical payment-control framework

The following is a suggested control design, not a claim about controls at the unnamed victim organisation.

1. Separate beneficiary changes from payment release. Apply independent verification to new or amended bank details. Where feasible, the person approving the change should not be the sole person releasing the payment.
2. Define enhanced-check triggers. New beneficiaries, unusual countries or amounts, urgent manual payments and requests to bypass normal channels should trigger additional review.
3. Make approval substantive. The second authoriser checks the supporting evidence and destination. Two people reading the same fraudulent message does not create independent assurance.
4. Control exceptions. Give genuine emergencies a documented route with named approvers and verification requirements. Apparent seniority or confidentiality should not suspend that route.
5. Keep a reviewable record. Retain the request, callback evidence, beneficiary details and approval. Recording that the CFO “looked genuine” is not a record of verification.

For eligible UK transfers, Confirmation of Payee provides an additional account-name check. The Payment Systems Regulator explains its role in reducing certain misdirected payments and authorised push payment fraud. A name match does not establish that the business purpose is legitimate or that an executive authorised the transfer.

Where a small team cannot fully separate duties, document compensating arrangements. An owner or independent manager could verify beneficiary changes through an established contact and review payment evidence. The design should reflect the available people and systems while preserving meaningful challenge.

Worked scenario: a confidential acquisition payment

Fictional training scenario. A controller receives a video invitation apparently from the group CFO. During the call, the apparent CFO requests £180,000 to a new beneficiary for a confidential acquisition. A follow-up message says ordinary approval will be documented tomorrow and warns against discussing the transaction.

The controller pauses the transfer, keeps the messages and contacts the CFO through an established directory entry. She also informs the authorised escalation contact without circulating transaction details unnecessarily. The real CFO confirms that no request was made.

The important features were a new beneficiary, an unusual instruction and an attempted exception to approval. The employee did not have to prove which AI tool created the video before following the control process.

Now change the scenario: the CFO confirms the acquisition is genuine. Payment still depends on checking the beneficiary, obtaining the required approval and documenting the transaction. Identity verification clears one question; it does not complete the payment workflow.

Why spotting a deepfake is not enough

Distorted images, odd movements or unnatural audio may justify suspicion. Their absence should not be treated as evidence that an instruction is authentic. Staff need a route to pause a payment even when they cannot identify a technical defect.

Detection tools can support that decision, but their performance depends on the tool, media and circumstances. Avoid presenting any product or visual test as a guarantee. A control that verifies the transaction through trusted records remains useful whether the deception uses AI, a stolen account or a persuasive human impersonator.

IT security also matters. Restrict access to payment and supplier records, protect accounts with appropriate multifactor authentication and remove unused privileges. The NCSC's phishing defence guidance uses a layered approach involving technology, processes and people. Payment controls complement those layers.

What if a payment has already been sent?

Contact the bank's fraud team immediately through an official route, explain the suspected fraudulent transfer and ask about stopping or recalling it. Alert the organisation's finance, IT and incident-response contacts. The NCSC's response guidance prioritises direct bank contact and prompt notification to IT.

Preserve messages, transaction references, beneficiary details and relevant logs. If systems may be compromised, coordinate containment with the security team rather than deleting evidence. Follow the applicable local reporting route and assess contractual, insurance and regulatory notifications with the appropriate specialists. Recovery and reimbursement depend on the facts; neither should be assumed.

A calm reporting culture helps employees raise concerns while action may still be possible. Review the control pathway that allowed the payment, including who could create beneficiaries, waive checks or approve their own exception.

Turn awareness into a tested team habit

Run a short exercise using a realistic urgent request. Ask staff to demonstrate where they obtain trusted contact details, who can approve a new beneficiary and what they record when an executive asks for secrecy. Include a legitimate urgent payment so the exercise tests a workable process rather than automatic refusal.

Track whether requests were independently verified and whether staff knew the escalation route. Review near misses as well as losses. The objective is a payment process that remains dependable under pressure, even when the apparent requester looks and sounds familiar.

For related reading, see our guides to cybersecurity training for finance professionals, cyber threats in finance and fraud risk and internal controls.