Supplier Bank Details Changed? Verify Before You Pay

A supplier bank-account change is a stop event, not a routine invoice edit. Hold the payment and the existing supplier master record. Capture the request, contact a previously verified supplier representative through a separate channel, read back the complete change, and require a second authorised person to review the evidence before anyone releases funds.

That process reduces a known business-email-compromise risk. It does not prove ownership of the destination account or eliminate fraud. A familiar invoice, an old email thread and even the supplier's correct email address are not independent verification: the Australian Government's Scamwatch case study describes a loss where all three looked genuine and the bank-detail change was the only visible sign.

Stop the payment and freeze the existing supplier record

Do not overwrite the stored beneficiary as soon as a revised invoice or email arrives. Place both the proposed record change and the related payment on hold. The control should apply whether the message comes from a new address, a familiar address, the existing email thread or an attached document.

The Australian Signals Directorate's Australian Cyber Security Centre (ASD/ACSC) identifies unexpected bank-detail changes, urgent payment requests and pressure to bypass normal processes as warning signs. Its business email compromise guidance explains that criminals can compromise a vendor's account, edit legitimate invoice details and send the changed invoice from that account.

The pause prevents urgency from becoming evidence. A shipment deadline, overdue balance, production hold or supplier escalation may be commercially important, but none verifies the proposed beneficiary.

Assign one person to own the hold. Tell the requestor through the established commercial relationship that the business verifies every beneficiary change before payment. Do not accuse anyone of fraud at this stage; a genuine supplier can change banks, and a discrepancy still needs investigation.

Capture exactly what changed

Preserve the original message and attachment. Start a beneficiary-change record rather than making notes across inboxes and chat threads.

Record:

• supplier legal and trading names;
• invoice, purchase order and contract references;
• amount, currency and payment due date;
• old beneficiary details held in the approved supplier record;
• proposed beneficiary name, bank, account identifier and bank location;
• sender address, channel and timestamp;
• stated reason and requested effective date;
• links or attachments provided with the request; and
• the person who imposed the payment hold.

This first comparison can expose a different company name, bank jurisdiction, currency or invoice reference. It cannot establish that a matching request is genuine. Treat each field as something to verify, not a score where enough familiar details create a pass.

Re-establish contact outside the request

Choose an independent route

Call a known and verified supplier number established before the change. Do not use the telephone number in the change email, revised invoice, attachment footer or follow-up message as the only contact route. ASD/ACSC's prevention guidance specifically recommends calling the sender on a known, verified number rather than one in the email.

Good sources include an approved supplier-onboarding record, a previously verified contract contact, or a number already used for operational calls. If there is no reliable historic number, source a new route independently and validate it through the supplier's established business presence and more than one known relationship. A website number can help, but a newly discovered number should not quietly be treated as equivalent to a long-held contact.

If you cannot establish an independent route, keep the payment held. Emailing “Did you really change your account?” into the same potentially compromised mailbox is not an independent check.

Speak to the right person

Ask for the supplier representative authorised to confirm finance changes. For a material payment, include an established commercial contact who knows the order, not only a new accounts contact named in the request.

Language and time-zone pressure can weaken the read-back. Use a competent interpreter or established bilingual contact where needed. If either party cannot clearly confirm the fields, stop and arrange a better call instead of inferring agreement.

Read back the complete change

The callback should reconcile a defined set of facts. Avoid an open question that supplies the answer, such as “You changed to account 123, correct?” Start by asking the authorised supplier representative to state the change and its business context. Then read back the recorded details field by field.

Confirm:

• supplier legal entity and trading name;
• affected invoice and purchase order;
• beneficiary name;
• bank name and location;
• complete account identifier using an agreed secure method;
• payment currency;
• effective date and reason for the change;
• whether the old account should no longer be used; and
• whether any other open invoice or customer communication is affected.

Record who participated, which independently sourced number was used, when the call occurred and what was resolved. Do not store passwords, access credentials or unnecessary personal information in the record.

The callback confirms what the contacted supplier representative instructed. It does not by itself prove the bank's account-ownership records, sanctions position or ability to receive the payment. Any bank or payment-provider validation is a separate layer and must be interpreted within that provider's current coverage.

