The Email That Says "We Have Changed Banks": Stopping Supplier Bank Detail Fraud Before the Payment Run

The email arrives at 15:40 on a Thursday. It comes from the credit controller at a supplier of aluminium castings, a company an engineering firm in the English Midlands has bought from for nine years. It is a reply in a real email thread, the one where the two companies have been discussing a late shipment for the past fortnight. The signature is right. The tone is right. It even mentions the late shipment.

It says the supplier has moved its banking after a refinancing, and asks the firm to update its records before Friday's payment run. There are three open invoices worth £86,400 in total, and the supplier would be grateful if they could be paid on time to the new account. A letter is attached, on the supplier's letterhead, giving the new sort code and account number. A final line says the supplier's phones are being moved to a new system this week, so it is best to reply by email.

The accounts payable clerk raises a change request to the supplier record. Her team leader checks it the next morning, sees the letter and the email thread, and approves. SAP's control works exactly as designed. Two different people looked at the change before it went live. Friday's run pays £86,400 to the new account.

Three weeks later, the real credit controller calls to ask why the three invoices are still unpaid. She never sent the email. Someone had been reading her mailbox for a month, waiting for the right moment. The firm's bank asks the receiving bank to recall the money. By then, it had been moved on within hours of arriving.

The company, supplier and figures in this story are a composite, built to show how these attacks usually unfold. The attack itself is one of the most common and expensive frauds a finance team faces. The FBI's Internet Crime Complaint Center recorded almost $3.05 billion in reported losses from business email compromise in 2025, second only to investment fraud. A large share of those cases follow exactly this pattern. Someone pretends to be a supplier and asks for future payments to go to a new account.

Why this works so well

Most people picture payment fraud as a fake invoice for something that was never delivered. This attack is cleverer, and that is why it succeeds. Nothing about the invoices is fake. The castings were delivered. The invoices are genuine, approved and due. The only thing that changes is where the money goes.

That means every control built to check invoices passes without a murmur. The purchase order matches. The goods receipt matches. The amounts are right. The invoices have been approved by the people who ordered the castings. Three-way matching, duplicate checks and approval workflows all say yes, because the invoices deserve to be paid. They just should not be paid there.

Think of it as someone redirecting your post. Every letter that arrives is genuine and addressed to you. The fraudster has simply filled in a change-of-address form at the post office. Nobody checks the letters, because there is nothing wrong with the letters.

The attack also lands on people at the worst possible moment. It usually arrives a day or two before a payment run, when AP is busiest. It comes from someone the team trusts, often in a thread they are already part of. It is polite and plausible. Companies do change banks after refinancing, mergers and new finance leadership. And it usually comes with a gentle push to act fast and to avoid the one step that would expose it, which is picking up the phone.

Why SAP's dual control does not stop it

SAP has a sensible protection for exactly this risk. A company can mark a supplier's bank details as sensitive. When anyone changes them, the supplier is blocked from payment until a second person confirms the change. The change is logged, with who made it, who confirmed it and when.

Every company that runs SAP should switch this on. But it helps to be clear about what it protects against. Dual control proves that two people inside your company agreed to the change. It does not prove that the supplier asked for it.

In our story, both people did their job. The clerk raised the change with the evidence attached. The team leader checked that evidence before confirming. The problem was that both of them were looking at the same email and the same letter, both of which came from the fraudster. Two people checking forged paperwork is still forged paperwork. The control did what it was built to do. It just was not built to answer the question that mattered.

Dual control is a strong defence against one specific risk, an employee changing a bank account on their own to divert money to themselves. Against an outsider with a convincing email, it adds a second signature to the same mistake.

Six warning signs inside a fake request

Fake bank change requests are getting better, but they still leave traces. Almost every one carries several of these signs. A careful person who knew where to look would spot most of them. The trouble is that nobody has time to look this carefully at every request, a few hours before a payment run.

The sender is almost right. Sometimes the email comes from a lookalike address, with one letter changed, a hyphen added or a different ending, such as castings-ltd.com becoming castlngs-ltd.com with an l in place of the i. Sometimes the address is genuine, because the fraudster is inside the supplier's real mailbox, but the "reply to" address quietly sends answers somewhere else. Sometimes the email is a reply in a real thread, which makes it feel safe precisely because the earlier messages in that thread are real.

The timing is suspicious. The request lands just before a payment run, or just after the firm has approved a large batch of the supplier's invoices. Fraudsters who are reading a supplier's mailbox can see exactly what is owed and when it will be paid, and they time the request for the biggest payment they can catch.

It discourages you from checking. The phones are being moved to a new system. The usual contact is on holiday. Here is a new phone number to call instead. A genuine supplier changing banks has no reason to make verification harder. A fraudster has every reason to.

