Vendor banking change policy: a one-page template

The policy, with blanks

Copy this into your own document and fill in the blanks in brackets:

• Scope. This policy applies to any change of bank name, account number or payment details for any vendor, contractor or supplier.
• The callback rule. No bank change request is accepted from email alone. The requested change is confirmed by calling the vendor at the number already on file — from the vendor master, a signed contract or a prior invoice — never a number supplied in the request itself.
• Dual approval. A confirmed change still requires sign-off from a second person, who was not the one who received the original request, before it is applied.
• Cooling-off hold. [Number] hours pass between a confirmed, dual-approved change and the first payment made on the new details. A shorter or zero hold requires a written reason and sign-off from [role].
• Record keeping. Every change — request, callback outcome, approvals, hold period and release — is logged and retained for [period].
• Exceptions. Listed here explicitly, with who may approve one and what they must document.

Why insurers want this in writing

A person in r/cybersecurity answering a question about domain impersonation without a breach put the reasoning as directly as it gets: "DOCUMENT AND ENFORCE (HR/LEADERSHIP) THIS. It will help in audits, cyber insurance, etc." (r/cybersecurity). A cyber-insurance underwriter reading a claim after a fraudulent bank change is not asking whether your team is generally careful — they are asking whether a written control existed and was followed on that specific transaction. "We always call to check" is not evidence; a policy document with the callback rule, the hold period and the approvers named is.

The rule that does most of the work

Everything else in the policy supports one line, and if you only write down one thing, write down this: "any banking change requires a callback using a number from our vendor master, plus dual approval and a short cooling off period before payment" (r/Accounting). The rest of the policy — retention, exceptions, roles — exists to make that one rule enforceable and auditable, not to replace it.

Keeping the policy current

A policy that says "48 hours" while the practice has quietly become "24 hours" is worse than no policy, because it fails the moment anyone checks it against what actually happened. Whoever owns the policy should re-read it at least once a year, and every version should carry a date, so a past version can be produced if a question comes up about what the rule was on the date of an earlier transaction.

Writing the exception rule so it cannot be talked around

Every real policy eventually meets a request that argues for skipping it: a vendor threatening to halt shipment, a deadline that lands on the same day. The exception line exists so that pressure has somewhere specific to go instead of quietly overriding the whole policy. Name the role who can approve an exception, and require that approval to be written down with a reason — not given verbally and forgotten. A policy with no exception path gets bent silently under pressure; a policy with a documented one gets bent on the record, which is the entire point of writing it down in the first place.

Why one page, not a binder

A policy that takes fifteen minutes to read gets read; one buried in a fifty-page vendor management manual does not. Keep this document to the one page above, and link out to anything longer — a full vendor management policy, a broader fraud response plan — rather than folding all of it into the same document. The people who need to follow the callback rule under pressure are the same people who will not go looking for it inside a binder.

Introducing the policy to the team that will follow it

A one-page policy still needs a short walk-through before the first real request lands, so the person receiving a bank change email for the first time already knows the callback number does not come from that email. A five-minute review at onboarding, plus a reminder any time the policy is updated, is usually enough — the policy is short precisely so that this is possible without a formal training program.

Questions

Who should own this policy?

Whoever is accountable for accounts payable, with sign-off from finance leadership. It needs one clear owner, not a committee.

How long should the cooling-off hold be?

48 hours is a common default. What matters more than the exact number is that it is written down, applied consistently, and only shortened with a documented, approved reason.

Do vendors, approvers, or clients need accounts to follow this policy?

No. The policy governs your own team's process; nothing about it requires the vendor to use any particular system.

Next step

BankChangeProof generates this same one-page policy for your account, versioned and dated, and the app enforces the callback rule, dual approval and hold period it describes on every bank change it logs.