The request looks routine. A supplier writes to say they have changed banks, the new details are attached, and could the next payment go to the new account. The letterhead is right, the signature matches earlier correspondence, the email thread even quotes a real purchase order number. Someone in accounts payable updates the vendor master, and the next payment run sends the money to an account controlled by whoever sent the message.
This is one of the most consistently successful forms of commercial fraud, and it does not depend on sophistication. Attackers compromise or spoof a supplier mailbox, read enough of the thread to be credible, and wait for an invoice cycle. Industry incident reporting consistently places business email compromise and payment diversion among the highest-loss fraud categories affecting organizations of every size, precisely because the technical barrier is so low.
What makes the attack work is not the quality of the forgery. It is that the change travels through a process with no independent verification step. The organization takes the request as evidence of itself. The remedy is narrow and well understood, and it belongs on the field being changed.
Why the request gets through
Diversion incidents share a small number of process weaknesses. None of them are exotic, and all of them are visible in advance to anyone who maps how a remit-to change actually moves through the organization.
- Self-authenticating requests, the contact details used to verify the change come from the request itself, so an attacker supplies both the instruction and the means of confirming it.
- Single-person authority, one person can receive, assess and apply the change, which removes any independent check on judgement or on a compromised account.
- Urgency as a bypass, requests arrive framed as time-critical, often tied to a payment already due, and urgency is used to justify skipping the normal step.
- No link to contract evidence, the signed agreement names authorized signatories and often specifies how payment instructions change, but that record is never consulted.
- Weak audit trail, the change is applied without recording who verified it, against what, and when, so a later investigation cannot establish where the control failed.
Taken together these produce a control environment where the deciding factor is how convincing a message looks. That is not a control. Verification has to come from a source the requester cannot influence, applied by someone other than the person who received the request, and recorded in a way that survives staff turnover and supports a later review.
A callback to a number supplied in the change request, or to a number found by searching for the supplier, verifies nothing. The number must come from the contract, the onboarding record or earlier verified correspondence held before the request arrived. Attackers anticipate callbacks and supply numbers they control; several documented incidents turned on exactly that. If the organization cannot produce a pre-existing contact, that itself is the finding.
What the verification step should test
The control is small and specific. It tests the identity of the requester and the authority of the instruction, using sources the requester did not provide, before the field changes.
- Out-of-band contact. a voice call to a number already on file, placed to a named individual, with the verifier recording who they spoke to and when rather than noting that a call was made.
- Authorized signatory check. the request is confirmed against the signatory list or authority terms in the signed agreement, so a change requested by someone outside that list is escalated rather than processed.
- Separation of duties. the person who receives the request cannot be the person who applies it, and the approver sees the verification evidence rather than a summary assertion that checks were done.
- Payment hold window. a short hold on payments to the amended account, with a low-value confirmation or a supplier confirmation of receipt before the first full-value run.
- Immutable change log. the old and new details, the verifier, the evidence and the approver recorded on the vendor record, retained so the sequence can be reconstructed under audit.
A five-step roadmap to close the gap
Step 1, Establish the verified contact of record
The control depends on having a contact that predates any request. Capture a named finance contact and a direct number during onboarding, store it on the vendor and contract record, and mark it as the verification source. Review it on a defined cycle rather than updating it from inbound mail, since an attacker who can change the contact can defeat every later callback.
Step 2, Route all change requests into one channel
Requests arriving in individual inboxes are requests nobody else can see. Direct every remit-to change into a single intake queue with a standard form, so each one is visible, logged and worked in the same sequence, the same intake principle behind supplier contract automation. An intake channel also removes the unrecorded side conversation where urgency usually gets applied.
Step 3, Verify out of band, against the contract
Call the contact of record. Confirm the requester is on the authorized signatory list in the agreement, and check whether the contract specifies a method for changing payment instructions. Record who was spoken to, on what number, and what was confirmed. A verification note that says only "confirmed by phone" cannot be relied on later.
Step 4, Separate approval from application
A second person reviews the verification evidence and releases the change. The reviewer's job is to test the evidence, not to re-run the call. Where volumes make this heavy, apply it by risk: new accounts, cross-border changes and high-spend suppliers always get a second pair of eyes.
Step 5, Hold, confirm, then release
Apply a brief payment hold on the amended account. Confirm with the supplier through the verified contact that the first payment arrived, then lift the hold. The hold is what converts a missed verification into a recoverable event rather than a loss, because funds are most often still traceable in the first days.
Put the control where the vendor record lives
Aavenir routes bank detail change requests through a verified intake, checks them against contract signatory terms, and logs every approval step.
Where the contract record earns its keep
The signed agreement usually contains exactly what the verification step needs: the entity's legal name, the authorized signatories, the notice provisions, and in many commercial agreements an explicit statement of how payment details may be amended. When the contract record and the vendor master sit in separate systems with no link between them, none of that is available at the moment of decision. When they are connected, the verification step stops being a judgement call about an email and becomes a comparison against terms the counterparty already agreed to, much as order form and MSA precedence is settled by the documents rather than by assertion. That is both faster and far harder to argue with.
Control, failure mode and evidence
Each control below addresses a specific failure mode, and each produces an artefact an auditor or investigator can test.
| Control | Failure mode addressed | Applied by | Evidence retained |
|---|---|---|---|
| Callback to contact of record | Self-authenticating request | Verifier, not requester | Name, number, time, outcome |
| Signatory check against contract | Unauthorized requester | Verifier | Signatory list reference |
| Dual approval | Single-person authority | Independent approver | Approver identity, timestamp |
| Payment hold on new account | Verification error | Payments team | Hold period, release note |
| Immutable change log | Unreconstructable incident | System | Old and new values, actors |
Payment diversion is unusual among fraud types in that the control which stops it is cheap, well understood and narrow. It is a call to a number you already held, made by someone other than the person who received the request, checked against a signatory list in a contract you already signed, and written down. The reason losses continue is not that the control is hard. It is that remit-to changes arrive in individual inboxes, get handled by one person under time pressure, and never touch the contract record that holds the answer. Moving the change into a visible queue with verification and dual approval built in closes the gap without adding meaningful friction for legitimate suppliers.
For related guidance, see How to build a clause library your legal team trusts, What agentic AI contract management actually changes and Getting the data model right in legacy contract migration.
