Premium leakage: why it hides, and how to find it

When insurers talk about premium leakage, they usually mean bad input: an undisclosed driver, a wrong garaging address, understated payroll. That leakage is real, and the industry attacks it with data prefill, inspections and premium audit. There is a second kind, and it hides better.

Two kinds of premium leakage

Input leakage is the right rate applied to the wrong facts. The risk is misdescribed, so the premium is too low.

Execution leakage is the wrong rate applied to the right facts. The filing says one thing and the system charges another, because:

• a revision was implemented with a wrong or missing row,
• the wrong edition was in force on the effective date,
• a carrier deviation, discount or cap was misapplied,
• or a factor drifted during a platform upgrade.

Execution leakage runs in both directions. An undercharge is lost premium that never appears in any report. An overcharge is a refund with interest, and a customer who may already have left.

Why execution leakage never shows up

A policy system never says "I don't know". It returns a premium, and a wrong premium looks exactly like a right one. User acceptance testing confirms that rating ran without error. It does not confirm the number is correct, because an engine cannot grade its own homework.

So execution leakage is found in one of three ways: a customer complains, an auditor or regulator asks, or a team goes looking. Only the last one is on your schedule.

How to measure it

You cannot measure execution leakage against the system, because the system is what you are measuring. You need an independent premium:

1. Build an independent rating model from the source of truth: your rate manuals, filings and bureau content, never from the system under test.
2. Rate the same cases both ways and compare, to the cent.
3. Treat every disagreement as a finding with a cause: the first rating step where the two calculations part ways, and the table cells it read.
4. Separate the unexplained. Anything you cannot attribute stays open. It is not rounded into "passed".

Done on every rate change before go-live, this stops new execution leakage at the door. Done backwards over the policies already written, it measures what has already leaked. That second use is where the money already lost is found.

Where to start

Do not start with the whole book. Start with one line of business, one state, and the next rate change due to go live. That is a bounded set of changed rows, a clear filing to check against, and a date that gives the work a reason to finish on time.

Questions

Is premium audit enough to catch premium leakage? Premium audit catches input leakage: wrong exposure, wrong class. It does not check whether the system applied the filed rates correctly.

Can leakage happen without any code change? Yes. A new rate edition, a deviation, or an effective date is configuration, and configuration is where most execution leakage comes from.