Supplier bank-detail change controls for UK finance teams in 2026

Verify a supplier bank-detail change through two independent checks before anyone releases payment. Authenticate the request using contact details that were trusted before the request arrived, validate the proposed beneficiary through your bank, separate the master-data update from payment approval, and retain the evidence. No email, callback or bank-name check should authorise the change on its own.

TL;DR

• Treat every supplier bank-detail change as a controlled exception, not routine invoice administration.
• Call a known supplier contact using a number already held in your records, not one supplied in the change request.
• Use Confirmation of Payee as corroboration, then investigate every close match, no match or unavailable result.
• Separate the person who changes supplier data from the person who approves the change and releases payment.
• Keep one audit record linking the request, verification, beneficiary check, approval and first payment.

Explore how connected finance operations can keep exceptions visible without removing human approval.

What should happen when a supplier asks to change bank details?

The first action is a payment hold, not a bank-record edit. Open a change case, preserve the original request and stop any invoice from using the proposed details until the case reaches an approved state.

Invoice or mandate fraud is the pattern in which a criminal presents new or amended bank details and diverts payment to an account they control. Take Five describes intercepted, compromised or spoofed supplier email as common routes. A convincing email thread is therefore context, not identity evidence.

The NI Cyber Security Centre explains that business email compromise can come from a compromised work email account or a new account that looks very similar. The practical consequence is blunt: a reply from the same mailbox, or from a convincing lookalike, does not independently verify the first message.

Use a six-stage workflow:

1. Quarantine the request. Record the supplier, old masked details, proposed masked details, affected invoices, value, currency, requester and received time.
2. Authenticate the supplier. Contact a known person through a number, portal or other route established before the request arrived.
3. Validate the beneficiary. Run the bank's account-name check and record the exact result rather than reducing it to a tick.
4. Approve the data change. A second authorised person reviews the case, its evidence and any exception.
5. Release the payment separately. The payment approver checks that the approved change case matches the beneficiary in the bank.
6. Review the first payment. Confirm receipt through the trusted supplier route and close the case only when the evidence is complete.

Which evidence is strong enough to approve the change?

The NCSC advises contacting the organisation directly when there are doubts about a message. Independence matters more than the channel label. Calling a telephone number printed in the suspicious email is still one compromised evidence path.

Start with the contact record that existed before the change. That may be the supplier onboarding file, signed contract, approved portal profile or a relationship owner's verified address book. If you do not have a trusted contact, stop and rebuild identity from authoritative records rather than letting urgency lower the standard.

Pay.UK describes Confirmation of Payee as checking account details and returning four possible outcomes: yes, close match, no match or unavailable. Record the outcome exactly.

A close match is not an approval. Ask why the name differs, repeat the trusted-contact check and confirm the legal or trading name expected on the account. A no match or unavailable result moves the case into an exception queue. It does not create permission to bypass the check.

The Payment Systems Regulator describes CoP as checking the payee account name against the other details supplied by the payer. That makes it useful corroboration. It does not establish who sent the change request, why the supplier changed accounts or whether the person approving the change is authorised.

How should maker-checker control work?

The person who receives or prepares a change should not be able to complete the entire chain. The NCSC says an identity and access management policy should decide which actions require multiple people and which actions are recorded. It also identifies approving financial payments as a critical function.

A lean team does not need a committee. It needs clear roles and a hard block against self-approval:

• Requester: submits the supplier change and supporting context.
• Preparer: opens the case, conducts the trusted-contact check and enters proposed details.
• Change approver: reviews the evidence and authorises the supplier-master update.
• Payment approver: compares the payment beneficiary with the approved case before release.
• Control owner: reviews access, exceptions, ageing and completed cases.

One person may hold more than one role in a very small team, but they should not prepare and approve the same bank-detail change. If staffing makes that impossible, use a director, outsourced finance lead or another formally authorised reviewer for the approval step.

ICO guidance says role-based profiles should reflect each role's requirements. Apply that principle to the supplier master: most users can view it, fewer can propose edits, and a smaller named group can approve them. Review access after role changes and leavers.

