Corpay

B2B Payment Fraud: When a Vendor Payment Goes to the Wrong Account, Who Eats the Loss?

Category:Risk management, AP Automation
Updated:2026-09-15
Author:David Luther

B2B payment fraud content almost always stops at the moment of the incident. The controls are listed, the warning signs are described, and the article ends. What happens on the day after, when the money is gone and four parties each believe the loss belongs to someone else, is the part nobody writes down.

That's the gap this covers. Not how to stop it, which is covered well enough elsewhere, but how the question of who absorbs the loss actually gets decided, why the answer changes dramatically depending on which rail the payment used, and why the window for getting the money back has been closing for several years.

One boundary up front. Nothing here is legal advice, and the allocation questions below are framed as questions to resolve with counsel rather than as answers. Loss allocation in commercial payments turns on contract terms, the specific facts, and the jurisdiction, and a general article that told you otherwise would be doing you harm.

Key Takeaways

  • Consumer payments carry statutory protections that business payments largely do not, and most finance teams have never been told this explicitly.

  • The liability question is decided differently on every rail, which means the payment method chosen months ago determines the answer.

  • Recovery rates have fallen sharply, and instant, irrevocable rails are removing the window that clawbacks depend on.

  • Crime and cyber policies frequently carry social-engineering sublimits far below routine wire values, so the coverage exists at a fraction of the exposure.

  • The one purpose-built deepfake insurance endorsement covers forensics and response rather than the transferred funds.

  • Controls that change the liability outcome are a different and shorter list than controls that improve detection.

What is B2B payment fraud, and how does it differ from consumer fraud?

B2B payment fraud is any scheme that causes a business to send money to an account controlled by an attacker, or to send more money than it owes. The structural difference from consumer fraud is legal rather than technical. Consumer electronic payments in the US carry statutory protections built specifically to shift losses away from individuals; commercial payments largely do not, and the allocation instead turns on contracts, the Uniform Commercial Code, and the security procedures the parties agreed to.

That difference is the single most important thing for a finance team to understand before an incident. A consumer disputing an unauthorized debit and a company disputing a fraudulent wire are not in the same position, and the assumption that a bank will simply make you whole is usually inherited from personal experience that doesn't transfer.

The exposure is close to universal. AFP's 2026 Payments Fraud and Control Survey found that 76% of organizations were hit by attempted or actual payments fraud in 2025, with business email compromise affecting 74%. The FBI Internet Crime Complaint Center's 2025 Internet Crime Report recorded $3.046 billion in reported BEC losses, up from $2.77 billion in 2024, with an average reported loss above $122,000, inside $20.9 billion in total reported cyber-enabled losses, up 26% year over year.

Which attack actually produced the loss?

Four patterns account for most B2B payment losses, and identifying which one you're dealing with matters because they allocate differently.

  • Vendor email compromise. An attacker sits inside a supplier's mailbox, waits for a genuine invoice in an active thread, and replies within it with changed banking details. Same sender, same thread, real invoice number. The mechanics are covered in the vendor email compromise breakdown, and more broadly in the business email compromise guide.

  • Executive impersonation. A spoofed or compromised internal account requests an urgent payment outside normal process. Vendor impersonation specifically reached 45% of organizations in AFP's 2025 survey, up 11 percentage points.

  • Internal payment error. No attacker at all. An AP specialist selects the wrong payment template from a library of hundreds, the approver misses it because the vendor names look alike, and the money goes to a real company that wasn't owed it.

  • Check alteration and counterfeiting. Paper remains heavily targeted. FinCEN received 682,276 check-fraud Suspicious Activity Reports in 2024, up from 665,505 in 2023, as reported by the Thomson Reuters Institute.

The third one deserves its own note, because it isn't fraud and finance teams consistently underestimate it. Bank portals accumulate payment templates, sometimes well past a thousand, and a near-miss selection sends a correct amount to the wrong recipient. There's no attacker to pursue and no insurance trigger. There's only a company that received money it wasn't owed and a conversation about whether they return it. The full guide to AP fraud schemes covers the patterns around it.

Who is liable when a fraudulent payment goes out?

There's no single answer, and anyone giving you one without reading your bank agreement is guessing. What can be said generally is which framework governs each rail and what the allocation tends to turn on, which is enough to know what to ask.

Rail

Governing framework

What the allocation turns on

Practical recovery window

