Voice-Clone Payment Fraud Needs a Callback Control, Not Better Ears

AI Trust & Governance

23 October 2026 | By Ashley Marshall

The cloned voice may arrive when your finance team tries to verify a payment. If your second check is another call arranged by the requester, it is not a second check.

A familiar voice is no longer an approval

A finance colleague gets a call from someone who sounds like the managing director. The caller knows the supplier, the invoice amount and the deadline. The request is to change bank details before today's payment run. Until recently, many teams treated the recognisable voice as a second factor. That assumption is now unsafe. A voice, video meeting or apparently familiar message can all be generated or manipulated; none proves that the person has authority to redirect money.

The scale of the surrounding fraud problem is already material. UK Finance reports £1.28 billion stolen through payment fraud in 2025, four per cent more than the previous year. That number covers payment fraud broadly; it is not a measure of AI-enabled fraud, and it would be misleading to present it as one. The useful lesson for a business is narrower: a weak authorisation step sits in a large, active criminal market. AI makes impersonation easier to package into that existing route.

The most revealing recent example is outside the UK. Vigil Security describes an Italian private-bank case in which a WhatsApp message purporting to come from a chief executive was followed by a call using a cloned lawyer's voice. Eleven transfers totalled about €95 million. The voice did not simply initiate the request. It appeared when the recipient sought reassurance. That is the practical threat: an attacker can imitate the very check your team thinks it is performing.

This does not mean employees should distrust every call. It means the proof must sit outside the conversation being used to request the payment. A callback to a previously registered number, initiated by the payer, has a different evidential value from a return call to a number supplied in the email or WhatsApp thread. Train that distinction before the first suspicious request, not in the middle of one.

Make the callback a defined control

A vague instruction to 'double-check unusual payments' is difficult to execute under pressure. Define the trigger precisely: every new beneficiary, change of bank details, exceptional early payment, or payment above a chosen threshold requires independent verification. Keep the rule even when the request appears to come from the chief executive or a trusted adviser. An exemption for seniority is exactly the gap an impersonator will exploit.

The payer should retrieve the contact number from a maintained supplier record or an established internal directory, not from the new invoice, incoming email, calendar invitation or chat. If the supplier has no verified number on file, pause the payment while procurement or the account owner establishes one through an existing relationship. During the callback, read back the beneficiary name, sort code and account number, then record who confirmed the change, on what date and through which trusted route. Do not ask only 'is this invoice real?' because a genuine invoice can carry substituted bank details.

What this means in practice is a small workflow change, not a new detection platform. Put a bank-detail-change ticket in the finance system, require a second approver who can see the previous and proposed details, and block the payment batch until the callback evidence is attached. The second approver should be independent of the requester. For a small firm, that might be the owner and bookkeeper; for a larger one, accounts payable and a supplier relationship owner. Document a backup approver for holidays so urgency does not become a reason to skip the step.

Do not rely on a shared secret phrase as the only safeguard. It can be disclosed, overheard or extracted from a compromised mailbox, and it may give a team false confidence. A callback to a number established before the request, plus a separate approval in your own system, gives the attacker two independent barriers. The control should be easy to explain in one sentence: no changed bank details are paid until we call a known number and log the confirmation.

Test the moment of pressure, not just the policy

Most policies look convincing when read calmly. They fail at 4:45pm when an urgent transfer seems to be holding up a deal. Run a short exercise with a realistic supplier-change message, a simulated follow-up call and a manager applying pressure to waive the control. Observe whether staff use the known number, where they find it, whether the payment system actually blocks progress, and whether an independent approver challenges the exception. The goal is to expose process friction, not to embarrass an individual.

A recent UK workplace training guide argues for specific, repeated examples rather than telling staff they can spot fake audio by listening for glitches. That is the right direction, but training alone cannot authorise a payment safely. The practical metric is the proportion of triggered changes with complete callback evidence and independent approval. Track attempted bypasses and the time needed to resolve legitimate changes. If every verification takes two days, people will create informal shortcuts; fix the supplier record and approval queue instead of relaxing the control.

What this means in practice: sample ten recent beneficiary changes this week. For each, ask whether the previous details were visible, whether the confirmer's number pre-dated the request, and whether the record names the colleague who made the call. If you cannot answer from the audit trail, treat the control as absent, even if staff say they remember phoning. Build a simple exception log for cases where the usual contact is unavailable. The exception must name who authorised the alternative route and why.

