---
title: "Free vendor bank-change verification policy template"
description: "A free, copy-ready vendor bank-detail change and callback verification policy template plus checklist for AP teams."
url: https://realpayee.com/templates/vendor-bank-change-policy
canonical: https://realpayee.com/templates/vendor-bank-change-policy
date_published: 2026-10-05
date_modified: 2026-10-05
updated: 2026-10-05
author: "RealPayee"
site: RealPayee
---

# Vendor bank-change verification policy template (free, copy-ready)

> This free **vendor bank-change verification policy** gives AP teams a copy-ready procedure for confirming vendor bank-detail changes before paying: log and hold the request, **call back a known contact** on the number already on file, validate the account, get a second approval, confirm the first payment and keep the evidence. It includes a callback script, roles, exception handling and a one-page checklist.

_Updated 2026-10-05 · 8 min read_

## Key takeaways

- Covers **purpose, scope, roles, procedure, callback script, executive requests, exceptions, record-keeping and review cadence**.
- The core rule: **never verify a change using contact details from the request itself**.
- Includes a 13-point **vendor verification checklist** to complete for each change.
- Free and ungated - copy it, edit the [bracketed] fields, and have your controller and CFO approve it.

## How to use this template

1. Copy the policy below into your document system (the button copies the full text).
2. Replace everything in [square brackets] - company name, roles, thresholds, systems.
3. Have the controller and CFO approve it, and the CEO sign the executive commitment in section 8.
4. Train everyone who can change vendor records or release payments, and keep a record of who was trained.
5. Use the checklist at the bottom of this page for every change, and keep the completed checklist with the vendor record.

> [!NOTE]
> This template reflects common practice for US finance teams. It is not legal or audit advice - adapt it to your systems, your bank's services and your insurance policy's verification conditions.

## Vendor bank-detail change and payment verification policy

**[Company Name]** · Policy owner: [Controller] · Approved by: [CFO] · Effective: [date] · Version: [1.0]

### 1. Purpose

This policy protects [Company Name] from paying fraudsters who impersonate vendors or executives. It sets out how we verify changes to vendor payment details and high-value or unusual payment requests before any money moves, and how we record that verification.

### 2. Scope

- All requests to add or change a vendor's bank account, remit-to address, payment method or payment contact, however received (email, portal, phone, letter, in person).
- All new vendors before their first payment.
- All outgoing wires and same-day payments above $[threshold], and any payment requested outside the normal approval workflow, including requests that appear to come from executives.
- Applies to all employees, contractors and outsourced providers with access to [ERP: NetSuite / QuickBooks / Xero], [AP platform] or bank portals.

### 3. Definitions

- **Known contact:** a vendor contact whose name and phone number were recorded in the vendor master file, contract or onboarding documents before the change request was received.
- **Out-of-band verification:** confirmation through a channel and contact details that the requester did not supply - for example, calling the known contact on the number on file.
- **Change request:** any instruction that would alter where or how a vendor is paid.

### 4. Roles and responsibilities

| Role | Responsibility |
| --- | --- |
| AP specialist (preparer) | Logs the request, performs the callback, completes the checklist. Cannot approve their own change. |
| AP manager (approver) | Reviews evidence and approves routine changes in the ERP. Reviews the weekly vendor master change report. |
| Controller | Approves changes for top-[N] vendors, vendors with open invoices above $[threshold], and all exceptions. Owns this policy. |
| CFO | Approves executive-requested or confidential payments together with the controller. Signs the executive commitment. |
| IT / Security | Investigates suspected compromised mailboxes and reports incidents. |

### 5. Policy statements

1. No change to vendor payment details is entered or released until it has been verified out-of-band with a known contact and approved by a second person.
2. Contact details in the change request (phone numbers, email addresses, links, letters) are never used to verify that request.
3. The person who receives or enters a change cannot approve it.
4. The first payment to new or changed bank details is [held for verification of receipt / limited to $[amount]] until the vendor confirms receipt.
5. No employee will be disciplined for delaying a payment to complete verification, regardless of who requested it.
6. Executives may not waive this policy for any individual payment.

### 6. Procedure: verifying a bank-detail change

1. **Log** the request in [system/ticket queue] with the date, channel, sender and a copy of the request. Do not edit the vendor record.
2. **Hold** any scheduled payment to the vendor that would use the new details.
3. **Find the known contact** in the vendor master file, contract or onboarding documents. If no known contact exists, find the vendor's main number independently (for example, its official website) and record where it came from.
4. **Call back** using the script in section 7. Ask the contact to read the new account details to you; do not read them out.
5. **Validate the account** using [micro-deposit / bank account validation service / AP platform check] and record the result.
6. **Notify** the vendor at its previously known email address that a change has been requested and will take effect after approval.
7. **Approve:** the approver reviews the checklist and evidence and approves the change in the ERP. Changes meeting controller criteria go to the controller.
8. **First payment:** apply the first-payment rule in section 5 and confirm receipt with the vendor.
9. **File** the completed checklist and evidence with the vendor record.

### 7. Callback script

1. “Hello, this is [name] from [Company Name] accounts payable. I'm calling the number we have on file for [vendor] about a change to your payment details. Is now a good time?”
2. “We received a request on [date] to change your bank account. Did you or someone on your team send it?” (If no: thank them, end the call, escalate as attempted fraud.)
3. “Please read me the new bank name, routing number and account number.” (Compare with the request.)
4. “What is the reason for the change, and what name is the new account held under?”
5. “Is there anyone else at your company we should confirm this with?” (Required for controller-level changes.)
6. “Thank you. We will send a confirmation to the email address we have on file. The change takes effect after our internal approval.”

Record: contact name and title, number dialed and its source, date and time, answers given, and outcome.

### 8. High-value and executive payment requests

