The actuarial team says they cannot use the claims data your reporting warehouse produces. What are they missing?

Reporting answers "now"; actuaries ask "as at then"

A reporting warehouse typically holds one row per claim with its current paid, current reserve and current status. That answers every question a claims manager has, and none of the questions an actuary has.

Reserving works by observing how a cohort of claims develops over time. You take all claims from one accident period, and you look at what they were believed to cost after twelve months, after twenty-four, after thirty-six, and so on. The pattern in that development is what lets you estimate where a young cohort will end up, and therefore what to hold for claims that have happened and not yet been reported.

That requires the value as it stood at each past valuation date. A table that overwrites the reserve as the adjuster revises it has destroyed exactly the series the actuary needs. There is one row, it says 29,500, and nothing records that it said 3,500 at the first year end and 30,000 at the second.

Which date does the claim belong to

Before anything else, establish which date the cohort is defined by, because there are at least four and they routinely differ by years.

Date	What it means	Used for
Accident date	When the loss occurred	The usual cohort for reserving
Report date	When the insurer was told	Reporting-delay analysis, IBNR shape
Transaction date	When a payment or movement was booked	Cash and financial reconciliation
Valuation date	The as-at point of the whole view	The column of a triangle
Underwriting year	When the policy was written	Reinsurance treaty allocation

A claim from an accident in November, reported in February, paid across three years, on a policy written the previous June, sits in a different bucket under each of these. Building a cohort on the wrong one produces numbers that look plausible and describe nothing.

The one that catches engineers is underwriting year, because reinsurance treaties attach by the year the policy was written while claims arrive by accident date, so a single payment can be split across structures negotiated years apart.

What a triangle actually is

A development triangle is a grid: accident period down the side, development period across the top, and in each cell the cumulative incurred (or paid) for that cohort as at that point in its life.

Incurred, cumulative, in thousands
accident year   dev 12    dev 24    dev 36    dev 48
2022             4,120     5,880     6,340     6,410
2023             4,460     6,210     6,690        —
2024             4,890     6,980        —         —
2025             5,240        —         —         —

It is triangular because the recent cohorts have not lived long enough to fill the later columns. The whole exercise is estimating those blanks from the pattern in the completed rows.

Now read what one cell requires: the 2023 row, dev 24, is the incurred figure for all 2023 accident-year claims as at the end of 2024 — not as at today. Every claim's paid and reserve at a date two years in the past. Nothing in a current-state table can produce that.

Two ways to make it available

Periodic snapshots. At each valuation date, write a complete copy of every open and recently closed claim's figures, stamped with that date. Simple, obviously correct, and the storage is unremarkable because claim counts are not web-scale. This is what most carriers do, and quarter-end snapshots are the common cadence.

A movement store. Record every reserve and payment movement as an immutable row with both an effective date and a booked date, and derive any as-at view by summing movements up to that point. More flexible — any valuation date, not just the ones you snapshotted — and it demands discipline, because a single movement inserted retrospectively without a booked date silently changes history that was already reported.

The two combine well: movements as the source of truth, snapshots materialised from them so the actuarial run is not recomputing the world.

What does not work is reconstructing from an audit log of table changes. Audit logs record that a field changed, not what the business event was, they usually lack the accident-period context, and they are frequently pruned. Several programmes have discovered this at the point of needing the data.

Two complications worth raising unprompted

Reopened claims. A claim closed at zero and reopened two years later adds cost to an accident period whose triangle rows were published long ago. The figures for that cohort move after the fact, which is normal and has to be visible rather than silently absorbed.

Large losses distort the pattern. One enormous claim in a small cohort makes the development factor for that row meaningless, so actuaries typically analyse large losses separately from attritional ones. That means the data has to be sliceable by size band, and the threshold is a business parameter that changes — so it must be applied at query time rather than baked into the extract.

The question to ask first

Before building anything, ask the actuarial team for the shape they want: which date defines the cohort, which measure (paid, incurred, counts), gross or net of reinsurance, which valuation dates, and which segmentation. Those five answers determine the model, and they differ by line of business within the same carrier.

Engineers who skip that and build "a claims extract" deliver something that gets loaded into a spreadsheet and manually reshaped every quarter, which is the outcome the project existed to prevent.

Reporting keeps the latest value. Reserving needs the value as it stood at every past year end, and an overwrite is the one operation that makes it unrecoverable.