The Secure Supplier Bank Detail Change Process: Callback, Dual Approval and Audit Trail

IN THIS ARTICLE
Table of Contents
Like it? Share it

A supplier bank detail change should never be treated as a routine administrative update. It is a high-risk change to payment master data that can redirect a legitimate payment to an account controlled by a fraudster.

A secure supplier bank detail change process combines authenticated submission, independent account validation, callback verification and dual approval. The new account should remain on payment hold until the required checks are complete.

This control is increasingly important in the UK. UK Finance reported that criminals stole £1.28 billion through payment fraud in 2025, including £75.6 million in business losses from authorised push payment fraud.

For organisations looking to strengthen this process while reducing manual effort, automated bank account validation can help verify supplier account ownership and identify suspicious changes before payment.

Key Takeaways

• Treat every supplier bank detail change as a high-risk master-data event.

• Do not use ordinary email or spreadsheets as the source of truth.

• Combine account ownership validation with an independent callback.

• Separate request creation from approval and retain evidence for every decision.

Nouveau call-to-action

Why Do Supplier Bank Detail Changes Require Strong Controls?

Supplier bank detail changes require strong controls because they can alter where money is sent without changing the invoice, purchase order or supplier relationship.

A fraudulent request may contain accurate invoice numbers, familiar signatures and a convincing explanation, such as a bank merger or internal restructuring. In a supplier email compromise attack, criminals may also use a genuine supplier mailbox or reply inside an existing email thread.

That makes traditional email reviews unreliable. The message may look authentic even though the bank details are fraudulent.

Trustpair’s guide to supplier email compromise explains why checking the sender is not enough when a supplier’s genuine mailbox has been compromised. The account itself must be verified independently.

The consequences of payment diversion can include financial loss, delayed deliveries, duplicate payments, difficult recovery efforts, supplier disputes and audit findings. The control objective is simple: no replacement account should become eligible for payment until the organisation has verified both the legitimacy of the request and the ownership of the destination account.

How Should a Secure Supplier Bank Detail Change Process Work?

A secure supplier bank detail change process should follow a consistent sequence:

  1. The supplier submits the request through an approved channel.
  2. The request is checked for completeness.
  3. The new banking details are validated independently.
  4. A callback is completed when required.
  5. An independent reviewer approves or rejects the request.
  6. The account becomes eligible for payment only after approval.

This sequence separates the person submitting the change from the people validating and approving it.

Which Changes Should Be Covered?

The policy should cover changes to sort codes, account numbers, Bacs instructions, Faster Payments details, CHAPS instructions, beneficiary names, payment addresses, bank countries and payment currencies.

It should also cover related changes to supplier telephone numbers, email addresses and legal-entity information. A bank change that follows several other master-data changes deserves additional scrutiny.

Which Submission Channels Should Be Approved?

The preferred channel is an authenticated supplier portal or a controlled workflow connected to the supplier master-data process.

Ordinary email may notify a supplier that a request has been received, but it should not be used as the source of truth for updating the master record. Spreadsheet-based requests should also be rejected because they create outdated versions, unauthorised edits and unclear ownership.

How Should Supplier Banking Details Be Captured Securely?

Supplier banking details should be submitted through a secure form that identifies the supplier user, records the submission time and preserves the original request.

The form should capture the supplier’s legal name, account holder name, financial institution, sort code, account number, bank country, payment currency, effective date and reason for the change.

UK payments commonly use a sort code and account number, so both fields should be validated before the request progresses.

The workflow should prevent uncontrolled edits after submission. If the supplier needs to correct the request, the correction should create a new version rather than silently replacing the original.

How Should Sensitive Data Be Protected?

Full account numbers should be masked wherever complete visibility is unnecessary. Access should be role-based, and employees should only see the information required for their task.

Banking data should be encrypted in transit and at rest. Callback notes and supporting evidence should be stored in line with the organisation’s UK GDPR obligations, internal retention policy and access controls.

How Should Submitted Banking Details Be Validated?

Banking details should be validated in several layers. A format check can identify obvious mistakes, but it cannot prove that an account belongs to the supplier.

The validation process should assess the sort code, account number, financial institution, account ownership, existing supplier record, country, currency and any unusual changes.

Are Sort Code Checks Enough?

No. A valid sort code confirms that the details follow an expected banking format or identify a financial institution, but it does not establish that the account belongs to the intended supplier.