- Any wire above $[threshold], any payment to a new beneficiary, and any request from an executive outside the normal workflow is verified with the requester out-of-band before release.
- Verify executives on a channel finance chooses - the directory phone number or internal chat - with the agreed challenge question or identity-bound approval. An inbound call, voice message or video meeting is never verification on its own.
- Executive commitment: “I will never ask finance to skip this policy or keep a payment secret from the controller. If a request looks or sounds like me but hasn't been verified, verify it first.” - [CEO signature]

### 9. Red flags requiring escalation

- Urgency, secrecy, or pressure to bypass this policy.
- Sender domain or reply-to differs from known records; a new phone number is supplied for verification.
- Account holder name differs from the vendor's legal name, or the bank or country changes.
- Change requested together with payment of overdue invoices.
- Known contact unreachable, or they say they did not request the change.

Escalate red flags to the controller and IT/Security the same day. If the vendor denies the request, notify the vendor that its email may be compromised.

### 10. Exception handling

- If the known contact cannot be reached within [2] business days, the change remains on hold; the controller may approve an alternative verification (second known contact, vendor portal with MFA, in-person confirmation) and must document why.
- Emergency payments still require out-of-band verification. Only the [CFO and controller together] may authorize an emergency exception, recorded in writing with reasons.
- Exceptions are reported in the monthly control review.

### 11. Record-keeping

- For each change keep: the original request, completed checklist, callback record, account-validation result, approvals, and first-payment confirmation.
- Store records with the vendor record in [ERP/document system] for at least [7] years or as required by your retention policy.
- Records must be available to internal and external auditors and to our insurer on request.

### 12. Monitoring, training and review

- The AP manager reviews the vendor master change report [weekly]; the controller reviews a sample of completed checklists [monthly].
- Everyone in scope completes training on this policy at hire and [annually], including examples of vendor impersonation and deepfake executive requests.
- The controller reviews this policy [annually] and after any incident or near-miss, and confirms it still meets our insurance policy's verification conditions.

## Vendor bank-change verification checklist

Complete for every new vendor and every bank-detail change. Keep it with the vendor record.

- ☐ Request logged (date, channel, sender, copy attached); vendor record not yet edited
- ☐ Scheduled payments to new details on hold
- ☐ Known contact identified from vendor master / contract (source recorded)
- ☐ Callback made to number on file - not from the request (name, number, date, time)
- ☐ Contact read back new routing and account number; matches request
- ☐ Reason for change recorded; account holder name matches vendor legal name
- ☐ Account validated (method and result recorded)
- ☐ Notice sent to previously known vendor email address
- ☐ Red flags reviewed; any escalation recorded
- ☐ Approved by second person (name, date) - not the preparer
- ☐ Controller approval if top vendor, above threshold or exception
- ☐ First payment held/limited and receipt confirmed by vendor
- ☐ Evidence filed with the vendor record

## Customizing the policy

- **Thresholds:** set the wire and open-invoice thresholds from your actual payment distribution so the controller sees the riskiest changes, not every change.
- **Small teams:** if one person handles AP end to end, make the controller or an owner the approver and add a weekly independent review of the change log.
- **Insurance:** compare section 6 with your social engineering fraud endorsement; some policies spell out the verification they expect.
- **Automation:** platforms like [RealPayee](https://realpayee.com) can enforce the hold, run the out-of-band verification with the known contact and store the evidence automatically. See [how approaches compare](https://realpayee.com/compare).

## Frequently asked questions

### What is a vendor bank-change verification policy?

A written procedure that says how your company confirms a request to change a vendor's bank details before paying: who verifies, how (out-of-band callback to a known contact), who approves, and what evidence is kept.

### What is callback verification?

Callback verification is confirming a payment instruction by phoning the requester on a number you already had on file - not one provided in the request - and having them confirm the details.

### Is this template enough to satisfy auditors or insurers?

It reflects common practice, but requirements differ. Review it against your auditors' control expectations and your insurance policy's verification conditions, and make sure you keep evidence that each step was performed.

### Can I use this template for free?

Yes. Copy it, adapt it and use it internally. No email is required.

## Related

- [Vendor verification: how to verify vendor bank details before you pay](https://realpayee.com/vendor-verification) - A practical guide to vendor verification for finance teams: how to confirm vendor bank-detail changes, run callbacks, and prevent vendor impersonation fraud. (markdown: https://realpayee.com/vendor-verification.md)
- [Vendor fraud: types, examples and how to prevent it](https://realpayee.com/vendor-fraud) - What vendor fraud is, the most common schemes (vendor impersonation, fake bank changes, fake invoices) and the controls that stop them. (markdown: https://realpayee.com/vendor-fraud.md)
- [Wire fraud prevention: how to stop bank wire fraud](https://realpayee.com/wire-fraud-prevention) - Controls that prevent business wire fraud: out-of-band verification, payment thresholds, dual approval and audit trails. (markdown: https://realpayee.com/wire-fraud-prevention.md)
- [Compare: manual callbacks vs bank-account validation vs RealPayee](https://realpayee.com/compare) - An honest comparison of approaches to stopping vendor-impersonation and fake payment requests. (markdown: https://realpayee.com/compare.md)

---

**Further reading**
- [Vendor verification guide](https://realpayee.com/vendor-verification.md)
- [Compare: callbacks vs bank-account validation vs RealPayee](https://realpayee.com/compare.md)
- [Vendor fraud: types and controls](https://realpayee.com/vendor-fraud.md)
- [Pricing](https://realpayee.com/pricing.md)

Canonical HTML: https://realpayee.com/templates/vendor-bank-change-policy · Site index for AI agents: https://realpayee.com/llms.txt?src=md-footer · Pricing: https://realpayee.com/pricing.md · Book a demo: https://realpayee.com/demo