Wire transfer

UCC Article 4A, plus the funds-transfer agreement with your bank

Whether the bank offered a commercially reasonable security procedure, whether the customer agreed to it, and whether both followed it

Hours, and shrinking

ACH credit

Nacha Operating Rules and your originating agreement

Authorization and the return-reason framework, which is narrow for originated credits

Very limited once settled

ACH debit

Nacha rules, with different return rights for the receiving side

Whether the debit was authorized and whether return deadlines were met

Defined return windows apply

Check

UCC Articles 3 and 4, plus bank service agreements

Alteration versus forgery, the timeliness of your review, and whether offered controls were used

Days, subject to statutory notice periods

Commercial card

Card network rules and the issuer agreement

Chargeback and dispute rights under network rules, which are more developed than any other rail

Dispute timelines measured in weeks

Real-time payments

Scheme rules; settlement is final

Very little, because irrevocability is the design

Effectively none after settlement

This table describes which framework applies and what the analysis tends to consider. It is not a statement of outcome in any specific dispute, and every row should be reviewed against your own agreements with counsel.

The single most useful thing on that table is the last column. Two rails offer a real dispute process, one offers a defined return window, and two offer close to nothing once the payment settles.

What does "commercially reasonable security procedure" mean?

It's the phrase at the center of most wire-fraud disputes, and it comes from UCC Article 4A, which allocates loss for unauthorized funds transfers between a bank and its commercial customer. The analysis considers whether the bank offered a security procedure appropriate to the customer's circumstances, whether the customer agreed to use it, and whether the parties actually followed it.

The counterintuitive implication is worth sitting with. A security procedure your company declined years ago, on a form someone signed during onboarding, can matter more in a dispute than the procedures you use today. Pull your funds-transfer agreement and read what was accepted and what was declined, before you need to. That's a thirty-minute exercise most treasury teams have never done, and it's the one that determines where you stand.

Why does the answer change so much by rail?

Because the rails were built at different times for different purposes under different rules. Card networks built dispute infrastructure because consumer disputes were core to the product. The ACH network built return reason codes for a batch world with settlement windows. Wire transfers were built for finality between sophisticated parties, and real-time rails were built for finality on purpose.

The practical consequence is that your payment mix is also your liability profile, which almost never appears in the analysis when a team decides how to pay a given supplier. Rail choice is usually made on cost, speed, and supplier preference. It's also a risk allocation decision, made once and inherited by whoever handles the incident. Comparing wire transfer mechanics and costs against the ACH credit fraud controls available on the other side is the version of this comparison most teams have actually run.

How long do you actually have to get the money back?

Less time than you think, and less than you would have had five years ago. Recovery depends on the funds still sitting somewhere reachable, and the payment infrastructure is systematically removing that somewhere.

The trend is measurable. AFP's 2025 survey found only 22% of organizations recovered 75% or more of funds lost to payments fraud in 2024, down from 41% the year before. The cause is faster settlement rather than worse response procedures.

The mechanics behind it are explicit. RTP settlement is described by The Clearing House as final and irrevocable, and the Federal Reserve raised the FedNow per-transaction limit to $10 million in November 2025. A payment that settles finally in seconds has no interception point. The clawback that worked in 2020 depended on a correspondent bank holding funds overnight, and that pause is disappearing from the system by design.

Regulators have moved in response rather than in prevention. Nacha's risk-based ACH fraud-monitoring rules are now in effect, phased with Phase 1 effective March 20, 2026 and Phase 2 effective June 19, 2026. FinCEN widened the 314(b) safe harbor on June 12, 2026 to cover real-time fraud-signal sharing between institutions. Both changes push detection earlier, which is the honest read of where this is going. Detection has to happen before the payment leaves, because after it leaves there is increasingly nothing to detect.

Protect cash flow with modern AP

Modernize AP to cut costs, speed approvals, and mitigate payment risk — gaining the real-time visibility to protect cash flow and scale with confidence.

Download the whitepaper
protect-cashflow-with-ap.jpg

What should the first six hours look like?

