Bank Account Change Scams: The Last Line — and the Most Broken One

The Simplest Fraud with the Highest Body Count

Of all the payment fraud schemes that confront accounts payable and treasury functions, phony bank account change scams are, mechanically, among the simplest. An attacker — posing as a vendor, an employee, or an internal colleague — requests a change to banking information on file. The change is processed without independent verification. The next payment goes to the attacker's account instead of the legitimate recipient. By the time anyone notices, the funds have moved and the window for recovery has largely closed.

There is nothing technically sophisticated about this attack. No network intrusion is required. No malware is deployed. No complex fraud infrastructure needs to be built. What is required is a gap — and in most organizations, that gap exists. The gap is the absence of a mandatory, documented, out-of-band verification protocol for every banking information change, enforced without exception.

The fraud case record on this point is remarkably consistent. Milwaukee's near-loss of $460,000 to vendor impersonation fraud revealed a critical gap: no secondary verification of bank account changes, and reliance on easily forged documentation. That description — no secondary verification, reliance on submitted documents — appears in incident after incident across industries, organization sizes, and geographies. The control failure is not obscure or technical. It is a missing step in a process that most organizations already know should be there.

This article addresses that gap directly: what phony bank account change scams are, how they work, why they succeed so consistently, and what the specific controls look like that prevent them. It also addresses the regulatory dimension — because the 2026 Nacha rule amendments have elevated these controls from best practice to compliance requirement for ACH originators — and the recovery question, because knowing what to do in the first 60 minutes after a fraudulent transfer is initiated matters as much as the controls that were supposed to prevent it.

What This Fraud Is — and Where It Lives in the Taxonomy

Bank account change scams occupy a specific position in the payment fraud taxonomy. In the preceding articles, we addressed business email compromise as the primary delivery mechanism through which these attacks are often initiated, and vendor impersonation as the identity fraud that gives the attacker their false standing to make the request. This article addresses the endpoint: the fraudulent banking information change itself, how it is executed, and how it is stopped.

The fraud takes three primary forms, each defined by who the attacker impersonates and which payment channel they target.

Vendor payment redirect. The most common and highest-dollar form. An attacker posing as an established vendor contacts the AP function and requests a change to the vendor's ACH routing and account number, or wire transfer beneficiary details, before a scheduled payment. If the change is processed, the next payment — which may be a large invoice payment accumulated over a billing cycle — goes to the attacker's account. The legitimate vendor, unaware any change was made, continues to expect payment. The fraud often surfaces only when the vendor follows up on an unpaid invoice, days or weeks after the money has moved.

Employee payroll diversion. An attacker — or, in the internal fraud variant, the employee themselves — submits a request to change direct deposit banking information in the payroll or HR system. Payroll diversion attacks targeting ACH deposits are a variant of BEC specifically identified in the 2026 Nacha rule amendments, and they share the same essential vulnerability: a banking change processed without independent verification of the requesting party's identity.

Internal payment diversion. This variant, addressed more fully in the Internal Payment Fraud article, involves an employee with access to the vendor master or payment system altering banking records to redirect payments to accounts they control. The mechanics are identical to the external attack; the attacker's advantage is insider access rather than social engineering. The control response is also identical: no banking change should be processed without an independent verification step that falls outside the control of the person making the change.

How the Attack Is Executed

Understanding the operational mechanics of a bank account change scam — not just its existence — is essential for designing controls that interrupt it at the right point.

Phase One: Selection and Research. The attacker identifies a target organization and, within that organization, a vendor relationship worth targeting. High-value, established vendors with regular payment schedules are preferred: a construction contractor on a large project, a major logistics supplier, a recurring professional services provider. The attacker researches the payment cycle to time the request for maximum impact — ideally just before a large payment is due. In many cases, this research is enabled by publicly available information: contract awards in municipal procurement records, vendor announcements on company websites, or payment terms visible in industry filings.

