Data Analytics · PostgreSQL · SQL · Tableau

Why counting claims isn't enough to understand risk

Two insurance teams can handle a similar number of claims but face very different financial exposure. I used a 10,000-claim dataset to investigate how claim values vary by insurance product, and why totals alone can lead to misleading comparisons.

At a glance

10,000Claims analysed
165.64MTotal recorded claim value, in dataset units
55.23%Share of total claim value from Life Insurance
103Claims at or above the 95,000 threshold

Headline figures were independently cross-checked against the 10,000-row source in the historical October 2026 audit. That validates selected aggregate counts from that audit, not every SQL view or the external Tableau dashboard. This is an independent portfolio analysis, not a live insurer's operating dashboard.

The question

How can an insurance analyst identify where the greatest financial exposure sits without confusing a large number of claims with a large amount of money at stake?

What the analysis found

Life Insurance accounts for 16.82% of claims but 55.23% of recorded claim value. The number of claims is fairly balanced across product categories, while their average values differ sharply. Life Insurance averages 54,386.44 per claim; Mobile Insurance averages 406.80 in the same dataset.

All 103 claims at or above 95,000 fall in Life Insurance. This identifies where the largest recorded individual claims appear; it does not establish fraud, financial losses, future risk probabilities or why those claims occurred.

Why the distinction matters

Ranking agents or vendors by total claim value alone can be unfair. Someone handling higher-value insurance products may appear to carry more exposure simply because of the types of claims assigned to them. A useful management view should show claim count, average claim value, total exposure and product mix together.

The dataset also shows that claim amount is not the same as an expected loss estimate. A descriptive distribution of historical claims cannot, on its own, predict future claim frequency or establish the adequacy of reserves.

How the evidence was built

The project uses PostgreSQL and SQL to audit claim records, check relationships with employee and vendor reference data, calculate portfolio KPIs and test candidate findings. A Tableau dashboard presents the results for executive review. Findings that did not support a meaningful standalone conclusion were retained in a separate rejected-findings log rather than promoted into recommendations.

What was independently checked

The reported total claim value, product counts and all 103 claims at or above the 95,000 threshold were cross-checked against the original 10,000-row CSV in October 2026. The raw source files are not currently distributed on the public branch while their provenance and redistribution rights remain unverified. The independent Python audit now has 11 locally passing tests on synthetic inputs, including safe CLI behavior and missing-source handling. These tests are not a fresh reproduction of the historical 10,000-claim totals, a licensing review or a verification of the external Tableau dashboard.

What the data cannot tell us

This analysis describes the supplied dataset. It does not prove causal relationships, establish that an agent or vendor performs poorly, identify fraud, or validate a production insurance decision. Product-specific review thresholds are recommendations to evaluate, not implemented controls or demonstrated business improvements.

Explore the evidence

Start with the business findings for a plain-language explanation, or inspect the KPI report and SQL for reproducible definitions and calculations.