# Supplier asking to change bank details > The email looks normal, the sender is right, the invoice matches. This is the most common form of invoice fraud, and how to tell in ten minutes. Canonical: https://vetthisvendor.com/guide/supplier-changed-bank-details Published: 2026-08-02. Updated: 2026-09-09. Author: Jose Pollman, VetThisVendor. If you have an email in front of you from a supplier saying their bank details have changed, stop before you update anything. This request is the single most common form of invoice fraud in Europe, and the version that works does not look suspicious at all. If the request arrived by email, the [supplier email check](/tools/supplier-email-check) reads that message in your browser and says whether it really came from your supplier’s domain. **The one thing to do: phone them on a number you already had.** Not the number in the email, not the number in the signature, not the number on the new invoice. A number from an old invoice, your accounting system, or their website that you navigated to yourself. Everything below explains why that specific step is the one that matters. ## Why the email looks completely normal The version of this fraud that succeeds is not a stranger with a lookalike domain. It is a **real email, from the real supplier's real mailbox**, because somebody got into that mailbox — usually with a password from an unrelated breach, or a phishing page that collected it weeks earlier. Once inside, the attacker reads the mail thread. They see your PO numbers, your payment terms, the name of the person who normally emails you, how that person signs off. They often wait for a genuine invoice to be sent, then follow up on the same thread with new account details. Sometimes they set a mailbox rule so your replies are hidden from the real supplier, which is why "I emailed to check and they confirmed" is not confirmation. This means the usual checks pass: - The **sending domain is genuine** — it is their domain, so SPF and DKIM pass. - The **email address is correct**, character for character. - The **VAT number on the invoice is real and registered**, because it is their VAT number. - The **thread history is real**, because it is the real thread. - The **new IBAN passes its checksum**, because a working account was opened to receive the money. Nothing on the invoice is forged. Only the destination changed. ## Why the phone call is not a formality Every automated check answers a question about *identity*: is this a real business, is this a real VAT registration, is this a well-formed account number. None of them answers the only question that matters here, which is about *authority*: did this business actually ask you to send money somewhere new. No public data source can answer that. Bank account ownership is not public in the EU or UK, so nothing you can look up will tell you whose name is on the account. A human being at the supplier can, in about a minute. Use a number you already had — that is the whole point. An attacker who controls the mailbox also controls the phone number in the signature of the email they sent. ## What to check while you wait for the call back None of these is a substitute for the call. They are useful because they occasionally turn a "probably fine" into an obvious answer, and because they cost a minute. - **Does the IBAN country match where the supplier is registered?** A German supplier whose account is suddenly in another country is worth naming on the call. It is often innocent — group treasury, factoring, or a payment provider like Wise or Revolut — but it is a fact worth stating out loud. See [IBAN country differs from VAT country](/guide/iban-country-mismatch). - **Does the name on the registry match the name on the invoice?** See [VAT number is valid but the name is different](/guide/vat-name-mismatch). - **Is the domain exactly right?** Read it character by character, right to left. `rn` looks like `m`, `l` looks like `I`, and an added or dropped hyphen is invisible when you already know what the word says. - **Does the domain enforce DMARC?** If it does not, anyone can forge mail from it, which widens the range of ways this email could have reached you. See [No DMARC policy](/guide/no-dmarc-policy). You can run the VAT number, the new IBAN and the domain together on [the homepage](/) in one submission. ## Signs worth taking seriously None of these is proof, and their absence is not reassurance. They shift the odds: - **Urgency attached to the change.** "Before the month end", "the old account is closed as of today", "the payment failed, please resend". Urgency exists to stop you phoning. - **A change that arrives with an invoice** rather than as its own notice from an account you already know. - **A request to keep the change quiet**, or to route the confirmation through the same email thread rather than any other channel. - **Reply-to differs from From.** Worth a look in the message headers, though its absence means nothing when the mailbox itself is compromised. - **The amount is unusually round, or unusually large**, relative to what this supplier normally invoices. - **First contact is a bank change.** A supplier you have never paid before, whose first substantive email is new account details. ## If you have already paid Speed decides the outcome, so do this before anything else. 1. **Call your bank immediately** and ask them to attempt a recall. Money can sometimes be stopped within hours; after a day or two it is usually gone. Say the words "authorised push payment fraud" — it is the term that routes you to the right team. 2. **Call the supplier** on a known number, so they learn their mailbox is compromised. They are a victim here too, and other customers of theirs are being targeted with the same email today. 3. **Report it.** In the UK, Action Fraud. In the EU, your national police cybercrime unit — most take online reports. A crime reference is usually required before a bank will consider reimbursement. 4. **Keep everything** — the email with full headers, the invoice, payment confirmation, and a note of who you spoke to and when. In the UK, reimbursement rules for authorised push payment fraud changed in October 2024 and cover many cases that previously went uncompensated. Ask your bank directly rather than assuming either way. ## What Verification of Payee does and does not cover Since **9 October 2025** every bank in the euro area has been required to check the payee's name against the IBAN before you confirm a credit transfer. You enter the account, and your bank tells you whether the name on it matches the name you typed. The obligation comes from the EU's Instant Payments Regulation, and it applies to ordinary transfers as well as instant ones. This is the single best control that has ever existed against this specific fraud, and it changes what the phone call is for rather than replacing it. **What it catches.** The account is in somebody else's name. That is the ordinary shape of this fraud, and the bank will now say so before the money moves. **What it does not catch, and this is the part worth knowing:** - **A "close match".** Banks report near-misses as well as matches, and a near-miss is exactly what a legitimate trading-name difference looks like — and also what a deliberately similar account name looks like. The screen does not distinguish them. - **A mule account opened in the supplier's name.** If the account really is in that name, the check passes. It is a check on the account, not on who asked you to pay it. - **Anything outside the euro area.** The UK has had Confirmation of Payee since 2020; much of the rest of the world has nothing. - **A payment you make by any other route.** A direct debit change, a card payment, a standing order amended in a portal. So the rule does not change: **a change of bank details is verified by voice, on a number you already had.** Verification of Payee tells you whose account it is. It cannot tell you whether your supplier asked you to pay into it, and that remains the question. [What the bank payee check does and does not cover](/guide/verification-of-payee) goes through it in full. ## Making it not happen again The control that works is a rule, not a habit: **bank detail changes are verified by voice on a stored number, every time, by someone other than the person who received the request.** Written down, applied to everyone, no exceptions for people you like. Store supplier phone numbers in your accounting system, not in your inbox, so the number you call cannot be edited by whoever sent the email. And treat a change confirmed only by email as not confirmed at all — including a reply that arrives from the correct address. There is a [one-page checklist](/guide/bank-change-checklist) for this — who called whom, on which number, who signed it off — to print and keep with the payment.