Vendor bank account change requests: the fraud vector nobody talks about

Why vendor bank account changes are the highest-risk event in accounts payable

Every AP department processes bank account updates. Vendors switch banks. Companies restructure. Acquisitions close. These are normal business events, and that's precisely what makes them dangerous.

Fraudsters don't need to create a fake vendor from scratch. They don't need to generate convincing invoices or build elaborate cover stories. They only need to intercept — or convincingly impersonate — a single communication: the bank account change request. Once the new account details are entered into your vendor master file, every future payment flows directly to the attacker.

The 2025 AFP Payments Fraud and Control Survey found that 79% of organizations experienced actual or attempted payment fraud in 2024. Among those incidents, vendor impersonation was cited by 60% of respondents as a primary fraud vector, with 63% identifying business email compromise as their top avenue for fraud attempts. The common thread in both categories is the manipulation of payment routing — and that starts with a bank account change.

What makes this particularly devastating is the lag time. Unlike a single fraudulent invoice that triggers one bad payment, a compromised vendor master record can redirect multiple payments over weeks or months before anyone notices. The average U.S. company loses approximately $300,000 per year to vendor fraud, according to industry estimates, and bank account change fraud accounts for a significant portion of that figure.

How fraudsters exploit the vendor bank account change process

The attack methodology has become disturbingly refined. Here are the three most common approaches finance teams encounter today.

Compromised vendor email accounts

This is the most dangerous variant because the communication comes from the vendor's actual email address. Attackers gain access to a vendor's email system — often through phishing or credential stuffing — and monitor ongoing payment conversations. When the timing is right, they send a bank account change request from the real email account, sometimes even replying within an existing email thread. Your AP team sees a familiar sender, familiar context, and a routine request. There's nothing to flag.

This is known as Vendor Email Compromise (VEC), and it's a more targeted evolution of standard BEC. According to research from Abnormal AI, VEC attacks are harder to detect than traditional BEC because they bypass every email-based security filter — the sender is legitimate.

Spoofed email with social engineering

In this variant, attackers create email addresses that closely mimic the vendor's domain — think accounts@supp1ier.com instead of accounts@supplier.com. They pair this with detailed knowledge of the business relationship: correct contact names, recent invoice numbers, and specific contract terms. The email often includes urgency framing: “We've changed banks due to an acquisition” or “Our previous account is under audit — please update immediately.”

AP clerks processing dozens of requests per week rarely scrutinize domain names character by character. One moment of inattention is all it takes.

Intercepted postal or PDF communications

Some organizations still accept bank account changes via mailed letters or PDF attachments — assuming paper-based communication is more secure. Attackers exploit this by sending forged letters on stolen or recreated vendor letterhead, complete with updated bank details. In one documented case, a fraudster even included a follow-up phone number that routed to a burner phone staffed by a confederate posing as the vendor's accounts receivable team.

The verification gap that exists in most AP departments

Here's the uncomfortable truth: most AP departments have some form of bank account change verification process. The problem is that these processes rely on the same communication channel the attacker has already compromised.

A typical verification workflow looks like this: AP receives a bank account change request via email. AP sends a confirmation email back to the vendor. The vendor “confirms” the change. AP updates the master file. If the attacker controls the email account — or has inserted themselves into the email thread — they simply confirm their own fraudulent request. The verification step is theater.

Even organizations that require phone verification often fall short. AP teams call the number provided in the change request email (which the attacker controls) rather than independently looking up the vendor's phone number from original onboarding records. According to the AFP survey, only a minority of organizations use out-of-band verification — meaning they contact the vendor through a completely separate, pre-established channel — for bank account changes.

The result is a verification process that feels rigorous but provides almost no actual protection against a determined attacker. Read how BEC plays out against AP teams.

A step-by-step verification protocol that actually works

If your organization processes vendor bank account changes — and every organization does — you need a protocol that assumes the request could be fraudulent, regardless of how legitimate it appears. Here's what that looks like in practice.

