What is a loss development triangle, and what does the actuary need from your claims system that reporting does not?

The object itself

A loss development triangle is a matrix. Rows are cohorts of claims grouped by the period the loss belongs to, conventionally the accident year. Columns are development periods: how long after the start of that cohort the measurement was taken, at twelve months, twenty-four months, thirty-six and so on. Each cell holds the cumulative claim cost for that cohort as measured at that point.

It is triangular for the obvious reason. The 2019 accident year has been observed for seven development periods; the 2025 accident year has been observed for one. The upper-left is filled, the lower-right is the future, and the entire purpose of the exercise is to fill in the lower-right.

The method that gives the shape its name is chain ladder. You compute the ratio between consecutive columns for each row, average those ratios across rows to get a development factor for each column transition, and apply the factors forward to project each immature row to its ultimate cost. Ultimate minus what is currently incurred is the amount not yet reflected in the books: the reserve the actuary is estimating, of which the part relating to claims not yet reported at all is IBNR, incurred but not reported.

That last point is worth stating explicitly because it is misunderstood constantly. IBNR is an aggregate, estimated, top-down quantity. It does not decompose onto individual claims, because by definition the claims it represents have not been reported. Your claims system holds case reserves, set claim by claim by handlers. The actuary's reserve estimate sits above those, and the difference between the two is a governance conversation, not a data reconciliation error.

Cohorts and why you cannot pick just one

Accident year groups claims by the date the loss occurred. It is the natural basis for understanding claim experience, because it isolates the year in which the events happened.

Underwriting year, also called policy year, groups claims by the policy that covers them, specifically by when that policy incepted. It is the basis you need to assess whether a year's underwriting decisions were good, and it is standard in reinsurance and in Lloyd's-market reporting. It develops more slowly than accident year, because a policy written in December 2024 can produce a loss in November 2025.

Reporting year groups claims by when they were notified. It is used where reporting delay is the dominant feature, which is typical of claims-made liability covers.

Your data model does not choose between these. It stores the underlying dates, loss date, report date, policy inception date, transaction date, and lets the cohort basis be a query decision. An engineer who bakes one basis into a warehouse table has removed the actuary's ability to look at the book the other way round, and they will need to.

What actually breaks: rebuilding history from current state

Reporting systems are built to answer "what is true now", and they optimise for that by overwriting. A claim's outstanding reserve gets updated, a claim's status becomes closed, a claim's cause code gets corrected to the right value. Every one of those overwrites is correct for reporting and fatal for reserving.

Consider a triangle cell: accident year 2022 at development period twenty-four months. That cell means "the cumulative incurred cost of 2022 losses, as measured at 31 December 2023". If you build it by asking the current database for 2022 claims and summing their incurred cost, you get the cost as measured today, not as measured at the end of 2023. Do that for every cell and the triangle you produce is not a triangle: every row shows today's figure across all columns, the development pattern flattens out, and the factors you extract from it are meaningless. The failure is silent, the numbers look plausible, and it will not be caught by any test that checks totals.

There are two correct approaches and mature shops use both. The first is to snapshot: physically store the state of every open claim at each evaluation date, typically each month-end and quarter-end, and never touch a snapshot again. The second is to store transactions with dates and derive any evaluation date by summing transactions up to it:

-- The 2022 accident-year row of an incurred triangle, evaluated
-- at each anniversary. The date filter on transaction_date is what
-- makes this a triangle rather than seven copies of today's number.
SELECT eval.as_at,
       SUM(t.paid_amount + t.reserve_change) AS incurred_at_eval
FROM   claim_transaction t
JOIN   claim c ON c.claim_id = t.claim_id
CROSS JOIN (VALUES ('2022-12-31'::date), ('2023-12-31'), ('2024-12-31')) AS eval(as_at)
WHERE  c.loss_date BETWEEN '2022-01-01' AND '2022-12-31'
  AND  t.transaction_date <= eval.as_at   -- knowledge cut-off, not loss cut-off
GROUP BY eval.as_at;

The transactional approach is more flexible, because it lets the actuary evaluate at any date rather than only at dates someone thought to snapshot. It also depends absolutely on the transaction ledger being append-only. A single in-place correction to a historical transaction changes a triangle that has already been used to book a reserve, and reserve figures that move retrospectively are an audit finding, not an inconvenience.

The granularity and immutability that follows

Working backwards from the triangle, the requirements on the claims system are specific.

Every financial event on a claim is a separate row: payments, reserve increases and decreases, recovery receipts, expense payments, reversals. Each carries the date the event was recorded and the date it is effective for. Each identifies the claim, the feature or coverage, the transaction type, and a reason code. Nothing is ever updated except to be superseded, and a mistake is corrected by a reversing entry that itself has a date.

Alongside the transactions you need the claim's own dates, loss and report at minimum, the policy identity and its term, and the exposure measure that the cohort will be normalised by, which for motor is typically vehicle-years earned and elsewhere is whatever the rating exposure base is. You also need indemnity separable from expense, gross separable from recoveries, and gross separable from the reinsurance-ceded position, because the actuary reserves gross and net and those are different exercises.

Finally you need homogeneity. A triangle mixes claims that develop similarly; combining a short-tail property book with a long-tail liability book produces a development pattern that describes neither. That means the transaction rows need enough dimensional detail, product, coverage, jurisdiction, large-loss flag, to let the actuary cut the data into homogeneous groups after the fact rather than asking you for a new extract each time.

The distinction to carry away is that reporting wants the truth as it is, and reserving wants the truth as it was believed to be at a sequence of past instants. A system that only does the first cannot be made to do the second retrospectively, because the information has already been destroyed.