Payee Impersonation

What Payee Impersonation Is and How It Works

Payee impersonation is a classic payment fraud pattern: the attacker does not break the payment system itself, but abuses trust in a legitimate recipient’s identity, instructions, or banking details to divert funds.

It often begins with a believable pretext, such as a supplier update, payroll correction, or executive request. The fraud succeeds when the recipient of the request accepts the false change without checking it through an independent channel.

Common Variants of Payee Impersonation

Although the tactic is simple, the delivery methods vary. The most common forms are invoice redirection, bank-detail substitution, and forged payment instructions that arrive by email, messaging app, or a compromised portal.

The Pretexting Guide covers the social-engineering patterns behind impersonation, including vendor, auditor, and help desk abuse, which is the same trust exploitation used in many payee frauds.

In more technical environments, payment diversion can also ride on account compromise, mailbox takeover, or manipulated workflows. That is why Entra ID actor token flaw (CVE-2025-55241) is relevant as a reminder that impersonation can be amplified when attackers gain authoritative access to business communications or identity systems.

Why Payee Impersonation Is Dangerous

Payee impersonation is dangerous because it targets the point where fraud looks operationally routine. A single believable request can trigger a legitimate payment, and once the transfer clears, recovery is often difficult or impossible.

The impact is not limited to one lost invoice. Organisations may face direct financial loss, supplier disruption, reconciliation problems, chargeback or recall effort, and internal control failures if approval steps were bypassed or manipulated.

Because the fraud depends on trust rather than malware, it can evade security tools that focus on technical intrusion alone. The strongest defence is a payment process that assumes messages can be forged and treats changes to destination accounts as high-risk events.

How Organisations Reduce Exposure to Payee Fraud

Exposure usually concentrates in payment workflows that allow bank-detail changes, emergency approvals, or exceptions to normal verification. The practical question is not whether a request looks authentic, but whether the organisation has a second path to validate it independently.

RFC 8693: OAuth 2.0 Token Exchange is about digital delegation, not payments, but it illustrates a useful principle: when one party acts on behalf of another, the handoff must be explicit and controlled. Payment teams should apply the same mindset to bank-detail changes and recipient instructions.

Authoritative security guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls supports the underlying control pattern through access control, auditability, and procedural safeguards around sensitive business actions. In practice, that means treating recipient changes as controlled events, not ordinary data edits.

Detection, Recovery, and Post-Incident Review

Detection often starts with behavioural clues: a new beneficiary account, an urgent request to skip approval, a change in communication style, or payment instructions that arrive outside the usual workflow. These are not proof on their own, but they are strong indicators that the request deserves escalation.

After an incident or near miss, review the full chain, not just the payment. Confirm which channel carried the request, whether the approver was deceived, whether email or collaboration accounts were compromised, and whether other supplier records were altered at the same time.

Where the fraud involved account compromise or email abuse, teams should also look for broader suspicious activity, such as mailbox rules, forwarded messages, deleted threads, or other signs that the attacker was shaping the approval path before the payment request was made.

Related resources from NHI Mgmt Group

• What is the difference between phishing and deepfake-based impersonation?
• How should security teams respond to deepfake impersonation of employees or executives?
• Who is accountable when a SAML implementation allows impersonation or outage?
• When should teams use impersonation instead of changing redirect URI settings?