Finance Index
A vendor emailed new bank details - how do I verify a bank change request safely?
Reference guide to vendor bank change callback protocol, including vendor records, onboarding requirements, compliance checks, fraud controls, and payment readiness.
Treat every bank-change request as unverified until you confirm it through a channel you already trust - never by replying to the email. The standard control is a call-back: phone the vendor on a number already on file (not one supplied in the request), confirm the change with a known contact, document the verification, and route the change through a second-person approval before any payment uses the new account.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| A vendor emailed new bank | Treat every bank-change request as unverified until you confirm it through a channel you already trust - never by replying to the email. | Keeps vendor records and payment decisions reliable. |
| Call-back protocol | A call-back protocol is a written rule that no banking change takes effect until someone independently phones the vendor and confirms it. | Keeps vendor records and payment decisions reliable. |
| Write a bank-change verification sop | Keep it to one page so it survives a busy Friday: (1) any bank-detail change request lands in a "pending verification" state. | Reduces payment errors, timing issues, and reconciliation cleanup. |
| Bank change requests be portal-only | Yes, and it's the strongest single control: make "banking changes only through our authenticated portal" a written policy, and refuse email change requests as a matter of course. | Keeps evidence clear and reduces control risk. |
| Payment impact | Urgency *is* the classic pressure tactic - manufactured time pressure exists precisely to push you past your verification step. | Reduces payment errors, timing issues, and reconciliation cleanup. |
What is a call-back protocol, and why must I use the number on file?
A call-back protocol is a written rule that no banking change takes effect until someone independently phones the vendor and confirms it. The non-negotiable detail: dial the number from your vendor record or a separately verified source - never the phone number, email, or contact in the change request itself. A fraudster who can email you fake bank details can just as easily supply a fake "verification" phone number that rings their own desk. The call-back only works when the contact channel is one the fraudster couldn't have planted.
How do I write a bank-change verification sop my team will follow under deadline pressure?
Keep it to one page so it survives a busy Friday: (1) any bank-detail change request lands in a "pending verification" state - payments to that vendor pause automatically; (2) call back on the on-file number and confirm with a known contact, not whoever emailed; (3) record who verified, when, the number called, and who confirmed; (4) a second person who didn't process the change approves it; (5) only then does the new account become payable. The control that matters most is step 1 - making the pause automatic so urgency can't skip it.
Should bank change requests be portal-only - can we refuse email change requests entirely?
Yes, and it's the strongest single control: make "banking changes only through our authenticated portal" a written policy, and refuse email change requests as a matter of course. A portal change is attributable to a logged-in vendor account; an email change is attributable to whoever controls an inbox. Refusing email isn't rude - it's the modern equivalent of not handing cash to a stranger who phoned.
The vendor is pressuring US to update banking before a big payment run and getting aggressive about delays - is urgency the red flag?
Urgency *is* the classic pressure tactic - manufactured time pressure exists precisely to push you past your verification step. A real vendor will tolerate a one-day verification hold to protect a payment they want to receive correctly. Escalating aggression about a routine control is itself a reason to slow down, not speed up.
Who should approve a bank-detail change, and should it auto-hold payments?
A second person who didn't enter the change should approve it - same segregation-of-duties logic as vendor creation. And yes: a pending banking change should automatically hold payments to that vendor until verification and approval complete, so the control can't be bypassed by a payment run that happens to fire first.
How do I verify a bank change when the on-file contact has left and the requester is new?
Don't verify a new contact using only that new contact - that's circular. Re-establish identity through an independent path: a main-line number for the vendor company (not a direct line in the request), confirmation from a second known contact, or verification against the executed contract or a prior invoice's letterhead. A simultaneous contact change *and* banking change is a high-risk pattern that deserves the most rigorous confirmation.
Should we notify the old banking contact and confirm to the vendor's known email after every change?
Yes to both - they're cheap detective controls. A confirmation to the vendor's known-good email ("we've updated your banking on file") gives a legitimate vendor a chance to say "we didn't request that," and notifying the prior contact catches account-takeover where a fraudster changed the contact first. Out-of-band confirmation closes the loop the call-back opened.
A vendor legitimately changed banks mid-payment-run - how do I recall or redirect a payment already in flight?
Speed governs everything. If the payment hasn't released, hold and re-point it to the verified new account. If it's already sent, contact your bank immediately to attempt an ACH reversal or wire recall - odds drop by the hour. Going forward, verify and approve the new account before scheduling the next run, and never edit banking on a payment that's mid-flight.
What audit evidence should we retain for every bank change?
The full chain: the original request, who verified it and through which channel, the on-file number called, who confirmed on the vendor side, the approver (distinct from the processor), and timestamps for each step. If an auditor or investigator asks "how did you know this change was legitimate?", that record is the answer - and if a change ever goes wrong, it's the difference between a controlled process and negligence.
Stampli perspective
Stampli is built so a changed bank account can't quietly become a payment. Vendor-submitted banking changes can require review and approval before they take effect, and payments can be blocked from scheduling or execution while a change is pending. When invoice-derived payment details differ from the vendor's known information, Stampli surfaces that as a signal in the payment workflow rather than silently trusting it - and for high-risk changes, Stampli's own guidance is that AP should still confirm independently through a trusted channel. The system enforces the pause; the call-back authenticates the counterparty.