The most expensive fraud in accounts payable is also the hardest to spot, because almost nothing about it looks wrong. The invoice is real. The supplier is real. The email comes from the supplier's actual address, sometimes from their actual compromised mailbox, inside a genuine invoice thread. Only one thing has changed: the bank account the payment goes to. This is vendor payment fraud through bank-detail-change and business email compromise, and it bypasses the controls most AP teams rely on. Here is how it works, why it gets through, and what actually stops it, including the new NACHA rules that make addressing it a 2026 requirement.
TL;DR
Vendor payment fraud through bank-detail-change and business email compromise (BEC) is among the most prevalent and costly fraud affecting accounts payable. BEC affects roughly three-quarters of organizations (per the 2026 AFP Payments Fraud and Control Survey), and vendor email compromise specifically accounts for a large share of it. The scheme: a fraudster, posing as a legitimate vendor (often from the vendor's own compromised email account, sometimes from a spoofed lookalike domain), requests a change to the vendor's bank account details, so future payments are redirected to the fraudster's account.
It bypasses AP controls because it exploits trusted, normal processes rather than breaking them. The invoice is genuine, the vendor relationship is genuine, the request follows the normal process, and when the email comes from the vendor's actual compromised mailbox, it is genuinely from the vendor's address, so email security cannot flag it as spoofed. The fraud often goes undetected for months, until the real vendor asks why they have not been paid, by which time the funds are usually unrecoverable.
The controls that stop it are process controls applied consistently, not email security alone. The most important: out-of-band verification of any bank-detail change, confirming the change by phone using a number obtained independently of the request (never the number in the email), before updating the vendor record or paying. Others include bank-account validation before payment, segregation of duties between vendor-master-data changes and payment, and applying these controls on every bank-detail change and every payment, not just when someone remembers. The recurring failure is not the absence of controls but their inconsistent application under time pressure.
This is now also a regulatory requirement. NACHA's 2026 ACH fraud-monitoring rules require originators to implement risk-based processes to identify ACH entries authorized under false pretenses, NACHA's term explicitly covering BEC, vendor impersonation, and payroll diversion, phased in through 2026.
This post covers how the fraud works, why it bypasses controls, the controls that stop it, the NACHA rules, and how consistent, auditable control enforcement addresses it. For the broader fraud context, see The 2026 Payments Fraud Playbook: Deterministic AI Controls vs Manual Review.
How vendor payment fraud works
Vendor payment fraud through bank-detail-change is a specific, highly effective scheme, and understanding its mechanics shows why it is so hard to catch.
The setup: a fraudster targets the payment relationship between a company and one of its vendors. The goal is simple, to redirect a legitimate payment from the vendor's real bank account to an account the fraudster controls, by getting the company to update the vendor's banking details in its records.
The access: the fraudster reaches the AP team posing as the vendor, through one of a few routes. The most dangerous is vendor email compromise, where the fraudster has actually compromised the vendor's email account (via phishing or account takeover) and emails from the vendor's real address, often inserting themselves into a genuine, ongoing invoice thread, monitoring it for weeks, and sending the fraudulent request at exactly the right moment. Less sophisticated but still effective routes include spoofed lookalike domains (an address that closely resembles the vendor's) and impersonation using researched details. In the vendor-email-compromise case, the email is genuinely from the vendor's address, which is what makes it so hard to detect.
The request: posing as the vendor, the fraudster requests that the company update the vendor's bank account details, "our banking has changed, please send future payments to this account." The request is often timed near a real payment (right before an invoice is due), supported with legitimate-looking documentation, and framed within the normal process, so it looks routine. Variants include submitting fraudulent or duplicate invoices, but the bank-detail change is the core and most damaging move.
The result: if the company updates the vendor record and pays, the payment goes to the fraudster. Because everything looked legitimate, the fraud is typically discovered only later, often months, when the real vendor follows up about a missing payment, and by then the funds have usually been moved and are unrecoverable. In one documented 2026 case, an organization issued three payments totaling $150,000 on a fraudulent vendor request and recovered only $915. The combination of high loss and low recovery is what makes this fraud so costly.
Why it bypasses AP controls
Vendor payment fraud is effective precisely because it bypasses the controls most AP teams rely on, and it does so by exploiting normal processes rather than breaking them. The specific reasons:
1. The invoice, the vendor, and the relationship are all real. Unlike crude fraud, there is no fake invoice or unknown payee to flag. The vendor is a legitimate, established supplier the company genuinely owes money to. The only fraudulent element is the bank account, which is a single changed field in an otherwise legitimate transaction. Controls that look for suspicious invoices or unknown vendors do not catch a real invoice to a real vendor.
2. Email security cannot catch a compromised legitimate mailbox. When the fraudulent request comes from the vendor's actual compromised email account, it is genuinely from the vendor's address, with no spoofed domain, no malicious link, no malicious attachment. Email security tools, which look for those signals, cannot flag it, because there is nothing technically wrong with the email: it is a legitimate email account sending a fraudulent request. This is the crucial point that defeats a purely technical defense: a perfectly configured email security stack still passes a BEC message from a genuinely compromised vendor mailbox, because the message is, technically, legitimate.
3. It exploits trust in established relationships. AP teams are, reasonably, less suspicious of established vendors than of new ones, and concentrate verification on new payees. Vendor-email-compromise fraud exploits exactly this, attacking the trusted, established relationship where scrutiny is lowest, which is why higher-friction environments push attackers toward compromising real vendor accounts rather than using crude spoofs.
4. It exploits speed and process pressure. AP teams are expected to process payments quickly and at volume, which reduces the time for thorough verification, and the fraudster's timing (right before a payment is due) and framing (urgency, routine) exploit that pressure. The verification step most likely to catch the fraud, independently confirming the change, is also the step most likely to be skipped under time pressure.
5. The verification that would catch it is often bypassed or flawed. Many AP teams have a callback-verification policy for bank-detail changes, but it is inconsistently applied (skipped under pressure), or flawed in a specific way: the verification uses contact information from the same email that made the request, so the team calls the fraudster, who confirms the fraudulent change. Verification that relies on the requester's provided contact information is not real verification, but it is common, and it is exactly the gap the fraud exploits.
The pattern across all five is that the fraud lives in the normal process: the real invoice, the real vendor, the real email account, the routine request, the time pressure: so controls designed to catch abnormal transactions miss it, and the one control that would catch it (genuine out-of-band verification) is the one most often skipped or done wrong.
The controls that actually stop it
Because the fraud exploits normal process and defeats email security, the controls that stop it are process controls, applied consistently. The ones that matter most:
1. Out-of-band verification of every bank-detail change
This is the single most important control. Any change to vendor payment instructions, new bank account, changed account or routing number, must be verified by directly contacting the vendor using a phone number obtained independently of the request (from the vendor's verified records or a known directory, never a number provided in the email or document making the request). This breaks the fraud, because even if the fraudster controls the email, they do not answer the vendor's real phone number. The critical detail is "independently obtained": verifying via the contact information in the request itself is the flawed verification that fails.
2. Bank-account validation before payment
Validating that the bank account belongs to the legitimate vendor, through account-validation services that verify account ownership and match it to the vendor identity, before paying, catches redirected payments. Dedicated vendor account-validation services exist for exactly this and are increasingly the expected control, validating bank details against verified databases before every payment.
3. Segregation of duties between vendor-master-data changes and payment
The person who can change a vendor's bank details should not be the same person who approves and releases payments, so no single individual (or single compromised account) can both redirect and pay. Separating vendor-setup and vendor-change permissions from payment permissions is a foundational control against both external fraud and internal collusion.
4. Vendor master data integrity
Because the fraud targets the vendor record (the bank details), the integrity of the vendor master data is central: controlled, audited processes for changing vendor records, with verification built into any bank-detail change, so the record cannot be quietly altered. Vendor master data hygiene is the foundation that the payment controls rest on, connected to The Top AI Tools for Vendor Management and Supplier Onboarding in Finance.
5. Consistent application on every change and every payment
The recurring failure is not the absence of these controls but their inconsistent application: the callback skipped under time pressure, the validation not run on a "trusted" vendor, the verification done using the wrong contact information. The controls only work if applied every time, on every bank-detail change and every payment, regardless of how routine or trusted the request seems, which is precisely where consistent, enforced control execution matters more than the existence of a policy.
The throughline is that stopping vendor payment fraud is an operating-model problem, not a single-control problem: the right controls, enforced consistently on every relevant change and payment, rather than relying on individual judgment and memory under pressure.
The NACHA 2026 rules make this a requirement
Addressing vendor payment fraud is now not just prudent but, for ACH payments, a regulatory requirement, because of NACHA's 2026 ACH fraud-monitoring rules.
NACHA (which governs the ACH network) introduced, for the first time, a formal requirement for proactive, risk-based ACH fraud monitoring across the network. The rules require covered participants to implement processes and procedures to identify ACH entries suspected of being authorized under false pretenses, a term NACHA introduced specifically to capture the fraud typologies used against ACH, explicitly including business email compromise, vendor impersonation, and payroll diversion, exactly the vendor payment fraud this post addresses.
The rules phase in through 2026: Phase 1 (effective March 20, 2026) applies to ODFIs, RDFIs, and non-consumer originators with ACH transaction volume of $1 billion or more, and Phase 2 (effective June 19/22, 2026) extends the requirement to third-party senders, third-party service providers, and originators regardless of volume. The programs must be risk-based, documented, and subject to annual review. The practical effect is that companies originating ACH payments are now required to have risk-based processes to identify payments authorized under false pretenses, which is precisely what vendor bank-detail-change fraud is. This turns the controls above, verification of bank-detail changes, account validation, monitoring for the signals of authorized-under-false-pretenses fraud, from best practice into compliance with NACHA's rules, and it makes consistent, documented, auditable control execution a regulatory expectation, not just a fraud-prevention preference. Companies should confirm which phase applies to them and ensure their vendor-payment controls meet the risk-based, documented standard the rules require.
How consistent, auditable control enforcement helps
The recurring lesson across vendor payment fraud is that the failure is usually not missing controls but inconsistently applied ones: the verification skipped under pressure, the validation not run on a trusted vendor, the callback done using the wrong number. So the most effective response is enforcing the right controls consistently, on every bank-detail change and every payment, so the verification is never skipped and never done wrong, and is documented for the audit and review the NACHA rules now expect.
This is where a deterministic, agentic platform like Kognitos is relevant to vendor payment fraud, honestly scoped. Kognitos is not a dedicated bank-account-validation service (services like the ones noted above specialize in validating account ownership against verified databases) and not an email-security tool (which addresses the email layer). Its relevance is the control enforcement layer in the AP process: enforcing that the required verification and control steps happen on every bank-detail change and every payment, deterministically and the same way every time, rather than depending on a person to remember under time pressure. Because Kognitos executes deterministically, a defined control ("any bank-detail change requires out-of-band verification before the vendor record is updated or payment is made") is applied to every instance, not just when someone remembers, which directly addresses the inconsistent-application failure that the fraud exploits. And because every step is logged in plain language, the control execution is auditable and documented, which is exactly what NACHA's rules' documented, risk-based, reviewable standard requires. For the requirements around AI and automated decisions in financial processes, see AI Audit Trail Requirements: A 2026 Checklist for Finance, Healthcare, and Banking.
In practice, this means Kognitos can enforce the verification workflow (route every bank-detail change through the required independent verification before it takes effect), enforce segregation of duties and approval on payments, integrate the output of dedicated account-validation services into the enforced process, and maintain the vendor master data integrity that the controls rest on, consistently and auditably. It works alongside dedicated account-validation and email-security tools rather than replacing them: those address the validation and email layers, while Kognitos enforces that the controls actually execute on every transaction and are documented. For a finance team whose vendor-payment-fraud exposure comes from controls that exist on paper but are inconsistently applied, which is the documented common failure, consistent, auditable enforcement is the gap that most needs closing, and it is also what the NACHA rules now require. English-as-code agentic AI makes this kind of control definition and enforcement accessible to finance teams without code. For why payment fraud controls are less widely deployed than the risk warrants, see Why Only 17% of Companies Use AI to Fight Payments Fraud.
This is the deterministic, neurosymbolic approach applied to vendor payment fraud: consistent with the broader argument in The 2026 Payments Fraud Playbook: Deterministic AI Controls vs Manual Review.
Book a working session with a Kognitos solutions engineer → Or try Kognitos free →
Putting it together
Vendor payment fraud through bank-detail-change and business email compromise is among the most prevalent and costly AP fraud because it bypasses controls by exploiting normal process: the invoice is real, the vendor is real, the email often comes from the vendor's actual compromised mailbox, and only the bank account has changed, so email security cannot catch it and controls looking for abnormal transactions miss it. It is usually discovered months later, when funds are unrecoverable. The controls that stop it are process controls applied consistently, out-of-band verification of every bank-detail change using independently obtained contact information, bank-account validation before payment, segregation of duties between vendor-data changes and payment, vendor master data integrity, and above all consistent application on every change and payment, because the documented failure is inconsistent application, not missing controls. NACHA's 2026 ACH fraud-monitoring rules now require risk-based, documented processes to identify payments authorized under false pretenses, making this a compliance requirement, not just best practice. The most effective response is enforcing the right controls consistently and auditably on every transaction, which is a control-execution problem, addressed by applying the verification and controls deterministically and documenting them, so the control is never skipped under pressure and is evidenced for the review the rules require. Vendor payment fraud sits within the broader accounts payable automation process, and consistent fraud controls here protect the accuracy and integrity of the entire AP cycle. For the broader financial services context, see The Top AI Automation Tools for Banking Back-Office Operations. The Finance and Accounting Automation layer is what makes consistent, auditable control execution possible.