Verify Vendor Bank Changes Outside the Email Thread Before the Next Payment Run

The Signal

A vendor emails new bank instructions two days before the payment run. The message comes from the usual address, carries the old invoice chain, and asks accounts payable to use the new account immediately.

If the same email thread can request the change and prove the request is legitimate, there is no independent control. A compromised mailbox can supply the history, tone, signature, and urgency. The missing object is a bank-change receipt that shows who requested the change, how the vendor was verified outside that request, who approved it, and when the new instructions may first be used.

The FBI’s Internet Crime Complaint Center describes business email compromise as a scheme that targets legitimate transfer-of-funds requests and advises businesses to verify changes in account information through a known contact method. That verification step belongs in the vendor record, not in someone’s memory.

Why this matters now

Payment work is built for routine. Invoices arrive, approvals clear, and a payment file is prepared on schedule. A bank-detail change enters that routine as a small master-data edit, but it changes where every future payment can land.

The request can look completely normal because the attacker does not need to invent the relationship. Access to a real vendor or employee mailbox can expose prior invoices, payment timing, names, and writing style. A reply inside the existing thread may only confirm that the same mailbox still controls the conversation.

This is why the amount alone is a weak control. A small test payment still validates a destination the business has not independently confirmed. A second internal approval can also fail if both employees rely on the same email as evidence. Separate the request, verification, approval, and payment-release layers.

The mistake to avoid

Do not tell the team to “be careful with suspicious emails” and call the process fixed. The hardest requests are designed not to look suspicious. A familiar address, correct invoice, and plausible deadline are context, not proof.

Do not use a phone number, payment portal link, or contact detail supplied in the change request. That lets the requester define the verification path. Use a number already stored in the approved vendor record, printed on a prior validated contract, or obtained through a separately confirmed source.

The other bad fix is freezing all vendor updates. Legitimate vendors change banks, legal entities, and payment contacts. The objective is a controlled change with evidence, not a process so slow that staff create workarounds.

Trace the bank-change request

Take the last ten vendor bank-detail changes. For each one, line up five records: the original request, the pre-existing vendor contact, the independent callback or portal verification, the named approver, and the first payment sent after the change.

Classify the first missing receipt. If the contact method came from the request, verification is not independent. If the callback happened but no name, date, or result was recorded, the business cannot prove what was confirmed. If one person changed and approved the vendor record, the approval boundary failed. If the first payment left immediately with no review window, payment release absorbed all the risk.

Then inspect system history. The vendor record should preserve the prior instructions, the changed fields, the editor, the approver, and the effective time. A current account number without change history is not a complete control.

What stays protected

Keep valid invoices, payment terms, vendor relationships, and the normal payment calendar in place while you inspect this control. Do not cancel a legitimate obligation because the bank-change process is weak. Hold only the destination change or affected payment until verification is complete.

Protect bank data and personal contact details. The receipt needs a masked account reference, verification method, date, participants, approval, and evidence link. It does not need full banking instructions copied into an open spreadsheet or chat thread.

Keep payment release separate from vendor-master approval. Verifying a new destination does not authorize an invoice, and approving an invoice does not verify a new destination.

The first move

Pull the last ten bank-detail changes and the first payment after each one. Confirm that every change used a pre-existing contact method, recorded the person reached, retained an approval, and preserved the prior value in system history.

Flag any payment where the same email supplied both the new instructions and the verification path. Also flag changes made and paid on the same day. Those are the first records to review before the next payment file is released.

The move this week

Create a vendor bank-change receipt with eight fields: vendor ID, masked old destination, masked new destination, request timestamp, independent contact method, person reached, approver, and effective date. Add a link to the system audit history and the first affected payment.

Require accounts payable to verify through a pre-existing contact path before editing the vendor master. Have a second authorized person approve the change, then review the first payment against the receipt before release.

The objective is simple: no email thread should be able to change where company money goes and also serve as the proof that the change was real.