The email came from a supplier the company had paid for nine years. Same contact name, same signature block, a reference to a real open invoice, and one request: we have switched banks, please use the new account from the next payment onward. The AP clerk updated the vendor record that afternoon, because updating vendor records was her job. Eleven days later the payment run sent €340,120 to the new account. Twenty-seven days after that, the real supplier called about an overdue invoice, and everyone learned at the same moment that the new account had never belonged to the supplier at all.
No firewall failed and no password was cracked. The attacker changed one attribute in the vendor master, using nothing more sophisticated than a polite email, and every security product the company owned sat downstream of the field that mattered. Vendor master data fraud is master data governance failing in the most expensive way available to it. The defense is not a better spam filter. It is treating bank details as what they are: the one attribute in your entire data estate that moves money directly.
One field moves the money
Almost every master data error corrupts information. A wrong conversion factor orders too much, a lazy category hides spend, a duplicate splits a purchase history in two. The damage is real but indirect, because a person or a process still has to act on the bad value before it costs anything. Bank details skip that step. The payment run reads the account number from the vendor master and sends the money there, with no human in between and no moment where anyone looks at it. The vendor master is the payment instruction.
Attackers worked this out years before most governance programs did. The FBI's Internet Crime Complaint Center counted $2.77 billion in reported business email compromise losses in 2024, and the supplier impersonation scheme is one of its oldest forms: pose as a vendor, request a bank detail change, wait for the payment cycle to do the rest. The target is whoever has edit rights on the vendor master, not your bank and not your network, because changing the record is far easier than intercepting a payment.
The same fraud, five shapes
None of these need malware. Most do not even need much skill, just patience and a plausible story. What they all need is a vendor master nobody is watching.
The convincing email
An outsider impersonates the supplier: a lookalike domain, the right logo, invoice numbers lifted from a compromised mailbox or guessed from a predictable sequence. No technical control trips, because technically nothing happened. A person was asked to edit a field, and editing that field was part of their job.
The hijacked thread
The supplier’s own mailbox is compromised, and the change request arrives inside a genuine conversation about a genuine order, from the real address, quoting the real history. Replying to double-check goes straight back to the attacker, who is happy to confirm. Email verification cannot survive this one, which is why the callback has to use a number from the record, not from the thread.
The insider edit
Someone with legitimate access changes the account, waits out one payment run, and changes it back. Between the two edits, every report looks normal. Without field-level history recording the old value, the new value, and who saved it, the window closes behind them and the missing payment gets filed as a bank error.
The duplicate vendor
A second record for the same supplier, name one character off, real tax number, fraudulent account. One invoice gets routed to it. Duplicate checks tuned for data quality treat it as a housekeeping problem to merge someday, not as a payment heading out the door this Thursday.
The revived vendor
A supplier dormant for three years is reactivated with fresh bank details and a plausible invoice. Dormant records sit outside everyone’s attention because nothing has happened to them for years, which is what makes them the quietest way in.
Five shapes, one signature: bank details changed, and a payment followed soon after. That is good news, in a limited way, because a fraud whose signature lives in the data can be caught in the data, before the payment run instead of thirty-eight days after it. The last two shapes also point at chronic hygiene problems worth fixing in their own right: duplicate records and a record lifecycle with no owner for the dormant end of it.
Controls that live in the data, not the inbox
The standard advice is to train AP staff to be suspicious. Do that, and then do not build the defense on it, because the fraud is designed to be indistinguishable from the thousand legitimate change requests the same clerk handled correctly last year. The controls that hold are structural, and there are three of them.
Put an approval in front of the change. Bank details change only through a workflow where a second person, never the editor, sees the old value and the new value side by side and signs off before the record updates. One clerk can be fooled by a good email. The fraud now needs two people fooled in sequence, one of whom is looking at a screen that says this field controls where the money goes.
Verify out-of-band, against the record you already have. Call the supplier on the phone number that was on the vendor record before the change arrived, never a number from the email that requested it, because the hijacked-thread variant exists precisely to poison that channel. This is the cheapest control on the list. It costs one phone call per bank change, and a mid-size company does not process many of those in a week.
Make bank-detail changes visible as a class. A field-level audit trail records every change with who, when, old value, and new value, and a standing report of every vendor whose bank details changed since the last payment run gets reviewed before the run is released. That single report turns the fraud's own timing against it: the attacker needs the change to sit quietly until payday, and the report makes payday the moment someone looks. It also catches the shapes the approval step can miss, the brand-new vendor paid within days of creation, the dormant vendor reactivated with a fresh account, the details changed and changed back inside one cycle.
If you are coming off MDS
Microsoft MDS had the raw material for this and never assembled it. The transaction log recorded old value, new value, user, and timestamp for every attribute change, which is the evidence a fraud review needs, but it was evidence, not a control: nothing stopped the change from landing, and reading the log meant querying it. Approval only arrived with changesets in SQL Server 2016, awkward enough that plenty of installations never turned it on. Meanwhile the Excel add-in would cheerfully publish a pasted column of new bank accounts across four hundred vendors in one click, from any user with update permission.
If you are migrating off MDS, spend one hour of the project on this question: which entities carry payment-relevant attributes, and does the new system put an approval step and a readable audit trail in front of them from day one. It is a small line item next to the rest of the migration, and it is the difference between the story at the top of this post and a change request that died in a review queue where it belonged.
Common questions
What is vendor master data fraud?
Payment fraud committed by altering supplier records instead of intercepting payments. The attacker, an outsider impersonating the supplier or an insider with edit access, changes the bank account on the vendor master and lets the normal payment run send the money. The FBI counted $2.77 billion in reported business email compromise losses in 2024, and the supplier bank detail change is one of its classic forms.
How does supplier bank account change fraud work?
It looks like routine supplier admin: an email announcing new bank details, often referencing real invoices, sometimes sent from the supplier’s own compromised mailbox. Someone updates the vendor record, the next payment run pays the new account, and the theft surfaces weeks later when the real supplier chases an invoice that was already paid to someone else.
Which controls prevent it?
A four-eyes approval so no single person can change bank details alone. Out-of-band verification using a phone number that was on the record before the change, never one taken from the request. And a report of all bank-detail changes since the last payment run, reviewed before payments go out. Training helps, but these three do not depend on someone being suspicious on the right day.
Does an audit trail help once the money is gone?
It decides how the aftermath goes. Who changed the account, when, and from what old value is what the bank and the insurer ask for in the first days, when a recall is still sometimes possible. It is also the only way to catch the change-back pattern insiders use. Without it, reconstructing the fraud means guessing.
Put an approval in front of the field that moves money
Primentra runs changeset-based approvals on the entities you flag, so a bank-detail change is a proposed change until a second person reviews and approves it, and the audit trail shows exactly who changed which field and when. It runs on your own SQL Server, deploys in a day, and costs €7,500 per year flat. The 60-day trial is long enough to route a full payment cycle's worth of vendor changes through it.