The vendor invoice scam: deconstructing account details substitution
This fraud does not require a forged invoice, a fake domain or a spoofed sender. It requires access to a real vendor's mailbox and the knowledge that account numbers are displayed truncated on the screen where they are approved.
Why is vendor bank change fraud so hard to stop?
Because nothing about it is anomalous. The invoice is genuine, the letterhead is genuine, the vendor's email account is genuine — it is simply controlled by someone else. The changed field arrives inside a legitimate document, through a legitimate channel, from a legitimate sender.
- The attacker sends from the vendor's real mailbox, so every email authentication check passes. There is no signal to detect.
- Approval screens truncate account numbers and bury change flags in sub-tabs, which is where the substituted digits live.
- Total rendering — showing every material field in full at the moment of approval — is the cheapest half of the fix and requires no cryptography.
Part of Payment release authorization
The sequence, with the detection opportunities marked
- Vendor mailbox compromised. Typically through credential phishing at the vendor, not at you. No detection opportunity on your side.
- Attacker observes. They read months of correspondence, learn invoice cadence, amounts, contacts and tone. None.
- Change request sent. From the genuine mailbox, on genuine letterhead, referencing a real invoice. SPF, DKIM and DMARC all pass because the mail is genuine. None from email authentication.
- AP updates the vendor record. Sometimes after a callback to a number in the email. This is the control point, and it usually fails.
- Invoice approved. The approver sees vendor name, amount and reference. The account number is truncated. This is the second control point, and the interface defeats it.
- Payment released. Recovery window measured in hours for a wire.
Why every email control passes
Organisations invest heavily in email authentication, and it works against spoofing — a message claiming to be from a domain it did not originate from.
This attack does not spoof. The message originates from the vendor's genuine infrastructure, signed by their genuine keys, from their genuine mailbox. Domain-based authentication confirms it is authentic, which it is. The compromise is upstream of everything your gateway can evaluate.
The account masking problem
Truncating account numbers in user interfaces is a habit imported from consumer banking, where it prevents shoulder-surfing of a customer's own account. In an approval screen it is actively harmful.
Consider a genuine account number and a substituted one, displayed as most AP systems display them:
Genuine GB29 NWBK 6016 1331 9268 19 displayed as ****9268 19
Substituted GB29 NWBK 6016 1331 4471 02 displayed as ****4471 02
Genuine 021000021 / 5847392016 displayed as ****2016
Substituted 121000248 / 9932847016 displayed as ****7016In the second pair, the routing number changed entirely — a different bank, a different state — and the display shows only trailing digits of the account. An approver comparing against memory or against a prior payment sees a different suffix, which is exactly what a legitimate account change would also show.
Total rendering, which costs nothing
The first half of the fix requires no cryptography, no vendor enrolment and no new system. Change the approval screen to render every material field in full:
- Beneficiary legal name, in full, as it will appear on the payment.
- Account number, complete and unmasked.
- Routing, sort code or SWIFT, complete.
- Beneficiary bank name and country.
- A prominent indicator where any of these changed since the last payment to this vendor, with the previous values shown alongside.
The last item is the highest-value single change available, and most AP systems either do not surface it or bury it in a sub-tab an approver never opens.
The second half: verifying the change itself
Rendering helps the approver notice. It does not establish that the vendor requested the change, which is the underlying question.
That requires a signal from the vendor that an attacker in their mailbox cannot produce: a signed change statement from the vendor's authorised officer, rendering the full old and new details, verifiable by you without calling anyone.
The callback disappears from the critical path, which matters because the callback is the step that most often fails — the number came from the compromised mailbox.
What to do this week
- Pull every vendor bank detail change from the last twelve months. Count them.
- For each, determine whether it was verified by any means beyond reading the request, and whether the contact used came from the request itself.
- Screenshot your own approval screen. Count how many of the five material fields are rendered in full.
- Compute your exposure: average payment value to a vendor over the interval between a details change and the next reconciliation.
That fourth number is your loss per undetected substitution, and it is usually larger than people expect because it spans multiple invoices rather than one.
Why the usual controls miss it
| Control | Why it misses |
|---|---|
| Email authentication | The mail is genuine — the account is compromised, not spoofed |
| Invoice matching | The invoice is real and matches a real purchase order |
| Callback verification | The number often comes from the fraudulent message |
| Anomaly detection | A vendor changing banks is a normal, frequent event |
| Dual approval | Two people compare the same masked field on the same screen |
The single highest-value change is to gate the amendment rather than the payment, and to render the delta: what the details were, what they are becoming, when they last changed and through which path. A change plus a recent prior change is the strongest signal available.
Objections and honest limits
“We verify every change by phone.” Then the control is only as good as where the number came from. Use a number from the vendor record as it stood before the change request, and record which number was used.
“The vendor should secure their email.” They should. You cannot make them, and your loss does not depend on their improving. The control has to work while their mailbox is compromised.
Gating the amendment
- Treat a banking change as its own approval event. Separate from invoice approval, with its own evidence.
- Render the delta in full. Old and new account, old and new bank, last change date and path.
- Call a number from the pre-change record. And record which number was used, not just that a call occurred.
- Ask the vendor to countersign. For your top twenty payees by value, which is most of the exposure.
- Hold the first payment after a change. A short delay costs little and removes the attacker's timeline.
Terms used here
- Vendor master
- The stored supplier record including banking details. Amending it redirects every future payment.
- Business email compromise
- Fraud conducted from a genuine, compromised mailbox rather than a spoofed one, which is why authentication controls do not detect it.
- Delta approval
- Approving a change by reviewing what it changes from and to, rather than reviewing the resulting record.
Frequently asked questions
Would better email security stop this? No. The message is genuine, sent from the vendor's real mailbox. Every authentication check passes correctly because there is nothing inauthentic about the message.
Is the callback useless? It is useful when the number comes from your own vendor record rather than from the request, and it still fails when the vendor's own systems and phone are compromised. Treat it as one signal, not as verification.
Why is masking harmful here? It hides the characters an attacker alters. Masking protects a customer viewing their own account; it degrades an approver verifying someone else's.
What is the cheapest improvement? Render all material fields in full and flag changes since the last payment with the old values shown. No new system, no vendor cooperation, immediate effect.
Why doesn't email authentication help? Because the mail is genuine. The vendor's own account is sending it; nothing is spoofed.
Why gate the change rather than the payment? The change redirects every future payment. A perfectly controlled payment to an altered record is still a loss.
What is the strongest available signal? A banking change, combined with how recently the details last changed and through which path.
Where this fits in Manav
Manav renders the full beneficiary details and the delta from what was on file, binds the approver's signature to that exact payload, and has the payment service recompute the digest before it releases funds.
Sources and further reading
- FBI IC3 2025 Internet Crime Report
- AFP — Payments Fraud and Control Survey
- Email authentication specifications: SPF, DKIM and DMARC, and their scope.
- Research on visual verification and truncated identifier comparison.
- Nacha Operating Rules