Verify a payment request on a channel it never touched
Verifying a payment request against a cloned voice means confirming a bank detail change on a phone number taken from a record the request never touched. That record is a vendor master file, a signed contract or a settled invoice. Voice clone fraud defeats a callback made on the same call, so the number never comes from the request itself.
The callback is dialled before the transfer or the change proceeds. The National Anti-Scam Centre recorded $166.8 million in payment redirection losses in 2025, second only to investment scams by loss that year, up 9.3% on the $152.6 million lost in 2024. Its Targeting Scams report states that false billing reports from business generally relate to payment redirections, also known as business email compromise scams. The Australian Signals Directorate's Annual Cyber Threat Report 2024-25 lists business email compromise fraud resulting in financial loss as the second most common self-reported cybercrime threat for business, at 15%.
Why can't you trust a voice or a video call anymore?
That report states that cybercriminals use generative AI to create high-quality videos, fake voices, websites, know-your-customer records and spearphishing emails to more convincingly present themselves as legitimate actors. It lists this as achievable with relatively minimal effort. Voice and video sit beside the spearphishing email in that description. Source audio can come from public material such as a conference talk, a webinar recording or a voicemail greeting.
A video call has been the step a finance team escalates to when a phone call feels wrong. The reasoning is that a face is harder to produce than a voice. The same report lists high-quality video alongside fake voices, so a video call adds no verification the phone call did not already give. The National Anti-Scam Centre lists an increase in the sophistication of scams, including the use of artificial intelligence, among the factors that may have contributed to the decrease in reports to Scamwatch between 2024 and 2025, making it harder for consumers to recognise scams and report them.
Why does replying on the same channel fail the out-of-band rule?
Scamwatch is specific about what counts as independent. Its guidance on business email compromise scams says to stop and check any changes to payee information on invoices. It says to contact the business by phone using a number sourced independently, not the contact details in the email, because those might have been changed by the scammer. It also says to check the email address, since scammers sometimes add one extra letter or number so you think you are dealing with the real business.
The rule holds whether the request arrived by email, by text or by a call that already sounds right. A reply in the same thread does not satisfy it. Neither does a call to the number on the invoice, nor a second call from the voice that made the first request. In each case the channel that carried the instruction is the channel confirming it. A number qualifies only when it came from somewhere the request could not reach. That means a vendor master record, a signed contract, a settled invoice, or a directory the requester does not control.
How do you build a verification workflow that holds under time pressure?
A workable policy names who may request a payment or bank detail change, what independent step confirms it before the change proceeds, and what happens when that step is skipped. The confirming step is a callback to a number the business held before the request arrived. Where headcount allows the split, someone other than the request's recipient makes that call. Seniority and urgency do not release anyone from the step, and the policy says so in writing.
Banks are adding a check of their own at the point of transfer. The Australian Banking Association, in the National Anti-Scam Centre's Targeting Scams report, describes Confirmation of Payee as an industry-wide initiative banks, building societies and credit unions are rolling out. It is a payment-checking service that verifies the name of the intended recipient against the account details entered by the payer before a transfer completes. It alerts the customer before authorisation where the details do not match. It tests whether the account number belongs to the name on the invoice. The callback tests whether the vendor sent the instruction at all, so both run on the same payment and answer different questions.
- Name in writing who can request a payment or bank detail change.
- Source the callback number from a record the request did not touch, such as a vendor master file, a signed contract or an earlier invoice.
- Make the call before the transfer or the detail change proceeds, never after.
- Remove seniority and urgency as grounds for skipping the callback.
Does the callback step hold when tested under pressure?
A vishing scenario puts a time-pressured instruction in front of the person who would normally act on it. It records what happened to the callback: made to an independently sourced number, made to a number carried by the request, or not made at all. It runs inside a standing phishing simulation practice, on the same written scope and consent as any other social engineering test. The result recorded is the state of the verification step.
Results are reported per team, naming the step that failed rather than the person who missed it. Where the callback was skipped or an approval was rubber stamped, the follow-up training is written against that step. A second wave after the training measures whether it holds the next time.
What do you log when a request is challenged and declined?
A declined request still needs a record, because the same instruction is often put through a second channel once the first attempt fails. Log the date and time, the channel it arrived on, and the identity it claimed. Log the independent verification step taken and its outcome, who made the call, who declined the request, and what was done to the vendor or payment record afterwards.
That log is what a bank's fraud team or an insurer will ask for if the same instruction later succeeds through a different employee or channel. It carries the evidence that the control ran on the day. Black Shard builds the verification workflow with the people who process the payments and runs the vishing scenario against it as an AI cyber defence engagement, then reports which step held.