Often, yes. If your policy includes social-engineering or funds-transfer-fraud coverage, that coverage almost always comes with a condition attached: before you act on a request to change a vendor’s payment details, you have to verify it out of band — typically a phone call to a number you already had on file — and you have to be able to show you did. Skip the call, or skip the record of the call, and the insurer can deny the claim even though you “had coverage.”
This catches small bookkeeping and accounting firms off guard constantly, because the policy language is easy to misread. You bought the endorsement, so you assume you’re covered. But the endorsement is conditional, and the condition is a procedure most firms perform inconsistently and document almost never.
Why the gap exists: base policy vs. social-engineering endorsement
A standard cyber policy is built around system compromise — malware, ransomware, network intrusion, a breach of your data. When an attacker tricks an authorized person into voluntarily sending money or changing a payment record, that’s not a system intrusion. It’s social engineering, and base cyber policies frequently exclude it.
Coverage for that scenario usually lives in a separate add-on — a social engineering or fraudulent funds transfer endorsement. Many firms have it. The problem isn’t whether the coverage exists; it’s the strings attached to it.
What insurers typically require before they’ll pay
Across carriers, the conditions on social-engineering coverage tend to rinse and repeat. The common ones:
- Out-of-band verification of payment changes. A request to change a vendor’s bank account, routing number, or remittance details should trigger a verification step that does not rely on the channel the request came in on. In plain terms: call the vendor back on a number you already had — not a number or link from the change request.
- A known, independent contact. The number you call has to come from your own records (a prior invoice, signed contract, your vendor file), not from the email asking for the change. Attackers helpfully include their own “updated” number; calling it just connects you to the fraudster.
- Dual authorization above a threshold. Many policies require a second approver for payments or payment-detail changes over a set dollar amount.
- A documented procedure, applied consistently. Insurers increasingly expect a written payment-change verification process — and evidence you actually follow it, not just that it exists on paper.
- “Reasonable efforts” to verify. Even where the wording is looser, policies expect reasonable steps to confirm payment instructions. After the fact, “reasonable” is judged by what you can show you did.
The throughline: the callback isn’t a nice-to-have. For coverage purposes it’s frequently a precondition, and the burden of proving it falls on you, the insured.
How these claims actually get denied
The denials are rarely exotic. The most common pattern is heartbreakingly simple: the firm “verified” the change using the contact details in the fraudulent message itself.
A typical denied claim looks like this. A vendor emails new banking details. The bookkeeper, doing their due diligence, replies to the email to confirm — and gets a reply (from the attacker, who controls the thread) reassuring them the vendor opened a new account. The payment goes out. The money is gone. The insurer denies the claim because the verification wasn’t independent and wasn’t out of band — the exact condition the policy required.
The second common pattern is even more frustrating: the firm did call and verify correctly, but kept no record of it. When the claim is reviewed months later, there’s no log of who was called, on what number, when, or what was confirmed. With nothing to produce, the firm can’t demonstrate it met the condition — so the outcome is the same as if it had never called. You can do everything right and still lose the claim if the verification lives only in someone’s memory.
What to document so the callback is provable
If the callback is the requirement, the record of the callback is what protects you. At minimum, capture:
- The date and time you performed the verification.
- Who you spoke with at the vendor (name and role).
- The number you called — and, crucially, where that number came from (e.g., “from the signed engagement letter dated March 2025,” not “from the email”).
- What you confirmed — the specific account or routing change, in their words.
- Who approved the change on your side (and the second approver, if your policy requires dual authorization).
- A tamper-evident trail — a record that can’t be quietly back-dated or edited, so its credibility holds up when a claims adjuster reviews it.
That last point matters more than it looks. A note typed into a spreadsheet after the fact is better than nothing, but a log where entries are time-stamped and can’t be silently altered is far more persuasive when someone is deciding whether to pay a five- or six-figure claim.
Making it routine instead of heroic
The reason firms skip the callback isn’t laziness — it’s that, in the moment, the request looks legitimate and the payment feels urgent. The fix is to make the procedure the default path, not a judgment call: every payment-detail change is treated as unverified until someone calls the vendor back on an independently sourced number, confirms the change verbally, gets a second sign-off if required, and logs all of it. No log, no payment.
If you want a ready-made version of exactly that, our free vendor bank-change verification template lays out the independent-contact rule, a word-for-word callback script, a dual-approval step, and a one-page log sheet — no signup, nothing to buy. For the step-by-step mechanics, see how to verify a vendor bank account change, and if you’re staring at a suspicious message right now, a vendor emailed new bank details — is it fraud? walks through triaging it.
CallbackProof itself is a documentation and workflow tool: it enforces that callback-and-approval sequence and keeps a tamper-evident log across all of your clients, so when an insurer or auditor asks for your callback procedure, you hand them the record instead of trying to reconstruct it. It doesn’t prevent fraud or guarantee a claim is paid — it makes the verification you performed provable.
The bottom line
Having social-engineering coverage and being able to collect on it are two different things. The coverage is usually conditional on an out-of-band callback to a known number, performed before the change and documented after. The single most common reasons firms lose these claims are verifying through the fraudster’s own contact details, or verifying correctly but keeping no proof. Both are avoidable with a procedure you run every time and a record you can produce on demand.
Read your policy, confirm the exact verification and documentation conditions with your broker, and then make sure your firm can actually meet them on the worst day — the day the money already moved.
Frequently asked questions
Does every cyber policy require a callback?
No. Requirements vary by carrier and endorsement, and some policies use looser “reasonable efforts” language. But a documented out-of-band callback is one of the most common conditions on social-engineering and funds-transfer-fraud coverage, so assume it applies until your policy says otherwise.
Is a callback enough on its own, or do I need to document it?
Both. Performing the callback satisfies the procedure; documenting it is how you prove you satisfied it when a claim is reviewed later. A verified change with no record is hard to defend.
What counts as a “known number”?
A phone number you already had from an independent source — a prior signed contract, an earlier invoice, your vendor master file — not a number, link, or reply address supplied in the change request itself.
Who should I confirm my requirements with?
Your insurance broker or agent. Ask them, in writing, what your policy requires for payment-change verification and documentation, and what would cause a social-engineering claim to be denied.