Vendor Won't Verify a Bank Change? What to Do Next

A stalled verification has two very different causes, and they lead to the same action but a different tone.

Sometimes the vendor genuinely can't verify on the spot: the AP contact is out, the person who answers doesn't handle banking, the number on file is stale, or the business is small enough that there's no formal process. That's friction, not fraud — but the change still waits until you reach someone who can confirm it on a number you trust.

Sometimes the vendor (or someone posing as them) won't verify: they object to being called, insist the emailed details are sufficient, claim urgency to skip the step, or steer you to a phone number they supplied. That pattern is the textbook shape of a payee-redirect scam. The FBI's 2024 Internet Crime Report attributed $2.77 billion in losses to business email compromise, much of it from exactly this move: an impersonator changes where a real invoice gets paid and pressures the payer past the verification step.

Either way, the rule holds: no confirmation on an independent channel, no release. The difference is whether you're patiently rescheduling a call or quietly escalating a suspected impersonation.

Work it in order. Each step assumes the prior one didn't resolve cleanly.

1. Re-dial the independent number, not the one in the request. Use a phone number from your vendor master file, a signed engagement, or an old invoice — never the number in the change email or a “call me here” reply. If the first attempt failed because nobody answered, a second documented attempt to the known number is reasonable. The number the requester offers is not.
2. Ask the vendor to confirm through a second known channel. A return call from the vendor's published main line, a message through an existing portal you already use with them, or confirmation from your day-to-day contact who recognizes the request. Adding a channel the requester doesn't control is the point.
3. If they refuse the call entirely, treat it as suspicious. A legitimate vendor wants their money to arrive and will tolerate a two-minute confirmation. Refusal, manufactured urgency, or pressure to skip the callback are escalation triggers — pause the change and loop in the client and a second approver before going further.
4. Keep paying the old, previously verified account for legitimate outstanding invoices if business must continue — or hold payment outright. Do not split the difference by sending to the unverified new account “just this once.”
5. Document the hold and the reason at each step. This is the part firms skip, and it's the part that matters most after the fact.

If you want the underlying mechanics of a clean callback before it stalls, the step-by-step verification procedure walks every checkpoint, and the callback script gives you the exact words for the read-back.

When a change verifies cleanly, the record is easy: you called, they confirmed, you logged it. When it doesn't, there's a temptation to simply move on — leave the request in limbo and handle it later. That gap is where firms get exposed.

If a payment is later disputed, or a client asks why a vendor went unpaid, or an auditor reviews your controls, the question is the same: what did you do, and when? “We weren't comfortable, so we waited” is a defensible answer only if you can show it — a dated note that the callback was attempted, the number you used, who you reached (or didn't), and the decision to hold. A control you can't evidence is, for review purposes, a control you didn't have.

This cuts both ways. If the change turns out to be legitimate and a vendor complains about a delay, your log shows you followed a consistent, reasonable process rather than singling them out. If it turns out to be an impersonation attempt you stopped, the same log is the proof that your firm's procedure worked. Either way the documented hold protects the firm — see what auditors ask about vendor verification for how reviewers actually probe this.

A usable hold record captures, at minimum:

• The request: date received, which client, which vendor, the channel it arrived on, and the new details requested.
• The attempt: the number you dialed and where it came from, the date and time, and who (if anyone) you reached.
• The outcome: confirmed / not confirmed / refused, in plain language, plus any red flags noted.
• The decision: held, paid old account, or escalated — and who on your side approved that decision.

Across many clients, that's a lot of small records that all need to be consistent, time-stamped, and retrievable months later. Our free vendor bank-change verification template includes a one-page log sheet built for exactly this — the independent-contact rule, the read-back, a dual-approval line, and space to note a failed or refused attempt. No signup.

NACHA Phase 2 took effect June 22, 2026, and applies to every ACH-originating business with no volume floor — including small firms originating client payments. It asks originators to use commercially reasonable methods to confirm the legitimacy of vendor banking-detail changes and to be able to produce evidence of that verification.

A failed or refused verification is precisely the moment the rule is built for. Releasing funds to a new account you couldn't confirm is the opposite of commercially reasonable. Holding the payment and recording why is the behavior the rule rewards — and the record is what you'd produce if asked.

CallbackProof enforces that callback-and-hold sequence on every change across every client you serve, and hashes each entry — including the ones that ended in a hold — into a SHA-256 chain, so the record of the day a verification failed is provable later when a client, auditor, or insurer asks what you did.