Vendor bank-details change: stop the payment detour

Exercise: Vendor bank-details change: stop the payment detour
Scenario: Synthetic vendor email thread
Channel: Email
Sender: Accounts <billing@northwind-supplies.example>
Subject: RE: August invoice — updated remittance account
Message: We changed banks during an audit. Please replace the account on file before today's payment run.
Message: The attached letter has our new routing details. Do not call the old number; that team no longer handles billing.
Message: Reply when the vendor master is updated so our delivery is not placed on hold.
Attachment: Northwind-remittance-change.pdf (synthetic; not downloadable)
Question: What should finance do before changing the vendor record?
Decision 1: The payment batch closes in 25 minutes. What is your first action?
Option: Replace the bank record so the batch is not delayed
Option: Pause the change and call the known contact in the existing vendor record
Option: Call the new number in the email signature
Preferred option: Pause the change and call the known contact in the existing vendor record
Rationale: The FBI recommends a secondary channel for account-information changes; the contact data must come from a trusted record, not the request.
Decision 2: How should you interpret and handle that conflict?
Context: The known contact says the vendor did not change banks. The email appears in an existing thread.
Option: Trust the email because it is inside a real thread
Option: Stop the change, preserve the message, and report it through the normal security/fraud path
Option: Reply asking the sender for a second signed letter
Preferred option: Stop the change, preserve the message, and report it through the normal security/fraud path
Rationale: The trusted contact contradicts the request. Stop processing and preserve the original message for the established incident or fraud route.
Decision 3: Which control best reduces repeat risk without relying on one employee spotting a clue?
Option: Tell staff to reject messages with poor grammar
Option: Require known-channel verification plus a separate approver for bank-detail changes
Option: Allow every request from previously seen sender addresses
Preferred option: Require known-channel verification plus a separate approver for bank-detail changes
Rationale: Independent verification and segregation of duties turn a social-engineering decision into a controlled business process.
Answer: Verify the change outside the message before touching the vendor master.
A familiar thread, signed letter, or urgent delivery warning does not authenticate new bank instructions. Use a previously established contact and require the organization's normal second approval.
Signals:
- Strong evidence: New bank details supplied only in the request. The proposed destination has not been authenticated through an existing trusted channel.
- Strong evidence: Instruction not to use the established phone contact. The request attempts to control both the action and the verification path.
- Contextual signal: Urgent delivery consequence. Pressure matters as context, but real vendors can also have deadlines.
Safe actions:
- Hold the record and payment change.
- Use the contact already stored in the vendor master or a known main business number.
- Require the normal independent approver and report the conflicting request.
Reviewed: 2026-08-02