CEO fraud is an impersonation scam that uses a leader’s apparent authority to push someone into an unauthorized payment or other sensitive action. It can arrive by email, message, voice, or video; AI is not required. Before paying, independently confirm the exact request, apply the organization’s approval process, and verify any changed destination separately. A familiar face or voice does not replace those checks.
This guide is for the person receiving an unusual executive request and the colleague reviewing it. Its purpose is payment authorization, not diagnosing every kind of phishing or predicting whether money can be recovered. The fictional walkthrough below contains no bank details, usable scam template, or actual incident. Follow your organization’s approved finance and security procedures rather than improvising a new payment process from this article.
Recognition is not payment authority
A message may use a real executive’s name and refer to work you recognize. That can make it relevant without proving that the executive issued it. A convincing request can also appear inside an existing communication context. The FBI’s business email compromise guidance describes known-source impersonation and recommends checking payment requests and changed procedures independently. Do not require an obvious typo before taking the risk seriously.
The decision becomes easier when you remove the persuasive introduction. Write the proposed action plainly: issue a new payment, change an approved destination, purchase something outside the usual process, or release sensitive records. That action is what needs authorization. The sender’s title and explanation may provide context, but they do not establish that this particular action fits the organization’s rules.
Urgency and confidentiality are not automatic proof of fraud. Real organizations have urgent and confidential work. The practical warning is a request to make those circumstances cancel normal verification. A legitimate confidential task should still have an approved route for confirming authority and involving the appropriate reviewer. You should not have to rely solely on a stranger’s account, a new number, or a message thread to establish that route.
Do not treat verification as personal disobedience. A sound process applies even when the requester is senior and even when a request ultimately proves legitimate. The purpose is to protect the task and its owner from unauthorized changes. Describe what you need to confirm rather than accusing someone of fraud based on a communication style or a poor-quality video call.
Separate identity, authorization, and destination
These questions often get compressed into “Did the CEO send it?” Keep them separate. Identity concerns who is communicating. Authorization concerns whether this person and process approve the proposed transaction. Destination concerns where funds or information would actually go. Confirming one question does not silently answer the other two.
For example, reaching the real executive through an established internal contact can confirm that they want a supplier task completed. It does not necessarily confirm new payment instructions copied into a separate message. The responsible finance process may still need to validate the supplier change. Conversely, recognizing a supplier’s name does not authorize a transaction outside the approved purchasing process.
Use a small transaction record rather than a general feeling of trust. Identify the internal task or reference, who can authorize it, what changed, and which established record supports the destination. Keep sensitive details inside the approved system. A review worksheet should describe where a check happened; it does not need to expose an account number in a public chat or shared training document.
| Check | Question to resolve | Insufficient by itself |
|---|---|---|
| Identity | Was the requester reached through an independently established contact? | Name, avatar, caller display, familiar voice, or incoming video. |
| Authorization | Does the exact task pass the approved permission and review process? | A senior title or a general statement of urgency. |
| Destination | Was a new or changed recipient validated through the appropriate established record? | Details copied only from the request being reviewed. |
| Release | Are all required checks complete before the action is executed? | One reassuring answer while another check remains unresolved. |
This is an original teaching worksheet, not an audit certification or mandatory legal standard. Your organization determines the actual roles, approvals, thresholds, and records. The useful principle is that evidence should answer the relevant question instead of being borrowed from another row.
Verify outside the incoming conversation
Use contact details established before the unusual request: the normal internal directory, approved work channel, or known finance escalation route. Do not use a new callback number supplied only by the request. Changing from email to a phone number supplied in the same email does not make the check independent. You would still be using the sender’s chosen verification path.
Confirm the precise task and any requested exception. “Are you working on a supplier payment?” is too broad if the question is whether this particular change was authorized. Do not volunteer private transaction details to an unverified helper while asking for confirmation. First establish the legitimate route and use the approved record to discuss the request with the appropriate person.
The FTC’s small-business cybersecurity guidance, under Business Email Imposters, recommends internal verification policies, including calling to confirm wire requests received through email. Apply that as a procedural principle, not a guarantee that any completed phone call is safe. The contact’s origin and the question you asked still matter.
If the person is unavailable, use the existing escalation or delegate process. Do not invent an emergency exception because the incoming message says everyone else is occupied. “Unable to confirm” is a valid temporary outcome. A deadline may explain why the task matters, but it does not itself supply missing authority.
A familiar voice or video is supporting context, not a release control
The FBI’s December 2024 generative-AI fraud advisory describes generated voice and video used to make impersonation more believable. That is a documented warning about a capability, not a finding that a particular incoming call used AI. The immediate payment decision should not depend on proving which tool, if any, created the media.
A real recording can also be reused out of context, and a real person can appear in an unauthorized account. A technical result with no strong manipulation finding therefore does not approve the transaction. The AI impersonation guide covers the broader identity and media relationship. Keep the narrower finance question here: what establishes authority for this action?
If a suspicious clip needs analysis, preserve the best authorized source and note how it relates to the request. Do not delay pausing an unverified payment while you search for visual defects. The voice clone scam guide covers audio-led interruption more broadly. A payment workflow should remain protective even when a voice sounds normal.
Make the second review independent
A second approver can add a useful check only if they evaluate the relevant evidence. Forwarding the same suspicious message with “I think this is fine” can transfer your assumption rather than establish authority. Follow the approved division of responsibilities and tell the reviewer which parts were verified and which remain open.
For a changed destination, the reviewer should use the authorized supplier or recipient validation process instead of accepting copied details because a colleague already saw them. The process may be handled by a separate team. Do not bypass it by asking a senior person to approve a screenshot that does not establish how the change was verified.
Separate preparation from release in your own explanation. Someone can assemble an incomplete task for review without being permitted to execute it. Label that distinction clearly in the approved system so a draft entry is not mistaken for a fully authorized payment. Avoid creating live payment instructions merely as a training exercise.
Ask the second reviewer to state the unresolved condition, not just choose a reassuring label. They might confirm authority but require destination validation, or confirm the stored destination while questioning the new amount or purpose. That precision prevents partial confirmation from turning into unrestricted permission.
These are practical review principles, not a proposed replacement for your control framework. The organization should define who can release payments and how exceptions are handled. The article’s role is to help a recipient explain the evidence needed, without granting themselves powers they do not have.
Keep a confirmed decision within its scope
Confirmation should travel with the particular task, not become reusable permission for everything in the conversation. If the amount, purpose, recipient, or release timing changes afterward, identify that change for the responsible reviewer. Do not infer that approval of an earlier version covers a materially different action. The approved process determines whether renewed review is required.
When handing the task to a colleague, distinguish the confirmed version from any outstanding variation. A brief status such as “the normal supplier task is confirmed; the requested recipient change remains pending” is more useful than “the executive checked out.” It tells the next person what they may rely on and prevents reassurance about identity from becoming an accidental authorization.
If the requester corrects a genuine misunderstanding, retain the corrected scope in the authorized record. Verification is not a hunt for a predetermined fraud conclusion. A good review can end with a legitimate task completed through the usual route, provided the relevant changes and permissions were actually resolved.
A fictional urgent supplier request, worked through safely
Imagine a small design business receives an unexpected message presented as its chief executive. It refers to a real supplier task, insists that the work is confidential, and requests an urgent change before the next payment. This is an invented scenario. There is no real company, payment destination, message template, or measured loss attached to it.
The receiving employee first separates the legitimate background from the new action. The business does have a supplier task, but the incoming request proposes a change. Familiarity with the original task does not verify that change. The employee leaves release paused and records the proposed exception in the appropriate internal review channel.
Next, the employee reaches the executive through the established directory rather than the contact route in the message. They ask whether the specific urgent change was requested and whether the normal approval process still applies. They do not read sensitive banking information aloud to the person who sent the unexpected message.
In the first possible branch, the executive says they did not request the change. The employee reports that denial through the existing finance and security process, preserves the relevant evidence, and does not proceed. Their conclusion is about authorization: the claimed source did not approve the request. They have not established whether AI was involved.
In another branch, the executive confirms a genuine business need but has not approved any recipient change. Finance checks the supplier through its own established process. Until that check is complete, identity and general task confirmation do not release the payment. The worksheet makes the remaining gap visible rather than treating the genuine executive contact as a blanket approval.
In a third branch, the employee cannot reach the executive or the approved delegate. They record the request as unresolved and follow the ordinary escalation route. No invented countdown is allowed to create authority. The employee can communicate that the task is waiting for required confirmation without accusing an unavailable colleague or abandoning legitimate work.
Finally, imagine all required checks support a legitimate request. The employee uses the established workflow and independently validated record rather than reconstructing payment details from the original incoming message. The safe outcome is not “the unusual message looked convincing.” It is “the task, authorization, and destination passed the checks required for release.”
Compare those branches during training. The employee does not need a different media-detection technique for each outcome. The distinguishing evidence is the independent answer to the task and change. The same structure protects against ordinary impersonation, miscommunication, and AI-supported presentation without claiming that every interruption reveals a scam.
Do not confuse a genuine business relationship with this specific request
A long-standing supplier or familiar executive can still be the subject of an unverified message. The relationship tells you where to seek confirmation; it does not prove that the latest communication belongs to it. Use that existing relationship to move toward a trusted record rather than treating familiarity as a reason to bypass review.
Keep the business problem visible while you pause the risky change. If a genuine supplier deadline exists, the approved team may have a safe route for resolving it. Escalating through that route is different from allowing the unverified message to define a new recipient or exception. This distinction helps teams avoid a false choice between paying immediately and ignoring an important task entirely.
Do not import procedures from unrelated fraud situations. Investment-offer due diligence belongs to the AI investment scam guide, and hiring identity binding belongs to the deepfake interview guide. Here, the narrower object of review is an executive-authorized organizational transaction and any change it introduces.
If a payment or sensitive release already happened
Notify the responsible finance and security contacts promptly using established routes. State exactly what occurred: a payment was prepared, approved, submitted, or settled; a recipient was changed; or information was disclosed. Those are different events. Do not hide uncertainty by saying only that someone “clicked something.”
The FBI’s business email compromise guidance advises contacting the financial institution immediately when a transfer was sent. Use the institution’s legitimate contact process and explain the suspected unauthorized transaction. Ask what action remains possible; do not promise recall, reversal, or recovery. Reporting promptly is not a substitute for the provider’s actual assessment.
Preserve the original relevant communications and transaction reference in the approved incident location. Screenshots can assist a quick explanation, but keep original records where your security team can examine them. Do not alter or broadly distribute the evidence, reopen suspicious attachments, or confront an unknown sender to obtain an admission.
If an account or device may be involved, let the authorized security team assess that exposure. A payment incident and an account compromise may require different containment work. The article does not provide a technical eradication procedure, insurance determination, legal deadline, or jurisdiction-wide reporting rule. Follow appropriate organizational and official guidance for the situation.
Design an exception path before the urgent request arrives
Teams should know where to take an unusual request before they receive one. Identify an approved escalation contact, who can act if the normal approver is unavailable, and how the decision is recorded. A process that exists only as one employee’s informal habit can become unclear precisely when several people are rushed.
Make ordinary verification socially acceptable. A senior requester can model this by expecting confirmation rather than demanding that their apparent identity override controls. The desired habit is not distrust of colleagues; it is a consistent explanation of how the organization knows a sensitive action is authorized.
Rehearse the fictional supplier example without initiating a real transfer. Ask each role which evidence it can verify, what remains outside its authority, and where it would escalate an incomplete request. Do not conduct covert deception or send live scam-style messages as part of this article’s worksheet. A tabletop discussion is enough to reveal confusion about responsibilities.
Review the handoff afterward. Did the second reviewer receive verified facts or merely the first person’s confidence? Did anyone mistake urgency for an exception? Did the task retain a legitimate path to completion? Use those questions to clarify the process with its actual owners, not to blame an employee for failing to recognize a supposedly obvious artificial voice.
A short record makes the final decision understandable
Record the exact task, the independent route used, the authorized reviewer, the status of any change, and the release outcome. Refer to sensitive details inside the approved system rather than duplicating them across chats. Another authorized colleague should be able to understand why a task proceeded or stayed paused.
Use narrow language: requester independently confirmed, transaction authorized under the normal process, destination change unresolved, release paused, or suspected unauthorized action reported. Do not turn an incomplete media review into “the CEO is fake,” or a clean video result into “the payment is safe.” Each conclusion should match the evidence that supports it.
CEO fraud exploits the gap between apparent authority and verified permission. Closing that gap does not require perfect AI recognition. It requires a request that survives independent confirmation and the controls appropriate to its destination and consequences. Keep those checks separate, make uncertainty visible, and let the approved process—not the incoming presentation—decide what can happen next.
Questions about executive payment requests
Does CEO fraud always use AI?
No. Impersonation can use ordinary messages, spoofing, or misused accounts. AI may make presentation more convincing, but payment authorization remains the essential question.
Does reaching the real CEO confirm the payment destination?
Not automatically. Confirm the exact task and apply the organization’s separate destination-change and approval controls.
What if the request is confidential?
Use the approved confidential escalation process. Confidentiality does not require relying exclusively on the incoming sender’s verification route.
Can a convincing video call approve an unusual payment?
It should not replace the established authorization process. Media analysis and transaction approval answer different questions.
What should a second approver check?
Evaluate the required evidence independently under the approved division of responsibilities. Do not merely inherit the first reviewer’s confidence in the same incoming message.
Can a sent payment always be recovered?
No recovery is promised here. Contact the relevant institution and organizational incident owners promptly through legitimate channels to establish the available response.
Primary references and scope
- FBI: Business Email Compromise — request verification, changed payment procedures and financial-institution contact.
- FBI/IC3: Criminals Use Generative Artificial Intelligence to Facilitate Financial Fraud — dated December 2024 warning about generated media in fraud.
- FTC: Cybersecurity for Small Business — Business Email Imposters section and internal verification policies.
Sources checked on 14 October 2026. The supplier scenario and approval worksheet are original defensive teaching material. No real transaction, attack, recovery result, or legal compliance test is claimed.
Verify the request before acting.
A video check can support your review, but use an independent contact channel too.