Vendor Impersonation Fraud: How It Works and How to Stop It

The Fraud That Starts Before the Invoice Arrives

Vendor impersonation fraud is not a new phenomenon. Organizations have always faced the risk of someone claiming to be a supplier they are not. What has changed is the precision, the scale, and the sophistication of the deception — and the degree to which a threat once associated with unsophisticated schemes has evolved into one of the most technically and operationally advanced forms of payment fraud facing AP functions today.

According to the AFP's 2025 Payments Fraud and Control Survey, vendor impersonation was cited by 60% of respondents as a BEC tactic their organizations encountered in 2024 — making it the dominant form of business email compromise in the current fraud environment and marking a decisive shift away from the CEO fraud schemes that characterized earlier threat patterns. The target of choice has moved from the corner office to the vendor relationship: the trust that organizations extend to their established suppliers has become the primary attack surface.

This article addresses vendor impersonation fraud as a distinct threat category — one that encompasses email-based attacks but extends well beyond them. It covers the full range of impersonation methods, the stages at which attacks occur across the vendor lifecycle, the red flags that distinguish legitimate vendor communications from fraudulent ones, and the structural controls that are most effective in defending against them.

A note on scope: Vendor impersonation fraud overlaps with other threats in this series. When the attack is delivered by email — through a spoofed domain, a lookalike address, or a compromised vendor account — the delivery mechanism is BEC, addressed in the preceding article. When the impersonation succeeds in generating a fraudulent banking information change, the outcome is a phony bank account change scam, addressed in the article that follows. This article focuses on the impersonation itself: who the attackers pretend to be, how they establish fraudulent credibility, and what controls interrupt the attack before either of those outcomes occurs.

What Vendor Impersonation Fraud Is

Vendor impersonation fraud occurs when an external actor falsely presents themselves as a legitimate vendor — existing or prospective — to induce an organization to make a payment, release sensitive information, or alter vendor records in ways that enable subsequent theft.

The definition encompasses a wide range of attack mechanics, unified by a single common element: the attacker's primary tool is assumed identity, not technical intrusion. They do not need to breach a firewall or compromise a system. They need an AP function to believe, long enough to act, that they are dealing with a vendor they know and trust.

This distinguishes vendor impersonation from purely technical fraud and explains why it remains so persistently effective. Organizations have invested heavily in technical defenses — email security tools, endpoint protection, network monitoring — but have often invested far less in the procedural and structural controls that address the trust exploitation at the heart of impersonation.

The Three Attack Scenarios

Vendor impersonation fraud occurs in three distinct phases of the vendor relationship, each with its own mechanics and controls implications.

Scenario One: Impersonating an Established Vendor

The most common and immediately costly form of vendor impersonation targets an existing vendor relationship. The attacker identifies a supplier that has a regular, high-value payment history with the target organization, then contacts the AP function — by email, phone, or written correspondence — posing as that vendor and requesting a change to payment details.

The attack succeeds through a combination of social engineering and, in many cases, supporting documentation that appears legitimate. In the Milwaukee case — in which fraudsters targeted the City of Milwaukee's payment to a construction contractor working on a $38 million library project — "the fraudster's email was designed to appear almost exactly as a legitimate email from the vendor," and a forged bank verification letter was provided as supporting documentation. The city's standard security measure required a bank letter to validate account changes, but the fraudsters successfully forged it. The only visible red flag was that the email had been sent from an unusual domain — .us instead of .com — a small but telling indicator that the city's process was not designed to catch. The funds were recovered only through swift law enforcement action, not through any control that stopped the payment before it left the organization.

The Milwaukee case is notable not because it is exceptional, but because it is representative. The same attack pattern — impersonated vendor, forged supporting documentation, absent independent verification, near-miss or actual loss — recurs across industries, geographies, and organization types. The controls that would have prevented it are well understood, straightforward, and largely procedural. Their absence is the problem.

Scenario Two: Fictitious Vendor Creation

The second form of vendor impersonation does not target an existing relationship; it creates a fraudulent one. The attacker establishes a fictitious vendor entity — sometimes a fully constructed shell company with a professional-looking website, registered business address, and fabricated tax identification number — and presents it to the AP function as a legitimate new supplier.

