Was That Really Your Boss on the Video Call? Checking a Deepfake Payment Request

2026-10-26 · Philip Choo · AI9OS

A request arrives that appears to come from a senior executive. A call, a video meeting, an email or a message. It is urgent. It asks for something consequential: a payment to a new account, a credential, a set of files. It is a little unusual, and it comes with a reason not to follow the normal process this once.

Afterwards, somebody has to establish whether it was genuine.

That is a different task from detecting impersonation while it is happening, and it is worth being clear about which one is being done. After the event, the job is verification, and it has three legs, not one.

The first thing is preservation

Before any analysis, secure whatever exists: the recording of the call or video, the full email headers, screenshots of the messages, and a verbatim log of the request itself, including the amount, the destination, the urgency framing used and exactly who received it.

This is the most perishable evidence in the whole matter. Messages get deleted, recordings are overwritten on a schedule, and accounts used to send the request disappear. Everything else can wait a few hours. This cannot.

And one question has to be asked before anything else: has any payment, data or access already been given? If it has, this is an active fraud, and the bank or payment provider and the police need to be contacted in parallel. The verification work must never become the reason that call is delayed.

Leg one: the technical review

Where a recording exists, it can be examined for the traces that synthetic voice and video sometimes leave: inconsistencies in facial movement, lighting or blinking on video; timing and tonal artefacts in audio.

The critical point is what a clean result means. Current voice and video cloning can leave no detectable artefacts at all. A technical review that finds nothing does not clear the request as genuine. Anomalies can be reported as anomalies. Their absence is not a verdict.

An automated detection tool has the same limit. It produces a probability, not a finding. Claims about detection accuracy deserve the scepticism owed to any vendor's marketing, which is the subject of reading a vendor's OSINT article without buying the premise. A low score is one data point for a person to weigh, never a substitute for the other two legs.

Leg two: behavioural consistency

This is usually the stronger leg, not the secondary one.

Compare the request against documented patterns from the real executive: their vocabulary, how they make decisions, and above all the normal approval process for this kind of request.

A request that bypasses the established approval route, or leans on unusual urgency or secrecy, is a stronger signal than any single artefact in a recording. Impersonators can clone a voice. They find it much harder to clone an organisation's actual way of doing things, which is why their requests so often arrive with a reason to skip it.

The discipline is to compare against specific documented prior behaviour, not a general impression that it "sounded like them".

Leg three: the infrastructure

Trace the channels the request came through: the domain an email was sent from and when it was registered, the account used, any signs of spoofing, and whether the same delivery pattern has been reported against other organisations. A pattern seen elsewhere turns a single incident into part of a wider campaign, which is worth knowing and worth sharing through industry channels. Where the impersonation runs through fake social accounts rather than a single message, the method changes, and the order of operations is set out in brand impersonation: capture before you report.

The finding that matters regardless of the verdict

One question sits across all three legs: was an independent check attempted at the time? A call back on a known number. A question only the real executive could answer. Confirmation through a second channel the requester did not control.

If it was attempted, what happened is central evidence. If it was not, that is the primary control finding, whatever the verdict turns out to be. The recommendation to require an out-of-band check for high-value requests is worth making in every such matter, including the ones where the request proves genuine.

The distortions that push toward a wrong answer

These matters are run under pressure, and pressure produces predictable errors. The five distortions map onto them closely:

• Authority. A clean technical read feels authoritative. It is not a clearance.
• Consensus. Several people on the call recognising the voice is not independent verification. People are poor at detecting current voice clones, and they were all listening to the same voice.
• Motivated reasoning, in both directions. "Clearly genuine, process it" and "clearly fake, no harm done" are both convenient. "Unresolved: do not act on the request" is a legitimate interim finding, and often the correct one while evidence is gathered.

If you are the organisation affected

"What would we have had to do, at the moment the request arrived, to know it was genuine?"

The answer is almost never a better detection tool. It is a process that makes the request check itself through a channel the requester cannot reach, and that applies to everybody, including the most senior person in the building.

(General information for practitioners, not legal advice.)