A Payment Verification Policy Template Outline for Contractors

An outline for a written payment verification policy: scope, roles, thresholds, call-back steps, exceptions, and what to do when a request looks wrong.

3 min readBy Ironfield Cyber Team

A written payment verification policy turns good intentions into consistent behavior. Without one, controls depend on who happens to be at the desk and how busy they are. With one, staff have clear backing to slow down and verify when a request looks unusual, even when it appears to come from a senior person.

Below is an outline you can adapt for a contractor or energy services company. It is a starting framework, not legal advice. Have your finance leader, IT provider, and counsel review it and tailor it to your actual processes and systems.

1. Purpose and scope

State why the policy exists: to protect the company from fraudulent or erroneous payments and to define how payment instructions are verified. List what it covers, such as ACH, wire transfers, checks, virtual cards, and changes to vendor, subcontractor, payroll, or customer remittance details. State who must follow it: all employees involved in requesting, approving, or releasing payments, including executives.

2. Definitions

Briefly define terms used in the policy:

  • Payment instruction change: any new, added, or altered bank account or remittance information.
  • Known contact: a person and phone number already recorded in your vendor file or contract.
  • Independent verification: confirming through a channel not supplied by the requester.

3. Roles and responsibilities

Assign clear owners.

  • Requester: the person who receives or submits a change or payment.
  • Verifier: the person who performs the call-back.
  • Approver: a different person who authorizes the change or payment.
  • Releaser: the person who sends the payment.
  • Policy owner: typically the CFO or controller, responsible for maintaining the policy.

State that no single person may perform all steps for a change or large payment.

4. Adding or changing banking details

List the required steps in order:

  1. Record the request and its source.
  2. Verify independently by calling a known contact at a known number. Never use contact details provided in the request.
  3. Confirm account details verbally and the reason for the change.
  4. Obtain a signed form where practical, and compare it to existing records.
  5. Obtain approval from a second person.
  6. Update the vendor record and log the change.
  7. Notify the previously known contact of the change.

5. Payment release controls

Define thresholds. For example, payments above a set amount require dual approval, and wires above a higher threshold require approval by a named executive and a call-back to the recipient. Set the amounts yourself, based on your business. Consider a waiting period before the first payment to a changed account.

6. Handling urgent or executive requests

State explicitly that urgency does not suspend the policy. Requests that appear to come from executives, owners, or customers are subject to the same verification. Explain that employees will be supported, and not disciplined, for following the policy when it delays a payment.

7. Red flags

List warning signs staff should treat as a prompt to escalate:

  • A change request timed near a payment due date.
  • Requests for secrecy or unusual haste.
  • Slightly different email addresses or domains.
  • Changes from check or ACH to wire.
  • An account in a different name, bank, or location.
  • Reluctance to take a verification call.

8. Systems and access controls

Specify who can edit vendor banking fields, require individual accounts and multi-factor authentication, and describe logging and periodic review of changes.

9. Incident response

If fraud is suspected or discovered:

  1. Notify the bank immediately to request a recall.
  2. Notify the policy owner and IT.
  3. Preserve messages and logs.
  4. Report to the FBI IC3 and notify the insurance carrier and counsel.
  5. Secure affected accounts.

10. Training and review

Require training for relevant staff at onboarding and at least annually. Review the policy yearly and after any incident or near miss. Record exceptions and their approvals.

11. Exceptions

Define who may approve an exception, in writing, and how it is logged. Keep the list of exceptions short.

Making it stick

Policies fail when they sit in a folder. Walk the team through the policy, use real examples, and make the call-back step simple with a current vendor contact list. Measure compliance by sampling changes each quarter.

Ironfield Cyber's role

Ironfield Cyber helps contractors and energy companies turn outlines like this into working procedures and secure the email and accounting systems behind them. We are glad to review your draft or help you start one.