Apply dual control before changing the master record

ASD/ACSC recommends an approval process for requests to change payment details or make a large transfer. Scamwatch also advises businesses to consider multi-person approval for transactions over a chosen threshold.

For supplier bank changes, make the second approval evidence-based. The approver should see the original request, old-versus-new comparison, independent contact source, callback record, unresolved discrepancies and related invoice/PO. A bare “verified” checkbox is too easy to approve without understanding what was checked.

Where staffing permits, separate these actions:

1. receiving and recording the request;
2. verifying the supplier through the independent route;
3. changing the supplier master data; and
4. approving or releasing the payment.

A small business may not have four different people. It can still prevent one inbox action from changing a beneficiary and sending money by requiring a second authorised person at the change or payment-release gate.

Use a fail-closed verification record

The following table turns “we checked it” into a reviewable decision.

Keep the old record in place until every required gate passes. If a field changes after verification, reopen the process. Do not treat a revised invoice as a minor correction to an already approved change.

Evidence retention should follow the organisation's approved policy and any advice applicable to its transaction and jurisdiction. This framework does not prescribe one universal retention period.

Release payment without losing the evidence chain

Beneficiary verification is only one payment gate. Reconcile the invoice and purchase order, confirm that the commercial milestone is actually due and keep the payment approval connected to the verified change record.

OPL's supplier payment-terms guide explains how to align deposits and balances with controlled milestones. The proforma-invoice checklist covers the transaction basis before a deposit. The business-licence guide helps identify the registered Chinese counterparty; it does not verify a bank account.

After approval:

• update the supplier record with the authoriser and effective date;
• preserve the old details and change history under controlled access;
• create the payment from the approved record, not by copying from the email;
• have the payment approver compare the beneficiary to the approved change; and
• record the payment reference against the invoice and verification record.

A small test payment is not a substitute for independent verification. Money can still reach the wrong account, and receipt confirmation sent through the same compromised channel proves little.

If the change cannot be verified

Keep the payment and supplier-record change blocked. Notify established supplier contacts that a change request is unresolved and ask their finance and IT teams to investigate through their own procedures.

Escalate internally if the message involved urgency, secrecy, changed domains, suspicious links or a possible mailbox compromise. Preserve the email in its original form where your technical process allows; forwarding screenshots alone may lose useful header or attachment evidence.

Do not negotiate around a failed control by splitting the payment, reducing the amount or asking the same sender for another document. Those steps do not create an independent trust path.

If money has already been sent

Contact the financial institution immediately using its official contact details. ASD/ACSC says the institution may be able to stop a transaction; that is a reason to act quickly, not a recovery guarantee.

Use the current ACSC recovery steps, including ReportCyber where applicable, and report the scam through Scamwatch. Preserve the payment record, original messages, headers, attachments, verification notes and contact timeline. If an email account may be compromised, follow current account-security guidance and obtain qualified technical support.

The incident may also create contractual, privacy, insurance or reporting questions. Get advice appropriate to the facts rather than relying on a general checklist to decide those obligations.

Final beneficiary-change checklist

Before payment release, confirm:

• the payment and existing supplier record were frozen when the change arrived;
• the original request and old-versus-new details are preserved;
• the supplier was contacted through a route independent of the request;
• an authorised supplier representative stated and confirmed the complete change;
• invoice, PO, entity, beneficiary, bank, currency and effective date reconcile;
• any additional bank/provider check is recorded with its limitation;
• a second authorised person reviewed the evidence;
• master-data change and payment release were separately controlled;
• unresolved discrepancies resulted in a hold, not a partial pass; and
• the immediate bank, ReportCyber and Scamwatch route is available if funds moved to suspect details.

The decision rule is simple: if the trust path depends on the same message that asked for the money, verification is incomplete. Keep the payment held until independent evidence closes the gap.

Sources

• ASD/ACSC — Preventing business email compromise
• ASD/ACSC — Protecting against business email compromise
• ASD/ACSC — Report and recover from business email compromise
• Scamwatch — Business email compromise: our business lost $190,000 when our supplier's email was hacked