Identify which trust has failed
An attacker may use a lookalike domain with correctly configured authentication. Alternatively, a real supplier mailbox may be compromised. In the second case the message can arrive in an existing conversation and contain details copied from earlier correspondence. Neither situation is resolved by a green authentication result alone.
Keep domain impersonation controls in place. They address an important part of the exposure. Add a separate control at the point where a person changes supplier payment details or releases funds. That decision depends on authority and independent verification, not just the message's route.
Define the trigger before the urgent request arrives
Use a consistent trigger such as new beneficiary details, a changed account, an unusual payment route or a request that bypasses the normal approver. Decide who pauses the transaction, who confirms the change and who can release it. An employee should not have to challenge a senior person's urgency without a documented process supporting that decision.
Do not rely on spelling mistakes. A convincing request may use the supplier's normal style and genuine invoice references. The operational question is whether the change was confirmed through a channel whose trust does not depend on the message under review.
Verify through an established independent channel
Use a previously verified supplier contact from your controlled records, or establish the correct contact independently. Do not take the callback number from the suspicious invoice or email. State the invoice reference and proposed change, and confirm that the person answering is authorised to approve it. The FBI similarly recommends independent verification of changes in payment details.
A callback is not a ritual that automatically makes a payment safe. If the supplier's contact records may also have been altered, or the response remains ambiguous, escalate and keep the payment paused. Voice familiarity alone should not override the process. Record how the contact was established and what exactly was confirmed.
A fictional decision example
An accounts-payable employee receives a revised invoice within a familiar email thread. Authentication passes. The beneficiary account differs from the approved supplier record and the message asks for immediate payment. Under the agreed process, the employee places the change on hold and contacts the supplier using the existing verified number.
If the supplier denies the change, preserve the message and relevant records, involve the incident lead and review related requests. If the supplier confirms it, the designated approver still reviews and records the change before release. This is an illustrative workflow, not a real client incident or a claim that every callback detects fraud.
| Decision | Evidence to keep |
|---|---|
| Why was the request paused? | Changed field and comparison with the approved record |
| How was the supplier contacted? | Source of the verified contact and time |
| What was confirmed? | Specific invoice, beneficiary change and authorised person |
| Who released or rejected it? | Named approver, decision and transaction reference |
If money has already been sent
Contact the bank immediately through a trusted channel and explain the suspected fraud. Follow its instructions on recall or other available action; recovery is not guaranteed. Preserve the original message, transaction details and the decision record. Activate the organisation's incident and reporting process, including the applicable local reporting routes.
Avoid coordinating solely through the possibly compromised supplier thread. The investigation should consider related invoices and altered supplier records as well as the single message. Our incident decision guide helps separate urgent containment, investigation and notification responsibilities.
Make the process usable under pressure
Keep the verification step short enough to follow during normal work. Provide an alternate approver for absence and a route for genuine deadline pressure. A control with no available decision-maker encourages workarounds. Test the process with a clearly authorised fictional exercise rather than an unannounced real payment request.
Download the payment-change verification card. It records the trigger, independent contact, result, approver and escalation. Store completed cards with the controlled payment records, using only the personal information needed for that purpose.
Dyasol can help align the human decision process with the technical mail controls and the company's approval structure. Success is a repeatable, recorded decision about a payment change. A mail authentication report supplies supporting information; it cannot make that decision for the business.