1. Establish a verification contact during vendor onboarding. When you first onboard a vendor, collect a designated verification contact name and phone number that is independent of any future email communication. Store this in your vendor master file. This becomes your out-of-band verification channel — a contact you call if anything changes. Never use contact details provided in a change request to verify that same change request.
2. Require dual-channel confirmation for every bank account change.No bank account change should be processed based on a single communication, regardless of the source. Require confirmation through two independent channels: the original request (email, letter, portal submission) plus a phone call to the pre-established verification contact. If the vendor can't be reached through the original onboarding contact, the change request waits.
3. Implement a mandatory holding period. Introduce a 5-to-10 business day holding period between receiving a bank account change request and activating the new account details. During this period, continue paying to the existing account on file. This creates a window for the real vendor to notice if a fraudulent change is in progress — and for your team to complete thorough verification without time pressure. Fraudsters rely on urgency. Remove the urgency, and you remove half their leverage.
4. Require senior approval for all vendor master file changes. Bank account changes in the vendor master file should require approval from a manager or controller — not just the AP clerk processing the request. Segregation of duties is a foundational internal control, but many organizations only apply it to payment approvals, not to the vendor data changes that determine where payments go. This is a critical gap. See common AP fraud schemes.
5. Audit vendor master file changes monthly.Run a monthly report of all changes made to vendor bank account details. Cross-reference these against documented, verified change requests. Any change that can't be traced back to a verified request should trigger an immediate investigation. This is your safety net — the control that catches what your front-line process missed.

Why manual verification alone is no longer sufficient

The protocol above is strong, but it depends on humans following it correctly every single time. In a busy AP department processing hundreds of invoices and dozens of vendor updates per month, perfect compliance is unrealistic.

According to the 2025 AFP survey, only 22% of organizations that experienced payment fraud in 2024 were able to recover 75% or more of the lost funds — a sharp decline from 41% the prior year. Recovery is getting harder because the money moves faster. Once a fraudulent wire clears, it's typically layered through multiple accounts within hours.

This is why leading finance teams are moving toward automated pre-payment verification. Instead of relying solely on human judgment and manual callbacks, automated systems cross-reference bank account change requests against multiple data signals: historical payment patterns, known vendor account details, domain authentication records, and behavioral anomaly indicators. When something doesn't match, the payment is held automatically — before the money moves.

The shift from “detect and recover” to “verify and prevent” is the most important evolution happening in AP fraud control today. The organizations that make this shift will stop losing money to vendor bank account fraud. The ones that don't will continue to rely on a recovery process that succeeds less than a quarter of the time. CFO-focused payment fraud prevention and control themes.

The real cost of getting this wrong

Vendor bank account change fraud doesn't just cost you the amount of the fraudulent payment. It costs you the time spent investigating — typically 200+ staff hours for a significant incident. It costs you the disruption to your vendor relationship when the real vendor doesn't get paid. It costs you the potential insurance premium increase, the audit findings, and — for accounting firms managing client payments — the reputational damage that can end client relationships permanently.

The 2026 NACHA rule updates are also raising the stakes. With enhanced requirements for ACH payment validation and fraud monitoring taking effect, organizations that lack documented verification controls for vendor bank detail changes face increased regulatory exposure.

Finance leaders who treat bank account change verification as a clerical task are mispricing the risk. This is a control that sits directly between your company's cash and a fraud ring's offshore account. It deserves the same rigor you apply to signing authority and wire approval limits.

What to do this week

If you're a CFO, Controller, or AP Director reading this, here are three things you can do before Friday:

• First, pull a report of every vendor bank account change processed in the last 90 days. Verify that each one has a documented, out-of-band confirmation. If any don't, investigate immediately.
• Second, update your vendor onboarding process to collect a designated verification contact and phone number — separate from the primary business contact. Make this a required field.
• Third, implement a mandatory holding period for all bank account changes. Even 5 business days dramatically reduces your exposure.

These are manual controls, and they work. But if your payment volume is growing — or if you're an accounting firm managing bank detail changes across dozens of clients — you'll hit the ceiling of what manual processes can handle. That's when automated pre-payment verification becomes not just helpful, but necessary.