The account does not fit the supplier. The name on the new account does not match the supplier's legal name, or matches only loosely, such as "C Supplies Ltd" instead of the full company name. The bank is in a different country from the supplier's registered address. Or the account number is already on file in your system, for a different supplier or, more worryingly, for an employee. 

The letter does not match earlier letters. The letterhead is a slightly blurred copy of the real one. The font is different. The signatory is someone who has never signed anything before. There is no confirmation from the bank itself, only a letter from the supplier that anybody could type.

Something else changes at the same time. The request asks to update the remittance email address too, so payment advice goes somewhere new. Or it asks for an early payment "this once." Or several suppliers send bank changes in the same week, which can mean a fraudster has found a way into one of your own inboxes and is working through your supplier list.

Why the usual fixes keep failing

Most finance teams already have a policy for this. It usually says that every bank change must be confirmed by calling the supplier. The policy is right. It fails in practice for three reasons.

People call the number in the email. The fraudster provides a phone number, and someone answers it with a confident voice and the right company name. The call-back happens, the box gets ticked and the money goes anyway. A call-back only works if the number comes from somewhere the fraudster cannot touch, such as the supplier record set up years ago, the signed contract or the supplier's public website.

The call never happens. The clerk is told the phones are down. It is Thursday afternoon and the run is tomorrow. The supplier is long trusted. Someone decides that this one is obviously fine. The policy exists, but nobody can see whether it was followed, because the evidence of a phone call is a line in someone's notebook, if it exists at all.

The voice on the phone is not who you think. Voice cloning tools now let a fraudster sound like a specific person from a few seconds of recorded audio. A call to the right number can still go wrong if the person answering has been impersonated well, or if the fraudster calls you first, pretending to confirm the change on the supplier's behalf. A call you did not start is not a check.

Some companies move bank changes into a supplier portal where suppliers update their own details. That removes the email, but it moves the risk to the supplier's portal login. If a fraudster is already in the supplier's mailbox, a password reset email gets them into the portal too.

All of these approaches share one weakness. They depend on one busy person, at one moment, spotting something subtle and choosing to slow down. That is a lot to ask of anyone at 15:40 on a Thursday.

Turning every request into a checked case

What changes the picture is treating a bank change as a case to be worked, not an email to be actioned. It should not matter how the request arrives, whether by email, portal, letter or phone call. Each one goes through the same checks, gets the same independent call-back and leaves the same record. That is work an agent can take on, so the people involved only have to make one decision, with all the evidence in front of them.

Go back to the Thursday email and watch what happens when an agent reads it first.

The agent recognises the message as a bank change request, even though the subject line is about a late shipment. It opens a case for the supplier and starts checking.

It reads the email's sender details. The display name is right, but the address uses castlngs-ltd.com, with an l where the i should be. Every earlier email from this supplier came from castings-ltd.com. The agent flags it.

It looks at the thread. The earlier messages are genuine and came from the real address. This reply is the first message from the lookalike address. Flagged.

It reads the attached letter and compares it with the supplier's last bank letter, from 2021, which is stored with the supplier record. The logo is a lower-resolution copy. The signatory has never appeared on any earlier document. There is no bank confirmation attached. Flagged.

It checks the new account details. The UK's Confirmation of Payee service compares the name on an account with the name you expect to pay, and here it reports that the account is not held in the supplier's name. The agent also checks the account number against every supplier and employee record in SAP. No match, which is good, but the name mismatch is already a serious warning. Flagged.

It looks at the timing. The supplier has three approved invoices worth £86,400, all scheduled for tomorrow's run. The request arrived less than a day before. Flagged.

And it reads the line about the phones. The request asks the firm to avoid a call. Flagged.

Six warning signs out of six. The agent does not need to decide whether this is fraud. It needs to make sure the right person sees all of this before anything changes, and that the call-back happens on a number the fraudster cannot control.

The call-back that actually protects you

The agent holds the change. Nothing in the supplier record is touched, and the three invoices are held out of tomorrow's run until the case is closed.

It then sends the case to the person who owns supplier bank changes, usually someone in the master data team or a senior member of AP, not the clerk who received the email. The case shows every check, the reason for each flag and the evidence side by side. It includes the phone number to call, taken from the supplier record and the signed supply contract, along with when that number was last confirmed. And it suggests the questions to ask. Confirm the request was sent. Confirm the last four digits of the new account. Confirm the name of the person who sent it.

The team leader calls the supplier's main number, the one on file for nine years. The real credit controller answers, says she sent nothing and that her company has not changed banks. She also learns that her mailbox has been compromised, which is something her own IT team needs to know urgently. The team leader rejects the change. The agent records the outcome, the call, who made it and when, and releases the three invoices to be paid to the existing, genuine account on Friday as planned.

The supplier is paid on time. The firm loses nothing. And the record shows exactly what was checked and by whom, which is the kind of evidence auditors look for, as we described in what auditors actually look for in an automated audit trail.