Treat it as a sequence with named owners rather than as a policy document nobody can find during an incident.

  1. Call the originating bank's fraud line immediately and request a recall, giving the exact amount, timestamp, and destination details.

  2. Preserve evidence before anyone cleans up, including the original emails with full headers, the payment file, the approval record, and system logs.

  3. Notify your insurance broker within hours, because most policies carry notice requirements and late notice is a recognized coverage defense.

  4. Contact the receiving institution if your bank will make the introduction, since a freeze depends on the funds still being there.

  5. File with the FBI's IC3 and with local law enforcement, which is often a condition of a claim as well as a route to recovery.

  6. Contact the supplier, both to tell them what happened and to establish whether they were also compromised.

The sequencing matters. Teams that call their broker last routinely discover that a notice provision was missed while they were busy trying to get the money back.

Does your insurance actually cover this?

Often less than expected, and the gap tends to sit in a specific place. These are questions to put to your broker rather than conclusions about your program, and the answers vary enormously between policies.

The pattern worth knowing is the social-engineering sublimit. Crime policies commonly cover computer fraud and funds transfer fraud at full policy limits while carrying a separate, much smaller sublimit for losses where an employee was deceived into authorizing the transfer. Aon reported in April 2026 that social-engineering sublimits frequently sit below routine wire values, and that deepfaked audio and video are now being used to confirm fraudulent instructions during callback verification. A company with a $5 million crime policy and a $250,000 social-engineering sublimit is covered for 5% of a typical BEC loss, and usually doesn't know that until the claim.

Voluntary parting is the related exclusion. Where an employee knowingly initiated the transfer, even under deception, a policy may treat the funds as voluntarily parted with rather than stolen, which can fall outside computer-fraud coverage entirely. Whether the social-engineering endorsement picks it up is the question, and the answer is in the endorsement wording rather than in the policy summary.

The newest product illustrates the gap precisely. Coalition's Deepfake Response Endorsement, introduced in December 2025, covers forensics, takedown, and public relations support. It does not provide funds-transfer indemnity. The product does what it says, and the observation here is narrower. The market's purpose-built deepfake coverage pays for the response rather than for the transferred funds, and buyers reading the headline frequently assume otherwise.

Six questions to ask your broker before you need to

  1. What is the social-engineering sublimit on our crime policy, and how does it compare to our largest routine payment?

  2. Does funds transfer fraud coverage sit on the crime policy, the cyber policy, or both, and do they coordinate or exclude each other?

  3. How does the voluntary parting exclusion read, and does our social-engineering endorsement override it?

  4. What callback or verification procedure does the policy require us to have followed for coverage to attach?

  5. What is the notice period after discovery, and who is authorized to give notice?

  6. If a supplier's email was compromised rather than ours, does coverage still respond?

Question four is the one that surprises people. Some policies condition coverage on a documented verification procedure having been performed, which means a control failure becomes a coverage failure as well as a loss.

Where does the supplier stand in all this?

Nobody writes about this and it comes up in every incident. The supplier wasn't paid, your money is gone, and the contract is usually silent on who bears that.

The legal question is whether payment to the fraudulent account discharged your obligation. That analysis typically turns on who bore the risk of the compromised communication channel, whether the supplier's own systems were the breach point, and what the contract says about how payment instructions change. A supplier whose mailbox was compromised is in a materially different position from one whose email was merely spoofed, though neither fact resolves the question on its own.

In practice, most of these resolve commercially rather than legally, because both parties want the relationship more than they want the argument. What determines the outcome is usually how the conversation starts. A buyer who calls the supplier the same day, explains what happened, and shares the forensic detail tends to end up splitting the loss or negotiating a payment plan. A buyer who goes quiet for three weeks while their insurer evaluates tends to end up in a dispute. That's not a legal observation, it's a relationship one, and it's the part of the incident finance teams have the most control over.

The contract fix is a clause specifying that banking details change only through a defined out-of-band verification process, agreed at onboarding rather than during an incident. Supplier-side hygiene of that kind is part of vendor management and gets far less attention than it deserves.

How do you prevent B2B payment fraud, and which controls change who pays?

Sort your controls by whether they change the liability outcome, not by how well they detect. Those are different lists, and the second one is shorter.

Controls that plausibly affect allocation include documented callback verification to a number sourced from the contract rather than from the invoice, bank-offered services you were offered and accepted rather than declined, a written vendor bank-change policy with out-of-band confirmation, and segregation between whoever maintains vendor records and whoever releases payment. The common thread is that each one produces evidence, and evidence is what an allocation analysis runs on. Detection controls without an evidence trail help you catch fraud and do nothing for you afterward.