Fraudsters create fake businesses complete with false tax IDs, illegitimate bank accounts, and convincing, professional-looking websites. AP teams may onboard these entities without sufficient due diligence, allowing fictitious vendors to slip through.

Once onboarded, the fictitious vendor submits invoices for goods or services that were never delivered. In the external impersonation variant, the attacker is entirely outside the organization. In the internal variant — the ghost vendor scheme — an employee with access to the vendor master creates the fictitious record themselves, often mimicking the name of a legitimate supplier with a slight variation that evades casual review. Ghost vendor schemes are addressed more fully in the Internal Payment Fraud article; what matters here is that the onboarding controls for new vendors are the first and most important defense against both external and internal fictitious vendor fraud.

Scenario Three: Supply Chain Infiltration

The most sophisticated form of vendor impersonation occurs at the supply chain level: an attacker does not merely claim to be a vendor; they insert themselves into an actual ongoing business relationship at precisely the moment a payment is expected. This is the Vendor Email Compromise model described in the preceding BEC article — the attacker has compromised an actual vendor's email account and is operating from within a genuine correspondence thread. But supply chain infiltration can also occur through non-email channels: fraudulent representatives attending vendor meetings, spoofed phone numbers that appear in caller ID as a vendor's main line or coordinated multi-channel attacks that use a combination of email, phone, and documentation to reinforce each other's apparent legitimacy.

After monitoring over 1,400 organizations over twelve months, email security researchers found that nearly half of all vendor scam emails triggered employee interaction — employees opened, replied to, or forwarded the fraudulent message. In large enterprises, where employees cannot know the nuances of every vendor's operations or correspondence style, this engagement rate reached 72.3%.

How Attackers Prepare: The Reconnaissance Phase

Understanding that vendor impersonation attacks succeed through assumed credibility changes the prevention calculus significantly. Effective impersonation requires preparation, and that preparation leaves traces — if organizations know where to look.

Before executing a vendor impersonation attack, sophisticated actors conduct targeted research on the target organization and the vendor being impersonated. Scammers can harvest data from individual social media profiles, corporate websites, and even conference listings to craft convincing personas. They identify which vendors have large, regular payment relationships. They study invoice formats, payment terms, and communication cadences. They research the names and roles of AP staff. They look for moments in the payment cycle when a change request would be least likely to trigger scrutiny — end of quarter, fiscal year close, executive travel — and time their approach accordingly.

This reconnaissance is enabled, to a significant degree, by the public information organizations routinely make available. Vendor lists disclosed in public procurement records. Contractor names visible in project announcements. Payment terms discussed in annual reports. Finance staff identified on LinkedIn. None of this information is secret; much of it is required to be public. But its aggregate effect is to give a patient, methodical attacker a detailed operational map of an organization's payment relationships.

The implication for prevention is not that organizations should restrict all public information — that is impractical and often legally impossible. It is that the payment controls must be robust enough to withstand attacks built on detailed knowledge of the organization's own processes. The assumption that fraud will announce itself through obvious implausibility is not a safe assumption when the attacker has done their homework.

Red Flags: What Legitimate Vendor Communications Don't Do

Detection and prevention are different disciplines, but in vendor impersonation fraud they intersect usefully in the identification of behavioral indicators that distinguish fraudulent contact from legitimate vendor communication. The following patterns, individually or in combination, warrant mandatory independent verification before any action is taken.

A request to change banking information, mailing address, or primary contact details, arriving unsolicited and outside the vendor's normal communication pattern, is the single highest-risk indicator. Legitimate vendors occasionally need to update their information; legitimate vendors do not, in general, treat the process as urgent or confidential. Urgency, secrecy, and pressure to process the change before the next payment cycle are behavioral signatures of fraud, not of routine vendor administration.

Supporting documentation provided with a change request — bank letters, letterhead communications, voided checks — should increase scrutiny, not reduce it. The Milwaukee case established clearly that forged documentation is a standard element of the impersonation playbook. Documentation confirms that something was submitted; it does not confirm that the submission is legitimate.

