As finance controller, what should trigger mandatory callback verification on supplier bank changes?

## The decision in front of the controller Everyone agrees that banking changes should be verified. The real questions are *when* the requirement bites, *who* can set it aside, and *who pays* for it in time and friction. Those are organisational calls, and they are what separates a policy that survives month-end from one that is quietly abandoned in week three. ## Trigger on the event, not the value The intuitive design is a threshold: verify changes on suppliers we pay more than some amount. It is intuitive because it looks like risk-based control, and it is wrong here for a specific reason. A value threshold is a **parameter the operator can read**. They do not need to see your policy; they can infer it from which requests get a phone call and which do not, and they only need to learn it once. The ask then arrives beneath it. Worse, sizing down costs the operator very little, because the technique is cheap to repeat and the invoice they ride is whichever one fits. Triggering on the *event* removes that. A change of destination is a discrete, countable event - most organisations have far fewer of them per month than they expect - and it cannot be sized around, because there is no smaller version of changing an account number. Value bands keep their proper job: deciding how many people must approve the disbursement. That is a control on magnitude. Verification is a control on destination. Conflating the two is what produces the threshold design in the first place. ## The four things the policy must answer **1. Who may waive it.** Some request will arrive with genuine urgency and a senior name attached, and someone will ask for an exception. The workable answer is that the requirement is not waivable below the controller, and that an urgency claim from a senior name raises the bar rather than lowering it - because that pressure is itself a standard technique. Publish that in advance, so declining is policy rather than a junior person's judgement call in the moment. **2. What happens when verification is impossible.** A supplier changes contact, the named person has left, the number in the contract is dead. The answer must be pre-decided, or the default becomes "pay it anyway": until a verifiable route is established, the previously held account continues to be paid and the relationship owner - someone who has actually met the counterparty - resolves it. Non-payment is a commercial problem; misdirected payment is a loss. **3. Who does the work.** If verification is unfunded it will be skipped under load. Count the actual changes per month, put a named role on it, and give that role the authority to hold a payment. This is where a controller's answer differs from an engineer's: the constraint is headcount and month-end pressure, not design elegance. **4. What suppliers are told.** Say at onboarding that banking changes are never actioned on correspondence alone, and capture a verification contact at that moment, while nobody is under pressure. This converts the control from friction the supplier resents into a process they expect, and it means a genuine change is not slowed. ## Extend the same policy to payroll Employee direct-deposit self-service is the same trick at smaller unit value and larger volume, and it typically sits with a different owner in HR, which is exactly how it gets missed. The same three moves apply: confirm through the contact route already in the personnel record rather than anything supplied with the request; notify the previously known route that a change occurred; and where the cycle allows, let a change season for one payday. Discovery in payroll is reliably external - the employee whose salary did not arrive tells you - so the notice to the old route is doing most of the work. ## Judging whether the control is working The seductive measure is "we had no losses". That is not evidence: you may simply not have been targeted this quarter, and the direction of the claim runs the wrong way. Judge instead on process facts you control - what proportion of banking changes went through the verified route, how many were held for want of a contact, how long verification took - and treat a genuine attempt that was declined as the control demonstrating itself rather than a near miss to be embarrassed about. ## Where the argument usually lands The cost of this policy is small and concrete: a handful of phone calls a month and occasional commercial awkwardness. The cost of not having it is rare, large and effectively irreversible, since money drawn down and moved onward is generally gone. That asymmetry is the whole case, and it is the case a controller has to make to a business that experiences the control as friction every month and the loss never - until once.