What are the signs that a vendor payment request may be part of a third-party reconnaissance scam?

Common warning signs include a newly registered domain, generic language about an outstanding invoice, pressure to switch to ACH or wire payments, and claims that the vendor cannot access its own accounting systems. Another indicator is the use of copied CFO or staff accounts to add credibility. When several of these appear together, treat the request as high risk.

How third-party reconnaissance scams signal themselves

A vendor payment scam usually starts by creating urgency and lowering scrutiny. The attacker wants the AP or finance team to act on the email thread itself, not on independently verified vendor records, because that is how the payment path gets redirected before anyone compares bank details, invoice history, or sender legitimacy.

One of the strongest indicators is a mismatch between the message and the vendor relationship you already know. A request that arrives from a newly registered domain, a lookalike mailbox, or a copied executive account is trying to borrow trust from the real relationship while bypassing normal verification.

Language also matters. Third-party reconnaissance scams often use generic invoice wording, vague references to “outstanding payment,” or a change request that avoids specifics an actual vendor would know. The less the message depends on shared context, the more likely it is trying to see whether your team will fill in the blanks for it.

Why the payment method change is the real warning sign

The most dangerous part of these scams is not the invoice itself, it is the pressure to change how money moves. Requests to switch from an established payment route to ACH, wire, or another fast-transfer method are attractive to attackers because those channels are harder to reverse once the transfer clears.

Claims that the vendor “cannot access its own accounting systems” are also a classic social-engineering pivot. That story is designed to make a payment reroute seem operationally necessary, when in reality it is often an excuse to keep the fraud thread alive long enough for a transfer to be approved.

Another common sign is credibility stacking through copied staff, CFO, or assistant accounts. When the request appears to come from multiple people, the scam is no longer just asking for payment, it is trying to manufacture consensus and exploit approval habits inside the finance workflow.

What a finance team should compare before paying

The practical test is whether the request matches the vendor’s normal operating pattern. Compare the sender domain, bank instructions, invoice numbering, prior payment channel, and the tone of the request against the last verified record, not against the current email chain. A single inconsistency may be explainable; several together should be treated as an authentication failure for the request itself.

Teams should also separate invoice validation from payment authorization. A request can look administratively plausible and still be fraudulent if the bank account, contact trail, or communication path has been changed without out-of-band confirmation. For recurring vendors, payment changes should be verified through a known channel already on file, not through the email thread that requested the change.

At scale, the most useful control is a predictable exception process. If a payment request combines urgency, banking changes, and a story about inaccessible systems, it should leave the normal workflow and enter a manual verification step before any release is approved. That is especially important when copied executives are used to accelerate the decision.

Risk and Threat Considerations

These scams work because they exploit trust in routine vendor workflows, then compress time so that staff approve a transfer before they validate the request. The exposure is financial loss, but the broader risk is that one fraudulent change can alter payment instructions across future invoices if the account master is updated incorrectly.

Failure mechanism: The attacker impersonates or piggybacks on a trusted vendor relationship, then uses urgency, domain lookalikes, and copied accounts to bypass normal verification and redirect funds.

Impact: A successful request can cause direct payment loss, disputed bookkeeping, and follow-on fraud if the false banking details become the standing vendor record.

Standards & Framework Alignment

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

OWASP Non-Human Identity Top 10, MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-02 — Secret Leakage	Vendor-payment scams often seek or abuse payment credentials and account access paths.
	NHI-05 — Overprivileged NHI	Copied or abused accounts can widen the fraud blast radius in vendor workflows.
	NHI-10 — Human Use of NHI	Human-driven payment requests may exploit non-human accounts or delegated access paths.
Recommendation — Verify payment-change requests through a separate channel before exposing or updating account secrets. Limit who can change vendor payment details and require least-privilege approval. Restrict humans from using automated accounts to alter vendor payment instructions.
MITRE ATT&CK	T1585 — Establish Accounts	Fraudsters often create lookalike identities and mailboxes to impersonate vendors.
	T1656 — Impersonation	Copied CFO or staff accounts are used to add authority to fraudulent payment requests.
Recommendation — Hunt for newly created lookalike accounts and domains tied to payment requests. Validate requester identity out of band when executive or staff impersonation is suspected.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Payment scams often depend on stolen or misused authentication material and account changes.
	AC-6 — Least Privilege	Payment-detail changes should be restricted to minimal authorized roles.
	AU-6 — Audit Review, Analysis, and Reporting	Reviewing payment-change logs helps detect suspicious rerouting and impersonation.
Recommendation — Rotate and protect authenticator material used to access vendor and finance systems. Restrict vendor payment edits to the smallest set of approved roles. Review vendor master-change logs for unusual banking or contact edits.
CIS Controls v8	CIS-5 — Account Management	Vendor payment scams frequently abuse account changes and identity trust.
Recommendation — Require strong controls around vendor account creation, change, and review.
OWASP API Security Top 10	API5 — Broken Function Level Authorization	Unauthorized payment-detail changes are an authorization failure in finance workflows.
Recommendation — Enforce function-level authorization for vendor master and payment edits.

Practitioner Guidance

What to verify: Treat any payment change as untrusted until the vendor’s banking details and contact request are confirmed through a separate known-good channel. If the request mentions inaccessible systems, ask for a callback or previously established contact path before allowing any change to the payment destination.

Decision rule: If the message combines a new domain, payment reroute, and copied authority figures, pause the payment and route it for manual review. The threshold for escalation should be lower when the request asks for a faster settlement method or tries to override an established process.

Practitioner takeaway: The safest habit is to verify the payment instruction, not the story around it, because reconnaissance scams are built to make the story feel urgent while the destination account quietly changes.