Finance Index
We caught (or fell for) vendor fraud - what's the response playbook?
Reference guide to vendor fraud response playbook, including vendor records, onboarding requirements, compliance checks, fraud controls, and payment readiness.
If you caught it before paying: don't just delete the email - preserve it, document the attempt, report it internally and to the impersonated vendor, and check whether other requests slipped through. If you already paid a fraudster: speed is everything. Contact your bank immediately to attempt a recall, file with the FBI's IC3, preserve all evidence, and notify the real vendor - the first 24 hours largely determine recovery.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| We caught (or fell for) | If you caught it before paying: don't just delete the email - preserve it, document the attempt, report it internally and to the impersonated vendor, and check whether other requests slipped through. | Keeps vendor records and payment decisions reliable. |
| Risk check | Move in parallel, not in sequence. | Helps finance decide what to do next. |
| Request an ACH | Initiate through your bank, not the receiving bank, and do it immediately. | Reduces payment errors, timing issues, and reconciliation cleanup. |
| Who bears the loss | Generally yes: paying a fraudster doesn't discharge your obligation to the genuine vendor, so you can owe the debt twice - once to the thief, once to the vendor. | Reduces payment errors, timing issues, and reconciliation cleanup. |
| Vendor impact | Sometimes - and the details decide everything. | Keeps vendor records and payment decisions reliable. |
What's the first-24-hours playbook after sending money to a fraudster?
Move in parallel, not in sequence. Immediately: (1) call your bank's fraud line and request an ACH reversal or wire recall - ask them to invoke the Financial Fraud Kill Chain for wires; (2) file a complaint at the FBI's IC3 (ic3.gov) - IC3 can help freeze funds, and fast reporting materially improves recovery odds; (3) preserve everything - the fraudulent emails with full headers, payment records, and a timeline; (4) notify the real vendor that their identity was used and that they should check for a mailbox compromise; (5) alert internal stakeholders (finance leadership, legal, security). Recovery odds fall sharply with every passing hour, so don't wait to "investigate" before calling the bank.
How do I request an ACH or wire recall, and what are realistic recovery odds?
Initiate through your bank, not the receiving bank, and do it immediately. Wires: harder to reverse once settled, but a recall request inside the first day - especially via the kill-chain process - has a real chance if the funds haven't been withdrawn. ACH: a reversal is possible within tight windows, with somewhat better mechanics than wires but no guarantee. Across both, recovery depends almost entirely on elapsed time and whether the mule account still holds the funds. Treat every recall as time-critical; assume the money leaves the destination account fast.
Who bears the loss when we pay a fraudster - do we still owe the real vendor?
Generally yes: paying a fraudster doesn't discharge your obligation to the genuine vendor, so you can owe the debt twice - once to the thief, once to the vendor. Loss allocation between you and your bank turns on the payment type, your authorization, and your controls; banks often resist liability for payments you authorized, even if deceived. This is why prevention economics dwarf recovery economics.
Does insurance cover vendor impersonation losses?
Sometimes - and the details decide everything. A crime/fidelity policy may cover it under a social-engineering fraud rider, which is often a sub-limited add-on rather than standard coverage; cyber policies may cover related costs but frequently exclude the funds-transfer loss itself. Common denial reasons: no social-engineering endorsement, failure to follow your own stated verification controls, or "voluntary parting" exclusions. Read the riders before you need them.
How do I work with the real vendor after their identity was used?
Notify them promptly and without blame - they're a victim too. Tell them the specifics (the spoofed/compromised address, the fake banking) so they can investigate a possible mailbox compromise on their side, warn their other customers, and reset credentials. Re-verify their real banking through your call-back protocol before resuming payments, and document the re-verification.
What should the post-incident review change, and how do I document remediation?
Run a blameless review tracing how the fraudulent instruction got as far as it did, then close the specific gaps - usually a missing or skipped call-back, weak banking-change approval, or a dormant vendor that was trusted. Document the timeline, root cause, controls added, and training delivered; that remediation memo is what the board, auditors, and insurer will want, and it converts a loss into a defensible "here's what we fixed."
The fraud used a dormant vendor that was quietly reactivated - what does that tell US to fix?
That reactivation is an unguarded door. Treat reactivating a vendor as a controlled event - re-verify W-9, banking, and sanctions as if onboarding fresh - and require approval to reactivate. Dormant-but-active records are prime fraud cover; aggressive deactivation plus a controlled reactivation gate removes the hiding place.
Do we have to disclose a vendor fraud loss - and when does legal, the board, or the bank get involved?
Involve your bank and law enforcement (IC3) immediately for recovery; loop in legal and finance leadership early. Disclosure obligations depend on materiality, your insurance notice requirements (delay can void coverage), and whether personal data was exposed (which can trigger breach-notification duties). Public-company materiality and board reporting thresholds are judgment calls best made with counsel - but err toward early internal escalation.
Stampli perspective
Stampli's contribution to fraud response is prevention and traceability rather than recovery. Because vendor-detail changes, approvals, payment blocks, and the history of who changed what are preserved in an audit-ready record, a post-incident investigation can reconstruct exactly what happened and when. And because banking changes can be gated behind review and payments held while changes are pending, Stampli is designed to stop the most common payment-redirection attack before money moves - turning many would-be "we already paid" incidents into "we caught it" ones.