New Bank Details? Approve the Change Before You Pay the Invoice

The purchase was approved. The vendor is real. The invoice is the one you expected. Then an email arrives saying the vendor has "moved banks," and the next payment goes to an account nobody on your team has ever seen.

That's the pattern police and CERTs keep warning about this year, and it doesn't touch the approval at all. The approval was fine. The payment went to the wrong place. So the control has to sit between "approved" and "paid," on the vendor's payment details.

What's happening

• Singapore Police reported at least 66 cases since 1 January 2026, with losses of at least $19 million, in a business email compromise (BEC) variant where scammers ask victims to update a vendor's bank account and then pay into it (Singapore Police Force, 20 May 2026).
• In Canada, the Anishinabek Police Service issued a second warning on 9 September 2026 after five more cases with combined losses over C$544,000. In each, the organization had an established supplier and the fraudsters used a spoofed or compromised supplier mailbox to say payment details had changed (ArayaPRO summary of the police warning).
• Austria's CERT.at reported a rise in BEC reports in August 2026, including invoice fraud and thread hijacking, where attackers sit in a real invoice conversation and inject new payment instructions (CERT.at).
• The FBI's 2025 Internet Crime Report lists $3,046,598,558 in reported BEC losses for 2025, up from $2,770,151,146 in 2024 (FBI IC3 2025 report).
• The 2026 AFP Payments Fraud and Control Survey says BEC affected 74% of organizations in 2025, that fraudsters mainly impersonate vendors or executives to request changes to payment instructions, and that 39% of organizations still receive genuine emails that have been intercepted by fraudsters (AFP survey key highlights, via Truist).

The common thread: nothing about the supplier or the invoice looked wrong. Only the bank account did, and nobody checked it.

Why approval-first teams are exposed here

A Slack approval answers "should we buy this, from this vendor, for this amount?" It usually doesn't answer "where does the money go?" That lives in the vendor record in QuickBooks or Xero, or in whatever your payment run pulls from, and it can be changed by anyone with access, often by copying details out of an email.

So a team can have clean approvals, clean coding, and receipts attached, and still pay a fraudster, because the bank details were edited after the vendor was approved.

The fix is to treat a bank-detail change as its own request that needs its own approval, with evidence, just like a purchase.

Treat "new bank details" as a request, not an update

When a vendor (or someone claiming to be one) asks you to change where you pay them, don't edit the vendor record. Open a request instead, the same way you would for a purchase. Capture:

• Vendor and the open bills or upcoming payments the change would affect.
• Who asked and how: the sender address exactly as received, and whether it came in an existing thread.
• Old and new details, so the reviewer can see what's actually changing.
• Callback evidence: who on your side called, the number they called, where that number came from, who they spoke to, and when.
• Approver who is not the person who received the request or the person who will release the payment.

Then route it to finance for approval in Slack, like any other spend decision. Only after approval does someone update the vendor record.

Verify on a channel the requester doesn't control

Every source above lands on the same rule: confirm the change through a channel the requester can't also control.

• Call the vendor on a number you already hold on file, never one supplied in the change request (CERT.at; ArayaPRO).
• Don't treat a reply in the same email thread as confirmation. A supplier's real mailbox can be compromised, so a message inside a normal thread proves nothing (ArayaPRO).
• Check the sender's domain carefully. Lookalike domains with small misspellings or extra characters are common (Singapore Police Force).
• Don't let urgency, seniority, or "keep this confidential" skip the process. CERT.at specifically says these procedures must not be overridden by supposed urgency, hierarchy, or demands for confidentiality (CERT.at).

The same logic applies if the change request shows up in Slack, for example in a shared channel with the vendor. A message in Slack is still a message from whoever controls that account. The callback to a number you already had is the check, not the channel the request arrived in.

Split the roles

One person should never be able to receive a bank-detail change, approve it, and release the payment. CERT.at recommends the four-eyes principle, where one person never both approves and executes a transfer (CERT.at).

For a small team that usually means:

• The person who received the request opens it and records the callback.
• Someone in finance approves the change.
• Whoever runs payments only pays to details that have an approved change on file.

And a second approver only helps if they actually look at the callback evidence, not just the same email the first person saw (Adaptive Security).

Hold the first payment to new details

Even with a callback, the first payment to a changed account is the riskiest one. A practical rule:

• Flag the vendor as "details changed" until one payment has gone through and the vendor confirms receipt.
• Don't let that first payment ride along in a batch run unreviewed.
• If the vendor later says they never got paid, you know which approval, which callback, and which person to start with.

When it's already gone

Speed matters. Contact your bank immediately to try to recall the payment, and report it to the authorities. Singapore Police list immediate reporting as part of their advice, and in the US the FBI takes BEC reports through IC3. Then look at the change request trail: if there isn't one, that's the gap to close first.

Checklist

• Never edit vendor bank details straight from an email or chat message.
• Open a change request with the vendor, affected bills, sender, old and new details, and callback evidence.
• Call back on a number you already had on file, never one from the request.
• Get approval from someone other than the requester and the payer.
• Update the vendor record in QuickBooks or Xero only after approval, and note the request reference on the vendor.
• Hold and review the first payment to new details, and confirm receipt with the vendor.
• If money goes to the wrong account, call your bank right away and report it.