Bank-Account-Change Fraud: The AP Threat Your Automation Can't See

A fraudster studying your AP department in 2026 is not trying to slip a fake invoice past your three-way match. That game got harder. OCR is decent. Duplicate detection works. PO matching catches the obvious stuff. So they moved upstream, to a target that almost no automation watches: the vendor record itself.

Change a single field, the bank account number on a legitimate supplier, and every downstream control you built becomes a delivery mechanism. The invoice is real. The PO matches. The approval routes correctly. The payment runs on schedule. Your automation does exactly what it was designed to do, with perfect efficiency, and wires the money to the attacker.

This is the uncomfortable shape of modern AP fraud. The more automated your payables function, the more use a single hijacked banking detail gives the person on the other end.

The Frame: Your Vendor Master Is a Pre-Authorization List

Most AP leaders think of fraud controls as something that happens at the invoice. That made sense in a paper world, where the invoice was the artifact the fraudster had to forge. It does not describe what is happening now.

In an automated AP environment, every active row in your vendor master is a standing pre-authorization. The bank account on that row tells your treasury, in advance and without further review, where to send money the next time an invoice matches. The control point is not the payment run. The control point is the moment that row was created or changed.

Reframe it this way and the threat model rearranges. Invoice fraud forces the attacker to defeat your matching logic and your approver. Vendor record fraud forces them to defeat exactly one process: how your AP team handles a "please update our banking details" email. That is a much smaller surface for them to attack, and a much larger surface for you to defend.