Phase Two: Contact and Credibility. The attacker contacts the AP or treasury function, typically by email but sometimes by phone or, in documented cases, by physical mail. The communication is designed to appear as routine administrative correspondence from the vendor: a notification of updated banking details, often framed as a bank account change due to a switch in financial institutions or a company restructuring. Supporting documentation — a bank letter on what appears to be institutional letterhead, a voided check, or a W-9 — is frequently included to give the request an air of completeness and legitimacy.

As the Milwaukee comptroller described it: "The fraudster's email was designed to appear almost exactly as a legitimate email from the vendor. A forged bank verification letter was provided as supporting documentation." The forged bank letter was specifically designed to satisfy the organization's existing verification requirement — evidence that the attacker had researched the target's process and built the fraud around its known controls.

Phase Three: Processing the Change. If the request is received by an AP function that processes banking changes without a mandatory independent verification step, the change is entered into the vendor master or treasury system. In many organizations, this happens faster than it should: payment run pressure, understaffed AP teams, and the apparent legitimacy of submitted documentation all contribute to changes being processed without the verification that would expose them.

Phase Four: Payment and Disappearance. The next scheduled payment to the affected vendor processes to the attacker's account. Wire transfers settle in hours; ACH credits typically within one to two business days. Once funds reach the attacker's account, they are moved quickly — often through a series of domestic and international transfers, cryptocurrency conversion, or peer-to-peer payment services that make tracing and recovery increasingly difficult with every passing hour.

Why the Control Fails: The Four Gaps

Banking change fraud succeeds not because the controls that prevent it are technically complex, but because of predictable, recurring gaps in how organizations manage this specific process.

Gap One: The absence of a mandatory verification protocol. The most consequential gap is the simplest: no formal, enforced requirement to independently verify every banking change request before processing it. In many organizations, banking changes are processed if the submitted documentation looks complete and the request appears to come from a recognizable source. This is not a verification protocol — it is an assumption of legitimacy dressed up as a process.

Gap Two: Verification by the wrong channel. Even when organizations do attempt to verify banking change requests, the verification is frequently inadequate because it uses the wrong channel. Replying to the email that submitted the change request to "confirm" the change — still a common practice — is not verification. If the attacker controls the email account, they will confirm the change themselves. The correct approach is to always call the vendor using a known phone number from the organization's own records — not the contact information provided in the request itself. The phone number used for verification must come from the organization's independently maintained vendor master file, not from the document or communication requesting the change.

Gap Three: Over-reliance on submitted documentation. Documentation accompanying a banking change request — bank letters, voided checks, W-9 forms — is not independent verification. It is evidence that something was submitted. As the Milwaukee case demonstrated, bank letters are forgeable. Voided checks can be fabricated. W-9 forms can be completed with any information the submitter chooses. Submitted documentation has a role in the verification process — it establishes what is being claimed — but it cannot substitute for independent confirmation that the claim is true.

Gap Four: No segregation between change authority and payment authority. When the same person who updates vendor banking information also has the authority to initiate or approve payments to that vendor, the entire fraud prevention architecture for banking changes depends on that single person's judgment and integrity. A single error in judgment — or a single compromised employee — is all that stands between the organization and a successful payment redirect. This is a structural vulnerability, not a behavioral one, and it cannot be addressed through training.

The Control Architecture: What Effective Prevention Requires

The controls that prevent bank account change fraud are procedural and structural. They do not require sophisticated technology. They do require consistent design, explicit policy, and enforced execution.

Mandatory Out-of-Band Verification — Every Time, No Exceptions

Every request to change vendor banking information, payroll direct deposit details, or any payment destination — regardless of the channel through which it arrives, regardless of the apparent legitimacy of the documentation provided, regardless of the urgency asserted — must trigger a mandatory independent verification before the change is processed.

The verification must be out-of-band: conducted through a channel separate from and independent of the channel used to submit the change request. Nacha's guidance is explicit: if a vendor calls to request a change to their routing and account information, use contact information contained in the organization's own internal database to contact the vendor via phone or email — not the contact information provided in the request. The same principle applies regardless of the channel: email request verified by phone call to a number from the vendor master; phone request verified by callback to a number from the vendor master; written request verified by both. The verification contact information must come from a source the attacker cannot contaminate.

