A familiar voice is not a payment control
Imagine a finance officer receiving a voice note from someone who sounds exactly like the director. A supplier must be paid today; the usual approver is travelling; the bank details have changed. The message is plausible because the surrounding situation is plausible. This is an illustrative scenario, not a reported Solid Elf client incident. Its useful question is simple: what would your team do before releasing the money?
AI-generated voices and polished messages raise the cost of judging authenticity by appearance. But an organisation does not need to prove that a recording is synthetic before refusing an unverified payment change. The control is the independent approval process. That process should work equally well against a human impersonator, a compromised mailbox and a convincing generated voice.
Move verification outside the request
A callback is useful only when the number comes from a trusted record established before the suspicious request. Calling the number supplied in the message simply asks the sender to confirm their own story. The same problem applies to a new meeting link or an attachment labelled “updated contact details.”
For a supplier-account change, retrieve the established contact from your vendor records. Ask them to confirm the change through the agreed channel. Record the reason, the verification method and the second approver. The person entering the new payment details should not also provide the only approval. If the authorised contact cannot be reached, the exception should be escalated rather than silently accepted.
Make the safe action possible under pressure
A written rule that staff cannot follow during a busy day will become a ceremonial rule. Give the team a short escalation path and a named backup approver. Make “I need to verify this first” an acceptable response even when the request appears to come from the most senior person in the organisation.
Run a ten-minute exercise using a fictional message. Ask staff where the trusted contact record lives, who may pause the transaction and how an urgent exception is recorded. Do not turn the exercise into a test of who is clever enough to spot the fake. Measure whether the process gives an ordinary employee enough authority and information to stop an unsafe transfer.
If someone has already acted
Contact the bank or payment provider promptly using its established support channel and explain the suspected fraudulent transfer. Follow your organisation’s incident procedure, preserve the messages and transaction details, and involve the people responsible for finance and security. Do not promise a recovery outcome: available options depend on the payment system and timing.
If an account may be compromised, use a trusted device and your approved response process to review access and recovery settings. Preserve useful evidence before making changes that could destroy it. Avoid accusing the apparent sender; their identity or account may also have been abused.
A decision to take into your next team meeting
Choose one consequential action—changing supplier details, approving a refund or sharing a sensitive report—and write down the independent evidence required before it happens. Test the rule when the requester is senior, the deadline is short and the primary approver is unavailable.
The practical goal is not to train everyone to identify every deepfake. It is to make a believable message insufficient on its own to move money or expose data. A five-minute verification delay is easier to explain than a payment process with no reliable stopping point.