Deepfake executive fraud turns a payment decision into an identity question. A cloned voice, a synthetic video call or a convincing message from a senior figure asks staff to decide whether the person is real. If the answer seems to be yes, the money moves.
That design puts the whole loss on one control, and it is the control generative AI is best at attacking. For fraud and risk leaders, the practical response is to make payment approval hold up even when the requester looks and sounds exactly right.
Two documented cases, Fideuram in 2026 and Arup in 2024, follow the same pattern. The request looked legitimate, the verification step was supplied by the attacker, and any reduction in the loss came from the payment side, where transaction monitoring and recall sit.
An impersonation has to pass three control layers: who is asking, how the request arrived and whether the payment fits its mandate. Detection and recall limit the loss when the first layer fails.
Impersonate
A message or call appears to come from a senior executive asking for an urgent transfer.
Confirm
The attacker supplies the verification, such as a cloned voice on a follow-up call or a deepfake video meeting.
Approve
Seniority and urgency carry the payment past normal approval friction.
Pay out
Funds move to new beneficiaries, often in another jurisdiction, before anyone checks.
Deepfake executive fraud uses AI-generated voice, video or messages to impersonate a senior figure and instruct a payment. It succeeds because identity, communication channels and payment approval usually sit with different teams, and each assumes another has checked. The defence is a payment decision that does not depend on whether the requester seems genuine: verification through a channel the organisation chooses, no seniority override, and hold rules on new beneficiaries, new jurisdictions, urgency and secrecy.
What is deepfake executive fraud?
Deepfake executive fraud is payment fraud in which criminals use AI-generated voice, video or messages to impersonate a senior executive, or someone the executive trusts, and instruct staff to transfer funds. It extends business email compromise beyond email into phone calls, video meetings and messaging apps.
FinCEN has been explicit that this typology targets financial institutions as well as their customers. In its November 2024 alert on deepfake media, the US Financial Crimes Enforcement Network noted reports of criminals using generative AI to impersonate an executive or trusted employee and instruct victims to transfer large sums. The same alert describes business email compromise schemes that use accounts belonging, or purporting to belong, to company leadership, vendors or lawyers.
Both cases below fit that description. One used a message app and a cloned voice; the other used a video conference.
What the Fideuram Case Shows About How These Frauds Work
On 25 September 2026, Reuters reported, citing two sources, that fraudsters had used AI to impersonate senior figures and obtain about €95 million from Fideuram, the private banking arm of Intesa Sanpaolo. The scheme began in February 2026, when Fideuram’s then chairman received a WhatsApp message that appeared to come from Intesa Sanpaolo’s chief executive, asking for urgent help with an overseas transaction.
A follow-up call that appeared to come from a senior partner at a prominent law firm confirmed the instruction. According to the sources, AI was used to replicate the lawyer’s voice. The chairman then instructed the finance department to make a series of transfers, mainly to accounts in China and Hong Kong. Fideuram detected irregularities quickly and alerted banks and authorities in several countries, and more than half of the funds were later recovered. Intesa Sanpaolo and Fideuram declined to comment.
The Arup case in Hong Kong had the same structure through a different channel. In January 2024 a finance employee joined a video conference with people he believed were the company’s chief financial officer and other colleagues. Hong Kong police later said all of them were deepfake recreations. He made 15 transfers totalling HK$200 million (about US$25.6 million) to five bank accounts, and Arup confirmed that fake voices and images had been used.
Attacker-supplied confirmation
The call that appeared to verify the Fideuram request was part of the fraud, so seeking a second voice worked against the bank.
Authority from the top
The instruction reached someone who could direct the finance team, so ordinary approval friction did little to slow it.
Payment-side detection
What limited the loss was spotting irregular transfers and contacting other banks quickly, after the money had moved.
Video as verification
At Arup, a video call with deepfake colleagues was treated as the verification step itself.
The Three Control Layers an Impersonation Has to Pass
Every impersonation-led payment passes through three layers. In most organisations, each layer belongs to a different team.
The failure pattern is delegation between layers. Finance processes the payment because a senior person approved it. The senior person approved it because the voice or face was familiar. The channel the instruction travelled through, often a messaging app or a personal number, belonged to nobody. A deepfake only has to defeat the first layer if the other two have been built to trust it.
| Control layer | Question it answers | What a deepfake does to it | A control that still holds | Typical owner |
|---|---|---|---|---|
| Requester identity | Is this really the person they claim to be? | Imitates the face, voice or writing style of someone staff know | Treat recognition as one signal, never as approval | Often unowned |
| Instruction channel | Did the request and its confirmation arrive through channels we control? | Moves to messaging apps, personal numbers or attacker-hosted calls, and supplies its own “verification” | Call back on contact details from internal records, never details supplied with the request | Cyber security and IT |
| Payment authority | Does this payment fit an existing mandate, limit and beneficiary pattern? | Uses seniority, urgency and confidentiality to bypass approval steps | Hold rules that apply regardless of who approved the payment | Treasury, finance operations and fraud |
Warning signs in an impersonation-led payment request
None of these signals depends on recognising a face or voice, which is why they belong in the payment process.
Why Identity Checks Cannot Carry the Decision on Their Own
FinCEN also points to the limits of live verification. Audio or video checks can expose inconsistencies, but people using deepfake identities may try to avoid them or change communication methods partway through. Deepfake detection is worth having, and it keeps improving, but it is a contest between generation and detection tools. A payment process that depends on winning that contest every time has no margin for error.
Identity controls at onboarding answer a different question. Liveness detection checks whether a real person is present when an identity is verified, and synthetic identity controls test whether the identity itself is genuine. Executive impersonation borrows a real, known identity during a live instruction, so neither control sits in its path.
That leaves the payment layer as the place where the decision has to hold.
Illustrative example: rehearsing an impersonation
Phishing simulations test whether staff click links. They rarely test whether a convincing senior voice can push a payment through.
A more useful exercise has a simulated executive ask the finance team for an urgent, confidential transfer to a new overseas beneficiary, then checks each layer in turn:
- Is the call-back made to a number from internal records, or to one supplied with the request?
- Does the new beneficiary and jurisdiction trigger a hold, whoever approved?
- Can the request be pushed through on seniority alone?
- When someone refuses, does the escalation path work without penalty?
How to Make Payment Controls Hold When Identity Fails
The aim is a payment decision that stays sound even if the requester is a perfect imitation. Five design choices do most of the work, and none of them depends on recognising the person asking.
1. Verify through a channel you choose
Confirmation that arrives with the request, or through contact details the requester supplies, is not independent. Call back on a number held in internal records, or confirm through a channel registered in advance. The Australian Signals Directorate’s Australian Cyber Security Centre (ACSC) advises organisations to set a clear and consistent process for staff to verify and validate requests for payment.
2. Remove the seniority override
The ACSC lists unexpected payment requests from someone in a position of authority as a warning sign, and says staff need a way to report pressure for secrecy or requests to get around protective processes. If a chief executive can waive a control, so can anyone convincingly pretending to be one. Senior requests should face the same checks, and staff need explicit permission to apply them.
3. Attach hold rules to the payment, not the person
Define payment characteristics that trigger mandatory independent verification and a short hold, whoever approved: a new beneficiary, a new jurisdiction, a value outside the normal pattern for that account, a request for confidentiality, a hard deadline. The payment process can see these signals even when the identity layer has been fooled.
4. Monitor the institution’s own outbound payments
In many financial institutions, transaction monitoring is built around customer activity, while treasury and corporate payments run through a separate approval route. Impersonation targets that second route. Fideuram’s partial recovery depended on spotting irregular transfers quickly and alerting other banks, so detection and recall deserve as much design effort as approval. Our analysis of APP fraud and money mule detection explains why action at the receiving end matters too.
5. Rehearse the scenario end to end
Phishing simulations test whether staff click links. They rarely test whether a convincing senior voice can push a payment through. Run exercises like the one above, and check whether each layer behaves as designed, including the escalation path when someone refuses.
Who Should Own Deepfake Impersonation Risk
Because the layers sit with different teams, impersonation risk often has no single owner. Cyber security sees social engineering, fraud sees a payment risk and treasury sees an operational process.
Assign one accountable owner for the end-to-end payment instruction journey, with each layer’s control owner reporting into that view.
Requester identity
Individual judgement today, often with no formal owner. Recognition should count as one signal, never as approval.
Instruction channel
Cyber security and IT. Owns the rule that verification uses contact details from internal records.
Payment authority
Treasury, finance operations and fraud. Owns hold rules, outbound monitoring and recall.
End-to-end owner
One accountable owner for the whole payment instruction journey, with each layer’s control owner reporting into that view.
Common Control Gaps Behind Deepfake Executive Fraud
The same gaps appear when identity, channel and payment controls are designed separately:
- Verifying a request through contact details that arrived with the request.
- Allowing senior executives to waive payment checks.
- Applying hold rules to customer payments but not to treasury or intra-group payments.
- Treating deepfake detection as the deciding control rather than one signal.
- Leaving impersonation risk without a single accountable owner.
Deepfake detection can help, but FinCEN notes that people using deepfakes may try to avoid live verification or change communication methods. Payment controls should hold even when a deepfake goes undetected.
The Same Pattern Applies to Customer Payments
When the target is a corporate customer rather than your own treasury, the institution sits on the payment side as the sending or receiving bank. FinCEN lists business email compromise among the scams in which deepfake social engineering is used against customers and employees. The three-layer map still applies, but the controls you own are mostly in the third layer: payment-level checks, monitoring and recall.
For Australian obligations, our guide to Scams Prevention Framework evidence covers what regulated sectors should be able to show. For a wider view of AI-enabled identity fraud, see MemberCheck’s analysis of synthetic identities, deepfakes and AI-enabled scams.
How Nexiant Supports Impersonation-Resilient Payment Controls
Nexiant brings together specialist capabilities across identity verification, PEP and sanctions screening and transaction monitoring through MemberCheck and FraudShield, supporting the identity and payment layers of this model.
Verification rules, approval policies and escalation paths remain the organisation’s own controls to design and govern.
Questions Risk Leaders Should Ask About Their Payment Controls
Risk leaders can put these questions to their own organisation:
- Which high-value payment routes can one person authorise, and who can override them?
- How many verification steps rely on a channel or contact detail the requester could control?
- Do hold rules on new beneficiaries and jurisdictions apply to treasury and intra-group payments as well as customer payments?
- How quickly can outbound payments be identified, recalled and reported to other institutions?
- When were these controls last tested against a realistic impersonation scenario?
The answers show where a convincing voice could still move money.
Frequently Asked Questions
Test your payment controls against executive impersonation
Speak with a Nexiant expert about connecting identity, channel and payment controls so a convincing voice is never enough to move money.
Speak to our fraud prevention teamThis article was accurate at the time of publication in October 2026 and is intended for general informational purposes only. It does not constitute legal, regulatory or compliance advice. Organisations should seek qualified professional guidance in relation to their specific obligations.




