Payment Verification Policy Template: Callback and Approval Rules That Stop Invoice Fraud

Business email compromise and invoice fraud succeed when one person can change a supplier's bank details or release an urgent payment on the strength of a message, so the control that stops them is a written payment verification rule that nobody, including the chief executive, is allowed to skip. This template is an editable payment verification policy covering callback verification, supplier and employee bank detail changes, dual approval, urgent and out-of-process payments, new payees, and what to do when a fraudulent payment has already left. It is written for finance directors, accounts payable and treasury teams, payroll, and the security and risk teams who support them, and maps to ISO/IEC 27001:2022 and NIST CSF 2.0. For how BEC works and how to train finance staff, see the Business Email Compromise Awareness for Finance Teams Guide; for the incident response steps, the Business Email Compromise Response Playbook. This page is the policy document.

How to use this template

• Replace placeholders: text in square brackets, such as [Organisation], [Finance director] and [GBP 10,000], is yours to set. Bracketed values are suggested defaults, not external requirements. Set thresholds in your own currency.
• Must and should: "must" is mandatory; "should" is recommended, and departures need a documented reason.
• Channel-neutral on purpose: the rules apply whether a request arrives by email, phone, text, chat, video call or letter. Fraudsters now use compromised supplier mailboxes, spoofed phone numbers and cloned voices, so no channel counts as proof on its own.
• Back it with system controls: where your ERP or banking platform can enforce dual approval and lock bank detail fields, configure it so that the policy is enforced, not only written.
• Tell your suppliers: publish section 6 to suppliers so that they expect the callback and know you will never change payment details by email alone.

1. Purpose

This policy sets the verification and approval steps [Organisation] uses before creating or changing payees, changing bank details, and releasing payments, so that funds are paid only to the intended, legitimate recipient and no single person, message or channel can redirect them. It supports NIST CSF 2.0 outcome PR.AA-05 (access permissions incorporate least privilege and separation of duties) and the organisation's fraud risk management.

2. Scope

This policy applies to:

• Supplier payments, including one-off and recurring invoices, prepayments and refunds.
• Payroll and expense payments to employees and contractors.
• Treasury transfers, intercompany payments and payments to customers.
• Creation of new payees and any change to payee name, bank account, sort code, IBAN, SWIFT/BIC, remittance address or payment method.
• Payments by bank transfer, real-time payment schemes, cheque, card and digital asset where used.
• All staff who request, create, approve or release payments or maintain the supplier and employee master data, and any outsourced finance or payroll provider acting for [Organisation].

3. Roles and responsibilities

4. Supplier onboarding and new payees

1. A new supplier or payee must not be created on the strength of an email or invoice alone. Procurement must confirm the supplier's legal identity (for example company registration number and registered address) and obtain bank details through [the supplier onboarding portal or signed form].
2. Bank details for a new payee must be verified by callback under section 6 before the first payment.
3. Where the bank offers a payee name check (for example Confirmation of Payee in the UK, or equivalent services elsewhere), it must be used for every new payee, and a "no match" or "close match" result must be resolved before payment. See the Confirmation of Payee and Payee Verification Guide.
4. The person who creates a payee must not be the person who approves its first payment.
5. The first payment to a new payee above [GBP 10,000] should be preceded by a test payment of a nominal amount, confirmed by the payee through a verified contact.

5. Bank detail changes

1. Every request to change a supplier's or employee's bank details must be verified by callback under section 6, whatever its source, including requests that appear to come from senior staff or from a known supplier's genuine email address.
2. Bank detail changes must be entered by one person and approved by a second person in [the ERP or payroll system], with the callback record attached.
3. After a supplier bank detail change, [accounts payable] must notify the supplier through the previously verified contact (not the requester) that the change has been made.
4. Payments to newly changed bank details above [GBP 10,000] must be held for [24 hours] after verification, unless the [finance director] approves an earlier release after a second callback.
5. Employee bank detail changes must be made only through [the HR self-service system with MFA], or verified by callback to the number held in the HR record. Requests by email to payroll must be refused.
6. The ERP must log every change to payee master data, and a report of all changes must be reviewed [weekly] by someone independent of accounts payable.

6. Callback verification rules

Inbound calls, video calls and voice messages do not count as verification, because caller ID can be spoofed and voices and faces can be cloned. See the Deepfake and AI Impersonation Guide and the Callback Phishing (TOAD) Guide.

7. Payment approval and release

1. No person may prepare, approve and release the same payment. The banking platform must enforce at least two users for release above [GBP 10,000].
2. Approvers must check that the payee and bank details match the verified master record, and that the invoice matches a purchase order or contract where one exists.
3. Payments must not be split to avoid approval thresholds.
4. Banking platform users must authenticate with [hardware token or phishing-resistant MFA], and user rights must be reviewed at least [quarterly].

See the Segregation of Duties Guide.

8. Urgent, confidential and out-of-process requests

