Payment Fraud Prevention: The Controls That Work and the Ones That Only Look Like Controls

The email came from the right domain. It referenced the correct invoice number, the correct amount, and the name of the account manager who normally sends invoices. It said the company had changed banks and attached a letter on headed paper. $61,400 went into the new account.

Nine days later the real supplier called about the overdue invoice. Every payment fraud prevention guide describes this attack, and it still works.

The process simply had no step requiring anyone to speak to the supplier before money moved to an account it had never gone to before.

Payment fraud prevention starts with four attacks

Payment fraud is a short list.

It has been stable for years, which is unusual in security and useful here: payment fraud prevention is not a race against novelty, it's a matter of closing four known routes.

The first is the one that produces the incident reports and the insurance claims.

The third moves money constantly and quietly, and nobody counts it as fraud at all, which is exactly why it accumulates. The fourth is the smallest by count and the most damaging by consequence, because it usually involves someone whose judgement other people were relying on.

What the public numbers show

The FBI's Internet Crime Complaint Center publishes an annual count of what victims reported to it.

For 2025 it recorded 24,768 business email compromise complaints and $3,046,598,558 in reported losses. Across all internet crime types the same report recorded 1,008,597 complaints and $20.877 billion in reported losses.

Two things about that figure. It counts complaints filed with the FBI, so it's a floor rather than a measure: companies that recover quietly, or would rather not report, don't appear. And it aggregates wildly different attacks, from a $4,000 invoice redirect at a plumbing firm to eight-figure losses at companies with treasury departments.

Which is the useful reading.

This is not a sophisticated-attacker problem. It's a process problem, distributed across every size of company, and the ones that avoid it are not the ones with better technology. They're the ones where a specific person has to make a specific phone call before a specific field changes.

The callback, and why most callbacks fail

Every guide says verify bank detail changes by phone. Most companies believe they do this. Fewer actually do, because the control has three failure modes and each one looks like compliance.

Calling the number on the request. The attacker supplied it.

This is the failure mode we see described most often, and the reason is mundane: the number is right there in the email, and looking up the old one takes effort at the end of a busy afternoon.

Calling anyone who answers. The verification has to reach a person you already know, or at minimum a person whose role you can confirm independently. "Someone in their finance team said it was fine" is not verification.

Treating it as a form field. When "callback completed" becomes a checkbox in a workflow, it gets ticked.

The control lives in the phone call. A system that records the outcome with no way of knowing whether the call happened is recording an intention, and it produces an audit trail showing the process was followed.

A callback that works has four properties. The number comes from your own records, entered before the change request. The person called is named in advance. The caller is not the person who received the change request. And the result is recorded with who called, who answered, and when.

One more thing about timing. The callback belongs to the change, not to the payment.

Verifying at payment time means the fraudulent record has already been sitting in your supplier master for weeks, waiting for an invoice to arrive against it. By then it looks established.

Internal controls on payments: maker, checker, and the limits people set wrong

Separating the person who prepares a payment from the person who approves it is the foundational one among internal controls on payments, and almost everyone has some version of it. The version usually has holes.

The first hole is the threshold. A maker-checker rule that applies above $10,000 teaches attackers to send invoices for $9,800, and teaches staff that small payments don't need scrutiny. Frequency matters as much as size: forty payments of $9,800 is $392,000.

The second is delegation.

When the approver is away and their access is handed over informally, the control disappears at exactly the moment the person covering knows least about the supplier relationships. Attackers time requests around holidays for this reason, and they don't need inside information to do it: an out-of-office reply is enough.

The third is self-approval by another route. The rule usually says nobody approves their own request. It rarely says nobody approves a request they helped prepare, or a request from a supplier they onboarded.

And the fourth is the one nobody writes down: who can change the rules.

If the person who can approve payments can also edit approval thresholds, there is one control, not two.

The approval structure that sits under this, including bands and delegation, is part of the accounts payable process, and automating the routing without weakening the check is covered in vendor payment automation.

Duplicates and ghosts in the supplier master

Two problems, one root cause: the supplier master file is usually the least governed data in finance.

Duplicate payments come from records that describe the same obligation differently. INV-4471 and INV4471. The same company under two names because someone typed "Ltd" once and "Limited" the next time. A credit note recorded as a second invoice.

Fictitious suppliers come from the fact that creating a supplier record is usually easy, and reviewing the list of suppliers is usually nobody's job. A record created in March and paid in April looks identical to a legitimate one unless somebody asks what the company does.

Four checks, run periodically rather than continuously, catch most of it:

Suppliers whose bank details match an employee's. Suppliers with no purchase orders and steady monthly invoices. Suppliers created and paid within a short window. Suppliers whose address is a residential one or matches another supplier.

None of those is proof of anything.

All of them are worth ten minutes, once a quarter, by somebody who doesn't process invoices.

The rail decides how long payment fraud prevention has to work

Once money leaves, recovery depends entirely on how it left. This is the practical reason a payment rail decision is also a fraud decision.

