AI Fraud Verification Protocol

Key takeaways

• ✓AI-generated voice, video and text can now convincingly impersonate executives, making standard email or phone approval checks insufficient for large financial transactions.

• ✓A verification protocol replaces single-channel confirmation with a defined sequence of checks, calibrated to the dollar value and risk level of each request type.

• ✓The protocol only works if staff know it exists, understand why it matters, and feel empowered to apply it even when a request appears to come from a senior leader.

• ✓Friction is a feature, not a bug. A short delay on a $500,000 payment is a reasonable trade-off; the goal is to make the protocol fast enough for normal operations while hard enough to defeat impersonation attempts.

• ✓Training staff to recognise the social engineering patterns behind high-stakes fraud is as important as the procedural rules themselves.

Why standard approval workflows are no longer enough

Most finance and operations teams already have some version of an approval process. A payment above a certain threshold needs a second sign-off. A new supplier requires a form. A change to banking details triggers a callback. These controls made sense when the main threat was a poorly worded phishing email that a careful reader could spot.

That threat model is out of date.

AI tools can now generate a voice recording that sounds indistinguishable from your CFO, a video of your CEO authorising a transfer, or an email thread that mimics months of genuine correspondence. The voice cloning and executive impersonation techniques behind these attacks have moved from nation-state operations to commercially available services. The barrier to entry has collapsed.

This matters for verification because most traditional controls rely on recognising something: a familiar voice, a known email address, a writing style. Once any of those signals can be synthesised on demand, recognising them is no longer reliable evidence of authenticity.

The core problem with callback verification

Calling back on a number you already have on file only confirms that someone can answer that number. If the original request came through a compromised channel, the callback number may itself have been supplied by the attacker.

Business email compromise (BEC), where an attacker impersonates an executive or supplier to redirect payments or extract sensitive data, has been one of the costliest fraud categories in Australia for several years running, according to the Australian Cyber Security Centre's annual threat reports. AI-generated content makes BEC faster to execute, harder to detect, and easier to scale. An attacker no longer needs prolonged access to an email account. A convincing one-off message, built from publicly available audio or video of an executive, can be enough.

The gap this creates is specific: your existing approval workflow probably asks who is making a request. A strong AI fraud verification protocol asks how do we confirm that, through a channel the requester could not have influenced. That is a different question, and most standard processes are not built to answer it.

What counts as a high-stakes request?

A high-stakes request is any instruction that, if acted on fraudulently, would be difficult or impossible to reverse. The test is not the dollar amount alone. It is the combination of irreversibility, the authority being invoked, and the presence of urgency, all of which are the exact conditions a social engineering attack is designed to create.

Four categories cover the vast majority of incidents Australian finance and operations teams encounter.

Payment and banking detail changes. Any request to update a supplier's BSB and account number, redirect a payroll run, or change the bank account attached to a vendor record. These are the most common vector for business email compromise and AI-assisted impersonation attacks. A fraudulent update made on a Friday afternoon may not surface until the following week, by which time the funds are gone.

Executive-directed wire transfers. A request that arrives as an instruction from a senior leader, often under time pressure, to transfer funds outside the normal purchase order process. The CFO's guide to AI deepfake fraud covers the mechanics in detail, but the short version is that voice cloning and synthetic video make it genuinely difficult to trust an instruction that arrives only by phone or video call.

Credential and access resets. IT helpdesk requests to reset a password, grant elevated system privileges, or re-provision access to financial or HR systems. These feel like routine tickets. They are also how attackers establish a foothold before a larger fraud.

Sensitive data releases. Requests to export employee records, share contract terms, or provide account statements to a third party. The requestor may appear to be a legitimate auditor, a legal firm, or a senior internal contact. If the release cannot be undone and the data has value, it belongs in this category.

The common thread

All four categories share the same risk profile: an attacker impersonating a trusted authority, applying time pressure, and asking someone lower in the hierarchy to act without checking. The protocol exists to interrupt that dynamic before the action is taken.

A practical rule of thumb: if the person receiving the request would feel awkward pushing back on it in person, it probably needs a verification step built into the process so that the burden does not sit with the individual alone.

How to build your AI fraud verification protocol

A workable AI fraud verification protocol has five components. You do not need all five for every request, but you need to decide in advance which combination applies to which category of transaction. Improvising the verification process at the moment of the request is how mistakes happen.

Step 1: Define your trigger thresholds

The protocol starts before any human picks up the phone. Set explicit thresholds that automatically escalate a request to verification mode. These are not guidelines; they are written rules.

Common thresholds for a finance team:

Your thresholds will depend on your industry and transaction volumes. A government procurement team will set them differently from a 50-person services firm. The point is to write them down, not to leave them to individual judgement.

Step 2: Choose out-of-band confirmation channels

"Out-of-band" means confirming the request through a channel that is separate from the one the request arrived on. If the instruction came by email, you do not confirm it by email. If it came by phone, you do not call back on the number the caller gave you.

