Vendor payment fraud: documentation for an insurance claim

The first hour: the bank, then the evidence

1. Call your bank. The FBI's Internet Crime Complaint Center puts this first: "Immediately contact your financial institution and request a recall of the funds along with any necessary indemnification documents." It also asks victims to file a complaint at ic3.gov as soon as possible (IC3). Note the time you called, who you spoke with and the reference the bank gives you.

2. Tell your insurer or broker, in writing. Crime and cyber policies set conditions for giving notice and for proving a loss, often with deadlines. Find them in your policy's conditions section, and send the first notice by email so it carries a date.

3. Preserve the evidence before anyone tidies up. Save the original request as a file (.eml or .msg) rather than forwarding it: a forward is a new message and leaves the original routing headers behind. Before anyone corrects the vendor's bank details, export or screenshot the vendor record as it stands, and the change history your accounting or payment system keeps for it.

The record, item by item

Whoever reviews the loss rebuilds the same timeline: what arrived, how it was checked, who approved it, who changed the payment system, and when the money left. Each row answers one part of it.

Keep only the last four digits of any account number in these notes. The full number belongs in the bank's records, not in a spreadsheet that gets emailed around.

Why the verification step gets the most questions

A loss like this typically falls under social engineering fraud cover, which can sit in a crime policy or a cyber policy. WTW describes that cover as largely sub-limited, and notes that the wording can include verification language setting out how an instruction must be checked, a call-back for example (WTW).

Some wordings make the callback a condition of the cover itself. One published social engineering endorsement, Intact's form M350 "Call Back Provision", covers a transfer only if "an Employee verified the Transfer Instruction according to a pre-arranged callback or other established verification procedure before acting upon such Transfer Instruction." It continues: "Such verification must be recorded, logged or otherwise documented by the Organization." Its conditions then ask the insured to "furnish an electronic recording or other documentation evidencing verification" (Intact M350).

That is one insurer's form, not a description of yours. It shows why "we always call" is not enough: the question is whether this callback, on this request, was made and written down before the money moved. In an r/Accounting thread on vendor email compromise, a commenter described the other outcome: "Their insurance claim was subsequently denied because they didn't call to verify the wire instructions" (r/Accounting). The callback rule guide covers what a usable call record contains.

What an auditor adds

An insurer looks at one payment. An auditor also asks whether the control works in general, so expect two more requests:

• The population. A list of every vendor bank change in the period, with dates. The auditor picks a sample from it and traces each change from request to callback to approval to the system change. A sampled change with no callback record is a finding of its own, even when that change was genuine.
• The design. The written policy that applied on the day, and evidence that people followed that version. A procedure that exists only in someone's head cannot be tested, and a policy rewritten after the loss does not describe the day it happened. The one-page policy template is a starting point.

Keeping the record honest

• Write down what was skipped, too. If nobody called the vendor, the record says so. Do not write a callback log after the fact or backdate a note: a reconstructed record presented as the original undermines every other document you hand over.
• Prefer records made at the time. A note written when the call happened, with its own timestamp, carries more weight than a summary written after the loss.
• Fingerprint the files. A SHA-256 hash taken when a file arrives lets anyone check later that the copy you hand over is the copy you received. On macOS run shasum -a 256 file; on Windows, Get-FileHash file in PowerShell.
• Keep it in one place. One folder per incident, with a short index of what each file is and where it came from, saves rounds of back-and-forth with each reviewer.

Records, not advice.

Questions

If the record is complete, will the claim be paid?

Not necessarily. Cover depends on your policy's wording, limits and conditions, and only your insurer, broker or lawyer can answer that. A complete record makes the facts quick to check; it cannot change them.

We did not call the vendor before paying. Is the record still worth collecting?

Yes. The recall request, the IC3 complaint and the timeline do not depend on the callback, and an honest account of what did happen is what any claim or audit response starts from. Then close the gap with a written callback rule before the next request arrives.

The email just arrived and nothing has been paid. Where do we start?

With the first ten minutes after a "banking details have changed" email, then the six-step verification.

Next step

BankChangeProof keeps this record while the work happens, one change request at a time. Every request has an evidence PDF: a timeline with actors, timestamps and IPs, attachment hashes, the sender-domain verdict, the callback record, approvals, the hold, the release, the policy version in force, and an integrity page with the document's SHA-256 and a verify link (how it works, security). On Team and Firm, Reports → Export produces a CSV of vendors and change requests plus a zip of every evidence PDF for a date range: the population and the records an auditor samples from. It does not call anyone, check who owns the account, move money or connect to your accounting system, and it does not determine coverage: the PDF states what was recorded, by whom and when. It is free for 10 vendors.