The pattern is consistent.

The faster and more final the rail, the more of the control has to happen before the payment rather than after it. Instant rails did not create a new fraud problem; they removed the recovery time that used to hide the existing one. The domestic trade-offs are set out in wire transfer vs ACH, and the wider set in payment rails.

The first hour after a bad payment

Have this written down before you need it, because the first hour decides the outcome and it's a bad time to be deciding who does what.

Contact your bank immediately and ask for a recall or a hold. On a wire this is a request to the receiving bank, and it works far more often at hour one than at hour six.

Report it. In the US that means the FBI's Internet Crime Complaint Center, which operates a Recovery Asset Team for exactly this situation. Speed matters because the chance of freezing funds before they move on falls away quickly.

Preserve the evidence. The original email with full headers, the change request, the approval record, the payment instruction.

Do not delete the email. Do not reply to it.

Check whether it happened more than once. An attacker who succeeded on one supplier record usually tried several.

Then fix the control that failed, not the person. If the callback wasn't done, ask why the process allowed a payment without it, because "be more careful" has a very short half-life.

Sanctions screening is a different problem

It's worth separating two things that often get merged in vendor pitches.

Fraud controls ask whether the payment is going where you think it's going.

Sanctions screening asks whether the counterparty is someone you are permitted to pay at all. Different question, different failure mode, different regulator, different consequence for getting it wrong.

Both matter, and confusing them produces a control that does neither well. The screening side, including what to check before sending to a wallet address and what the blocking obligations actually require, is set out in cryptocurrency address screening.

Payment fraud prevention when payments are irreversible by design

Every control above tightens when the payment settles on-chain, because the recovery column in that table says "none" and means it.

Three specific changes. The wallet address becomes the controlled field, with the same treatment bank details get: logged changes, second-person approval, verification through a channel the requester didn't supply. Screening happens before the first payment rather than after a problem. And a small test transfer to a new address, followed by confirmation from a known contact that it arrived, costs a few cents and removes the largest category of loss.

Address poisoning is worth knowing about specifically.

Attackers send tiny transfers from addresses that closely resemble ones you already use, so that a copy-paste from transaction history picks up theirs instead. The first and last characters match, which is exactly the part a human checks. An address book with named entries defeats it. Copying from history does not.

Platforms built for business payouts handle this as a matter of course. VaultNow keeps an address book, screening, and per-person permissions on the same dashboard as the payout run, which is what makes the check part of the process rather than a separate thing somebody remembers to do.

Frequently asked questions

What is the most common type of payment fraud against businesses?

Redirection of a legitimate payment through a change of supplier bank details, usually initiated by email. The invoice and the debt are genuine, which is what makes it effective: nothing about the payment looks wrong except the destination account.

How do you verify a supplier bank detail change?

Call a number held in your own records from before the request arrived, speak to a named person you can identify, and have the call made by someone other than the person who received the request. Record who called, who answered, and when. Never use contact details supplied in the change request itself.

What is accounts payable fraud?

Fraud that exploits the invoice-to-payment process: redirected payments to changed bank details, invoices from suppliers that do not exist, duplicate payments, and misuse of approval rights by staff. It's a process weakness rather than a technical breach in almost all cases.

What should a payment approval workflow include?

An approval band by amount with no gap at the bottom, a named delegate for absence, a rule that the preparer cannot approve, a separate control over who can change the approval rules themselves, and a mandatory second approval for any change to bank or payment details.

Can a fraudulent wire transfer be recovered?

Sometimes, and only quickly. A wire is final on settlement, so recovery depends on the receiving bank persuading its customer to return the funds and on the funds still being there. Contacting your bank and reporting it within the first hours materially changes the odds.

How do you prevent duplicate payments?

Normalise invoice numbers on entry, block on the combination of supplier, amount, and date rather than invoice number alone, keep one supplier record per legal entity, and run the duplicate check again at payment as well as at data entry.

Does automation increase or reduce payment fraud risk?

It reduces the errors and removes an informal control at the same time. The person who keyed every payment noticed unfamiliar bank details as a side effect of typing them. Removing that step requires replacing it with an explicit control over changes to payment details, or the net risk goes up.

What is address poisoning?

Sending a very small transfer from a wallet address that closely resembles one you regularly pay, so that copying an address from transaction history picks up the attacker's. Using a maintained address book with named entries, rather than copying from history, is what prevents it.

Almost every payment fraud loss traces back to a control that existed on paper and not in practice: a callback nobody made, an approval threshold with a gap under it, a supplier record anybody could edit. None of them are expensive to fix, and all of them are easier to fix before the incident that makes them obvious.

Where payments settle on-chain there's no recovery step at all, so the whole control budget has to be spent before sending. VaultNow puts screening, the address book, and permissions in the same place as the payout, so the check is part of the run rather than a separate discipline.

General information, current as at 31 August 2026. Not legal advice. IC3 figures are counts of complaints reported to the FBI, not estimates of total losses.