This matters because voice cloning and executive impersonation have made it trivial to fake both the voice and the email identity of a senior leader. Confirming through the same channel gives you no additional assurance.

Practical out-of-band options:

• Call back using the number stored in your internal directory, not the number in the message

• Use a dedicated internal messaging channel (Teams, Slack) that requires corporate authentication to access

• Walk to the person's office if they are on-site

• Use a pre-agreed secondary email address on a different domain

Designate which channel is the official verification channel for your organisation and make sure every person with payment authority knows it.

Step 3: Establish shared secrets or code words

A shared secret is a piece of information known only to your internal team, agreed in advance, that confirms a person is who they say they are. It is simple and surprisingly effective.

For high-value transactions, the requestor and the approver agree on a rotating code word or phrase at the start of each month. If someone calls claiming to be the CFO and cannot produce the code word, the request does not proceed regardless of how convincing the caller sounds.

Keep this process low-friction: one short word, refreshed monthly, shared through a secure internal channel. Do not email it, and do not put it in a document accessible to the whole organisation.

Step 4: Map your approval chain

Every high-stakes request should require sign-off from at least two people who are not in the same reporting line. A lone approver under time pressure is a vulnerability.

Define the chain clearly:

1. The person who receives the request logs it in your verification register (a simple spreadsheet is fine to start)

2. They notify the secondary approver through the out-of-band channel

3. Both approvers confirm the request independently before any action is taken

4. The outcome is recorded with the date, time, and both approvers' names

For anything involving a change of bank details or a new payee, consider adding a mandatory 24-hour hold period. Fraudulent requests almost always include urgency pressure. A required delay removes that lever entirely.

Step 5: Build in a mandatory time delay for the highest-risk requests

Speed is the attacker's best friend. Deepfake fraud works because the recipient feels they are in a live, real-time situation where hesitation seems inappropriate. A mandatory cooling-off period breaks that dynamic.

For requests that hit your highest-risk thresholds (large payments, bank detail changes, new international payees), require a minimum delay between receipt and execution. Even two to four hours is enough to allow the adrenaline to settle and give a second approver time to respond without pressure.

Document the delay as a policy, not a personal choice. When a staff member tells a fraudulent caller "our policy requires a 24-hour hold on all new payee payments", they are protected from social pressure. They are not being obstructive; they are following procedure.

The protocol's value is in writing it down

An unwritten verification process relies on staff remembering to apply it under pressure. A written protocol with defined thresholds and assigned roles removes individual discretion from the highest-risk moments, which is exactly where discretion is most likely to fail.

Which requests need which level of verification?

Not every request carries the same risk, and treating a $1,200 supplier invoice the same way as a $150,000 wire transfer will grind your operations to a halt. The table below maps common finance and operations request types to a three-tier verification model. Use it as a starting point and adjust the thresholds to fit your organisation's risk appetite and transaction volumes.

A few things worth noting about how to read this table.

Tier 1 is your baseline. System controls and a single sign-off are sufficient because the dollar value is low and the payee relationship is established. Even so, staff should still treat unusual urgency or unfamiliar language in a Tier 1 request as a prompt to pause.

Tier 2 introduces a second channel. The key principle here is that any verification must happen through a communication path that is independent of the one used to make the request. If the request arrived by email, the verification call should go to a phone number already in your system, not the number included in that email.

Tier 3 is your hard stop. No request in this tier should be processed on instruction alone, regardless of how senior the apparent requester is or how pressing the deadline sounds. The combination of voice cloning and executive impersonation means that a convincing phone call from your CEO is not, by itself, sufficient authorisation.

The change-of-bank-details request is your highest-risk trigger

Fraudsters overwhelmingly target payee record changes because a single successful change redirects all future payments. Any request to update bank details should automatically escalate to Tier 3, regardless of the dollar amount involved.

One column deliberately absent from this table is "AI-generated request." That is because you cannot reliably detect AI-generated fraud at the point of receipt. The better control is to apply tier requirements based on what the request is asking for, not on how it arrived or how authentic it appears. A well-crafted deepfake and a legitimate urgent email from your CFO can look identical. Your verification steps should be identical too.

How do you keep the protocol from becoming a bottleneck?

The honest answer is that some friction is the point. A wire transfer that takes four minutes longer because a finance officer made one phone call is a worthwhile trade. The goal is not to eliminate delay but to make the delay predictable and proportionate, so staff do not route around the process to hit their own deadlines.

A few design principles help with this.

Pre-approve the channel, not just the contact. Rather than verifying a request from scratch every time, establish in advance which phone number, which calendar link, or which internal system is the legitimate route for a given type of request. When the CFO needs to authorise an urgent payment, the finance team already knows to call the mobile number pinned to the internal directory, not the number that just appeared in an email. The verification step becomes "did this arrive through the agreed channel?" rather than a full investigation each time.