The organisation should also verify the relationship between the account and the supplier’s legal entity. Relevant information may include the account holder name, company registration data, financial institution, account details and country.

Trustpair’s guidance on account validation services explains why checking bank details alone is not enough to prevent payment fraud.

What Is the Role of Confirmation of Payee?

Confirmation of Payee provides an additional check by comparing the payee name with the account details, sort code and account number. The Payment Systems Regulator explains that the service can return a match, close match or no match before a payment is sent.

However, Confirmation of Payee should not replace supplier verification. It can identify an obvious mismatch, but it does not prove that the supplier requested the change or that the account was not opened by a fraudster using a similar name.

Which Changes Should Trigger Additional Review?

Additional review is appropriate when the request introduces a new financial institution, account holder name, country, currency or contact detail. Multiple bank changes within a short period should also be investigated.

A new country is not automatically fraudulent. It may reflect an acquisition, treasury change or legitimate banking arrangement. However, the business reason should be documented and independently confirmed.

When Should You Use a Manual Callback or Automated Validation?

Manual callbacks and automated validation should work together.

Automated validation is useful for routine checks, high transaction volumes, consistent decision-making and continuous monitoring. Manual callbacks are most valuable when a request is unusual, incomplete, urgent or high risk.

Trustpair’s article on supplier validation automation describes this layered approach: automated checks handle routine verification, while human review addresses exceptions and cases requiring additional confirmation.

Control areaManual workflowAutomated workflow
SubmissionEmail, spreadsheet or manual formAuthenticated portal or integrated workflow
ValidationEmployee performs individual checksRules and account checks run automatically
CallbackOften required for every changeTriggered for exceptions and high-risk cases
Processing timeDepends on staff and supplier availabilityNear real-time for supported checks
Audit trailRequires manual documentationCaptured throughout the workflow
Best useComplex or exceptional casesRoutine volume and continuous monitoring

Automation should reduce repetitive work without removing human judgement. An inconclusive result should be reviewed, not automatically approved.

How Do You Complete an Independent Callback?

An independent callback confirms that the supplier actually requested the change. It must use contact information that did not originate from the request.

Use a Trusted Telephone Number

Use a telephone number from the existing supplier master record, a previously verified contract, a trusted procurement contact or another independently sourced record.

Never use the number included in the email, invoice, attachment or signature associated with the bank detail request. If the supplier’s telephone number has recently changed, verify that change before using it for the callback.

The National Cyber Security Centre warns that business payment fraud can involve an apparently legitimate contact asking an organisation to pay into a different bank account. It recommends contacting the bank directly using official details if a fraudulent payment is suspected.

Ask the Supplier to State the Change

Do not read the new account information aloud and ask the supplier to confirm it. Instead, ask the representative to state the reason for the change, the new financial institution, the expected effective date, the account holder name and the authorised contact responsible for the request.

This provides stronger confirmation because the representative must provide the information independently.

Record the Callback Outcome

The callback record should include the date and time, telephone number used, source of the number, representative’s name and role, questions asked, information provided and final result.

Trustpair’s guide to callback procedures provides additional recommendations for documenting phone-based verification before releasing payment.

Why Is Dual Approval Required Before Activation?

Dual approval prevents the person who creates a change from unilaterally activating it.

The requestor should submit the change and attach the validation evidence. An independent reviewer should assess the callback record, account ownership result, reason for the change and any risk indicators.

The new account should become payment eligible only after approval. Rejected or incomplete requests should remain in a controlled queue rather than being repeatedly edited until they pass review.

Urgency should accelerate escalation, not eliminate the approval requirement.

What Should Happen When a Request Looks Suspicious?

A suspicious request should trigger an immediate payment hold and escalation.

The organisation should prevent activation of the new account, notify finance or procurement leadership and involve information security if supplier mailbox compromise is suspected. The original email, attachments, portal submission, validation results, callback notes, approval decision and related payment records should be preserved.

If payment has already been sent, contact the bank immediately using official contact details. The FCA advises customers who have paid a scammer to contact their bank or payment service provider without delay. Recovery and reimbursement depend on the circumstances and the payment scheme involved.

Organisations in England and Wales can also report fraud through Report Fraud. Suspicious phishing emails can be forwarded to report@phishing.gov.uk through the GOV.UK reporting process.

What Should the Audit Trail Include?

The audit trail should reconstruct the complete decision from the original supplier record to the final payment eligibility decision.