What happens when the change is real

Most bank change requests are genuine. Companies do refinance, merge and switch banks. A check that treats every supplier as a suspect, or that drags on for weeks, damages relationships and delays payments that should go out on time.

Here the agent makes the honest case quicker too. When a supplier sends a genuine change, the checks usually come back clean. The email comes from the usual address and has the usual history. The letter matches earlier ones, and often comes with a confirmation on the bank's own letterhead. The account name matches the supplier's legal name. The timing is ordinary. The case still goes to a person and the call-back still happens, because that step is not optional. But the person sees a short, clean summary, makes a two-minute call and confirms. The supplier record is updated the same day, with the evidence attached.

The difference is not that some suppliers skip the check. Every change gets the same check. What changes is how much of the reviewer's time each one needs. Clean cases take minutes. Suspicious ones get the attention they deserve, before money moves rather than after.

The payment run as a final gate

Even with every request checked, there is one more place to protect, and that is the payment run itself.

Before each run, the agent lists every supplier in the run whose bank details changed recently, say in the past 90 days. For each one, it shows the case, the call-back record and who confirmed it. Any supplier whose bank details changed without a completed case is held out of the run and flagged.

This catches changes that never went through the front door. A bank account edited directly in the supplier record, perhaps by someone with the access to do it, shows up here even though no request was ever received. That is the insider risk SAP's dual control was designed for, and it is good to have a second net under it. It also catches the case where a supplier record is changed through a portal or an automated feed that bypassed the usual steps.

It catches a quieter pattern as well. Several suppliers changing banks in the same few weeks is unusual, and when it happens, it often means one of your own mailboxes has been compromised and someone is working through your supplier list. A person looking at one request at a time would never notice. An agent looking at all of them together does.

There is a link here to duplicate invoice payments, too. One of the oldest internal frauds is to post a real invoice twice and send the second payment to a different account. The payment run gate catches the second half of that trick, because the second payment would go to a bank account that does not belong to the supplier.

What the agent does not do

This is a fraud control, so the limits matter as much as the checks.

The agent never changes bank details on its own. It prepares the case and the change, and a person confirms it after a call-back. That keeps the decision with someone accountable, and it keeps the agent itself from becoming a new route for fraud. If a fraudster could talk the agent into changing an account, the agent would be the weakest link instead of the strongest.

The agent never treats an email as evidence of itself. A letter attached to a suspicious email is not confirmation. A phone number inside a suspicious email is not a safe number to call. The agent always looks for evidence from a source the requester does not control.

And the agent does not make the call. Verification depends on a human conversation with someone at the supplier who can be trusted, on a number that has been on file since before the request arrived. The agent makes sure that call happens, makes it easy to do well and records that it was done. We cover the broader question of which steps an AI agent should and should not take in why AI agent deployments need governance.

Getting started

You do not need a long project to reduce this risk. A few steps make a real difference quickly.

Switch on dual control in SAP for bank details, if it is not already on, and make sure supplier payments are blocked until a change is confirmed. It is not enough on its own, but it is the base layer.

Collect a trusted phone number for every active supplier, from contracts and long-standing records, not from recent emails. This one list is the foundation of every call-back.

Decide who owns bank changes. It should not be the person who received the request, and ideally not someone in the same team. Our post on the vendor onboarding bottleneck hiding inside your inbox looks at how supplier data changes flow today and where they get stuck.

Look back at the past year of bank changes. For each one, ask whether a call-back to a trusted number was recorded. The gaps show you where your process depends on luck.

Add the payment run gate. Even before every request is checked automatically, listing recent bank changes before each run, with the evidence behind them, closes the most expensive gap.

Tell your suppliers how you work. A short note saying "we will always call you on your number on file to confirm any bank change, and we will never act on an email alone" helps genuine suppliers expect the call, and makes fraudsters' jobs harder.

Back to Thursday afternoon

Picture the engineering firm again, the next time the email comes. And it will come, because fraudsters who have a supplier's mailbox try again, and other suppliers' mailboxes are being read right now.

The email lands at 15:40. Within a minute, the agent has opened a case, flagged the lookalike address and the mismatched account name, held the change and pulled the three invoices out of tomorrow's run. By 16:15, the team leader has called the number on file, heard from the real credit controller that nothing was sent and rejected the change. The supplier's IT team is already looking at their mailbox. On Friday, the £86,400 goes to the right account.

The clerk who received the email did nothing wrong in either version of this story. She read a convincing message from a trusted supplier and followed a reasonable process. The difference is that, the second time, she did not have to spot a single wrong letter in an email address at the end of a long day. The checks happened every time, the call was made to the right number and the money went where it was meant to go.

If you want to see how your last few bank change requests would have looked as checked cases, talk to us. We will show you what the agent would have flagged.