Most claims are not ransomware, they are misdirected payments

Event dated 19 May 2026 · Published 2 September 2026 · 3 sources

Claims data reported in May 2026 puts business email compromise and fund transfer fraud together at 58–60% of all cyber insurance claims by volume. Ransomware remains the larger figure by severity — fewer claims, bigger ones — which is why it dominates the conversation. But by count, most of what actually gets claimed is somebody being persuaded to send money to the wrong account. That is not a technical compromise: no system is breached, no malware runs, and the payment leaves through the process that exists to make payments.

Claims data is unusually trustworthy by the standards of this field. Almost every widely quoted security figure comes from a survey, a vendor's telemetry or a self-assessment, and this site has spent several pages on figures whose original question cannot be recovered.

A claim is different. Somebody lost money, filed for it, and an organisation with a direct financial interest in disputing the account examined it. The resulting numbers are narrow — they only describe insured losses reported by insured organisations — but within that boundary they were checked by a sceptic.

Two ways of counting, two different answers

Ransomware leads on severity and payment fraud leads on frequency, so the honest summary depends on which question is being asked. Where does the largest single loss come from? Ransomware. What is most likely to happen to your organisation this year? A member of staff sending a payment to an account controlled by somebody else.

Security budgets are set almost entirely against the first question. The spending pattern follows the headline rather than the frequency, and the frequency is where most organisations will actually meet the problem.

Why it is barely a security incident

In the ordinary case there is nothing for a security tool to detect. An email arrives — frequently from a genuine, compromised account at a genuine supplier — mentioning changed bank details. The finance team updates the record and pays the next invoice. Every system involved behaved correctly.

Which is why it sits awkwardly in most organisations. The loss is financial, the control is a payment process, and the incident lands with a security team whose tooling has nothing to say about it.

The control that works, and its cost

Out-of-band verification of any change to payment details, using a number held on file rather than one supplied in the message. It is unglamorous, it slows down a genuine supplier's legitimate change, and it defeats the majority category by volume in a way no detection product does.

The reason it is not universal is the friction, and the reason to accept the friction is on the claims sheet. Three in five claims arriving from one mechanism is a strong argument for a process step that stops that mechanism, even when the step is annoying every single time it runs.