It should preserve the original banking details, submitted replacement details, requestor identity, submission time, validation results, account ownership evidence, callback outcome, reviewer identity, approval decision and payment hold or release timestamps.

The audit log should capture before-and-after values rather than only the current record. Administrative actions, reopened requests, rejected changes and changes to approval status should also be recorded.

Access to the audit log should be restricted and monitored separately from access to the supplier master record.

How Should Evidence and Retention Be Managed?

Retention requirements should reflect applicable regulations, contracts, internal policies, audit requirements, litigation needs and risk level.

The organisation should document what is preserved, how long it is retained, who can access it and how records are protected from alteration. Higher-risk records, including rejected, emergency, escalated and fraud-related changes, may require stronger evidence handling and longer retention.

The UK GDPR principles of data minimisation and restricted access should be considered when storing full account details, call notes and supporting documentation.

How Should Supplier Banking Details Be Protected After Approval?

Approval does not end the control process. Banking information remains sensitive master data throughout the supplier lifecycle.

After approval, organisations should limit editing permissions, mask full account numbers, encrypt data, monitor related master-data changes and review access rights regularly.

Monitoring should include changes to supplier telephone numbers, email addresses, payment addresses and legal-entity information. Fraudsters may change contact details first and banking details later.

How Should Urgent Requests Be Handled?

An urgent request should follow an expedited process, not a weaker one.

The request should include a documented business justification, confirmation from the business owner, an independent callback, dual approval from authorised reviewers and a post-event review.

If payment must proceed before every check is complete, an authorised senior employee should explicitly accept the risk. The remaining validation steps should then be completed immediately.

How Can the Process Be Monitored Continuously?

Organisations should measure whether the process works in practice, not just whether a policy exists.

Useful metrics include callback completion rates, automated validation exceptions, rejected requests, emergency changes, approval-separation failures, repeated supplier changes and records with incomplete evidence.

Internal audits should sample approved, rejected and escalated requests to confirm that the request used the approved channel, account ownership was checked, the callback used an independent number, the reviewer was separate from the requestor and payment eligibility remained blocked until approval.

A high approval rate is not necessarily a sign of a strong process. It may indicate that reviewers are approving changes without sufficiently challenging the evidence.

What Is the Practical Implementation Checklist?

Policy and Ownership

Define supplier bank changes as high-risk master-data events, assign ownership to the supplier maintenance team, prohibit ordinary email and spreadsheets as intake channels, and document payment holds and escalation rules.

Intake and Validation

Use an authenticated portal, mask sensitive information, validate sort code and account details, confirm account ownership, and flag unexpected country, currency and account-holder changes.

Callback and Approval

Use a trusted telephone number, ask the supplier to state the requested change, record the callback outcome, separate request creation from approval, and require approval before payment eligibility.

Audit and Monitoring

Capture user identities and timestamps, preserve before-and-after values, restrict audit-log access, review rejected and emergency changes, and test the process through internal audits.

Final Recommendations for Secure Supplier Bank Detail Changes

The strongest secure supplier bank detail change process is layered. It does not depend on a single email, employee, Confirmation of Payee result or sort code check.

Use secure intake to control where requests originate. Use automated validation to identify account and supplier inconsistencies. Use an independent callback to confirm the request with the supplier. Use dual approval to prevent unilateral activation. Finally, preserve the evidence so every decision can be reviewed.

For additional guidance, explore Trustpair’s resources on supplier fraud schemes and UK sort code checking.

The goal is not to make every bank detail change slow. It is to make high-risk changes visible, verifiable and supported by evidence before money moves.

FAQ
Frequently asked questions
Browse through our different sections and find the answer to your question.

The safest approach combines secure submission, account ownership validation, an independent callback, dual approval and a payment hold until the change is approved.

Email should not be the approved source for changing supplier banking data. The supplier should be redirected to a secure portal or controlled workflow, and the request should be verified independently.

No. A callback confirms that the supplier requested the change, but it does not always prove that the new account belongs to the supplier. The callback should be combined with account ownership validation and dual approval.

The email, invoice or request may have been created by a fraudster or sent from a compromised mailbox. A number from the request could connect the employee directly to the attacker. Use a trusted number from an independent source.

No. Request creation and approval should be separated. An independent reviewer should verify the evidence before the new account becomes eligible for payment.

You’d like these articles

Ready to beat the fraudsters? Try our 2-minute game

Ready to beat the fraudsters? Try our 2-minute game