1. A request that asks for a payment to be made urgently, kept confidential, made outside the normal process, or made to new or changed details must be treated as suspicious until verified.
2. Requests that appear to come from executives, board members, lawyers or auditors follow the same rules as any other request. No one has authority to waive this policy by message, and executives must state publicly to finance staff that they will never ask for an exception.
3. The recipient must verify the request by contacting the apparent requester on a known number or in person, not by replying to the message.
4. Staff who delay or refuse a payment under this policy will be supported, even if the request turns out to be genuine.
5. Requests to buy gift cards, vouchers or digital assets for a business purpose must be refused and reported.

See the Executive Deepfake and CEO Fraud Guide.

9. Supporting technical controls

1. [Organisation] must publish SPF, DKIM and a DMARC policy at enforcement for its domains, and inbound email should be tagged when it comes from outside the organisation. See the DMARC, SPF and DKIM Guide.
2. Finance mailboxes must be protected by MFA and monitored for new forwarding and inbox rules, which are a common sign of mailbox compromise.
3. Bank detail fields in the ERP should be locked to a restricted role, with alerts on change.
4. Payments to new or recently changed accounts should be flagged in the payment run for extra review.

10. Suspected or confirmed fraudulent payment

1. Anyone who suspects a payment has been made to a fraudster must immediately tell [treasury] and [security team]. Speed matters more than certainty: the FBI IC3 advises contacting the financial institution immediately to request a recall.
2. [Treasury] must contact [Organisation]'s bank's fraud team at once to request a recall, using the number in [the bank contact list], and record the time.
3. The incident must be reported to the national fraud reporting route: in the US, the FBI Internet Crime Complaint Center (IC3); in England, Wales and Northern Ireland, Report Fraud (reportfraud.police.uk or 0300 123 2040), run by the City of London Police, which replaced Action Fraud in December 2025; in Scotland, Police Scotland on 101; elsewhere, the national police or fraud reporting service.
4. [Security team] must investigate whether a mailbox or account at [Organisation] or the supplier was compromised and follow the Business Email Compromise Response Playbook.
5. Evidence (emails with full headers, call records, change logs, payment confirmation) must be preserved.

11. Training

1. Everyone in scope must complete payment fraud training on joining and at least [annually], including real examples of altered invoices and impersonated executives.
2. Finance teams should take part in an exercise at least [annually] in which a fraudulent request is made or a fraudulent payment must be recalled.

12. Exceptions

1. There are no exceptions to callback verification of bank detail changes.
2. Other exceptions, such as a temporary change to approval thresholds, must be approved in writing by the [finance director], with a reason and an end date.

13. Compliance, metrics and review

• Percentage of bank detail changes with a complete callback record (target 100%).
• Payee master changes made without second-person approval (target zero).
• Suspicious requests reported by staff, and the share stopped before payment.
• Time from suspected fraudulent payment to bank recall request.
• Training completion for staff in scope.

Internal audit should sample bank detail changes and high-value payments at least [annually]. The policy is owned by the [finance director], approved by [the audit committee or board], and reviewed at least [annually] and after any payment fraud attempt that reaches the approval stage.

Implementation guidance

Rollout

1. Clean the vendor master first: confirm a verified phone contact for every active supplier, starting with the top [100] by spend. Without it, callbacks fall back to the number in the email.
2. Turn on system enforcement: configure dual approval for payee changes in the ERP and dual release in the banking platform before announcing the policy.
3. Brief executives: get the CEO and CFO to tell finance staff in writing that they will never ask for an exception. This removes the authority pressure most fraud relies on.
4. Write to suppliers: tell them about the callback rule and how to report a suspected spoofed request in your name.
5. Measure from week one: sample callback records weekly for the first quarter, then monthly.
6. Small organisations: where only two people handle finance, the owner or director should be the second approver for every bank detail change and every payment above [GBP 5,000].

Common failure patterns

• Calling the number on the fraudulent invoice: the callback reaches the fraudster. The number must come from the master record.
• Trusting the genuine supplier address: compromised supplier mailboxes send requests from real addresses in real threads.
• Executive exceptions: one "just this once" approval teaches staff that the rule bends under pressure.
• Policy without system controls: if one ERP user can change bank details and release a payment, the policy is advisory.
• Slow recall: nobody knows the bank's fraud number when it matters. Keep it in the incident contact list.

Framework mapping

Sources

• FBI IC3: Business Email Compromise: The $55 Billion Scam (I-091124-PSA)
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• City of London Police: Report Fraud service goes live (December 2025)
• GOV.UK: Report Fraud: New service from City of London Police
• Pay.UK: Confirmation of Payee

Related NHI Mgmt Group resources: Business Email Compromise Awareness for Finance Teams Guide · Business Email Compromise Response Playbook · Payment Fraud Guide · Authorised Push Payment (APP) Fraud Guide · Email Identity and BEC Guide