An email domain that does not exactly match the vendor's established domain, even in minor respects — a hyphen, a TLD change from .com to .us or .net, a character substitution — is a red flag in any communication requesting payment action. This is distinct from the VEC scenario in which the attacker is using the vendor's actual compromised account; in the spoofed-domain variant, the mismatch is detectable by anyone who looks. The problem is that, under the pressure of routine operations, people often do not look.

Requests that arrive during high-pressure periods — end of quarter, fiscal year close, holidays, executive travel — should be treated with heightened caution, not expedited. Fraud actors deliberately time impersonation attempts to coincide with periods when verification is most likely to be skipped.

The Vendor Lifecycle as a Control Surface

Vendor impersonation can be attempted at every stage of the vendor relationship. An effective defense addresses each stage as a distinct control point.

At Onboarding. The new vendor onboarding process is both the point of greatest exposure for fictitious vendor fraud and the moment when the most comprehensive verification is possible. Before a vendor is entered into the master file and authorized to receive payment, the organization should independently confirm the vendor's legal identity, business registration, tax identification, and banking information — through sources it controls, not through documents the vendor submits alone.

This means verifying TIN against IRS records, confirming business registration through state-level databases, and validating banking information through a direct, independently initiated contact with the vendor — not through the contact information on the onboarding form. Third-party platforms provide the infrastructure for this process: automated TIN verification, bank account ownership validation, OFAC and sanctions screening, and secure vendor portal submissions that create a documented, auditable verification chain for every new vendor record.

Professional training programs equip AP staff with the specific knowledge and procedural frameworks for secure vendor onboarding — the practical competency that turns policy into consistent practice. In a threat environment where fictitious vendor fraud and supply chain impersonation are increasingly sophisticated, that professional-level knowledge is a material fraud risk reduction.

At Banking Information Change. This is the highest-risk moment in the ongoing vendor relationship and the most common point of attack for established-vendor impersonation schemes. The protocol for handling banking information change requests should be explicit, mandatory, and enforced without exception: every change request triggers an independent verification through a separately maintained contact channel before the change is processed. This control is covered in depth in the Phony Bank Account Change Scams article; the key point here is that the same verification discipline that applies at onboarding must apply equally — and with equal rigor — to every subsequent change request.

During Ongoing Payments. Periodic review of the active vendor master file for anomalies — duplicate addresses, duplicate account numbers across different vendor records, recently changed banking details that have not been re-verified, inactive vendors that have suddenly submitted invoices — is a detection control that can identify fraudulent vendor records that evaded initial screening. The vendor master should not be a static file that grows without review; it should be monitored as the dynamic, fraud-relevant data set it is.

Prevention: The Control Architecture

Effective vendor impersonation fraud prevention requires layered controls addressing identity, process, and technology. No single control is sufficient; the case record consistently shows that fraud succeeds when one layer is absent or bypassed.

Independent Vendor Identity Verification. The identity of every new vendor — and any vendor requesting changes to established records — should be confirmed through independently sourced information. Business entity verification (confirming registration status, ownership, and address against state and federal databases), TIN verification against IRS records, and bank account ownership verification against the actual financial institution are the foundational verification steps. Vendor-submitted documentation — W-9 forms, voided checks, bank letters — is a starting point for verification, not a substitute for it.

Secure Vendor Portals. The channel through which vendors submit their information matters as much as the information itself. When banking details, tax information, and contact updates are submitted through a secure, authenticated vendor portal — rather than via email, fax, or phone — the attack surface for impersonation is materially reduced. Email can be spoofed; a secure portal with authenticated vendor access cannot be as easily compromised. VendorInfo's vendor portal model addresses this directly: vendors submit and update their information through a controlled environment, and the organization maintains a documented audit trail of every submission, verification, and change.

Mandatory Out-of-Band Verification for All Change Requests. Any request to change vendor banking information, regardless of the channel through which it arrives, must trigger a mandatory callback to a contact number independently maintained in the vendor master — not to a number provided in the change request. This single procedural control is the most consistently effective defense against the established-vendor impersonation scenario. Its absence is the most consistently documented gap in organizations that suffer vendor payment losses.

