How should teams verify a supplier bank-detail change before releasing payment?

What the control is protecting

A supplier bank-detail change is not just a vendor admin update, it is a payment-routing control point. The decision you are trying to make is whether the new account belongs to the real supplier, whether the requester is authorised to ask for the change, and whether the payment you are about to release would land in the wrong place if the request is fraudulent or mistaken.

The practical failure mode is simple: if the organisation accepts the change from the same channel used to request it, the attacker or impostor can control both the claim and the evidence. A proper verification process separates the request from the confirmation so the reviewer is checking a real-world fact, not repeating what was already written in the message.

Good controls treat the bank-detail change as a high-impact exception, even when the invoice looks normal and the email thread appears legitimate. That matters because payment systems often trust vendor master data once it has been updated, so a bad change can redirect more than one payment before anyone notices.

How verification should work in practice

Verify the change through a contact route that was established before the request arrived. That means using a known supplier contact, a previously validated phone number, or another independently maintained route, not the contact details in the message asking for the change.

Require a separate reviewer to confirm three things: the request itself, the destination account details, and which payments or vendor records are affected. Separation matters because one person should not be able to both approve the change and release the payment based on the same unverified input.

Keep the confirmation focused on the specific change, not a broad “is this supplier real?” check. The reviewer should confirm the exact account name, routing information, change date, and whether the request is meant to replace an existing payment destination or add a second one. That reduces ambiguity and makes later investigation easier.

When the supplier is a recurring payee, compare the new request against prior banking history and approved vendor master data, but do not treat a historical match as enough by itself. A consistent name can still hide a compromised mailbox, a copied invoice, or a last-minute diversion request.

What teams should block until the check is complete

Do not update the vendor record first and “verify later.” Once the account has been changed in the payable system, the operational pressure to release the next payment grows quickly, and people tend to assume the master data has already been checked.

Do not accept evidence that comes from the same channel as the request. An email signature, a PDF invoice, or a phone number embedded in the message can all be part of the fraud path. The point of out-of-band validation is to break that trust chain.

Do not let urgency override review for high-value or unusual changes. An out-of-pattern bank update, especially one followed by a request to accelerate payment, is a strong signal that the process should slow down, not speed up.

Risk and Threat Considerations

Supplier bank-detail change fraud exploits trust in routine finance workflows. The main risk is payment redirection, but the deeper issue is that the attacker only needs one successful change to create immediate financial loss and a difficult recovery path.

Failure mechanism: The attacker impersonates a supplier or compromises a mailbox, then uses the same communication thread to supply a new bank account and supporting details. If the team verifies only inside that thread, the control collapses into self-confirmation and the payment is routed to the attacker-controlled account.

Impact: Organisations can lose funds, expose themselves to duplicate-payment disputes, and create downstream reconciliation work across AP, treasury, and vendor management. The longer the new account remains trusted, the more payments can be diverted before the error is detected.

Practitioner Guidance

What to verify: Build the review around evidence of independent contact, not evidence attached to the request. The reviewer should be able to show which pre-approved contact route was used, who confirmed the change, and which exact bank details were validated before release.

Decision rule: If the request changes payment instructions, treat it as a verification event, not a clerical update. If the business cannot complete out-of-band confirmation before the payment date, hold the payment rather than accept a weaker substitute control.

Common mistake: Teams often believe that dual approval is enough even when both approvers are reading the same fraudulent email. Separate approval is useful, but it does not replace independent verification of the supplier’s bank details.

Practitioner takeaway: The control is only strong when the person validating the change can prove they used a trusted route that is outside the request itself, and when payment release is blocked until that validation is complete.

Related resources from NHI Mgmt Group

• How should finance teams verify a wire transfer request before releasing funds?
• How should supply chain teams verify drivers and carriers before releasing a shipment?
• What breaks when finance and HR teams rely on email alone to verify payment or data-change requests?
• How should school HR and payroll teams verify pay change requests before updating direct deposit details?