What is Vendor Bank Account Verification?

Vendor bank account verification is the process of confirming that the bank details you are about to pay — routing number, account number, and account holder name — belong to the supplier you intend to pay, using a channel the person who sent you the details does not control. It applies at onboarding and, far more importantly, every time an existing vendor asks you to change where their money goes. A detail is verified only when an independent channel confirmed it; a document that arrived with the request and an email reply to the address that sent it are both the same channel as the request.

That last sentence is the whole control. Most procedures fail not because a step is missing but because every step in them runs through the channel the attacker already owns.

The short answer

A change-of-bank-details request is the highest-risk single email an AP team receives, because the resulting payment is unremarkable in every way a monitoring system checks: real vendor, real invoice, contracted amount, correct approver. Nothing about it looks wrong until the real vendor calls about a missing payment.

The procedure that holds is short:

1. Freeze payments to that vendor in the system, not on a sticky note.
2. Call the vendor on a number already in your vendor master — never a number in the request, the signature block, or the attached letterhead.
3. Have someone other than the person who received the request approve the change.
4. Record what was verified, by whom, against which number, on what date.

Everything else — bank letters, third-party validation, email confirmations — is useful supporting evidence and none of it substitutes for step 2.

The steps, and what defeats each one

Step	What it defends against	What defeats it
Freeze the vendor for payment	A pending run paying the new account mid-verification	A freeze that lives in someone's inbox rather than the system
Review the bank letter or voided check	Casual opportunism and sloppy forgery	A matching letterhead. Templates and logos are a download away, and a compromised mailbox supplies the genuine one
Confirm by replying to the email	A lookalike domain spoof	A compromised mailbox. The confirmation arrives from the real address because the attacker is reading it
Third-party account validation	An account whose holder name does not match the vendor	An account opened in a name close enough to pass, and the gap between a valid account and the correct account
Outbound call to a number in the vendor master	Both of the above, because it leaves the channel entirely	Calling the number in the request, dialling an extension the request supplied, or accepting voicemail as confirmation
Second approver who did not receive the request	A single compromised or complicit person redirecting payments	Nothing structural, provided the second approver actually re-checks rather than counter-signs

Read the right-hand column as a sequence rather than a list. Document review is defeated by presentation, email confirmation is defeated by mailbox access, and validation services answer a different question than the one you are asking. Only the callback changes channel, which is why it is the step that survives a convincing impersonation and the one under time pressure people skip.

On the callback specifically

Three details decide whether the call is a control or theatre.

The number comes from the vendor master, not the request. If the only number you hold is the one in the email signature, you do not have a callback procedure — you have a phone-shaped version of the same channel. Capturing a verified phone number belongs to vendor master data management at onboarding, before you need it.

You call out; they do not call in. An inbound call claiming to be the vendor proves nothing. Attackers will offer to call you.

A person confirms, not a voicemail. A message left on a number that may itself have been forwarded is not a confirmation. If you cannot reach a human, the change waits.

What the automated checks actually prove

The supporting methods are worth running. They are just worth running with an accurate idea of the question each one answers, because two of them are routinely credited with answering the question they do not.

Micro-deposits send two small amounts, under a dollar each, and ask someone to report the values back. What that proves is genuine and narrow: whoever answered has read access to the account. It costs a couple of days and almost nothing per check. It does not prove the account belongs to your vendor — an attacker verifying their own account passes this test perfectly.

Third-party validation services query account status and, where the network supports it, the account holder name. They return an answer in seconds and they are the fastest way to catch a typo, a closed account, or a name that does not resemble the vendor at all. The gap is the one named in the table above: they tell you the account is valid, not that it is the right one. An account opened in a name close enough to the vendor's trading name clears the check.

A bank letter or voided check proves that someone produced a document. That is worth less every year.

The callback proves that a person reachable at a number you already held, before this request existed, agrees that the request is real. That is a different class of evidence, and it is the only one on this list that does not run through the requester.

Run the fast checks first because they are cheap and they catch the ordinary mistakes — a transposed digit costs a returned payment and a week whether or not fraud was involved. Then make the call anyway.

Freeze first, and mean it

The freeze deserves a sentence of its own because it is the step most often performed nominally. A vendor with a change request pending should be blocked in the system that produces the payment file, not flagged in a spreadsheet or mentioned in a stand-up. Verification takes hours or days; payment runs do not wait for it, and the failure mode is not exotic. A scheduled run pays the newly saved details on Thursday while the callback is booked for Friday, and the change was never approved by anybody.

Two cases the standard procedure misses

The four steps above handle the ordinary request. Two situations bend them, and both are worth naming because each one supplies its own excuse for skipping the callback.

A change requested during an open invoice dispute

A dispute is unusually good cover. It explains urgency, it explains why you are suddenly dealing with a new contact in their finance team, and it explains why the amount is atypical — so the anomaly check that might otherwise fire has already been given a reason not to. An attacker reading a compromised mailbox can see the dispute thread and time the request into it.

The control is to route it away from the pressure. A bank change requested while a dispute is open goes to the relationship owner rather than AP, and the callback goes to the contact who existed before the dispute opened, not to whoever has been handling it since.

A change for a vendor you have not paid in over a year

A dormant vendor breaks the callback at its root: the number in your master may be disconnected, the contact has likely left, and the colleague who "knows" this supplier may have left too. Teams that would never skip the callback on an active vendor quietly skip it here because there is nothing to call.

Treat a dormant-vendor bank change as onboarding rather than as a change. Re-verify the entity from the contract, the company register, or the vendor's published main line — sources that predate the request and sit outside your own stale record. The rest of the vendor onboarding checks apply for the same reason.

Who is allowed to approve the change

Not the person who received the request. This is the part most procedures leave implicit and it is doing real work.

Someone who has spent twenty minutes on a request has already formed a view. They have read a plausible email, seen a convincing letter, and possibly spoken to someone helpful. Asking that person to also approve the change asks them to audit their own judgement under exactly the conditions that make judgement unreliable. Worse, if their mailbox is the compromised one, they are the single point the whole procedure runs through.

So the approval belongs to a second person who verifies independently — confirming the number came from the master, that an outbound call reached a human, and that the disposition was recorded — rather than confirming that a colleague says they did those things. This is standard segregation of duties applied to the one AP transaction where a single person's compromised account is enough to lose the money.

One more thing that is easy to miss: record the disposition, not just the outcome. "Verified" in a field tells an auditor nothing. Who called, which number, from which record, on what date, and who approved — a control that was silently overridden looks identical in the log to one that never fired.

When to run verification

• New vendor setup — before the first payment leaves.
• Any bank detail change — the highest-risk moment in AP, without exception for urgency.
• First payment to a vendor set up some time ago — the record has aged since it was checked.
• After dormancy — no payment in roughly a year means re-onboard, not update.
• International payments — recovery once funds settle abroad depends on the receiving bank's cooperation and on the money still being there, which is a weak place to be standing.

Key Takeaways

• Definition: confirming bank details belong to the intended supplier, through a channel the sender of the request does not control.
• The one step that holds: an outbound call to a number already in your vendor master. Documents and email replies travel the same channel as the request.
• Approval: a second person, never the one who received the request.
• Evidence: record who verified, against which number, and when — an unrecorded control is indistinguishable from a skipped one.

Related Terms

• Vendor Master Data Management — where the verified phone number has to already exist
• Segregation of Duties in Accounts Payable — why the approver cannot be the recipient
• Vendor Onboarding — the checks a dormant-vendor change falls back to
• Payment Reconciliation — matching payments against invoices and statements after the fact