Safeguard
Security Guides•

Checklist: verifying a vendor bank detail change request

A checklist for confirming vendor payment changes so a spoofed or hijacked email cannot redirect your money. Built for engineers who own the workflow.

Safeguard Security Team
3 min read

Never act on a bank detail change from the email that requested it. Confirm it through a second channel you already trust, such as a phone number from your vendor records, and require a second person to approve the change. That one rule defeats most payment redirection fraud.

Why email alone cannot be trusted

A request can come from a lookalike domain, a forged display name or a genuinely hijacked mailbox. In the last case the sender address is correct and the thread is real. Your eyes cannot settle it.

CISA's phishing guidance gives the right instinct: do not use any link or number in the message. Contact the company through its verified website, or reach the person by a different method you already trust. The FTC says the same for account and payment updates.

The checklist

  1. Treat every change as a request, not an instruction. New account number, new bank, new remit-to name, new payment portal, all count.
  2. Look up the contact yourself. Use the phone number in your vendor master record or the signed contract, not the one in the email or a new signature.
  3. Call and ask the vendor to read the details back. Do not read your copy to them first.
  4. Record who you spoke to, when, and the number used. This is the audit evidence.
  5. Require a second approver who did not take the call. One person should not be able to both verify and release.
  6. Hold the first payment to a changed account for a short, defined delay, if your process allows it.
  7. Send a small test amount or confirm with the bank where that is routine for you.
  8. Warn the vendor about the incident if the request looks fake, since their mailbox may be compromised.

Design it into the system

Engineers can make the safe path the easy one.

  • Lock vendor bank fields so edits need a ticket with the verification record attached.
  • Block edits that arrive through a shared inbox with no ticket.
  • Alert finance when a vendor record changes within a short period after an email thread mentioning payment.
  • Log who approved, from where, and from which account.

None of this needs new tools. A form, a required field and a second pair of eyes are enough to start.

Red flags worth noting

CISA lists urgent or emotional pressure, requests for financial information and incorrect addresses or links among the signs of phishing, and warns that perfect grammar proves nothing. In payment cases, add a sudden change of bank, a request to keep the matter quiet and pressure to pay before a deadline.

Quick check

Is it enough to reply to the email and ask if it is really them?

No. If the mailbox is compromised, the attacker answers. Use a separate channel and a contact you already hold.

Who should own this process?

Finance owns the policy, and engineering owns the controls in the vendor system and mail platform. Both should sign off on the written procedure.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.