The counterargument is that a blanket callback slows ordinary trade. That is fair when the rule is written too broadly. Do not call every supplier for every routine invoice to the same verified account. Focus the additional step on changed destination or unusual authority. A well-designed control distinguishes a normal repeat payment from a new instruction to send money elsewhere. It should protect the business without turning accounts payable into a call centre.

Plan the first hour after a suspected transfer

If a payment has gone out, speed matters more than a perfect incident report. The National Cyber Security Centre advises businesses that suspect payment fraud to contact their bank directly using its official website or phone number, and to alert their IT person or department promptly. Put those contacts in the finance runbook now. Do not use contact details from the suspicious thread. Ask the bank about recall or freezing options, preserve the transaction reference, and record the exact time the instruction was received and the transfer made.

Contain the route of compromise in parallel. If the attacker used a supplier's email thread, confirm with the supplier through a known channel and warn colleagues not to act on related messages. If an internal account may be compromised, involve IT to secure sessions, credentials and forwarding rules. Keep copies of email headers, messages, call records and approval logs. A voice recording may help investigators, but lack of one should not delay contacting the bank. The NCSC provides a route for UK organisations to report a cyber incident through gov.uk.

Assign roles before an event: one person phones the bank, another preserves evidence and checks account access, and a senior owner decides whether customers or partners need warning. The person who made the transfer should not have to coordinate everything while dealing with the shock of the loss. Avoid blame in the initial response. You need an accurate timeline and a chance to stop further payments, not a debate about whether someone should have recognised a synthetic voice.

After containment, review the control that should have stopped the transfer. Was the known contact number missing? Did the second approval occur in the same compromised channel? Could a manager override the hold without leaving evidence? Those findings should alter the workflow and then be tested in another exercise. A post-incident reminder to 'be vigilant' is not a repair. If your bank offers payment confirmation or beneficiary-check features, use them, but keep independent verification for changed details because a plausible-looking name alone does not prove the instruction came from the supplier.

Treat AI detection as supporting evidence, not the gate

It is tempting to buy a deepfake detector and let it decide whether a call is genuine. The problem is that the attack can arrive through multiple channels and at different quality levels, while the payment decision needs a dependable process. Vigil summarises recent listening research involving 1,768 people: listeners correctly identified clones from current commercial systems roughly 61 to 66 per cent of the time. That study concerns human listeners, not every commercial detector, but it is enough to undermine a policy that asks staff to decide from sound alone.

Detection products can still be useful for triage, recording analysis or high-risk contact centres. Ask a vendor for measured false-positive and false-negative rates on calls like yours, including short clips, noisy lines and partial voice splices. Ask what happens when the model is uncertain and whether your finance workflow still pauses a beneficiary change. A detector's confidence score should never silently override a failed callback or substitute for an approver's sign-off. Test it on real-world conditions before buying a seat for every employee.

For a UK business, the sensible order is process first, tooling second. Map where bank details enter the organisation, who can change the supplier master record, who can release a payment, and which channel each person uses to verify instructions. Remove single-person authority for high-risk changes. Then consider technology that makes the workflow easier to enforce or audit. You do not need to prove a recording was AI-generated to refuse an unverified change of destination. The request has failed your authorisation rule either way.

The wider lesson applies beyond finance. Where AI can imitate a familiar person, identity should be proved by a pre-agreed, independent route and action should be constrained by a recorded approval. In payment operations that means a known-number callback, separation of duties and an audit trail. Those controls work whether the threat is a sophisticated voice clone, a compromised mailbox or an ordinary fraudulent invoice. That is why they are worth implementing even if you never hear a convincing fake voice.

Frequently Asked Questions

Can a finance team reliably hear a cloned voice?

No. Sound quality is not an authorisation control. Verify the instruction through a known number and a separate approval.

Which payments should trigger a callback?

At minimum, new beneficiaries, changed bank details and exceptional payments. Set a documented threshold for other high-risk transfers.

Can we call the number on the new invoice?

No. Retrieve the number from a verified supplier record established before the request.

What if the usual supplier contact is unavailable?

Pause the transfer and use a documented alternative verified through an existing relationship. Record the approver and reason for the exception.

Does Confirmation of Payee replace a callback?

No. It may provide useful account-name information, but it does not verify who requested a change or whether the change is authorised.

What should we do immediately after a suspicious transfer?

Call your bank directly using its official number, alert IT, preserve messages and transaction details, and consider reporting through the NCSC route.

Should we buy a voice deepfake detector?

Consider it for supporting triage after testing on your own call conditions. Do not let a detector bypass callback and dual approval.

Will this slow all supplier payments?

No. Apply the extra verification to changed destinations and defined exceptions, not routine invoices paid to an existing verified account.