What should the audit record contain?

A useful record lets a reviewer reconstruct the decision without searching email, chat, the ERP and the bank portal separately. Store the decision trail, not just a screenshot of the final account.

• Case identifier, supplier entity and affected legal entity.
• Old and proposed bank details, masked except where the controlled process needs the full values.
• Original request, attachments and message headers where available.
• Trusted contact used, source of that contact and callback time.
• Name and role of the supplier representative who confirmed the change.
• Confirmation of Payee input, result and any exception explanation.
• Preparer, change approver and payment approver identities with timestamps.
• Affected invoices, payment batch and first-payment receipt confirmation.

The NCSC's logging guidance asks which questions you need to answer when choosing which logs to generate or retain. Apply the same logic here. Your record should show who changed what, who approved it, when it became effective and which payments used it.

Logs should be protected from casual alteration. An audit history that can be overwritten by the same user who edits supplier data is weaker than an append-only event record or a controlled system journal.

Which warning signs should send a request to the exception queue?

A red flag is a reason to inspect, not proof that a supplier is dishonest. Several signals together should raise the verification level and pause payment.

• New contact route: the request comes from a new domain, address, phone number or portal user.
• Combined changes: bank details, contact details and authorised personnel change together.
• Pressure: the requester asks you to ignore process, conceal the change or release payment immediately.
• Changed invoice: branding, layout, remittance wording or payment instructions differ from prior invoices.
• Beneficiary exception: the account-name result is close, wrong or unavailable.
• Unusual payment: the first payment is materially larger, earlier or in a different currency than the supplier's normal pattern.
• Mailbox anomaly: messages are delayed, diverted, deleted or inconsistent with the supplier's earlier correspondence.

An NCSC case study records doctored invoice details, later phone verification for new or updated supplier details, and MFA for Microsoft 365. The case matters because the fraudulent message appeared inside a credible supplier conversation. Grammar and visual polish were not reliable controls.

How do you strengthen the systems around the workflow?

NCSC guidance says business email accounts can expose banking details, enable impersonation and help attackers reach other accounts. Secure both finance and supplier-facing mailboxes with strong sign-in controls, monitoring and a reporting route that staff can use without blame.

The NCSC says accounts with access to sensitive data should have MFA enforced, apart from closely monitored emergency accounts. Prefer stronger, phishing-resistant methods where your systems support them, and do not leave legacy access routes outside the policy.

Technical controls support the workflow:

• Use MFA or passkeys for email, ERP, procurement and banking access.
• Alert on new mailbox forwarding rules, unusual sign-ins and privilege changes.
• Restrict supplier-master write access and review it regularly.
• Keep payment approval credentials separate from day-to-day email use.
• Publish a simple route for staff to report suspicious requests quickly.
• Practise the response for a compromised supplier or finance mailbox.

Do not make staff responsible for spotting every fraudulent email. The bank-detail workflow is one process layer alongside strong sign-in controls, monitoring and a reporting route.

Can you add control without slowing every supplier payment?

Yes. Apply the extra work to the change event, not every ordinary invoice. Once a bank record has been independently verified and approved, routine payments can follow the normal payment policy until another change or risk trigger appears.

Use service levels that preserve scrutiny without letting cases disappear:

• Standard: complete change, trusted contact available, no payment due immediately and a clean beneficiary result.
• Heightened: new contact route, urgent payment, combined contact and bank change, or a beneficiary exception.
• Escalated: suspected mailbox compromise, instruction to bypass controls, conflicting supplier answers or payment already released.

UK Finance also advises confirming changes with the supplier using contact information already on file. A clearly owned queue lets the finance team do that promptly while the ordinary invoice run continues.

What does the control cost in a lean finance team?

Use your own volumes and loaded staff costs. Here is an illustrative calculation, not a claim about fraud probability, loss avoided or product savings.

• 30 supplier bank-detail changes per month.
• Preparer: 8 minutes per case at an assumed loaded cost of £40 an hour.
• Approver: 4 minutes per case at an assumed loaded cost of £60 an hour.
• Preparer cost: 30 × 8 ÷ 60 × £40 = £160.
• Approver cost: 30 × 4 ÷ 60 × £60 = £120.
• Total operating cost under these assumptions: £280 a month.

