In invoice payment diversion, how does the operator time the bank-change request, and why does timing decide it?
answer
- one ask, not a campaign
- attach to a debt already believed in
- after approval, before the run
- the supplier's chase is the other clock
- the amount is inherited, not chosen
basics
~20 sThe ask is placed against an invoice that is real, already approved and about to be paid, shortly before the payment run. Riding an existing obligation means the change survives reconciliation, and paying early beats the supplier's chase.
solid answer
~50 sPayment diversion is not a spray; it is one ask, aimed. The operator needs three facts: that a specific invoice exists and is genuinely due, roughly when the payment run happens, and who can release it. Then the bank-change request arrives in the short window after approval and before disbursement. Timing decides the outcome for two reasons. Forward, it beats reconciliation: a change against an invoice the finance team already expects to pay raises no questions, whereas an unsolicited request about a debt nobody recognises does. Backward, it beats discovery: the real supplier's chase for non-payment is the usual way this comes to light, so the operator wants the money drawn down long before the supplier's own terms expire. Sizing follows the same logic - the amount is whatever the invoice says, because a figure that matches the purchase order is the one nobody checks.
go deeper
Know that the fraudulent request is attached to a real, outstanding invoice and arrives close to when that invoice would be paid, not at random.
Explain both clocks: reconciliation in front of the payment and the supplier's own chase behind it, and say why the amount is inherited from the invoice rather than chosen.
Show how the operator reads your approval bands and payment cadence as parameters, and argue why a control keyed to value alone is therefore weaker than one keyed to the change of banking details.
Be ready to discuss how much time your payment cycle and your supplier chase cadence hand an operator, and whether shortening that gap is worth its cost against simply verifying every banking change.
## One ask, not a campaign Mass phishing is a volume business: send a million, convert a handful. Payment diversion is the opposite. Each interaction with an accounts-payable team is a chance for someone to pick up a phone, and a phone call ends the operation. So the operator spends the effort up front on reconnaissance and then spends one message. ## The three facts the operator needs 1. **That a real payable exists.** The request must attach to a debt the finance team already believes in. 2. **When money physically moves.** Many finance functions pay on a cycle - a run on a fixed day, or weekly batches - and the change must be in place before the run and after approval. 3. **Who releases it, and what the value bands are.** Above a threshold there is a second approver; a request that stays inside the band the target already treats as routine draws the least attention. None of this requires code. It comes from the supplier's own correspondence when their mailbox has been taken over, from published contract awards and tender results, from payment terms printed on the company's own purchase orders, and from perfectly ordinary conversation with a clerk who has no reason to be cagey about when the run is. ## Why the window is narrow at both ends **Too early, and reconciliation eats it.** If the change lands before the goods, the invoice or the purchase-order match, someone in accounts payable has to create a payable that nobody expected. That is a conversation, and a conversation is fatal. It is also why the request is a *change* to a supplier record rather than a new invoice: a new invoice needs a purchase order, an approver and a receipting record; a bank-detail change needs a clerk and a keystroke. **Too late, and the payment has already gone** to the correct account, and the supplier will simply reconcile it. Worse for the operator, they have now shown their hand in a mailbox that will be re-read. **The chase clock decides how much time they get afterwards.** The characteristic discovery route is the real supplier calling about an invoice they were never paid, and that call comes at their own credit-control cadence - often thirty days or more after the due date. That gap is the operator's working room: it is why the money is drawn down and moved onward immediately, and why a diversion discovered on the day it happens is a very different problem from one discovered six weeks later. ## Sizing and threshold behaviour The amount is not chosen; it is inherited. The invoice says what it says, and matching it exactly is the whole point - a figure that reconciles against a purchase order is a figure nobody queries. Where the operator does exercise choice is in *which* payable to ride, and there the value bands of your approval scheme matter: a payable that sits comfortably inside a band the target already handles routinely converts more often than one that trips a second approver into reading the file. This is worth stating carefully because it is the point candidates most often get backwards: the value threshold is a property of the target that the operator *reads and works around*, not a barrier the operator must break. ## Variants that use the same clock - **Remittance-advice fraud**, where the ask is dressed as an administrative update rather than a request, timed to the same window. - **Payroll direct-deposit changes**, which have their own clock: the ask lands a few days before payday, and the victim discovers it only when the salary does not arrive. - **Advance-of-schedule pressure**, where the operator asks for an early settlement discount to pull the payment forward into a window they control, rather than waiting for the run. ## What a strong answer covers Say that the ask rides an obligation that already exists, name the two clocks (reconciliation ahead of the payment, the supplier's chase behind it), and explain that the amount comes from the invoice rather than from the operator's appetite. A weak answer describes a scattergun of fake invoices for arbitrary sums - that is a different, far less successful fraud, and it is the version that reconciliation catches.
- How would an operator learn the payment run date without touching any of your systems?From the supplier's side of the correspondence if that mailbox is taken over, from payment terms printed on your own purchase orders, from published contract awards, and from asking a clerk a mundane administrative question. None of it is secret and none of it needs code.
- Why not just submit a wholly fabricated invoice instead?Because a new payable needs a purchase order, a receipting record and an approver who recognises the goods. A bank-detail change on an existing payable needs one clerk and a keystroke, and it inherits an amount that already reconciles.
- The diversion is spotted the same afternoon. What does that change?Almost everything about the money. Recall depends on the beneficiary bank still holding the balance, so a same-day discovery has a real chance while a six-week discovery usually has none. The attack itself was identical; only the position on the chase clock differed.
saying these in an interview costs you the question
- Describes a spray of fabricated invoices for arbitrary sums
- Thinks the operator picks the amount for greed
- Ignores that the invoice must already be owed
- Treats the approval threshold as a barrier rather than a parameter to read
- Assumes reconnaissance requires access to finance systems