Picture this. Someone on your team gets an email from a trusted supplier. Everything looks normal: same apparent sender, same tone, a pending invoice. One small change: the next payment should go to a new bank account. The vendor master is updated in Business Central, Treasury releases the payment, and the month closes.
Weeks later, the real supplier calls asking why they haven't been paid.
The pattern repeats across companies of all sizes, and in public administrations too. In the last few months there are well-documented cases in Spain: the Valencia City Council uncovered a ~€194,000 fraud in 2024 at the Palacio de Congresos after the internal verification protocol for bank account changes was not followed (El Mundo), and Huércal‑Overa's City Council was hit in 2026 by a "Man in the Middle" scam that altered the supplier's bank account inside the invoicing emails (Europa Press). At a larger scale, INTERPOL reported in 2024 a case where a firm transferred USD 42.3 million to a fake supplier based on a legitimate-looking email (INTERPOL).
If it can happen to city councils with formal procedures and to multinationals with mature finance teams, it can happen to your company too.
Where the real risk lives (and why it keeps happening)
Fraud on bank account changes rarely starts in Treasury.
It starts earlier, in how the supplier master record is governed. The usual failures are four:
- Request = approval: an email request is treated as authorization.
- One person does it all: the same role validates, approves, and applies the change.
- Scattered evidence: justification lives in emails and calls, outside the ERP.
- No validation deadlines: critical tasks sit open for days with no escalation.
When two or three of these show up together, you don't need a sophisticated attacker: a believable email or an employee with enough access is enough.
How this process should be governed in Business Central (with AWH integrated)
The answer isn't to add bureaucracy or build a parallel circuit in spreadsheets. The answer is that a supplier bank account change must not be executable outside a controlled process inside the ERP itself. That is where Business Central, reinforced with AWH, turns internal control into something operational rather than decorative.
Separate request from authorization from minute one
The most common mental trap is treating an incoming email as sufficient authorization.
It isn't.
When a bank change request arrives, the first step is to open a formal process linked to the supplier, attach the minimum required documentation, and leave the bank data untouched until someone validates it. AWH lets you model that first stage with mandatory instructions and structured comments, so every request enters the same channel regardless of who picks it up.
Verify identity through a channel different from the one that delivered the request
If the request arrived by email, validation cannot happen by replying to that same email. You need to contrast it against a known contact on file, a pre-existing contractual channel, or a phone check to a number you already had.
Today that check usually lives outside the system, and that's part of the problem. With AWH it can live as a specific process stage, with an assigned owner and evidence attached to the task: it stops being a verbal best practice and becomes a step the flow requires before moving on.
Apply real, not nominal, segregation of duties
Segregation isn't asking for an "OK" over Teams from a colleague.
It's ensuring that whoever validates and whoever approves are different people, and that the system enforces it.
AWH lets you assign ownership per user or department at each stage and rely on Business Central's user tasks to formalize approval or rejection, keeping a record of who decided what and when. If the same person tries to close both steps, the flow design blocks it.
Control time, not just content
Sensitive bank changes shouldn't sit as "pending review" for a week. Every stage needs a reasonable target time, and the system must be able to flag what is past due. AWH supports durations in working hours, business days, or calendar days, and provides visibility over overdue tasks.
Execute the change only when the control is closed
Once validated and approved, the supplier's bank record is updated in Business Central. What matters is that the edit doesn't land before the approvals: the update is the end of the process, not a shortcut we rationalize afterwards. Executed inside the flow, the change is tied to its evidence, its owners, and its sequence, rather than being an isolated master edit.
Close with a traceability that actually serves audit
This last step isn't cosmetic.
When the process closes, it's clear who requested, who validated, who approved, when, with what documentation, and on what criteria.
AWH concentrates that history and makes it consultable next to the ERP context, which meaningfully cuts the preparation time for an internal audit, an external review, or — if it comes to it — an incident investigation.
For truly operational control, it also helps to connect this design with Business Central's standard workflows. AWH includes events and responses for scenarios involving changes on supplier bank records, so control lives where the operation happens rather than in a separate circuit.
What you'll notice when the process is actually under control
The most immediate effect is boring, and in this territory that's good news: bank account changes stop generating surprises. When the flow forces validation, separates responsibilities, and leaves structured evidence, the risk of a payment being diverted through impersonation drops significantly and, most importantly, stops depending on the judgment of whoever gets the email.
The relationship with audit changes too. Showing who did what stops being a last-minute race to recover emails and attachments, and becomes a direct query inside the ERP. Every organization has its own metrics, but four indicators are worth tracking to measure the improvement:
- average time from request to final approval
- percentage of changes with effective dual validation
- overdue tasks in validation or approval stage
- payment incidents linked to recent bank account changes
If those four numbers improve, the control is working.