What are the signs that a payment request is really an impersonation attempt?

What makes a payment request feel “real” but still unsafe?

A convincing impersonation attempt usually borrows the tone, timing, and habits of a legitimate counterpart while quietly changing one critical thing: the trust path. The request may look familiar, but the recipient, payment destination, or verification channel has shifted. That is why the strongest warning sign is not the wording alone, but any mismatch between the request and the normal process you already trust.

Impersonation works because the attacker wants you to act before you verify. In practice, that means the message is designed to create urgency, discourage independent verification, or move the transaction into a channel that is harder to scrutinise.

Which signals most often show a payment request is fake?

Unexpected urgency is a major signal, especially when the sender wants immediate action, secrecy, or a break from normal approval steps. A real business request can be time-sensitive, but it should still tolerate callback verification, internal approval, or a pause to confirm details.

Another strong signal is a request to move off the usual marketplace, invoice portal, ticketing system, or corporate payment flow. Impersonators often push for email-only, chat-only, or direct transfer handling because those channels make it easier to steer the recipient to the wrong account or suppress normal controls.

A changed recipient is especially important. If the payee name, bank details, wallet, or beneficiary account is new, altered, or “updated” at the last minute, treat that as a high-risk change until it has been confirmed through an independent channel. The same applies when a supposed support agent asks for another transfer, a refund movement, or a verification code, because legitimate support teams do not usually need the recipient to disclose an authentication code to complete a payment issue.

How should you verify before money leaves the organisation?

The safest pattern is to verify the person and the payment path separately. Confirm the sender through a known-good contact method, then confirm the payment destination through a second channel that was not used to deliver the request. If either step fails, the request should be treated as untrusted until it is rechecked.

For organisations that handle card or payment data, controls should also reinforce least privilege and step-up review around payment changes. PCI DSS v4.0 is relevant here because payment ecosystems need strong restriction on who can approve or alter payment instructions, not just who can initiate them. When impersonation is the threat, the key control question is whether a human can bypass the normal payment trail by persuasion alone.

Independent verification matters even more when the request claims to come from support, finance, procurement, or a senior executive. Those are the roles impersonators most often copy because they can plausibly ask for urgency and exception handling. If the request cannot survive a callback to a verified number, an internal approval check, or a second-person review, it should not be treated as legitimate.

Risk and Threat Considerations

Impersonation attempts are dangerous because they do not need to break the payment system itself, they only need to break trust in the request. Once a recipient accepts the false identity, the attacker can redirect funds, harvest a verification code, or create a second transfer under the cover of support activity.

Failure mechanism: The attacker abuses urgency, authority, and channel switching to bypass ordinary verification and get the target to approve a payment or reveal an authentication code.

Impact: Funds can be sent to the wrong recipient, the transaction may be hard to reverse, and the same deception pattern can be reused for follow-on fraud or account takeover.

Practitioner Guidance

What to verify: Treat the payment destination as the object to verify, not just the message content. A familiar name in an unfamiliar channel, or a familiar channel with a new beneficiary, is enough to require separate confirmation.

Decision rule: If the request includes urgency plus any change to recipient, payment method, or verification flow, move it into exception handling and verify out of band before any money or code is shared.

Practitioner takeaway: The best defence is not “spotting bad wording”, it is enforcing a process that makes identity changes and payment changes independently confirmable before execution.

Related resources from NHI Mgmt Group

• What are the signs that a vendor payment request may be fraudulent?
• What are the signs that an online retailer or payment request may be fraudulent?
• What are the signs that a payment scam is using social engineering rather than a normal customer request?
• What are the signs that a branded eSignature request is being used for impersonation rather than a real business workflow?