Set a response-time expectation for each tier. Tier one checks should resolve in under two minutes. A callback to a known number or a tap in an authenticator app does not take long. Tier two checks involving a second approver might take ten to fifteen minutes. Build these expectations into your approval workflow documentation so staff know what "fast" actually means at each level, and so they do not skip a step because they assume it will take too long.

Create a short list of pre-cleared, recurring requests. Some high-value transactions happen on a predictable schedule: monthly payroll runs, regular supplier payments, quarterly tax instalments. These can be pre-cleared in advance so that verification is lightweight, often just a system-generated confirmation rather than a manual callback. Anything that deviates from the pre-cleared pattern, even slightly, reverts to the standard tier.

The pattern that matters most

Fraudulent requests almost always introduce urgency or novelty: a new payee, an unusual amount, a tight deadline. Your protocol should treat urgency as a signal to slow down, not a reason to skip steps.

Designate a decision owner for urgent exceptions. Every protocol needs a named person who can authorise a verified exception quickly when a genuine time-sensitive need arises. That person should have a clear checklist: what evidence satisfies them, and what gets escalated further. Ambiguity about who decides is what causes genuine bottlenecks, not the verification steps themselves.

Finally, train your team on the protocol, not just the policy document. A one-page flowchart on the wall is easy to ignore. Staff who have practised the verification steps in a realistic scenario, including a simulated deepfake call or a spoofed email thread, will move through the process faster and with more confidence. Speed comes from familiarity, and familiarity comes from practice.

Frequently asked questions

What should trigger the verification protocol?

Any request that involves moving money, changing payment or banking details, granting system access, or acting on urgent instructions from a senior executive should trigger the protocol automatically. The channel matters too: requests arriving by email alone, via messaging apps, or through any channel where the sender's identity cannot be independently confirmed should receive closer scrutiny regardless of dollar value. If your team is unsure whether something qualifies, that uncertainty is itself a signal to pause.

How often should we update the verification protocol?

Review the protocol at least every six months, and immediately after any attempted fraud, a near-miss, or a significant change in how your organisation uses AI tools. Fraud techniques evolve quickly. Voice cloning and executive impersonation have become viable at scale in the past two years, and a protocol written before that shift may have gaps that are now consequential. Treat the review as a standing agenda item, not a one-off task.

What should we do if someone bypasses the protocol?

Treat every bypass as a formal incident, whether or not a loss occurred. Log what happened, who was involved, and what pressure or circumstance led to the shortcut. Patterns in that log are usually more revealing than any single event. Repeated bypasses in a particular team or under a particular type of request often point to a protocol that is genuinely too slow for the workflow, which is a design problem worth fixing rather than a culture problem worth prosecuting.

Is staff training enough on its own?

Training is necessary but not sufficient. Awareness helps people recognise suspicious patterns, and AI scam awareness training should be a baseline across finance and operations roles. But training alone asks individuals to hold the line under time pressure, which is exactly when judgement fails. A verification protocol moves the defence into the process itself, so it does not depend on any one person having a good day. Both are required. Neither replaces the other.

How do we handle a genuine executive who finds the process frustrating?

Be direct about why the control exists. Most executives, once they understand that a convincing deepfake audio clip of their own voice can now be generated from publicly available recordings, accept the friction. The harder cases are usually about speed: an executive who needs something done urgently and sees verification as a delay. The answer is to design fast-track paths for known, recurring request types, so the protocol adds minimal time to routine business and reserves its weight for genuinely unusual situations.

Build the habit, not just the policy

A written protocol is a starting point. It only works if the people who handle payment instructions, onboard suppliers, or approve transfers can apply it under pressure, when a request arrives at 4:45 on a Friday and the "CFO" sounds completely convincing over the phone.

That is the gap most organisations miss. The procedure exists in a document somewhere. The training never happened.

Voice cloning and executive impersonation have made this gap expensive. Attackers no longer need to compromise an email account. They can generate a convincing audio clip from publicly available recordings, call a finance coordinator, and instruct them to bypass the usual process because the deal is time-sensitive. A staff member who has never practised a verification protocol will hesitate, defer to apparent authority, and comply.

Practised behaviour is different from written knowledge. Your team needs to have made the call-back before the fraud attempt arrives. They need to know what it feels like to push back on an urgent request from a senior voice, and to know that the protocol protects them when they do.

Does your team know how to apply your verification protocol under pressure?

The Better People AI Scam and Deepfake Awareness workshop covers real fraud scenarios, verification habits, and how to respond when a request feels wrong. Teams leave with practical skills, not just awareness.

Explore the AI Scam Awareness workshop →

AI scam awareness training should be refreshed as attack methods evolve, and the people who most need it are not always in senior roles. A finance coordinator processing a supplier change, a PA authorising a travel reimbursement, an operations assistant updating bank details: these are the people attackers target, because they have access and they tend to defer.

Build the protocol. Then train the people who will use it.