Beneficiary whitelists: lock routine business payments to approved bank accounts

A beneficiary whitelist limits routine payments to bank accounts that have already passed the company's verification process. The control reduces the chance that one compromised email or finance login can redirect a large supplier payment to a new account without extra approval.

Create one approved beneficiary master

Maintain legal supplier name, approved account details, verification date, owner and supporting evidence in a controlled master record. Payment systems should draw beneficiary data from that source rather than free-text emails.

Limit who can edit the master. Accounts-payable users who create invoices do not all need authority to change bank destinations.

Treat every new or changed beneficiary as a high-risk event

Verify the change through a known phone number, secure portal or other trusted channel. Do not use contact information contained only in the change request.

Record who performed the verification and when. A genuine supplier should understand why the company needs an independent check.

Use maker-checker approval for whitelist changes

One employee can enter the new beneficiary while another approves it. The payment bank or ERP can enforce this where the functionality exists.

Separate adding a beneficiary from immediately releasing a large payment to it. A cooling period or enhanced approval can reduce social-engineering risk.

Use Confirmation of Payee as another signal

For UK accounts, Confirmation of Payee can compare the entered name with the account name. A match supports the verification process; a mismatch deserves investigation.

Do not train staff to override no-match warnings automatically. Trading names and group structures can create legitimate explanations, but they should be understood before payment.

Create a defined emergency-change process

Urgent payments are exactly where controls are most likely to be bypassed. Require senior approval and an independent callback for emergency account changes.

Do not let a director's email alone override the whitelist. CEO fraud relies on convincing employees that urgency is more important than process.

Recertify beneficiaries and remove obsolete accounts

Review high-value and dormant suppliers periodically. Old bank details that remain approved forever can be misused if the supplier changes ownership or the account is reassigned.

Keep change history rather than overwriting it. If a dispute occurs, finance should be able to show which account was approved on the date of payment.

Worked example: a supplier that has been paid monthly for five years emails new bank details two hours before a £180,000 run. The payment system should treat the new account as unapproved even though the supplier relationship is old. Finance verifies the change through a known phone contact, another employee approves the master-data update and the first payment receives enhanced review.

Use inactivity rules. A supplier bank account unused for 18 months can be moved to dormant status and require re-verification before the next payment. This reduces the chance that stale beneficiary records remain permanently trusted after ownership or banking changes.

Report whitelist exceptions to management. Repeated emergency changes, manual overrides or Confirmation of Payee mismatches can indicate poor procurement data or attempted fraud. The control should generate information about process quality, not merely block transactions.

For group companies, whitelist beneficiaries by legal paying entity. A supplier account approved for Subsidiary A should not automatically become approved for Parent Ltd if the commercial contract differs. This also prevents cross-entity payments being made merely because treasury can see one group-wide beneficiary list.

Review beneficiary additions against procurement data. A new bank account attached to a supplier with no recent purchase order or contract deserves extra scrutiny. Combining finance and procurement signals can catch fraudulent master-data changes before they reach the payment run.

Use role-based approval thresholds. A routine £5,000 payment to a long-approved beneficiary can follow standard dual approval, while the first £500,000 payment to a newly whitelisted account should require a higher-level approver and fresh verification evidence.

Keep rejected change requests as intelligence. If a supplier denies requesting new details, preserve the fraudulent email, domains and telephone numbers and alert security staff. One attempted beneficiary fraud can reveal a compromised supplier mailbox or a wider phishing campaign.

Set an annual certification for the highest-value beneficiaries. Procurement or business owners should confirm that the supplier relationship still exists and the bank account remains valid. Recertification catches dormant or acquired suppliers before an old trusted record is reused.

Where the bank offers beneficiary locking or trusted-payee features, align them with the internal whitelist rather than maintaining two conflicting lists. Bank-side controls are strongest when finance master data and portal permissions tell the same story.

Measure how long beneficiary changes take from request to approval. If the process is so slow that staff routinely seek emergency overrides, the control needs redesign. Strong security should be practical enough that legitimate users do not build workarounds around it.