What are the signs that a vendor payment request may be fraudulent?

What makes a payment request look suspicious rather than merely unusual?

A fraudulent vendor payment request usually creates friction in the normal approval path. The request may arrive from a lookalike domain, reuse familiar branding but change the destination account, or pressure staff to act before they verify the request through established vendor contacts. What matters is not one isolated clue, but whether the message tries to bypass the controls that normally protect invoice and banking changes.

That distinction matters because business email compromise and invoice redirection rely on trust shortcuts, not technical sophistication alone. A request that appears routine can still be fraudulent if it changes payment instructions, avoids prior channels, or depends on urgency to suppress checking. In practice, many finance and procurement teams first notice the anomaly only after a payment change has already been attempted, not during the initial deception.

How fraudsters manipulate the vendor payment workflow

Fraudulent payment requests work because payment operations depend on repeatable trust signals: known contacts, familiar invoice formats, and predictable turnaround times. An attacker or impersonator exploits those habits by inserting a small but consequential change, such as a new bank account, a revised remittance address, or a request to keep the change confidential. Even when the message is polished, the content often reveals pressure to override verification.

The practical test is whether the request preserves the vendor relationship in a normal way. Legitimate changes usually come through a known process, with confirmation from an independently trusted channel and documentation that can be reconciled against prior records. Fraudulent requests often break that pattern in one or more ways:

• They originate from a newly registered or slightly altered domain that resembles the real vendor.
• They redirect payment to a new account without a valid business reason already documented.
• They intensify urgency, especially around overdue invoices, tax deadlines, or end-of-month payment runs.
• They avoid the usual proof points, such as attachments, links, or the expected contact history.
• They reuse signatures, formatting, or thread history to lower suspicion and appear routine.

For teams that handle high-volume payments, the key issue is not whether a request looks professional, but whether it can be verified outside the message itself. A request that can only be “validated” by replying to the same email is already a control weakness. That is why thread hijacking is so effective: it borrows an existing conversation and makes the fake request feel like a legitimate continuation.

Where organisations have strong vendor master data controls, the warning signs are often easier to see because payment changes are rare and traceable. Where those controls are weak, the same request may look normal until reconciliation exposes the mismatch.

Where legitimate exceptions blur the line

Tighter verification often adds friction, requiring finance teams to balance speed against the risk of paying the wrong party.

Not every payment change is fraudulent. Vendors do change banks, legal entities merge, and contact details evolve. The difference is that legitimate changes can usually be supported through a known validation path and do not depend on secrecy, hurry, or informal approval. Industry consensus is clear that process deviation is the stronger signal than writing style alone.

Edge cases matter most when a vendor is genuinely urgent, newly onboarded, or operating through a procurement intermediary. In those situations, the request may be real but still require extra scrutiny because the same conditions that make a request inconvenient for staff also make it attractive to fraudsters. A request routed through a legitimate thread can still be hostile if the attacker has already compromised the conversation.

External indicators help, but they should not be treated as proof on their own. A lookalike domain may be obvious in one case and subtle in another; a polished signature block may be copied from publicly available material; a missing attachment may simply reflect a different business process. The decisive question is whether the request can be independently verified against the vendor’s known record and out-of-band contact method.

Risk and Threat Considerations

Fraudulent vendor payment requests are a payment diversion and social engineering risk. They target the trust relationships around invoice processing, vendor master data, and bank-detail changes, where a single accepted change can redirect funds before the error is detected.

Failure mechanism: The attack succeeds when staff rely on the message content, reply thread, or familiar branding instead of an independent verification path. Lookalike domains, thread hijacking, and urgency cues reduce scrutiny long enough for an account change or payment instruction to be accepted.

Impact: The immediate consequence is misdirected payment. Secondary impact can include recovery effort, vendor relationship damage, accounting reconciliation issues, and broader exposure of payment workflows to repeat abuse.

Practitioner Guidance

What to prioritise: Treat any vendor request that changes bank details, remittance instructions, or payee identity as a verification event, not a routine service request. The strongest evidence is an independent callback or known contact method that predates the email.

What to verify: Confirm whether the request aligns with the vendor’s established change process, whether the domain and sender history match prior correspondence, and whether any pressure to bypass review is justified by a documented business reason. If the request only validates inside the same thread, escalate it.

Common mistake: Teams often focus on spelling errors or obvious phishing cues and miss the operational clue that matters most: a payment change request that arrives outside the normal control path. That is the point where fraud becomes materially easier to execute.

Practitioner takeaway: The best fraud detection question is not “does this email look real?” but “can this payment change be confirmed without trusting the email that requested it?”

Related resources from NHI Mgmt Group

• Who is accountable when a payment is redirected through a fraudulent email request?
• Who is accountable when a fraudulent payment or vendor change slips through email workflows?
• What are the signs that an RFQ request is likely fraudulent?
• Who is accountable when a customer is tricked into authorising a fraudulent payment?