# Who approves a vendor's new bank details? > A vendor's new bank details are a payment control, not an email task. What FBI, AFP and UK data show, and how to move the check from habit into the system. - Author: Marlon Trettin - Published: 2026-10-24 · Updated: 2026-10-24 - Language: en - Canonical: https://yowpi.com/en/blog/who-approves-a-vendors-new-bank-details --- The person who receives the email should not be the person who approves the change. A vendor's new bank details should enter your system as a recorded request, get verified by someone else through a known contact, and hold the first payment until that check is done. A policy that lives only in people's heads fails on a busy day. ## TL;DR - Business email compromise (BEC) is the second-largest loss category in the FBI's 2025 report: [24,768 complaints and about $3.05 billion in reported losses](https://www.ic3.gov/AnnualReport/Reports/2025_IC3Report.pdf). - In the [AFP 2026 survey](https://www.financialprofessionals.org/about/learn-more/press-releases/Details/over-75-percent-of-us-firms-experienced-payments-fraud-in-2025-while-ai-adoption-for-fraud-mitigation-lags), 74% of the organizations surveyed were affected by BEC in 2025, and 76% reported attempted or actual payments fraud. - The standard advice is right: confirm a bank-detail change by calling a number you already used. It is weakest when it depends on one busy person remembering to do it. - The fix is architectural. Bank details live in one record, every change is a logged request, a different person verifies it, and the payment run blocks until they do. ## How common is payment diversion, and what do the numbers say? Common enough to be a routine risk, not an exotic one. The FBI's Internet Crime Complaint Center counted [24,768 BEC complaints in 2025, with reported losses of $3,046,598,558](https://www.ic3.gov/AnnualReport/Reports/2025_IC3Report.pdf), second only to investment fraud. Its definition describes scams aimed at businesses that work with suppliers or regularly make wire transfers. The Association for Financial Professionals surveyed 465 US treasury practitioners in January 2026. [76% reported attempted or actual payments fraud in 2025, and 74% were affected by BEC](https://www.financialprofessionals.org/about/learn-more/press-releases/Details/over-75-percent-of-us-firms-experienced-payments-fraud-in-2025-while-ai-adoption-for-fraud-mitigation-lags). Nacha, summarizing the same report, notes that this was [up from 63% in 2024](https://www.nacha.org/news/business-email-compromise-attempts-rose-sharply-2025-report-finds). In the survey, 85% of respondents received spoofed emails, and more than half saw messages from domains that looked almost identical to legitimate ones. The UK shows the vendor-specific version. In the National Crime Agency's January 2026 campaign notice, citing Action Fraud figures for September 2025, [invoice fraud accounted for 85% of payment diversion fraud losses, and the figures cited were £3,908,086 across 83 cases, an average above £47,000 per case](https://www.nationalcrimeagency.gov.uk/news/nca-and-natwest-launch-campaign-to-protect-against-invoice-fraud-in-business). That is one month of data, and the FBI category is broader than bank-detail changes. Read both as direction, not as a rate your company will experience. ## Why does "call the supplier back" fail in practice? Because it is a habit, and habits depend on whoever is at the desk. The advice itself is sound. The NCA tells businesses to [verify by calling the genuine supplier on a previously used phone number before transferring money](https://www.nationalcrimeagency.gov.uk/news/nca-and-natwest-launch-campaign-to-protect-against-invoice-fraud-in-business). The weakness is in the process around it, and this part is our reasoning, not survey data. The clerk who receives the request is also the one under pressure to pay on time. The phone number can easily be the one in the same email thread. Nobody else sees that a change happened, so nobody can ask whether the call was made. This is not a technology problem. It is an architecture problem: the control has no place in the system, so it lives in someone's memory. And when more than half of surveyed organizations receive mail from near-identical domains, "the email looked right" is not evidence of anything. UK police guidance reproducing Action Fraud advice points the same way. It says changes to payment arrangements should be [limited to designated employees through an established internal process](https://nbcc.police.uk/crime-prevention/cyber-and-fraud/bank-mandate-fraud). A process, in other words, not a reminder. ## What does a system rule look like? It turns four informal decisions into things the software enforces. You may not need a fraud platform for any of them. You need the bank-detail field to stop being an open text box. The first is one place. Supplier bank details live in a single vendor record. Not in the latest invoice, not in a spreadsheet of "who we pay," not in someone's inbox. Whatever the payment run reads, it reads from there. The second is a request, not an edit. A change is submitted as a request that records who raised it, through which channel, and when. The live details stay untouched until the request clears. The third is a different verifier. Someone other than the person who received the request confirms it, using a contact stored before the request arrived, and logs the result. This is the same separation of duties you would want on any payment approval, and it connects to how you handle [who sees and edits what](/en/blog/access-control-who-sees-what) in the first place. The fourth is a blocked payment run. A record with an unverified change cannot be paid. The first payment to a newly changed account goes to a named reviewer. Every step leaves a trail, which is exactly the material [audit logs](/en/blog/audit-logs-to-analyze-operational-deviations) are for when someone later asks what happened. ## Doesn't an extra approval step slow payments down? Only for the payments that should be slowed. Count the bank-detail changes your team handled last quarter against the invoices it paid. For most companies the first number is far smaller, and the rule applies only to it, so routine payments to unchanged accounts move as before. The real risk is a control that stalls for the wrong reasons: a verifier who is on leave, a queue nobody owns. That is a design question about ownership and fallback, the same one behind most [approval bottlenecks](/en/blog/approval-bottlenecks-where-process-stops). Name a primary verifier and a backup, and put an age limit on open requests so a stuck one gets noticed. ## An example of how this plays out The scenario below is hypothetical. It describes a mechanism, not a measurement. Picture an industrial distributor with 60 employees and several hundred active suppliers. Supplier bank details sit in a field of the accounting tool that three people can edit, and changes arrive by email to the accounts payable clerk. One morning an email arrives from what looks like a long-standing supplier, on a domain one letter off, with a letter attached announcing a new account. The clerk, who is also closing the month, updates the field. The next payment run pays the new account. With the rule in place, the same email creates a request. The live details do not change. A second person looks up the supplier's number from the original contract, calls it, and learns that no change was requested. The request is rejected, logged, and the payment run does not see a new account. Nothing about the clerk's diligence changed. What changed is that the outcome no longer depended on it. ## Frequently asked questions **We are a small team and already have a callback policy. Isn't that enough?** A policy tells people what to do. It does not show you whether they did it, and it does not stop a payment when they skipped it. If the callback is logged against the change and the payment run checks that log, the policy becomes a control. If it lives in a handbook, it works until the busiest week of the quarter. **Will this add a lot of work for a team that is already stretched?** It adds work only to bank-detail changes, which you can count in your own records. Most of the effort is one-time: moving bank details into a single record and defining who verifies. After that, the added work follows the number of changes, and the alternative is a payment you may not recover. **Our accounting software lets us add a bank account. Do we need custom software?** Not necessarily. First check whether your current tool can hold a change as a pending request, require a second approver and block payment until it clears. If it can, configure it. If bank details also travel through emails, spreadsheets or a separate onboarding form, the gap is the connection between those places, and that is an integration question before it is a software one. ## The next step If you cannot say today who verifies a supplier's new bank details, or where that verification is recorded, the Operational Architecture Diagnostic is a 30-minute conversation to map where the control lives and where it depends on memory: [book it through our contact page](/en/contact).