The Email That Changed the Bank Account
A supplier you have paid for years writes to say their bank has changed. The letterhead is right, the tone is right, and the clerk updates the record. The fraud that diverts a supplier payment is an edit to a field, and the defence is not a sharper clerk — it is a second person and a message to the address you already had.
The short version, first
Changing where a supplier is paid is the single most valuable edit in a finance system, because the next payment follows it without anyone looking again. In AWRA every change to a supplier’s bank or mobile-money details goes through one service, from the web form and the mobile app alike. A workspace can switch on a rule that holds the change until someone other than the requester approves it — that switch is set per workspace and is off by default. Whatever the switch says, once new details take effect the supplier is emailed at the address on file, and that notice cannot be turned off. While a change waits, payments keep going to the old details. What we have not yet closed: the notice goes out when the change applies rather than when it is asked for, and it goes to whatever email the record holds at that moment.
The email arrives on a Tuesday afternoon, from a supplier you have paid every month for four years. It is polite and a little apologetic: they have moved banks after a merger, please update your records before the next payment, new details attached on their letterhead. The sender name is right. The signature block is right. The invoice number it mentions is one you really are about to pay. The clerk who handles supplier records opens the supplier, types in the new account number, saves, and moves on to the next thing in the queue.
Three weeks later the real supplier phones to ask where their money is. It went, on time and in full, to an account that was opened a month ago and emptied the same afternoon the payment landed. Nobody in your organization did anything that looked wrong at the time. Every approval on that payment was genuine. The invoice was real, the amount was right, the payment run was reviewed and signed off by someone senior. The only thing that changed was a field — and the field was the one that decides where the money goes.
This is payment diversion, sometimes called mandate fraud or vendor impersonation, and it is the commonest serious fraud a finance team will meet. It does not need anyone inside the business. It needs a convincing message, an inbox that has been read by someone it should not have been, and a process in which one person can change payee details on their own.
Why training the clerk is the wrong defence
The usual answer is awareness: teach the people who maintain supplier records to spot a suspicious request. It is worth doing, and it is not a control. A good forgery is written by someone who has read the real supplier’s correspondence — often from inside a compromised mailbox on the supplier’s side — so it arrives in the right thread, references real invoices and matches the house style. The things a clerk is trained to look for are exactly the things the attacker has already copied.
More to the point, every check that relies on the request itself is checking the attacker’s own work. Phoning the number in the email reaches the attacker. Replying to the email reaches the attacker. A letter on letterhead proves only that somebody has a printer. The information that would expose the fraud — that the real supplier never asked for this — is held by exactly one party, and it is not the person reading the email.
Every check you run against the request is a check on the attacker’s homework. The only party who knows the change is false is the supplier, and the only way to reach them is through details you held before the request arrived.
So the defence has two halves, and neither of them is about judgement. A second person, so that one compromised or deceived individual cannot redirect money alone. And a message to the supplier through a channel the request cannot have touched — the contact details already on record — so that the one party who knows the truth gets to say so.
Checks that rely on the request
- Does the letterhead look genuine?
- Is the email from the usual address and thread?
- Does it mention a real invoice or contract?
- Does the phone number on the letter answer politely?
- Is the clerk experienced and careful?
Checks the request cannot reach
- A different person has to approve the change before it is used.
- The supplier is told at the contact details already on file.
- Payments keep going to the known details until the change is decided.
- A payment already approved will not silently follow a later change.
- Every request, refusal and change is recorded with who and when.
What AWRA does with a payout change
There is one path. Whether someone edits a supplier from the web form or from the mobile app, the bank and mobile-money fields are not written straight onto the supplier record; they are handed to a single service that compares them with what is on file and decides what happens next. Fields that did not actually change are ignored, so saving a supplier to correct their phone number does not raise a payout change at all.
The developer API refuses those fields outright: an integration can create and update suppliers, but it cannot set where they are paid. And payout fields are withheld from every outbound webhook, because a receiving address is whatever an administrator typed into a form, and a list of supplier account numbers sent there would be a ready-made kit for exactly this fraud.
-
Someone edits the supplier’s payment details
Only the fields that differ from what is on file are recorded, with their old and new values, as a change against that supplier. If an earlier change is still waiting, it is marked superseded — approving a stale request later would put back details somebody has already corrected.
-
With the switch off, it applies at once
The new details take effect immediately, as they always did, and everything in the last step still happens. This is the default for every workspace.
-
With the switch on, it waits
The change is held as pending and recorded in the audit log as requested. Everyone in the workspace who can approve suppliers — except the person who asked — gets a notification that a change needs a second person. The supplier page shows a Payment details change card with the old and new values masked to their last four digits, who asked, and when.
-
A different person decides
Approve or reject, on the web or in the mobile app. The requester is refused if they try to approve their own change, even if they hold the approval permission. Rejecting leaves the current details in use and records the rejection.
-
Once it applies, the supplier is told
The supplier is emailed a security notice at the address on their record: what changed, masked, and an instruction to contact you straight away using details they already trust — not a number from an email they were sent — if they did not ask for it.
The supplier notice has no off switch
Most emails in AWRA can be muted per workspace. This one is sent directly rather than through the notification settings, so there is nothing to mute. That is deliberate: it is a security control rather than a courtesy, and a control that can be switched off for convenience will eventually be switched off by someone who found it inconvenient. If the mail server is down, the change still stands and the failure is logged — a mail outage must not undo a decision somebody made.
What payments do while a change is waiting
This is the question that decides whether a hold is a control or an inconvenience. A pending change lives in its own record; the supplier record itself still carries the old details. So every payment made while the change waits goes to the account you already knew, and nothing is blocked. The supplier is not left unpaid because somebody is on leave, and the attacker gains nothing by timing a request just before a payment run.
The opposite timing is covered too. A payment run takes a snapshot of each supplier’s payee details at the moment it is approved, because what an approver signed off was paying those details. If the details change between approval and execution — legitimately or not — that line is refused when the run executes, with a message saying the supplier’s details changed after approval. An approver has to retry the line, which accepts the details as they now are. The money does not quietly follow an edit made after the person with authority looked at it. We wrote about the other half of that chain in The Person Who Keys the Bill Cannot Approve It.
A change that lands between approval and payment
Single payments made from a purchase order outside a run use the details on the supplier record at that moment — which, while a change is pending, are still the old ones.
Where each part of the control reaches
Which routes into the supplier record each safeguard covers
| Safeguard | Web edit | Mobile edit | New supplier |
|---|---|---|---|
| Second-person hold (when switched on) | Yes | Yes | No |
| Supplier emailed on change | Yes | Yes | No |
| Approvers notified | Yes | Yes | No |
| Audit entry with masked values | Yes | Yes | No |
| Payment run refuses a post-approval change | Yes | Yes | Yes |
Built and maintained Configurable by you, not maintained by us Not built
The developer API cannot write payout fields at all, and the supplier portal has no screen for a supplier to edit its own. The last column is the one we would change first: details entered when a supplier is created are written directly.
Two things in that table deserve plain words. First, the new-supplier column. When someone creates a supplier and types in bank details on the same form, those details are saved as entered, with no hold and no notice. That matters, because a well-run diversion sometimes does not touch an existing supplier at all — it creates a convincing new one. Today the defence there is your supplier onboarding process, not this control.
Second, the notice is only as good as the address it goes to. The supplier edit form saves the contact fields, email included, before it hands the payment fields to the service. So an edit that changes the supplier’s email and their bank account together will send the notice to the new email — which, in the case that matters, belongs to the attacker. With the switch on, the second person sees the payout change but not that the email moved in the same save. If your organization turns on one thing after reading this, make it a rule that a supplier’s contact email is never changed in the same edit as their bank details.
Should your workspace switch it on?
At least two people in your workspace can approve suppliers
Turn the switch on
The cost is one extra click by a second person, a few times a year per supplier. Payments are not delayed by a pending change, because they keep using the old details until it is decided.
Only one person can approve suppliers
Leave it off, or add an approver first
A held change cannot be approved by the person who asked for it, and there is no fallback, so in a one-approver workspace it would wait indefinitely. The supplier notice still goes out on every change with the switch off.
A supplier asks for a change by email or letter
Call the number you already had
Use the contact on file from before the request arrived, not the one in the message. Enter the change only after that call, and say in your own records who you spoke to.
You are changing a supplier’s email and bank details
Do it in two separate edits
Change the bank details first, so the notice reaches the address you trusted; change the email afterwards, once the supplier has confirmed through the old one.
What the record shows afterwards
Every held change is kept as a row with the old values, the new values, who asked, who decided, when, and its status: pending, approved, rejected or superseded. The audit log records the request, the rejection and the change itself, each with the masked before-and-after summary, so the trail can be read by someone who should not see full account numbers. The pending card on the supplier page, the mobile app and the supplier’s email all show the same masking — the last four characters of an account number, enough to recognise and not enough to use.
A supplier-detail routine that holds up without the software
- Never act on new payment details received only by email, however familiar the sender.
- Confirm every change by calling a contact you held before the request arrived.
- Require a second person to approve any change to where a supplier is paid.
- Tell the supplier, at the address already on file, every time their details change.
- Keep paying the known details until the change is confirmed.
- Never change a supplier’s contact email in the same step as their bank details.
- Review recent payout changes before every large payment run.
Five questions to ask any finance system about supplier bank details
Can one person change where a supplier is paid, and pay them, on their own?
What you will probably hear
A description of user roles.
How to read it
Roles say who may edit. Ask whether the edit itself is held for someone else, and whether the requester is refused at approval even when they hold the permission.
Who is told when a supplier’s payment details change?
What you will probably hear
An internal notification to an administrator.
How to read it
Internal notices go to people the attacker may already be deceiving. Ask whether the supplier is told, at which address, and whether anyone can switch that off.
What happens to payments while a change is waiting?
What you will probably hear
They are blocked until it is approved.
How to read it
A block punishes the genuine supplier and invites a workaround. The safer answer is that payments continue to the details already known.
If details change after a payment run is approved, what gets paid?
What you will probably hear
Whatever is on the supplier record when the file is produced.
How to read it
Then approval was of an amount, not a payee. Ask whether the approved details are kept with the run and checked again before money moves.
Can an integration or webhook read or write bank details?
What you will probably hear
Access is controlled by API keys.
How to read it
A key decides who may connect, not what leaves. Ask whether payout fields are excluded from the API and from outgoing payloads by name.
Closing the two seams is a small, specific build
The core of the control is built and in use. These are the pieces that would make the notice and the hold reach every route into the supplier record.
A notice to the previous email address
When a supplier’s contact email changes, the security notice for any payout change in the same edit goes to the old address as well as the new one, and the second approver sees that the email moved.
A supplier notice at request time
With the switch on, the supplier is told a change has been asked for while it is still pending, so they can object before anyone approves it rather than after.
The same hold on a new supplier
Payment details entered when a supplier is created go through the same service, so a convincing new supplier is held for a second person in the way an edited one is.
A recorded callback on the change
A field on the pending change for who confirmed it, by which contact on file, and when — so the approver is approving evidence rather than a typed number.
Each of these sits on the service every payout edit already goes through, which is what makes them small.
Tell us what your finance team needsWhat AWRA OpsHub does today
- One path for every payout edit. Bank and mobile-money details changed from the web form or the mobile app go through the same service; unchanged fields raise nothing.
- A second-person rule, per workspace. In Procurement settings; off by default. When on, a change is held until someone other than the requester who can approve suppliers approves it, on the web or in the app.
- Payments continue to the known details. A pending change lives in its own record, so payments use the old details until it is decided.
- A supplier security notice with no off switch. Sent to the supplier’s email on file whenever new details take effect, with masked values and an instruction to call back on a trusted number.
- Payment runs pay what was approved. Each line’s payee details are kept at approval, and a line whose details changed afterwards is refused until an approver retries it.
- Masked values and a full trail. Requests, rejections and changes are audited with last-four masking; superseded requests are kept rather than overwritten.
- Payout fields kept out of integrations. The developer API refuses them and outbound webhooks never carry them.
More we can add to your workspace
- A security notice to the previous email address. Sent when a supplier’s contact email changes in the same edit as their bank details, so the notice reaches the address you trusted.
- A supplier notice when a change is first requested. So the supplier can object while the change is still pending, before a second person approves it.
- The second-person hold on a newly created supplier. Payment details typed in at creation routed through the same hold and notice as an edit.
- A recorded callback against each change. Who confirmed it, through which contact on file, and when, shown to the approver.
- A reason captured on every approval and rejection. The change record already holds a decision note; the screens would ask for one.
- A warning to the approver when the supplier has no email on file. So the person approving knows the supplier will not be told.
Where we point you to a specialist
- We do not apply a change to payment details straight from an inbound email or an uploaded letter. A person enters it, and with the rule on, another person approves it.
- We do not offer a setting that mutes the supplier security notice. It is a control, and controls that can be muted for convenience end up muted.
- We do not judge whether a change request is genuine. The callback to a contact you already held is a decision for a person in your organization.
Each item in the middle column builds on the service every payout edit already passes through. Ask and we will scope it for your workspace.
See supplier bills and payments
Bills, payment runs that pay what was approved, and a second-person rule on where a supplier is paid — with the supplier told every time.
Explore payablesFrequently asked questions
Is the second-person approval on by default?
No. It is a per-workspace setting in Procurement settings and every workspace starts with it off, so edits to payment details apply at once as they always did. The supplier security notice is sent either way.
Are payments blocked while a change to supplier bank details is waiting for approval?
No. The pending change is kept in its own record and the supplier record still carries the old details, so payments made in the meantime go to the account you already knew. Nothing is held up because the approver is away.
Can the person who asked for the change approve it themselves?
No. The approval is refused for the requester even if they hold the permission to approve suppliers. If nobody else in the workspace holds that permission, the change waits until someone does, so a one-approver workspace is better served by leaving the switch off.
Can the supplier switch off the email telling them their details changed?
No, and neither can the workspace. The notice is sent directly rather than through the notification settings, because it is a security control. It goes to the email address on the supplier record when the change takes effect, and it is skipped only if the record has no email at all.
What if a supplier’s bank details change after a payment run has been approved?
The run keeps the details each line was approved to pay. When it executes, any line whose supplier details have changed since is refused with a message explaining why, and an approver has to retry it to pay the new details.
Can suppliers update their own bank details through the supplier portal?
Not today. The portal covers quotations, purchase orders and bills; payment details are entered by your own team, through the path that can require a second person and that tells the supplier.
