The vendor's own mailbox sent it
One treasury practitioner described the pattern in the AFP's 2026 Payments Fraud and Control Survey. A scammer took over the mailbox of one of the company's key vendors and began sending fake invoices, which "were processed in the normal way with all approval steps." At the same time, the fraudster asked for the vendor's bank account information to be changed, and the change "was entered into the system before Treasury could confirm the same."
Nothing in that sequence required breaking into the company. The email came from the vendor's real address. The invoices looked like every other invoice from that vendor. The weak point was the order of operations: the change reached the vendor master before anyone verified it.
A second account in the same survey shows the other common failure. Someone posing as a client emailed the sales and AP teams with updated banking details, and AP "called the number on the email to confirm the banking details." That is a callback in name only. It confirms the fraud with the fraudster.
The numbers behind the request
The AFP surveyed 465 treasury practitioners in January 2026 about their experience in 2025:
- 76% of organizations experienced attempted or actual payments fraud.
- Business email compromise affected 74%, and AFP reports that fraudsters primarily impersonate vendors or executives to request changes to payment instructions.
- Among organizations that experienced payments fraud, 33% saw manipulated ACH or wire instructions and 26% saw invoice fraud.
- 39% of organizations continue to receive genuine emails that fraudsters have intercepted.
- Among organizations with revenue under $1 billion that experienced payments fraud, 48% incurred a loss, and 24% of those recovered none of it.
The FBI's 2025 IC3 report counts 24,768 business email compromise complaints and about $3.05 billion in reported losses for 2025, the second-largest loss of any cyber-enabled fraud type after investment fraud.
Nacha now expects you to look
As of November 2026, Nacha's fraud monitoring rules apply to every business that originates ACH payments. Phase 1 took effect on March 20, 2026, for the largest originators, those with 6 million or more ACH originations in 2023. Phase 2 extended the requirement to all other non-consumer originators on June 19, 2026, with Monday, June 22 as the practical date because June 19 is a federal holiday.
The rule requires risk-based processes and procedures reasonably intended to identify entries suspected of being unauthorized or authorized under False Pretenses, and a review of those processes at least annually. Nacha defines False Pretenses as inducing a payment by misrepresenting a person's identity, their authority to act for someone else, or the ownership of the account to be credited. Nacha's guidance says this covers business email compromise and vendor and payroll impersonation. A documented, evidenced vendor bank-change control is the most direct proof that such a process exists. Ask your bank what it expects to see from you.
Five controls that stop it
1. Split request, entry and approval
Three different people should touch every bank change: one receives and logs the request, one enters it in the vendor master, and one approves it after verification. Nobody who can release payments in the bank portal should be able to edit vendor bank fields in the ERP. If the team is too small for that, the owner or controller approves every change from a system report, and the three-person duty split shows where that review fits.
2. Verify using pre-existing contact data
Call a known contact at a number that was in the vendor master before the request arrived, taken from the contract or the onboarding file. Never use a number from the request, the email signature or a new letterhead. Ask the contact to confirm the change and the name of the person who requested it, and ask them to confirm details of the old account too. Record the number, the time, the contact and the result. AFP found that 94% of organizations verify transfer requests by calling an authorized contact at a number from official records, and 63% of those rated the practice very effective. The failures quoted above are failures of execution, not of design.
3. Hold the first payment
Treat the first payment after a change as a payment to a new payee. Hold it for a set period, such as five business days, and require a second release in the bank. Send a notice of the change to the vendor's previous contact details, so a vendor that never asked for the change has a chance to say so before money moves.
4. Lock down the bank side
Use the bank portal's dual control for ACH and wires, restrict payments to saved payee templates, require a second approver to add or edit a payee, and send alerts to the controller or owner for every payee change. Positive pay and ACH debit filters cover the neighboring check and debit schemes.
5. Monitor the vendor master
Every week, someone outside AP reviews the vendor change log and matches each bank change to its verification record. A change without evidence is a finding even if the payment turned out to be legitimate. Add simple data tests: vendor bank accounts that match an employee's account, two vendors sharing one account, bank changes made shortly before a large payment, and requests from email domains one character away from the real vendor's. Full-ledger analytics runs tests like these across the whole vendor master and payment history rather than a sample.
The vendor-master change workflow
| Step | Who | What happens | Evidence kept |
|---|---|---|---|
| 1. Intake | Whoever receives the request | Log it in a change ticket. Make no change in the ERP. Reply only through contact details already on file. | Ticket with the original message attached |
| 2. Documents | AP | Ask for a signed change form and a bank letter or voided check. Documents support a request but do not verify it. | Form and bank document on the ticket |
| 3. Callback | Someone without edit rights to vendor bank fields | Call the known contact at the number on file. Confirm the change, the requester's name and the old account. | Number, time, contact and result |
| 4. Entry | Vendor master administrator | Enter the change exactly as verified. | System change log |
| 5. Approval | Controller or second approver | Compare the entry with the ticket and callback record, then approve. | Approval in the ERP or signed ticket |
| 6. Notice | AP | Send a confirmation to the vendor's previous contact details. | Copy of the notice |
| 7. First payment | Two bank releasers | Hold the first payment for five business days, then release with two approvals. | Bank release history |
| 8. Review | Someone outside AP, weekly | Match every change in the log to a complete ticket. | Initialed and dated change report |
Steps 3 and 5 are the ones that slip under deadline pressure. If you can enforce only two steps in the system, make them those: an ERP approval workflow on vendor bank fields, and a bank rule that a changed payee needs a second release.
If a payment already went out
Call your bank's fraud line immediately and ask for a recall, then file a complaint at ic3.gov with full transaction details. The FBI states plainly that time is of the essence. In 2025 its Recovery Asset Team initiated 3,900 Financial Fraud Kill Chain incidents involving about $1.16 billion in attempted theft, froze about $679 million and reported a 58% success rate. Then call the real vendor on a known number. Its mailbox may still be compromised, and its other customers may be the next targets.
Where to start
Pull the vendor master change log for the last 12 months and pick five bank changes. For each, look for the callback record: the number called, when, and who confirmed. If you cannot find it for all five, start with control 2 and the workflow table above. For a review of the whole payment chain, from vendor master permissions to bank portal settings and staff drills, see payment fraud defense. Executive requests need the same discipline, set out in the deepfake CFO payment-verification protocol.