Before money moves, the challenge script is the control

The first deepfake fraud to reach your organisation will probably arrive as a routine payment instruction. It will not announce itself. A finance assistant gets a video call from someone who looks like the managing director, on an ordinary Tuesday, asking for a same-day transfer to a familiar-sounding supplier. The face, the voice and the manner are all good enough. The only thing wrong is the request.

The Australian Financial Review reported from its Cyber Summit on 21 September that banking groups have flagged 32,000 examples of dangerous internet content, including a growing number of deepfake investment scams, in coordination with Meta and telecoms providers. The reporting frames the fight as a war on truth. The operational problem underneath is narrower: the impersonations are improving faster than the eyes that have to judge them.

Detection hits a ceiling

The instinct after a headline like that is to add more detection training: show people better deepfakes, teach them to look for the flicker in a video or the slight wrongness in a voice. That path leads to a moving target. The 32,000 flagged items are the ones someone caught. If a deepfake is convincing enough that a bank, a platform and a telecoms provider have to coordinate to remove it, then an individual employee checking visual artefacts is a fragile final line.

Detection also fails in the direction that matters most. A well-run finance team pays people to be accommodating. The assistant who wants to help is acting exactly as the organisation trained them before deepfakes became operational. The question worth asking is why one person could move money on the strength of one call. If the answer is urgency, the organisation was relying on a single point of human judgement.

A more useful reading is that verification has to be procedural. If a person cannot reliably judge the face, the organisation needs a step that does not depend on that judgement. That step sits at the transaction.

What the payment run actually needs

In a mid-sized finance function, the person who can approve a payment often sits next to the person who updates supplier banking details. There is no separate payment operations team to review the video. A deepfake does not need to convince the whole organisation. It only needs to convince one authorised person who wants to be helpful. That makes the transaction itself the point of control, and it means the control has to survive the moment of pressure.

The cheapest control is a pre-agreed challenge script, written now, for the moment when a request arrives. For anything above the payment threshold, the recipient should verify through a channel independent of the caller. A finance assistant should be able to say: I'll call you back on the number we hold. A payroll lead should be able to say: I'll need the employee reference and the manager's approval before changing bank details. Then the test is not whether the face is real; the test is whether the request survives a second channel and a second person.

That is what a transaction-level verification baseline means in practice: the default assumption that any payment or data request above a low threshold is unauthorised until a separate channel confirms it. It requires no exotic technology. A script, a second person and a pre-registered number are enough to start.

The verification channel can be a number the organisation already holds, a second approver in a different reporting line, or a ticket opened in the procurement system. The rule is that it should use a separate channel and a separate person wherever the request can move money or release data. The question matters less than the fact that it has to be answered outside the original video call or email thread.

Training changes shape under this model. People rehearse the script until it feels ordinary, with simulated voice and video requests that look plausible. Reporting then shows who still skips verification when the request is urgent and who confirms before acting. A managed cyber awareness programme can run those drills, assign them by role, and route a report-phish button to a real SOC. An annual video exercise cannot.

The drill to run this month

Pick three workflows that can move money or release data outside the organisation: supplier payments, payroll bank-detail changes, customer refunds. For each, write the challenge script and the independent channel. Have finance, HR and IT run it once against a simulated request. Ask whoever owns the human-risk line in the risk register to review the results with the same seriousness as a penetration test.

If the current training contract cannot support that drill, that is the gap to address before the first convincing video arrives. Book a working session to map one payment-verification path, or ask us to review the awareness programme that is supposed to be doing this.