Vendor Bank-Detail Fraud: Why AP Is Now the #1 Attack Surface

The standard story about payment fraud goes like this: a bad actor sends a convincing email, someone clicks, money moves. Train the humans, filter the inbox, problem contained.

That story is wrong, or at least obsolete. The modern attack does not need a fake invoice or a spoofed CEO. It needs a real vendor, a real invoice that was already going to be paid, and a five-minute window to change one field in your ERP. In 2024, BEC complaints resulted in $2.77 billion in adjusted losses in the US across 21,442 reported incidents (Source: FBI IC3, https://www.ic3.gov/AnnualReport/Reports/2024_IC3Report.pdf), and the share of those losses tied to vendor impersonation, not executive impersonation, keeps growing.

Here is the frame worth holding. Your AP controls were built to validate invoices. The attack is no longer on the invoice. It is on the identity of the supplier the invoice belongs to.

The Control Stack Was Built for the Wrong Threat

Walk through what an AP organization actually controls today. Three-way match between PO, receipt, and invoice. Duplicate-invoice detection. Approval thresholds by dollar amount. Segregation of duties between the person who enters the invoice and the person who releases the payment. Coding accuracy. Tax compliance.

Every one of those controls assumes the supplier on file is who they say they are and that the payment instructions sitting in the vendor master are correct. None of them validate the supplier's identity at the moment of payment. None of them flag when a long-trusted vendor's banking information was edited two weeks ago by someone in your own AP shop responding to a polite email request.

This is the gap. The invoice is legitimate. The PO is legitimate. The receipt is legitimate. The three-way match clears. The money goes to the wrong bank account because the wrong bank account is what the vendor master says is correct.

That is why 79% of organizations experienced attempted or actual payments fraud in 2024 (Source: AFP 2025 Payments Fraud and Control Survey, https://www.afponline.org/publications-data-tools/reports/survey-research-economic-data/Details/payments-fraud) even as email security spend has gone up year after year. You cannot filter your way out of a problem that lives in your ERP.

The Anatomy of a Bank-Detail Hijack

Strip away the email theatrics and the attack pattern is mechanical. It looks like this.

Step one: reconnaissance. The attacker identifies a real supplier relationship, usually through a leaked invoice, an insurance certificate posted publicly, a press release naming a vendor, or a compromised mailbox somewhere upstream. They know who pays whom and roughly how often.

Step two: pretext. A request arrives at AP asking to update banking details. It comes from a lookalike domain, a compromised employee mailbox at the actual vendor, or in some cases a spoofed phone call referencing a real invoice number. The request is polite, well-formatted, and references real details only the vendor would know, because much of it was scraped from the vendor's own systems.

Step three: change. Someone in AP, often a junior coordinator processing dozens of these requests a week, updates the vendor master. There may be a form. There may be a manager approval. What there usually is not is a callback to a verified phone number on file, a vendor-portal-side change with multi-factor authentication, or a cooldown period before the new account becomes payable.

Step four: harvest. The next two to four payment runs send money to the attacker's account. By the time the real vendor calls asking where their money is, the funds have been laundered through two or three downstream accounts.

Notice what is not in that sequence. No phishing link clicked at the moment of fraud. No malware. No spoofed CEO. The breach happened weeks earlier and lived dormant in a database row until payment day made it visible.

Why AP Owns This, Not IT

Information security teams will keep getting blamed for these losses because the entry vector often involves email. That framing is convenient and wrong. IT can harden the inbox. They cannot govern who is allowed to edit row 4,217 of your vendor master, what evidence is required, what the cooldown is, and whether the change triggers an out-of-band callback.

Those are AP policy decisions. They sit in the operations org, not the security org. And in most companies, they are documented loosely or not at all, because the vendor master was treated for years as static reference data rather than a live control surface.

When the council reviews a bank-detail fraud postmortem, the failure is almost always one of three things. The change process did not require independent verification. The verification, if required, used contact information supplied with the change request itself, which is a circular control and therefore not a control. Or the change took effect immediately, with no holding period and no parallel notification to the existing vendor record's contacts.

These are operational fixes. They do not require new technology. They require AP leaders to claim ownership of the master file as a control surface and to write policy accordingly.

The Operational Playbook

Here is the sequence we recommend to mid-market and enterprise AP teams that are serious about closing this gap.

Treat every bank-detail change as a privileged operation. It should require more rigor than approving a new invoice, not less. Specifically, it should require independent callback verification to a phone number already on file before the change request arrived, not a number provided with the request.

Build a mandatory cooldown. New banking details should not become payable for a defined waiting period after the change is entered. During that window, an out-of-band notification goes to the existing contacts on the vendor record. This single control catches a large share of attacks because the real vendor will object before the cooldown expires.

Separate the editor from the approver from the verifier. Three roles, three people, none of whom can complete the change alone. Most AP shops have two of these. The verifier role, the person whose only job is to confirm via independent channel, is the one that tends to be missing.

Push the change off your desk and onto the vendor's. Bank detail updates should happen inside a vendor-managed portal with the supplier's own multi-factor authentication, not via email request to your team. This is the structural fix. The other controls compensate for not having this one. Supplier management workflows that let suppliers self-service their own banking data, behind their own authentication, eliminate the email-to-AP pretext entirely.

Shift payment mix toward instruments that don't expose bank details. Every ACH payment requires the vendor's account and routing number to sit in your master file. Every check exposes the same information on the MICR line. Virtual card payments do not. The single-use card number is generated at payment time, has a controlled spend limit, and carries no standing payment instruction that can be hijacked. Shifting even a portion of spend to virtual cards reduces the attack surface mechanically, not behaviorally.

Why the Industry Trend Makes This More Urgent

Two things are happening at once. The number of supplier records under management is growing as companies consolidate procurement onto fewer ERPs with longer vendor tails. And by 2026, one-third of B2B transactions will involve autonomous agents managing invoicing, reconciliation, or spend control (Source: Forrester 2026 Predictions, https://www.forrester.com/predictions/).

Autonomous agents on the AP side mean fewer human eyes on each individual bank-detail change. Autonomous agents on the supplier side mean more inbound change requests, more programmatic communication, and less of the social friction that used to cause a junior coordinator to pause and ask a question.

The controls that worked when AP was a manual, human-paced process do not scale to an agent-mediated one. If you do not codify the cooldown, the callback, and the portal-side authentication before agentic AP shows up, you are going to codify the gaps instead.

Where Finexio Fits

Finexio operates the payment orchestration layer between buyers, their suppliers, and the payment networks. The three-party model is deliberate. J.P. Morgan Chase is the issuing bank. Mastercard and Visa are the networks. Finexio is the orchestrator that handles supplier enablement, payment method routing, and the controls around how money actually leaves your AP system.

That position lets us do two things AP teams cannot easily do alone. We run supplier identity verification at enablement and at every change, against bank-account ownership data, not just against what the supplier types into a form. And Finexio Shield backs the payments we orchestrate with a $2M fraud guarantee, which exists because we believe the orchestration layer should bear the risk of identity failure, not the buyer's AP team.

After more than a decade in market and over $75M invested in the platform, the lesson we keep relearning is that the buyers who get fraud right are the ones who stopped treating the vendor master as a database and started treating it as the control surface it actually is.

FAQ

Is bank-detail fraud the same thing as BEC?

It overlaps but is not identical. BEC is the broader category of email-driven impersonation, which includes fake invoices and CEO-spoofing wire requests. Vendor bank-detail fraud is the specific subset where the attacker impersonates a real supplier to change payment instructions on a real, recurring relationship. It is the highest-yield variant because it rides on payments that were already going to happen.

Will moving to real-time payments make this worse?

Yes, in the absence of stronger pre-payment identity controls. Real-time means irrevocable. The recovery window that exists with ACH and check, however imperfect, collapses to zero with instant rails. Any organization adopting RTP or FedNow without first hardening vendor master governance is accelerating losses, not just payments.

Should bank-detail changes ever be processed via email?

No. Email is acceptable as a notification channel that a change is needed. It should not be the channel through which the change is authorized or the new account number is transmitted. If you cannot stand up a supplier portal immediately, the interim control is a mandatory verbal callback to a phone number that predates the change request, plus a cooldown before activation.

Close

The fraud problem in AP is not going to be solved by better email filters or more user training. It will be solved by AP leaders who claim governance of the vendor master, write the policies, and choose payment instruments that do not require standing bank credentials to sit in a database row waiting to be edited.

If you want to walk through how Finexio handles supplier identity verification, payment routing, and the Shield guarantee in the context of your AP stack, Book a Consultation.

Sources

- FBI IC3 2024 Annual Report: https://www.ic3.gov/AnnualReport/Reports/2024_IC3Report.pdf - AFP 2025 Payments Fraud and Control Survey: https://www.afponline.org/publications-data-tools/reports/survey-research-economic-data/Details/payments-fraud - Forrester 2026 Predictions: https://www.forrester.com/predictions/