A genuine supplier bank change and a fraudulent one look identical - what single step separates them?
answer
- both cases are authorised and correct
- look outside the message, not harder at it
- a route the requester did not supply
- the number in the signature is theirs
- change it and release it are two people
basics
~20 sContact through a route the requester did not supply. Both changes are the same fields edited by the same authorised clerk, so only a callback to a number captured at onboarding or written into the contract separates them.
solid answer
~50 sPut the two cases side by side and they are indistinguishable: an accounts-payable clerk with standing rights edits the bank fields on a supplier, using exactly the same keystrokes, on the strength of an emailed request. The finance system cannot tell them apart because it is behaving exactly as designed in both cases, and the clerk cannot tell them apart because every property of the request - domain, letterhead, invoice reference, signature block, tone, even a phone that answers - is something the operator can supply or borrow. The one thing they cannot supply is a contact route you already held: a number from the signed contract or captured at supplier onboarding, dialled to a named person. Verification through that route is the separator, and it must be paired with segregation of duties so that whoever makes the change is not whoever releases the payment against it.
go deeper
Know that you verify a banking change by phoning a number you already had, from the contract or supplier records, and never the number printed in the request.
Explain why nothing inside the finance system separates the two cases: the same authorised person makes the same edit, and the difference lives entirely outside your systems.
Articulate the design test - the control must depend on something the operator cannot substitute - and pair the callback with segregation of duties and a change notice to the previously held contact.
Own the position that a process requiring a clerk to intuit honesty has misallocated the decision, and be ready to defend redesigning it rather than retraining the individual.
## Why nothing internal distinguishes the two The uncomfortable premise of this question is worth stating plainly: **in the fraudulent case, every actor behaves correctly.** The clerk has the right to maintain the vendor master and uses it. The approver approves a payable that is genuinely owed, in the right amount, to the supplier named on it. The banking portal executes an instruction from an authorised user. There is no compromise, no unauthorised access and no anomaly of privilege anywhere in the chain. That is why looking harder at the change itself is a dead end. Compare the two: | | Genuine change | Fraudulent change | |---|---|---| | Who edits | AP clerk with standing rights | AP clerk with standing rights | | Fields touched | Sort code, account number | Sort code, account number | | Trigger | An emailed request from the supplier | An emailed request appearing to be from the supplier | | Supporting paperwork | Letterhead, invoice reference | Letterhead, invoice reference | | Payment released by | The normal approver | The normal approver | The only difference lives entirely outside your systems: whether a person at the supplier actually asked. ## The property the separator must have A control works here only if it depends on something the operator **cannot substitute**. Run through what they can: - The sending domain - they can register a lookalike, or use the supplier's own compromised mailbox. - The letterhead, the logo and the invoice reference - copied, or genuine. - The signature block and its phone number - theirs to write. - A phone that answers with the supplier's name - a phone number is cheap and a confederate is cheaper. - The wording, the urgency and the plausible reason for banking to have moved. What they cannot supply is a contact route **you already held before the request arrived**: a number written into the signed contract, or captured and verified when the supplier was onboarded, reaching a named individual you have dealt with. Dialling that, and asking the person whether they requested the change, is the separator. It costs a few minutes and it does not care which variant of the attack you are facing. Two details make or break it in practice. First, the number must never be taken from the request or its attachments - operators routinely include a helpful "if you need to verify, call us on..." line, and a callback to that number is theatre. Second, the call goes outbound to the contact you hold; accepting an inbound call from someone claiming to be the supplier reverses the assurance and gives it away. ## What pairs with it - **Segregation of duties.** Whoever edits the supplier's banking details should not be whoever releases the payment. If one person can do both, one deceived person is sufficient. - **Change notice to the previously held contact.** Tell the old, known contact route that details were changed. A genuine change is confirmed; a fraudulent one surfaces early, while the money may still be recallable. - **Onboarding expectation.** Tell suppliers at contract signature that you will never action a banking change on an email alone, so the verified path is the one they expect and a genuine change is not slowed by surprise. - **A hold on first payment to changed details**, where the cycle can absorb it, so the notice above has time to land. ## The wrong answers to avoid "Our staff would notice the wording was off" is the commonest, and it is the answer that has cost the most money. Operators write in the register of the correspondence they are reading; some of them have the supplier's real mailbox and can quote history. "We would see it in the approvals" is the second, and it fails because the approvals are genuine. And blaming the clerk is not only unkind but analytically wrong: a process that requires a clerk to intuit which of two identical requests is honest has misallocated the decision. The fix belongs in the process, not in the individual's judgement. The same logic transfers to payroll self-service: an employee's direct-deposit change is the same trick at smaller unit value, and it is answered the same way, by confirming through the contact route already on file rather than the one in the request.
- The request helpfully includes a verification phone number. Why is calling it worthless?Because the operator supplied it, so it verifies nothing outside their control. A number in the request, its attachments or the signature block is part of the fraud's payload of plausibility. The only useful number is one you held before the request existed, from the contract or onboarding.
- Would requiring the supplier to submit changes through a portal solve it?Only if enrolment into that portal is itself verified out of band, otherwise the operator simply enrols. A portal moves the trust decision to account creation and password reset, which is where you must then place the callback.
- How does this apply to an employee changing their own payroll bank details?Identically in structure: the change is authorised, self-service and indistinguishable from a genuine one. Confirm through the contact route already held in the personnel record rather than anything in the request, and notify the previously known route so a fraudulent change surfaces before payday.
You cannot tell a genuine key from a copied one by examining the key. You tell them apart by asking the person who is supposed to hold it whether they lent it out - on a number you looked up yourself.
saying these in an interview costs you the question
- Claims staff would notice the wording or format was off
- Calls back the number in the request or its signature block
- Relies on approval workflow, which the genuine payment also passes
- Blames the clerk rather than the process design
- Lets one person both change bank details and release payment