Segregation of Vendor Master Access. The employee or team responsible for maintaining vendor master records should not have payment initiation or approval authority. The employee who can add or modify a vendor record and the employee who can initiate a payment to that vendor should be different people operating under separate authorization. Where this segregation exists, fictitious vendor fraud and payment diversion require active collusion — a significantly higher bar for a fraud actor to clear than a single point of compromise.

Three-Way Invoice Matching. Invoices should be matched against both the originating purchase order and the receiving documentation (proof of goods or services delivered) before payment is approved. This control does not prevent every form of vendor impersonation fraud, but it eliminates the simplest fictitious-invoice schemes and creates the documentation discipline that makes anomalies visible.

Vendor Authentication Awareness Training. AP staff should be specifically trained in the impersonation indicators described above — not generic phishing awareness, but vendor-specific social engineering patterns: change requests from unfamiliar channels, urgency framing, forged documentation, and the particular danger of requests that arrive during high-pressure operational periods. Crucially, training must include explicit cultural permission — and clear management expectation — to slow down and verify any unusual vendor communication, regardless of apparent urgency. The organizational norm that a staff member who delays processing a suspicious change request is exercising good judgment, not creating obstacles, must be established from leadership and reinforced consistently.

Recovery: What to Do When Impersonation Succeeds

Even well-controlled organizations will occasionally face vendor impersonation attempts that make it further than they should. The outcome of those attempts depends significantly on how quickly the organization responds.

When a fraudulent vendor payment is suspected, the first call is to the originating financial institution — before any other action. Wire recall and ACH reversal requests are time-sensitive; the window for recovery narrows rapidly as funds move through multiple accounts. Simultaneous notification to the bank fraud team and the organization's senior financial leadership is appropriate. Law enforcement reporting — through the FBI's IC3 at ic3.gov — should follow within 24 hours and may be essential to activating financial institution cooperation for fund recovery.

Milwaukee's recovery of nearly the full $460,866 fraudulent payment was exceptional by the standards of the fraud case record — officials said the funds were traced and recovered before being released, a result credited to detectives in the Milwaukee police Financial Crimes unit working to trace the fraudulent transaction. Recovery at this rate is not typical; it reflects both the speed of the response and a degree of operational fortune. Most vendor payment fraud that makes it to settlement is not recovered. The controls that prevent the fraud from completing are the practical defense; recovery is the exception, not the plan.

The Convergence of Vendor Fraud and AI

The threat landscape for vendor impersonation is being reshaped by the same AI tools addressed in depth in the AI-Driven Payment Fraud article later in this series. Generative AI now enables attackers to produce impersonation communications — emails, letters, even phone scripts — with a fluency and vendor-specific accuracy that was previously achievable only through extended human reconnaissance. Voice cloning technology can replicate the voice of a known vendor representative from a small audio sample. Deepfake video, as demonstrated in the 2024 Arup case involving a $25 million loss, can simulate a live video call with apparent executives convincing enough to authorize major transactions.

The significance for vendor impersonation is not that these tools create entirely new attack types — they do not. They amplify existing attack vectors, making them more convincing, more scalable, and harder to detect through the human judgment that has historically served as a last-resort check. The procedural controls addressed in this article — independent verification, out-of-band callbacks, segregation of duties — are not made obsolete by AI. They become more important. When no communication channel can be treated as inherently trustworthy, the verification process must be designed to confirm vendor identity and banking information through independent, cross-referenced sources — not through the apparent authenticity of any single message, however convincing.

The Institutional Response: Policy, Process, and Professional Standards

Vendor impersonation fraud is, ultimately, a failure of the vendor information management process. Organizations that maintain complete, verified, regularly reviewed vendor data — and that have built the procedural controls to manage changes to that data rigorously — are materially more resistant to this category of fraud than those that do not.

That is not a conclusion about technology or tools. It is a conclusion about organizational practice. The vendor master file is a fraud-critical asset. The process by which vendor information is collected, verified, updated, and protected is a fraud-critical process. The professionals who manage that process — AP and procurement staff responsible for vendor onboarding and information management — are performing a function that has direct and material implications for the organization's financial security.

Treating vendor information management as a compliance checkbox or an administrative back-office function is precisely the posture that fraud actors depend on. Treating it as the control function it is — investing in the tools, the training, and the professional standards that rigorous management requires — is the organizational response that materially reduces exposure.