If one pending invoice is £180,000, record that as the payment exposure, not as an expected loss or a benefit. Do not add £180,000 to £280. One is a payment value and the other is an operating cost.

Measure turnaround, evidence completeness and exceptions separately. A control that closes cases quickly but leaves missing callback evidence is not performing well.

What should the approver check on payment day?

The final approval should compare the payment in front of the approver with the approved change case. Do not rely on a green status inherited from an earlier system.

1. Does the supplier and legal entity match the approved case?
2. Do the bank details and beneficiary name match the approved values?
3. Was the change approved before the payment file was created?
4. Are the invoice, amount, currency and due date expected?
5. Is any bank warning or CoP exception unresolved?
6. Is the approver independent of the supplier-master change?
7. Will the first-payment confirmation return through the trusted contact route?

Stop if any answer is unclear. The supplier's commercial urgency does not resolve an identity or beneficiary exception.

What if the payment has already gone to the wrong account?

Move immediately from approval workflow to incident response. If a fraudulent payment has been released, the NCSC advises contacting your bank directly through its official website or phone number.

• Contact the bank and request its fraud response and recovery process.
• Tell your IT or security owner so compromised accounts, sessions and forwarding rules can be investigated.
• Preserve the request, headers, approvals, bank response and relevant logs.
• Contact the genuine supplier through the trusted route.
• Report the incident through the appropriate UK reporting route and meet any sector-specific obligations.
• Freeze related supplier changes and payments until the scope is understood.

Do not continue replying in a possibly compromised thread. Move coordination to a known channel and document every action and timestamp.

How should you test the control in 2026?

Run a tabletop test with a plausible change that arrives before a large payment run. Use a known supplier, a convincing email thread, a slightly different beneficiary name and an unavailable decision-maker.

The test passes only if the team can show:

• the request entered a hold before supplier data changed;
• the callback used a pre-existing contact record;
• the beneficiary result and exception were retained;
• the preparer could not approve their own change;
• the payment approver could see the approved case;
• the incident route worked when compromise was suspected; and
• the complete trail could be retrieved without rebuilding it from personal inboxes.

Track median completion time, percentage with complete evidence, self-approval attempts blocked, aged exceptions and changes followed by bank warnings. Review false positives as well as misses so the control remains proportionate.

Where does Round Treasury fit?

At Round Treasury, we connect treasury, accounts payable and related finance work. Our automation prepares, reads and surfaces exceptions; named humans retain consequential approval.

That operating model fits teams that need supplier changes, invoices, payment preparation and approval evidence to stay connected while humans own the consequential decision. It is particularly relevant when several entities, banks or accounting systems make a shared queue more useful than another inbox checklist.

Payments sync to Xero or NetSuite. Treat that connection as part of the operating trail, not as independent proof that a supplier's new bank account is genuine.

Where we would put ourselves: choose us when you want connected treasury and accounts-payable operations with named human approval and visible exceptions. Keep your existing ERP workflow when it already provides independent verification, controlled master data and retrievable evidence with acceptable effort. Choose a specialist beneficiary-verification service when you need deeper account validation than your bank and operating stack provide.

The case against us is equally plain. If you want software to declare a supplier identity proven and remove human responsibility, that is not the model described here. Test the workflow with one real supplier change before making a platform decision.

Sources

• Take Five: Invoice and mandate fraud
• NI Cyber Security Centre: Business email compromise
• NCSC: How to check if a message is genuine
• NCSC: Business payment fraud
• NCSC Board Toolkit: Assurance and oversight
• NCSC: Identity and access management
• NCSC: Avoiding MFA anti-patterns
• NCSC: Secure your email
• NCSC: Logging for security purposes
• Pay.UK: Confirmation of Payee FAQs
• Payment Systems Regulator: Confirmation of Payee requirements
• ICO: Access control
• UK Finance: Protect your business from scams

Nothing within this blog is intended to be a recommendation. Round does not offer financial advice.