This control is sometimes resisted on efficiency grounds: it slows down processing, it creates friction in vendor relationships, it adds steps to an already busy AP workflow. These are real operational costs. They are also the costs of the control that most consistently prevents the most damaging payment fraud that AP functions face. The fraud case record does not document organizations that had this protocol and lost money because of it. It documents, repeatedly, organizations that lacked it.

Secure Vendor Portals for Banking Information Management

The channel through which banking information is submitted and updated is itself a control variable. When vendors submit banking details through a secure, authenticated portal — rather than by email, fax, or phone — the attack surface for banking change fraud is materially reduced. A fraudster who cannot impersonate a vendor through the submission channel cannot initiate a change, regardless of how convincing their email looks.

VendorInfo addresses this directly. Its vendor portal platform enables vendors to submit and update banking information through a secure, authenticated environment, with automated bank account ownership verification — confirming not merely that an account exists, but that it is owned by the vendor entity on record — along with TIN verification, OFAC and sanctions screening, and comprehensive audit trails documenting every submission, verification action, and change. This architecture removes the manual handling of vendor banking information from the equation and replaces it with a controlled, verifiable process. The fraud actor who attempts a banking change through a platform with ownership verification faces an obstacle that forged letterhead cannot overcome: the account must actually belong to the vendor.

Bank Account Ownership Verification — Beyond Account Existence

Not all account validation is equal. Confirming that an account number exists and is open at the named financial institution is a necessary but insufficient control. It confirms that the attacker has opened or identified a real account; it does not confirm that the account belongs to the vendor. Account ownership verification — which confirms that the account is held in the name of the entity requesting the change — is the control that closes this gap.

Account ownership verification tools go beyond simple account validation and into Know Your Customer (KYC) identification, providing data about the account owner including name, address, and other identifying details. These tools are now widely available through vendor management platforms and third-party verification services, and their use is specifically encouraged by Nacha as a fraud prevention best practice.

Segregation of Duties: Separating Change Authority from Payment Authority

The employee or team authorized to enter or modify vendor banking information in the vendor master should not be the same employee or team authorized to initiate or approve payments to vendors. This segregation is a structural control: it means that a successful banking change fraud requires either that two separate employees both be deceived or compromised, or that the two functions actively collude. Both scenarios are significantly harder to achieve than compromising a single point of control.

Nacha's guidance on dual controls is explicit: dual control requires more than one individual to initiate a payment. A fraudster may be able to get past one individual, but will have difficulty tricking two. Dual control is often offered by financial institutions to their corporate customers, and may even be required.

Payment Hold Periods for New or Changed Banking Details

A payment freeze applied to any vendor record for which banking information has recently been changed — typically 24 to 72 hours — creates a window for detection before funds leave the organization. During the hold period, the legitimate vendor may notice and report that their banking information has been fraudulently altered. The AP function has time to complete its verification protocol without time pressure. And the attacker, who has often timed the attack to coincide with an imminent payment, loses the operational advantage of their timing.

This control is simple to implement in most ERP and AP automation systems and adds no cost to the process other than the brief delay it imposes. Against the alternative — a fraudulent wire that leaves the organization before anyone knows a change was made — it is unambiguously worth the friction.

Anomaly Detection and Vendor Master Monitoring

Regular review of the vendor master file for changes that do not match the normal pattern of vendor account management is a detection control that can identify fraudulent banking changes before they result in a fraudulent payment. Key triggers for review include: banking information changed within a short period before a large scheduled payment; changes submitted through an unusual channel (email rather than portal); multiple vendors with the same banking account number; vendors with recently changed banking details that have no corresponding re-verification record; and new banking details in a geographic location inconsistent with the vendor's established profile.

Automated monitoring within vendor management and ERP systems can flag these patterns in real time, without requiring manual review of every record. The value of this control is not as a substitute for the prevention controls above, but as a parallel detection layer that catches fraud that makes it past the first line of defense.

The Regulatory Dimension: 2026 Nacha Rule Amendments

