Operated function · supplier onboarding
Tax forms, insurance certificates, addresses, contacts — administration, and the cost of getting them wrong is delay. Bank details are in the same queue, look the same, arrive the same way, and the cost of getting them wrong is the payment.
A new supplier needs a set of things collected before they can be paid: tax registration, insurance with the right cover and the right expiry, banking, contacts, sometimes certifications or a signed code of conduct. Each has an owner in a different part of the business and none of them owns the whole.
The collection is email. Somebody sends a list, the supplier returns some of it, a second request follows for the rest, and the exchange runs for weeks while somebody in operations is waiting to raise a purchase order and starts asking why.
Documents expire quietly. Insurance certificates in particular have an end date that was checked once at onboarding and never again, so a supplier can be working on your site uninsured and everything in your records says they are covered.
The bank field arrives in that same stream, and it is the reason this queue matters more than it looks. A change request that comes by email from a plausible address, referencing a real invoice, at a moment when a payment is genuinely due, is indistinguishable from the twenty other administrative messages that week.
And the same suppliers are onboarded repeatedly by different parts of the business, because nobody checked whether the record already existed under a slightly different name — which duplicates the effort and, more importantly, duplicates the payment surface.
Bank detail changes travel through the same channel, in the same format and at the same volume as routine supplier administration, so the control appropriate to them is applied inconsistently under the time pressure created by everything else.
Separating the two is the whole intervention. Everything except banking is a completeness and expiry problem: collect it, check it against a requirement set, watch its end date. Banking is a verification problem and it needs an out-of-band control that does not depend on the channel the request arrived on.
Out of band means exactly that: a call to a number held in your records from before the request, not a number in the email. That control is well known, it is cheap, and it fails in practice for one reason — under deadline, with a payment run closing, somebody decides this one is obviously genuine. Making it a rule that cannot be skipped rather than a step somebody performs is the difference.
The rest is genuinely delegable and genuinely tedious: chasing a certificate, checking that a document covers what it needs to cover, watching expiries forward, and matching a new supplier against existing records before a second one is created.
Duplicate prevention is worth more than it appears. Two records for one supplier is two payment routes, and consolidating them removes a surface as well as some administration.
What is never delegated is approval. Approving a supplier and approving a bank change are financial control acts, and they belong to your people under your delegation of authority — with the verification evidence in front of them.
Bank changes verified out of band — measured by changes with a recorded out-of-band verification against a pre-existing contact, as a share of all changes — usually well under complete before it is measured.
Elapsed time from request to a payable supplier — measured by days against your own baseline, split into our processing and waiting on the supplier.
Requests sent per supplier — measured by separate information requests before the file is complete.
Suppliers working with lapsed cover — measured by expired insurance or certification found in the active supplier base, before and after forward watching.
Duplicate supplier records — measured by the count of duplicates prevented at creation and consolidated in the existing base.
Verification steps actually performed — measured by changes carrying a full recorded control history, against a baseline where performance was assumed.
any supplier approval, any bank-change approval, and any determination that a document or a request is genuine. Nothing here approves a payment route. Verification steps are performed and recorded; whether the evidence is sufficient is a decision your finance function makes, and a vendor approving payment routes would be an obvious control failure.
The supplier master stays your system of record and no second supplier record is created anywhere — the entire point of duplicate matching is undermined by a parallel store.
Banking never enters the routine document stream. It is held under its own control path, and the out-of-band verification uses contact details drawn from records that existed before the request, which is the property that defeats the attack.
The requirement set is yours: what each supplier type must provide, what each document must show, and what expiry means for each. Written, versioned, owned — and it is what makes the collection request a single complete one rather than three.
The out-of-band verification is designed to be unskippable, because every recorded instance of this fraud succeeding involves somebody sensible deciding that this particular request was obviously genuine while a payment run was closing.
The number called is drawn from records predating the request. Not from the email, not from a letterhead, not from a website found by searching — because all three are controllable by whoever sent the request.
Every change carries a complete control history: what was checked, against what source, by whom, when, and what the result was. A change approved with no recorded verification is exactly the finding an auditor looks for, and this exists to make that impossible rather than merely unlikely.
Nothing determines authenticity. A document is checked for completeness and cover; whether it is genuine is a judgement, and a suspected forgery routes rather than being assessed.
Operational access is not permission to train. Supplier, banking and commercial terms data does not become material improving anything serving another organisation.
Internal audit will focus on the bank-change control and should. The question they will ask is whether it can be bypassed, and the answer needs to be about scope rather than about discipline — a control that depends on somebody not being under pressure is not a control.
Finance control owns the approval boundary and the delegation of authority. Nothing is approved here, and that needs to be stated in the scope rather than assumed from the absence of a mention.
Where an obligation attaches through your control framework, sanctions screening requirements or a jurisdiction, it is marked applicability-gated rather than presented as standing.
Every supplier bank change in a trailing period — read-only, nothing changed and nothing approved — checked for whether an out-of-band verification against pre-existing details was performed and recorded.
This is the phase that decides whether anything else matters, and it is uncomfortable by design. Most organisations find the control was performed on most changes and not on all of them, and that the exceptions cluster exactly where you would expect: close to payment runs, on long-standing suppliers, and when the requester was senior.
Where verification was performed but not recorded, the exposure is different but still real — an unrecorded control cannot be evidenced to an auditor or reconstructed after an incident.
If you continue, the first delegation is running the out-of-band verification and recording it, with approval untouched. That is the highest-value step and it makes no financial decision at all.
Most organisations say so and the audit usually finds it was performed on most changes rather than all, with the exceptions clustered near payment runs and on suppliers everybody trusts. The second question is whether the number called came from records predating the request, since a number supplied with the request verifies nothing. Both are answerable from your existing records in a read-only pass.
It adds a call. The comparison worth making is against the alternative cost, which is a payment made to an account controlled by somebody else and rarely recovered. Where genuine urgency exists, the correct response is a documented exception approved by a named person rather than a skipped control — an exception that is recorded is a control operating, and a skip is not.
The requirement set, the supplier relationship and every approval stay with them. What is delegated is the chasing, the completeness checking, the expiry watching and the duplicate matching — the parts that are high volume and low judgement, and the parts that currently make the queue slow enough that the bank control gets rushed. If procurement reads the scope as taking their decisions, it has been written wrong.
Long-standing suppliers are the preferred target precisely because a change on a familiar account attracts less scrutiny, and the audit usually shows the skipped verifications cluster there. That is not an argument that your organisation has been careless — it is that the control is hardest to apply exactly where it matters most, which is why making it unskippable is worth more than reminding people to apply it.