The numbers reflect the shift. 79% of organizations reported being victims of attempted or actual payments fraud in 2024 (Source: 2025 AFP Payments Fraud and Control Survey, https://www.afponline.org/publications-data-tools/reports/survey-research-economic-data/Details/payments-fraud), and business email compromise targeting vendor banking changes consistently ranks as a top vector. The attack does not require sophistication. It requires a plausible email and a busy AP coordinator.

Why Your Automation Is Structurally Blind

Here is the part that should make a CFO uncomfortable. The automation you bought to reduce AP risk has, in this specific scenario, no view of the risk at all.

Invoice automation inspects invoices. Approval workflows inspect approvals. Payment platforms inspect payment files. None of them, by design, inspect the integrity of the standing data those payments are drawn against. Your AP automation will faithfully execute a payment to a fraudulent account because, from the automation's perspective, nothing is wrong. The invoice is valid. The vendor is approved. The bank account is whatever the master file says it is.

This blindness has three reinforcing causes.

The vendor master sits outside the audit cadence. Most teams audit transactions. Few audit the reference data that authorizes transactions. Change logs exist, but no one reads them weekly.

Change events are treated as administrative, not security, events. A bank account update is filed under "vendor maintenance" alongside address corrections and contact name updates. It should be filed under "treasury authorization change."

The verification step, when it exists, is owned by whoever happens to open the email. That is not a control. That is a coin flip.

The Counterintuitive Implication: More Automation Raises Per-Incident Loss

Here is the claim worth defending. Holding fraud rate constant, the more automated your AP, the larger the dollar exposure of any single successful vendor record compromise.

Why? Because automation removes the human friction that used to catch fraud incidentally. In a manual environment, someone physically cuts a check. They notice when the remit-to address looks unfamiliar. They flag it. In an automated environment, the same payment runs in a batch of four hundred others, hits the bank file, and clears before anyone looks at it as an individual transaction. The first signal often arrives weeks later, when the real supplier calls asking where their money is.

The window between compromise and detection is where the loss compounds. A single bad bank account in your master file does not produce one fraudulent payment. It produces every payment to that supplier until someone notices, which in many organizations is the next invoice cycle, or the one after that.

The implication is not "automate less." The implication is that the verification layer must move upstream, to the vendor record, before automation accelerates the consequences of any error there.

The Operational Playbook: Treat Vendor Changes as Treasury Events

If you accept the frame, the response is straightforward in structure and demanding in execution. Here is the playbook Finexio recommends to mid-market and enterprise AP teams.

1. Reclassify bank-account changes as treasury authorization events. Stop filing them under vendor maintenance. Any change to bank account, routing number, payment method, or remit-to must trigger a defined security workflow, not a clerical one. Different SLA, different approver, different log.

2. Require out-of-band verification on every banking change. Always. No exceptions for "trusted" vendors. The verification call must go to a phone number already on file before the change request arrived, not a number provided in the change request itself. This single discipline defeats the majority of business email compromise attempts targeting AP. Document the call. Name the person reached. Date and time stamp.

3. Impose a cooling-off window between change and first payment. A bank account changed today should not fund a payment today. A short hold, even 48 to 72 hours, gives the real supplier time to flag an unauthorized change and gives your team time to complete verification properly. The operational cost is minimal. The fraud cost it prevents is not.

4. Monitor change-event patterns, not just individual changes. Look for clusters. A single banking change is routine. Multiple banking changes from suppliers in the same week, all routing to accounts at the same unfamiliar institution, is a campaign. Most fraud platforms will not flag this because they look at transactions in isolation. Your AP team, or your payments partner, should.

5. Segregate vendor master edit rights from payment execution rights. The person who can change a bank account in the master file should not be the same person who can approve a payment run. This is basic segregation of duties applied to the layer where it actually matters now.

6. Shift payment method away from bank-detail-dependent rails where feasible. Every ACH and wire payment depends on the bank account in your master file being correct. Every virtual card payment does not. A virtual card pushes a single-use credential to the supplier through a separate channel, decoupled from whatever banking detail is sitting in the vendor row. This is one of the structural reasons Finexio pushes mid-market and enterprise clients toward card-first payment mixes. Reducing your dependency on stored bank account data reduces the blast radius when that data is wrong.

Where Finexio Fits in This Picture

Finexio is the orchestration layer between your AP system and the payment networks. We do not replace your ERP or your invoice automation. We sit between them and the money movement, with J.P. Morgan Chase as the issuing bank and Mastercard and Visa as the network partners. Three-party model, over a decade in market, more than $75M in investment behind the platform.

What that means in this specific context: when a supplier is paid through Finexio's virtual card rails, the payment instruction does not depend on a stored bank account that an attacker can quietly change. The credential is generated for the transaction and delivered through a separate channel. The vendor master row matters less, because less of your money movement is gated by it.

For the bank-rail payments that remain, Finexio's supplier management layer validates banking details at onboarding and on change, with out-of-band verification built into the workflow rather than left to whichever team member opens the email first. And Finexio Shield carries a $2M fraud guarantee on supplier payments routed through the platform, because we are willing to put capital behind the controls we operate.

The point is not that any single tool eliminates this category of fraud. The point is that the controls have to live at the vendor record layer, with verification, segregation, and rail diversity engineered in. That is a different architecture than "buy AP automation and hope."

The Regulatory Backdrop Matters Too

A few external pressures are about to make this work less optional.

After 14 November 2026, unstructured addresses will be removed and only fully structured or hybrid postal addresses will be accepted in ISO 20022 messages (Source: Swift, https://www.swift.com/standards/iso-20022), and April Swift data showed 61.2% of payments included unstructured Debtor postal addresses, while 62.9% included unstructured Creditor information (Source: Swift, https://www.swift.com/standards/iso-20022). Translation: the vendor master fields that feed cross-border payments have to be cleaner and more structured than most teams have kept them. Hygiene work you put off is now on a clock.

Meanwhile, real-time rails are accelerating. 53% of businesses said they plan to adopt the RTP network within two years, and nearly 30% were targeting adoption within six months (Source: PYMNTS Intelligence / The Clearing House, https://www.pymnts.com/news/faster-payments/2024/businesses-look-to-adopt-rtp-and-fednow-within-two-years/). Faster rails mean faster fraud losses. A fraudulent ACH gives you days to claw back. A fraudulent real-time payment gives you minutes.

FAQ

How is this different from standard BEC training?
BEC training tells your team to be suspicious of emails. That helps, but it puts the entire control on human vigilance. The architectural fix is to remove the question of vigilance from the equation: a banking change does not get applied until out-of-band verification, segregation of duties, and a cooling-off window have all cleared. Training is the floor. Process design is the ceiling.

We already require verification calls. Why are we still seeing fraud attempts succeed?
Usually because the verification number came from the change request itself, or because the verifier reached "someone" at the supplier rather than the named contact, or because the call happened but was not logged and a second team member processed the change without knowing. The discipline is in the details, not in the existence of a policy.

Does moving to virtual cards really reduce this risk, or does it just move it?
It genuinely reduces it for the payments it covers, because virtual card credentials are not stored long-term in your vendor master in the way ACH details are. The attack surface shrinks. The remaining ACH and wire payments still need the full verification playbook.

Where to Start

If you read this and recognized your own AP function, the first move is not a procurement cycle. It is a one-page review of how your team handles supplier banking changes today: who can make the change, what verification is required, how it is logged, and how long before the change can fund a payment. Most teams find at least two gaps in that review.

The second move is to look at what share of your payments depend on stored bank account data, and where that mix could shift toward card-based payment rails that decouple the payment from the vendor master.

If you want a peer review of where your AP fraud perimeter is thinnest, and where Finexio's orchestration layer would meaningfully reduce your exposure, book a consultation. We will tell you what we see, including the parts you do not need us for.

Sources

- 2025 AFP Payments Fraud and Control Survey: https://www.afponline.org/publications-data-tools/reports/survey-research-economic-data/Details/payments-fraud - Swift ISO 20022 structured address requirements: https://www.swift.com/standards/iso-20022 - PYMNTS Intelligence / The Clearing House on RTP adoption: https://www.pymnts.com/news/faster-payments/2024/businesses-look-to-adopt-rtp-and-fednow-within-two-years/