"We've Changed Our Bank Details": Checking a Supplier Email Before You Pay It

The invoice is real. The bank account might not be

Most vendor payment fraud doesn't involve a fake invoice at all — it involves a completely genuine one, with genuine amounts and a genuine supplier name, and a single altered detail: the bank account. Guidance from Old National Bank and the Federal Small Business network describes the same red flag over and over — an unexpected email asking you to update ACH or wire details, timed to arrive mid-project or just before a payment is due, styled exactly like the supplier's normal correspondence because in many cases it genuinely is the supplier's account, just compromised.

A case documented by the FSB illustrates why this is harder to spot than it sounds. A business received what looked like a routine update from a long-standing vendor, in the same tone, same formatting, same email address as always. The payment went through normally. Three weeks later the real vendor asked why they hadn't been paid — the two sides compared records and found different account numbers on file. The vendor's mailbox had been compromised, and the criminals had been quietly editing genuine messages and sending them back out through the same visible thread, so nothing about the email address or thread history looked wrong at any point.

A concrete example

What to check when a payment-details email lands

For accounts payable, bookkeepers, or anyone with authority to update a vendor record.

The situation

An email arrives from a supplier your business has worked with for two years, asking you to update their bank details ahead of next month's invoice. The tone, signature and email address all look exactly like previous correspondence.

Source and destination you choose

Where it comes from

The original email file (.eml or .msg)

Saved directly rather than forwarded, to keep the headers intact

Why this one: The routing and authentication information that matters here isn't visible in the message body.

Also works with

Pasted raw headers
A batch of recent invoices from the same sender for comparison

Where the result goes

Forensics report (PDF or CSV)

Header analysis, authentication results, routing path and sender domain details

Why this one: Something concrete to attach to an internal fraud-check note before the record is updated.

Or choose

On-screen review before download
Plain text summary

What the report actually surfaces

1

Sender domain comparison

Checks the sending domain against what would be expected, which is where lookalike domains — a swapped letter, an extra hyphen — tend to show up.
2

Authentication status

SPF, DKIM and DMARC results for the message, shown plainly rather than as raw header text.
3

Routing path

The servers the message actually passed through, flagged if that path is inconsistent with how this sender's previous mail has arrived.
4

A summary you can act on

What looks normal and what's worth a second look, in plain language.

If this vendor's real mailbox has been taken over, the message will pass SPF and DKIM because it genuinely was sent from that account — authentication checks catch spoofing, not account takeover. Treat a clean report as one input, not a green light on its own.

The verification step that actually stops this

Every fraud-prevention resource on vendor payment fraud lands on the same control, regardless of company size: never use the phone number or contact details in the email requesting the change. Call the vendor using a number already on file — from a signed contract, a previous invoice, or your vendor master record — and confirm the change verbally before updating anything. Adaptive Security's payment verification guidance adds a second layer worth adopting even for a small business: require a second person to approve any bank detail change, so a single email and a single employee's mistake can't complete a fraudulent payment on its own.

Questions accounts payable teams ask

We already called and confirmed the change. Is a header check still worth doing?

It's a useful second data point and a good record to keep, but the phone verification is the control that actually matters. Do that regardless of what the header analysis shows.

Can this catch a lookalike domain automatically?

It surfaces the sending domain and flags anomalies for you to compare against what you'd expect — it's a strong aid for spotting a subtle domain swap, but it's still worth reading the sender address character by character yourself.

What should we do if the report and the phone call disagree?

Treat the phone-verified answer as the one that matters, but stop the payment and escalate internally — a mismatch between what a supplier says on the phone and what the email's headers suggest is exactly the kind of case worth a closer look before any money moves.