How should organisations verify unusual payment requests when AI phishing impersonates trusted executives or vendors?

Use out-of-band verification before any transfer or account change. Confirm the request through a known phone number or approved internal channel, not by replying to the message you received. Pair that with a second person review for high-value payments, because AI voice cloning, deepfake video, and realistic email chains can all be used to bypass normal trust cues.

How to verify a request when the sender looks familiar

The safest verification step is to stop treating the message thread as a trusted channel. If the request involves a transfer, beneficiary change, invoice change, or bank detail update, confirm it through a known callback number, a verified directory entry, or an approved internal workflow. The key control is separation: the channel used to request the action should not be the channel used to approve it.

For high-impact payments, the verification should include a second person who is not the original approver and who can challenge the business case, amount, destination, and timing. That makes impersonation harder to turn into an immediate loss, especially when the message includes urgency, confidentiality pressure, or executive authority cues.

What makes AI phishing effective against payment workflows?

AI-assisted impersonation works because payment teams often rely on familiarity signals, not just technical indicators. A realistic voice note, a polished email trail, or a convincing vendor follow-up can create enough trust to bypass informal habits. This is why the control is not just “spot the fake”, but “remove single-channel trust from the decision.”

Unusual payment requests are also high value because they often combine speed, authority, and routine exception handling. If staff are trained to move quickly when an executive is “blocked” or a supplier is “waiting on settlement”, attackers can exploit that urgency to bypass normal checks. The more a workflow depends on human recognition alone, the more it can be manipulated.

What good verification looks like in practice

Effective verification is specific, repeatable, and documented. The reviewer should confirm the request against an independently obtained contact method, compare the request to prior payment patterns, and check whether the change affects a known supplier, a new bank account, or a revised destination country. If the request cannot be validated cleanly, it should be treated as untrusted until proven otherwise.

Controls work best when they are embedded in the payment process itself. For example, a finance or AP team should know which changes require manual approval, which require call-back verification, and which require escalation to treasury, procurement, or security. That reduces the chance that a fraudulent request is approved simply because the approver believes it is “just a normal exception.”

Risk and Threat Considerations

AI impersonation raises the risk of authorised-looking fraud, because the attacker does not need to break the payment system if they can convince a person to initiate a legitimate transfer. The main exposure is loss of funds or account control through social engineering, where the request appears to come from a trusted executive or vendor.

Failure mechanism: The attacker uses synthetic voice, deepfake video, or convincing written context to create false authority, then pushes the victim to act before independent verification occurs.

Impact: A single successful request can result in fraudulent transfer, supplier payment diversion, or unauthorised account change, and the longer the delay before detection, the harder recovery becomes.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Payment approval changes depend on trusted verification and channel integrity.
	AC-6 — Least Privilege	Unusual payment requests should not let one person complete every step unchallenged.
Recommendation — Require independent verification and rotate or revoke any exposed approval credentials promptly. Split request, review, and release authority so no single actor can both request and approve.
ISO/IEC 27001:2022	A.5.15 — Access control	Call-back approval and maker-checker controls are access decisions over payment actions.
Recommendation — Define and enforce approval paths that require independent confirmation for high-risk payment changes.
NIST CSF 2.0	PR.AA-05 — Identity proofing and authentication are performed before granting access	Verification here is about authenticating the requester through a trusted alternate channel.
Recommendation — Use verified alternate channels before acting on any unusual payment instruction.
CIS Controls v8	CIS-6 — Access Control Management	Different approval roles and exception handling reduce fraud exposure in payment workflows.
Recommendation — Restrict who can approve, change, and release payments, and review exceptions separately.

Practitioner Guidance

What to prioritise: Build a hard verification rule for any payment or banking change that is unusual, time-sensitive, or outside a known pattern. If the request arrives by email, chat, or voice, the approval step should happen somewhere else.

What to verify: The approving person should verify the request origin, beneficiary details, and business justification against a trusted source, not against the same thread or number that delivered the request. For executive requests, treat urgency as a reason to slow down, not speed up.

Practitioner takeaway: The control objective is not to detect every fake sender, it is to make a fake sender insufficient on its own to move money.