What happens when authorised push payment fraud is combined with deepfakes and chatbot-driven social engineering?

Why the fraud becomes harder to detect and dispute

Combining authorised push payment fraud with deepfakes and chatbot-driven social engineering changes the attack from a simple false request into a layered trust deception. The payment may still be authorised by the victim or an internal approver, but the surrounding cues, voice, tone, urgency, and conversational back-and-forth are engineered to suppress suspicion and defeat informal verification.

Deepfakes are useful because they imitate a person the target already expects to hear or see. Chatbots then let the attacker maintain pace, answer objections, and adapt the script in real time. That makes the fraud less dependent on a single convincing message and more dependent on sustained interaction, which is much harder for people to assess under pressure.

For payments teams, the important shift is that the attacker is no longer just asking for a transfer. They are simulating the social conditions under which a transfer feels normal. That means traditional controls focused on transaction approval, call-back habits, or email hygiene can fail if they do not test the request against an independent trusted channel at the point of payment.

How deepfakes and chatbots reinforce each other

Deepfakes and chatbot-led conversation solve different parts of the scam. A synthetic voice or face provides familiarity and authority. A chatbot provides scale, consistency, and patience. Together they reduce the friction that usually gives a victim time to pause, compare details, or escalate the request.

This combination is especially effective where organisations rely on informal business process overrides, executive pressure, or one-person approval paths. The fraudster can mimic the right person, keep the conversation alive, and answer objections instantly, which makes social engineering feel less like a one-off trick and more like an apparently legitimate business interaction.

In practice, this means the defender is dealing with a trust problem, not just an impersonation problem. If the verification method is weak, shared, or easy to mimic, the attacker can move the victim from doubt to action before any secondary review occurs.

What controls matter when the request itself may be fake

The most effective response is to verify payment instructions using a separate, independently trusted process that the attacker cannot easily mirror. A reviewer should be able to confirm who is requesting the payment, whether the request matches normal behaviour, and whether the channel used for verification is outside the conversation being exploited.

Controls that work best here tend to be procedural as much as technical: payment holds for unusual changes, dual approval for novel payees, pre-agreed verification steps for out-of-band validation, and escalation rules when the request carries urgency or secrecy. The control objective is to make the fraud expensive to sustain even when the attacker has a believable voice or dialogue.

For payment workflows, one useful lens is whether the approval process still has a genuine point of challenge. If the fraudster can occupy every available communication channel, then the organisation has not built a real verification step, only a faster way to authorise loss.

Risk and Threat Considerations

This combination increases both manipulation success and operational blast radius. The main risk is that a legitimate-looking request can bypass normal suspicion, especially when staff are conditioned to treat speed, familiarity, or authority as evidence of authenticity.

Failure mechanism: The attacker uses synthetic identity cues to create trust, then keeps the target engaged long enough to push an authorised payment through before independent verification can intervene.

Impact: The result is higher-value fraud, slower detection, weaker dispute leverage, and greater likelihood that a normal business approval path becomes the vehicle for loss.

Practitioner Guidance

What to prioritise: Put verification at the payment decision point, not at account login or first contact. If the request can move money, the challenge must happen after the request is made and before the transfer is released.

What to verify: Test whether staff can confirm the request through a channel and script the attacker cannot easily anticipate. The strongest signal is not whether the voice sounds right, but whether the payment instruction survives an independent check against known contacts, known behaviour, and pre-agreed escalation rules.

Practitioner takeaway: The critical failure is not just impersonation, it is trust being accepted too early. Defences should assume the request may look and sound authentic and require a separate proof step before money moves.

Related resources from NHI Mgmt Group

• Who is accountable when social engineering leads to an authorised payment fraud loss?
• Why does authorised push payment fraud create a different control problem than account takeover fraud?
• How should banks reduce authorised push payment fraud without creating excessive friction for legitimate customers?
• How should organisations strengthen fraud prevention when identity attacks rely on social engineering, deepfakes, and voice cloning?