The 2026 Nacha rule amendments, rolling out in two phases this year, have elevated banking change fraud prevention from best practice to formal compliance obligation for ACH originators. Finance leaders whose organizations originate ACH payments should be aware of what is now required.

The updated rules incorporate a more explicit definition of false pretenses, covering fraud schemes such as Business Email Compromise, vendor impersonation, and payroll diversion. Nacha now emphasizes the need for proactive fraud monitoring, shifting from simple account validation to verifying identity and detecting suspicious behavior before transactions are initiated.

Phase 1, starting March 20, 2026, applies to non-consumer originators and third parties with 2023 ACH origination volume of six million or more. Phase 2, starting June 22, 2026, extends requirements to all remaining non-consumer originators and third parties.

The changes shift fraud prevention responsibility to originators and mandate verified, documented procedures with real-time controls — a fundamental shift from passive observation to active compliance.

Practically, this means that organizations originating ACH payments must now maintain documented, risk-based processes for identifying entries suspected of being initiated under false pretenses, review those processes at least annually, and be able to demonstrate compliance in the event of examination or inquiry. This includes setting up an account verification process — picking a method such as a third-party validator, micro-deposits, prenotification, or direct vendor contact — and applying it to every new vendor and every change to existing vendor banking details, documenting the method, the date, and the outcome for each verification, with records retained for at least two years.

For finance leaders who have not yet undertaken a formal review of their ACH origination practices in light of these amendments, that review is now urgent. The Nacha rule changes are not aspirational; they are in effect or imminently effective. Platforms such as VendorInfo, with their automated bank account ownership verification and documented verification workflows, are specifically designed to satisfy these requirements in the context of vendor payment management.

Recovery: The First 60 Minutes

When a fraudulent banking change has been processed and a payment has left the organization — or is believed to be imminent — every minute matters. The economics of recovery are stark: wire fraud and ACH credit fraud that is reported and acted on within hours has a meaningful recovery rate; fraud reported days or weeks later, after funds have been layered through multiple accounts, has nearly none.

Immediate steps, in order:

Contact the originating financial institution first. Before any other call, before any internal notification meeting, before completing any paperwork — call the bank's fraud line and request a wire recall or ACH reversal. Provide the amount, beneficiary account details, and the date and time of the transaction. Every minute of delay reduces the probability of a successful hold.

File an IC3 complaint at ic3.gov within 24 hours. The FBI's Internet Crime Complaint Center operates the Financial Fraud Kill Chain — a coordinated process through which the FBI works with financial institutions to freeze and recover funds from reported BEC and payment fraud incidents. The kill chain has a documented recovery rate when activated quickly; it has essentially no reach once funds have moved through multiple financial institutions or converted to cryptocurrency.

Preserve all records immediately. Every email, document, and system log related to the fraudulent change request and the resulting payment should be preserved in its original form before any remediation or cleanup effort. This evidence is essential for law enforcement and for any subsequent recovery action.

Notify legal counsel and senior leadership. BEC and wire fraud incidents may trigger notification obligations under data breach statutes depending on what information was accessed or exposed. Legal counsel should assess this promptly.

Conduct a post-incident review. Once the immediate response is complete, a structured review of how the fraud entered the process — what control failed, at what step, and why — produces the intelligence needed to prevent recurrence. Organizations that treat fraud incidents as isolated events to be resolved and forgotten are more likely to be victimized again. Organizations that treat them as process intelligence are not.

The Profession's Response: Knowledge as a Control

The controls described in this article are not new. The verification protocol — call the vendor on a number you already have, confirm the change, document the call — has been a published best practice for more than a decade. The Nacha guidance on dual controls and out-of-band authentication has been available for years. The segregation of duties principle is foundational to internal control theory.

What is new is the regulatory codification of these practices as formal compliance requirements, and the growing sophistication of the attacks that make them necessary. In a fraud environment where AI-generated voice calls can mimic a vendor representative's voice, where forged bank letters are printed on demand, and where attackers research their targets with a level of operational preparation that rivals internal audit functions, the difference between an organization that loses money and one that does not is increasingly a function of professional knowledge and disciplined process.