Most fraud that costs a company money does not involve breaking into anything. It involves changing one field. The vendor master file is the list of everyone the organization pays and the bank details it pays them to. It is maintained by a small number of people in accounts payable or procurement, updated routinely, and reviewed almost never. A change to a bank account number in that file redirects every subsequent payment to that supplier, silently and permanently, until someone complains about not being paid. That is the entire attack. There is no malware, no intrusion, no exploit. It is a request that looks like a hundred other legitimate requests, processed by a person doing their job correctly according to a process that was never designed to resist deception.
Why This Attack Works So Well
Four structural features of the back office make vendor master fraud unusually effective. The change is routine. Suppliers genuinely do change banks, restructure, get acquired and move payment details. Refusing or interrogating every such request would break normal operations, so the process is built to accommodate them efficiently. The controls sit on the transaction, not the master record. Organizations invest heavily in approval limits, three-way matching and payment authorisation — all of which examine whether a payment should be made, and none of which examine whether the destination account is correct. An approved invoice paid to a fraudulent account passes every control cleanly. Detection is delayed by the payment cycle. The supplier notices non-payment when they chase, typically after their credit terms expire. Thirty to sixty days can pass between the change and the first question, by which time several payment runs have executed and the funds have been moved through multiple accounts. The request arrives with authority. Fraudsters use compromised or spoofed supplier email accounts, correct letterheads, real contract references and genuine invoice numbers — frequently harvested from a real compromise of the supplier's mailbox. The AP clerk is not being careless. They are receiving a request that is indistinguishable from a legitimate one on its face. The internal variant is worse and less discussed: an employee with maintenance rights to the vendor master creates a supplier, or amends an existing one, and directs payments to an account they control. Where the same person can create a vendor and approve a payment, this requires no deception at all.
The Segregation Failure at the Centre of It
The control that prevents most of this is old, well understood, and frequently absent in mid-market finance teams for an entirely practical reason: there are not enough people. In a finance function of six, the person who maintains supplier records is often the person who processes payments, because splitting those duties would require a seventh person for work that does not fill a role. Segregation of duties gets documented in a policy and undermined in practice by a system role that was granted "temporarily" during an implementation and never revoked. The result is that the organization's actual control over where its money goes rests on the integrity and attentiveness of one or two people, with no independent verification that the details they maintain are correct.
Practical Guidance for Protecting the Vendor Master
- Verify every bank detail change by callback to a number you already hold. Not the number on the request, not a number in the email signature. A previously recorded number from the contract or the supplier record. This single control defeats the large majority of external attempts.
- Separate vendor master maintenance from payment processing. If team size makes full separation impossible, require a second person to approve the change — approval is cheaper than segregation and achieves much of the same effect.
- Report every master data change to a person who did not make it. A daily or weekly list of vendor additions and bank detail amendments, reviewed by a manager. Cheap, fast, and the most commonly missing control.
- Impose a cooling-off period before paying to changed details. A short hold on payments to a recently amended account, with a confirmation step, removes the speed the attack depends on.
- Notify the supplier through a separate channel when details change. A letter or call to the existing recorded contact. If the change is fraudulent, the real supplier tells you immediately.
- Audit the vendor master for anomalies regularly. Bank accounts appearing against more than one supplier, addresses matching employee addresses, suppliers with no recent transactions, and records created and paid within a short window.
- Review who holds maintenance rights, and remove the ones granted during implementation. This access list is almost always longer than anyone expects and contains at least one person who should no longer be on it.
- Train AP staff on the specific scenario, with authority to pause. The clerk who delays a payment to verify a detail must be supported when the supplier complains. Without explicit backing, pressure wins.
Verify independently
Use a previously recorded contact, not the number in the new request.
Approve separately
Require a second reviewer or separated maintenance and payment roles.
Confirm through another channel
Tell the existing supplier contact that details have changed.
Monitor the master
Review changes, unusual records and access rights.
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Why This Became a Category
What was an opportunistic crime in 2012 became an industrialised one. Business email compromise — the broader category that vendor master fraud sits inside — grew into one of the highest-loss forms of cybercrime by value, consistently exceeding ransomware in reported losses in some jurisdictions, precisely because it requires no technical sophistication and produces immediate cash. The method matured in two ways. Attackers began compromising supplier mailboxes and waiting — reading correspondence for weeks to learn the invoice cycle, the contacts and the language, then intervening in an existing thread at exactly the right moment. And they moved upstream, targeting suppliers with weak security to reach their larger customers, which made a company's exposure a function of its suppliers' security rather than its own.
The Regional Exposure
The Gulf presents a combination that suits this attack particularly well. Businesses here transact internationally as a matter of course, so an international transfer to a new account raises no inherent suspicion. Trading and contracting groups maintain large, frequently changing supplier lists across multiple jurisdictions. Payment values in construction, commodities and logistics are high, so a single successful diversion is worth a great deal. Recovery is the hard part. Once funds leave through the correspondent banking network, retrieval depends on speed and on cooperation between banks in different jurisdictions. Organizations that detect within hours sometimes recover. Organizations that detect after the supplier chases, thirty days later, almost never do.
What AI Changed
The defence that quietly carried most of the weight for years was linguistic. Fraudulent requests were often identifiable by awkward phrasing, inconsistent tone or a formality that did not match the usual correspondence. Experienced AP staff developed an instinct for it. That signal is gone. Generative tools produce requests in fluent, contextually appropriate business English, matched to the tone of a prior thread. Voice synthesis has removed the reliability of recognising a familiar voice on a confirmation call, which undermines the callback control unless the number — not the voice — is what is being verified. This makes the procedural controls more important, not less. Callback to a number already on file, second-person approval, notification through an independent channel and post-change monitoring all work regardless of how convincing the request sounds. Controls that depend on someone noticing something odd no longer do.
Common Questions
What is vendor master fraud?
Fraud that works by changing supplier bank details in the vendor master file so that legitimate payments are redirected to an account the fraudster controls. It requires no system intrusion — only a convincing change request or inappropriate internal access.
Why do standard payment controls not catch it?
Because approval limits, matching and payment authorisation verify that a payment is owed, not that the destination account is correct. A genuine invoice paid to fraudulent details passes every one of those controls without exception.
What is the single most effective control?
Verifying every bank detail change by telephoning a number already held on file — from the contract or the existing supplier record, never a number supplied in the change request itself.
How can small finance teams segregate duties?
Where headcount prevents true separation of vendor maintenance from payment processing, require second-person approval of every master data change and send a report of all changes to a manager who did not make them. Both are achievable without additional staff.
AP Controls Assessment — Outpace reviews who can change your supplier bank details, what happens when they do, and where a single request could redirect your payments.