Banking under change control
A change to bank details requires a second approver, a callback to a number already on file rather than one supplied in the request, and a hold on payment until both are recorded.
Platform · operations
The vendor master is where payment fraud happens. Not through a breached system — through a plausible email asking to update banking details on an existing vendor, actioned by somebody helpful who had permission to do it. Almost every business email compromise loss ends at a row in this table.
What it does
A change to bank details requires a second approver, a callback to a number already on file rather than one supplied in the request, and a hold on payment until both are recorded.
Total spend with a vendor across every subsidiary, which is how volume leverage becomes visible and how the same supplier onboarded three times becomes obvious.
W-9, W-8BEN, insurance certificates, licences, and signed agreements with expiry dates that raise a warning before they lapse rather than at payment time.
Matching across name, tax ID, bank account, and address — with the bank account match being the one that most often reveals something worth investigating.
A vendor can be approved for purchasing, restricted to specific entities, held pending documents, or blocked outright, and the state is enforced at bill entry rather than advisory.
Every field change with actor, timestamp, before and after values, and the approval that permitted it. The banking history is the one auditors read first.
A vendor record is a name, an address, a tax identifier, and a bank account. The first three are administrative. The fourth is an instruction to move money, and the control around changing it is usually far weaker than the control around approving the payments that follow it.
That asymmetry is the whole attack. Nobody needs to forge an invoice if they can change where a legitimate invoice pays to. The approval chain runs perfectly and the money leaves anyway.
Dual approval alone does not stop this, because both approvers are looking at the same fraudulent request. What stops it is verification against a channel the requester does not control: a phone number already on the vendor record, not one supplied in the email asking for the change.
So the callback is required, the number used is recorded, and payment to the new details is held until it has been done. It is a small amount of friction on a rare event, and it is the single highest-value control in accounts payable.
No agent may create a vendor, change banking details, or move a vendor out of a blocked state. The policy engine refuses those grants rather than making them configurable, which is the one place we take the decision away from the customer.
An agent can propose a new vendor from an onboarding packet and flag a duplicate. A person approves. That boundary does not move regardless of how the rest of the system is configured.
The same vendor onboarded three times means three negotiations, three sets of terms, and spend that looks smaller than it is when procurement goes to negotiate. It also means a duplicate payment eventually, because two records with two bank accounts will receive the same invoice twice and both will look correct.
Limits
Sourcing events, RFPs, and supplier scorecards belong in a dedicated tool. We hold the master record, the spend, and the controls around them.
The system enforces that one happened and records it. It cannot make the call, and a control recorded but not performed is worse than none.
Sanctions and watchlist screening runs through a specialist provider. We hold the result and the date, not the list.
Questions
Tell us how banking changes get approved today and we will tell you where the exposure is.