The Vendor Who Changed Bank Details on a Friday
On a Thursday afternoon, your AP shared inbox receives an email that appears to come from a long-standing supplier (3 years, ~$2.1M annual spend) requesting updated remittance details. The email uses the supplier's domain but the display name is slightly off, and the signature block lacks the usual phone extension. The new account is at a different bank in a different country. Attached is a letter on supplier letterhead with a signature you cannot verify. The supplier's regular AP contact is copied. Your payment run is scheduled for Monday, and the supplier has an open invoice of $310,000 due that week. A junior AP clerk has already updated the vendor master pending your approval.
1. Walk through your verification steps before approving the change. What specifically do you check, and in what order?
Read the worked answer
Treat every bank-change request as fraud until independently verified. Order matters:
- Do not use contact details from the request. The reply-to, phone number, and copied contact in the email are all potentially attacker-controlled. Even the 'regular AP contact' being copied proves nothing - that address could be spoofed.
- Call the supplier using a number from your own records (contract, prior verified contact, or a known-good source), not from the email. Speak to a person you can identify.
- Verify the letterhead signature out-of-band - ask the supplier to confirm the signatory's name and title through the independent channel.
- Inspect email headers for domain spoofing (lookalike domains, reply-to mismatches, SPF/DKIM failures).
- Hold the vendor master change and freeze payments to the old account until verification completes.
Key principle: Never approve a bank change based on information contained in the change request itself.
2. The junior clerk already updated the vendor master. What is your immediate containment action, and what do you do about the $310,000 invoice?
Read the worked answer
Contain first, then pay.
- Revert or lock the vendor master change immediately (or set it to 'pending verification' status) so no payment run picks up the new details.
- Confirm the payment run is blocked for this vendor - check that the scheduled run will not process the $310,000 to the new account.
- Contact the supplier via your verified channel to confirm whether they actually requested the change. If they did not, you have a confirmed fraud attempt: preserve the email, headers, and letter as evidence, notify your bank and information security, and consider law enforcement.
- For the $310,000 invoice: if the supplier is legitimate and the change is fraudulent, pay to the existing verified account on the normal schedule. Do not delay a valid payment because of an unverified request.
Do not pay to the new account 'just this once' to meet the due date - that is exactly the loss scenario the control exists to prevent.
3. What is the residual risk after this incident, and what process change would you make?
Read the worked answer
Residual risks:
- The attacker now knows your vendor master update workflow and may try again with better spoofing.
- Other vendors may have been targeted with similar requests that succeeded silently.
- The junior clerk's ability to update the vendor master without independent verification is a standing control gap.
Process changes:
- Segregate duties: the person who receives the request cannot also update the master; require a second, independent verifier.
- Callback verification policy: all bank changes require a documented callback to a number from the vendor file, with the verifier's name and timestamp logged.
- Vendor master change report: review all changes weekly for anomalies (new bank, new country, round-number timing).
- Email authentication: enforce DMARC and flag external emails that spoof internal or supplier domains.
Exam point: The control failure is not the phishing email - it is the single-point update with no independent verification.