The bank-offered services point is specific. Positive pay and its ACH equivalent are offered by most commercial banks, and the fact that they were offered can matter in the analysis regardless of whether you took them. Banking validation at vendor setup is the control that does the most work against the most common attack, and it produces exactly the documented verification record that both an allocation analysis and an insurance claim want to see.

Payment method substitution is the structural move. Single-use cards cap exposure at one payment for one amount and carry network dispute rights that no ACH or wire payment has, and the way virtual cards and automation reduce fraud exposure is mostly this containment property rather than better detection. Post-payment, duplicate payment detection catches the subset that reconciliation would otherwise find months later. ERP-specific control gaps are worth reading too, since the exposure differs by system, as the NetSuite and Sage Intacct walkthroughs show.

Move the controls into the payment operation

The controls that survive contact with a busy month-end are the ones nobody has to remember. A written vendor bank-change policy depends on an AP specialist following it at 4pm on the last day of the quarter. The same policy enforced inside the payment operation doesn't.

That's the practical case for a managed operation rather than a documented process. Corpay runs fully managed AP across virtual card, ACH, and check, with supplier enrollment and banking verification performed as part of the operation rather than as a task assigned to your team. Single-use virtual cards cap exposure per payment, and 100+ ERP integrations covering NetSuite, Sage Intacct, Business Central, and Acumatica keep the approval and payment record continuous, which is what produces the evidence trail an allocation analysis needs.

See the AP automation overview for the operation, or virtual cards for the containment control specifically.

Frequently Asked Questions

Who is liable when a business wire goes to a fraudulent account?

It depends on the funds-transfer agreement and the facts, and UCC Article 4A is the framework that generally governs. The analysis considers whether the bank offered a commercially reasonable security procedure, whether the customer agreed to it, and whether both followed it. Review your own agreement with counsel rather than assuming an outcome.

Will my bank reimburse a fraudulent wire transfer?

Not automatically, and business wires don't carry the statutory consumer protections many people assume apply. Reimbursement depends on the agreement, the security procedures in place, and the specific facts. Ask your bank in advance what its position is when a customer authorizes a payment under deception.

Does cyber insurance cover business email compromise losses?

Sometimes, often at a sublimit well below the policy limit, and sometimes under a crime policy rather than a cyber policy. Social-engineering coverage is frequently a separate endorsement with its own limit and conditions. Ask your broker specifically what applies when an employee was deceived into authorizing a transfer.

What is funds transfer fraud coverage, and how is it different from social engineering coverage?

Funds transfer fraud coverage generally responds where a transfer was initiated without the insured's knowledge, such as through system compromise. Social engineering coverage responds where an employee was deceived into initiating it. The second is usually a separate endorsement with a lower sublimit, and most BEC losses fall into it.

Can a fraudulent wire transfer be recovered?

Occasionally, and less often than it used to be. Recovery depends on the funds still being reachable, so speed matters more than anything else, and instant settlement rails are shortening the window. Recovery rates have declined sharply in recent survey data.

Who is liable for ACH fraud?

The Nacha Operating Rules and your originating agreement govern, and the answer differs between an ACH credit you originated and an ACH debit taken against your account. Return rights are meaningfully broader for unauthorized debits than for originated credits, which is one reason rail choice matters.

If a fraudster intercepted the payment, do we still owe the supplier?

That depends on whether payment to the fraudulent account discharged the obligation, which turns on the contract, the facts of the compromise, and the jurisdiction. It's an unsettled and fact-specific question, and most cases resolve commercially rather than through litigation.

How is liability different for a virtual card payment?

Card payments run under network rules that include a developed chargeback and dispute process, which no ACH or wire payment has. Single-use card numbers also cap exposure at one authorized amount, so the loss is bounded even before any dispute begins.

Headshot.JPG

David Luther

Product Marketing Program Manager
David Luther, MBA is a product marketing program manager with years of experience in commercial banking, finance, and technology sectors, with research and writing appearing in financial publications.
Risk management
AP Automation

Smarter payments. Stronger growth. Keep business moving.

Corpay powers payments for 800,000+ businesses worldwide. Let’s build what’s next for yours.

Please select your communication type
Please enter your first name
Please enter your last name
Email address is required
Please enter your company
Please enter your region

By submitting your information through this form, you agree to receive a telephone call or email from a Corpay representative. Your information will be used in accordance with our Privacy Policy.