November offer: EXTRA 30% off all courses & bundles. Use NOVEMBER30 at checkout. Ends 30 Nov.

Bank Detail Change Fraud: A 3-Step Control for AP Teams

A genuine invoice can still be paid to the wrong account. Verify the bank change, approve it independently and check the destination before release.
Nov 14 / Peter Ilas, FCCA
The invoice is genuine. The goods arrived. The approval is valid. The money can still go to the wrong account.

Bank detail change fraud targets the payment destination, not necessarily the invoice. The control needs to follow the request through to payment release.

In one workflow I worked with, recurring bank-account mismatches came from invoice-reading software selecting the wrong account. The lesson was to fix the extraction, not weaken the control.

The short answer

Independently verify the request, approve the change separately and check the payment destination before release. Keep evidence: a familiar email thread or approval tick is not enough.

Why bank detail change fraud can bypass invoice checks

A three-way match can show that the invoice agrees with the order and receipt. It does not establish that a newly supplied bank account belongs to the supplier.

An outsider may impersonate the supplier or compromise a genuine email account. An insider may divert payments through unauthorised master-data changes. These routes differ, but both exploit a gap between approving what you owe and checking where you pay.

The FBI’s business email compromise guidance describes spoofed accounts and compromised billing threads. It recommends verifying changes in account numbers or payment procedures directly with the requester, and warns about pressure to act quickly.

Step 1: verify through a trusted channel

Call a previously verified supplier contact using a number already held in an approved record. Do not use the telephone number in the change email, its attachment or the new invoice.

Confirm who requested the change, which account is replacing the old one, and when it should take effect. Read back the relevant details through the approved verification process; do not settle for “yes, we sent an email”.

Record the contact, number used, date, verifier and outcome. Keep the evidence in the controlled supplier record, not only in someone’s mailbox.

If no trusted contact exists, use a separate onboarding or escalation process to establish one. Do not turn the absence of evidence into an urgent-payment exception.

A reply in the same email thread is not independent verification. The thread itself could be compromised.

Step 2: separate the change from its approval

Restrict who can edit supplier bank details. Have a different authorised person review the verification evidence and approve the specific change before it is used.

The reviewer needs the old and new values, the request, the verification result and the effective date. “Please approve” without those details creates an approval trail, not necessarily a meaningful check.

In the company I describe below, Procurement and colleagues responsible for contracts could not create or edit supplier bank accounts. Agreeing the purchase did not grant authority to change the payment destination.

Where practicable, separate master-data maintenance from payment release too. Review access when roles change, including temporary and emergency access.

Small teams may not achieve full segregation. A documented owner or CFO review before payment can provide additional oversight, but it does not make the remaining conflict disappear.

Step 3: check the destination before payment release

Before releasing a payment run, compare proposed payment accounts with the approved supplier records and the relevant change log.

Start with accounts changed since the previous run and any unresolved earlier exceptions. Include new suppliers, first payments and manual changes to payment instructions where relevant. A monthly report alone can miss a change made this morning.

For each exception, check that the approved change applies to this payment and that the account in the payment file matches the verified account. Review the actual payment proposal or file, not only the invoice or master-data screen.

Hold unexplained differences while they are investigated. Record who resolved the exception, the supporting evidence and the release decision. Do not treat a clean exception report as proof that every underlying record is correct.

A recent change is a reason to check, not proof of fraud. Equally, an older change is not automatically safe.

Before payment release

  1. Verify request

    Confirm through a trusted supplier contact.

    EvidenceContact, date and result.

  2. Approve change

    Use a separate authorised reviewer.

    EvidenceOld/new details and approval.

  3. Check payment

    Match the file to the verified account.

    EvidenceFile match and release decision.

Missing evidence? Hold the affected payment.

Periodic review does not replace the check before payment.

A fictitious walkthrough: the change arrives before the payment run

A regular supplier asks AP to replace its bank account shortly before the next run. The invoice and delivery are valid. The email asks for immediate action and provides a telephone number “for verification”.

AP does not call that number. It uses a previously verified contact. If the supplier denies the request, the payment is held and the incident is escalated. The original email and relevant records are preserved.

If the supplier confirms the change, a separate reviewer checks the evidence and approves the new account. Before release, the payment approver checks that the file uses that same verified account.

A correct invoice cannot compensate for an unverified destination.

From practice: fixing the OCR selection, not the bank-account control

In one company I worked with, only three accountants could change supplier bank details. We verified every change through another channel before use and reviewed the change log monthly.

A new account printed on an invoice could not simply be entered into the AP posting or payment details. It had to match the approved supplier master data.

The recurring problem was an invoice listing several bank accounts—a pattern you may recognise. The OCR (optical character recognition) system selected the first account, while our supplier record held the second.

From memory, that selection issue explained more than 90% of those mismatches. That is my recollection of one workflow, not an industry benchmark. These cases created extra work; the mismatch itself was not evidence of fraud.

The correction was to teach the OCR system which account to select, so future invoices from the same supplier matched the approved record. The answer was not to change the supplier master data merely to fit the extraction.

For me, the key is to distinguish a real bank change from a capture error. Our monthly log review provided oversight, not a check before each payment.

Bank change or capture error?

A genuinely new account

Independently verify the request, approve the change and check the payment.

OCR selected another listed account

Check against the approved supplier record; correct the capture selection.

Do not change approved bank details just to make an OCR mismatch disappear.

A mismatch needs investigation. It is not, by itself, proof of fraud.

A short checklist for the next bank-change request

Before using the new account, can the reviewer answer these questions?
  • Who requested the change, and how was their authority checked?
  • Which trusted contact and independently held number were used?
  • Who verified the request, and where is the evidence?
  • Who approved the old-to-new account change and effective date?
  • Does the payment file use the verified, approved destination?
  • Who owns any exception, hold or escalation?
If the evidence is missing, pause the affected payment through the authorised process. “The supplier is chasing” does not answer any of these questions.

If money has already left and fraud is suspected, contact your bank immediately through a trusted channel. Preserve the evidence and follow your incident process. The FBI also recommends immediate contact with the financial institution and reporting BEC to IC3 in the US. Outside the US, use your country’s official fraud-reporting channel. Follow the relevant reporting route locally; recovery is not guaranteed.

Key takeaways

  • Verify the bank-change request independently before using the new account.
  • A second approver needs evidence, not only a request to click approve.
  • Check the actual payment destination before release; periodic review serves a different purpose.
  • Record and investigate exceptions without treating every change as fraud.

FAQ

Is replying to the supplier’s email enough?

No. A genuine-looking thread may be compromised. Use a trusted contact through a separately established channel.

Does a valid IBAN or an account-name match replace verification?

No. Format validation checks structure, not ownership. A bank’s name-checking service can add information, but does not establish the requester’s authority or replace the change-approval process.

What if the payment is urgent?

Escalate to the designated decision-maker, document the issue and follow the approved exception process. Urgency should change the escalation speed, not remove the verification requirement.

Learn the red flags, then automate the checks

In my prevention course, I explain fraud schemes, red flags and bank-change controls.
Build repeatable checks with ready-made AI prompts, without coding.

Peter Ilas, FCCA

Founder, RSAgile | E-LITE Consulting
30 years in finance, accounting, audit and internal controls.
Builds practical AI tools for finance teams.
LinkedIn
Created with