How does the reserve figure your systems produce end up changing next year's rates, and where does that loop break?
6 min readUpdated 2026-08-15Target archetype: Enterprise Captive
0
Answer
Short answer
Reserving estimates what business already written will ultimately cost, and pricing needs that cost attributed back to the characteristics that were rated. The loop breaks over which period a loss belongs to, over recent years whose figures are still moving, and over premium earned at rates nobody charges any more.
Was this answer helpful?
Likely follow-ups
→How would you allocate an aggregate IBNR figure down to the rating cells a pricing model consumes?
→A single very large loss dominates one segment's experience. What do you do with it on the pricing side and on the reserving side?
→How do you bring a factor into the price when you have only been collecting the data for six months?
→The reserve review moves last year's estimate up by a fifth. What has to happen to rates already filed?
Reserving asks what the business already written will ultimately cost, so that the liability can be recognised in the accounts. Pricing asks what a risk carrying a given set of characteristics will cost in future, so that it can be charged for. They are the same underlying quantity approached from opposite ends, and the actuarial control cycle is the discipline of closing the circle between them: rates are set, business is written, claims develop, an ultimate cost is estimated, that cost is compared with the premium charged, and the rates move. When the loop works, last year's experience becomes this year's price. When it breaks, you keep charging a price the evidence has already contradicted, usually for a year or two before anybody notices.
Loading diagram…
The awkward step is between the reserve review and the experience by segment. The review produces figures for a whole class of business, and the rate indication needs those figures broken down far further than the review ever computed them.
Reserving works in accident periods, pricing works in policy periods
A reserving actuary usually groups losses by the period in which the loss occurred, because that is the period the liability belongs to and the period whose development can be watched. A pricing actuary wants losses grouped by the period in which the policy incepted, because that is the period in which the rate under examination was in force. A twelve-month policy sold in October exposes two accident years, and the losses from its second half will not be visible for a long time.
Neither view is wrong, and the mapping between them is not a reporting nicety. Hand a pricing team accident-period losses against written premium and they are comparing the losses of one period against the premium of a different one, so the loss ratio they compute contains no rate change at all. Making both views available means claim transactions have to stay attributable to the policy term and to the policy version that was on risk at the date of loss, not merely to a policy number. That is the same requirement backdated endorsements impose, arriving from the other direction.
Premium has to be brought to today's rate level
The premium half of the ratio is worse behaved than the losses. Historical earned premium was collected at whatever rates were filed at the time, so a rising loss ratio can mean a deteriorating book or it can mean three years of rate reductions. On-levelling adjusts historical premium to what the same exposures would be charged under the rates in force now, and it is the step that makes several years comparable at all.
Doing it properly needs something many systems do not keep gladly: a record of every rate change, its effective date, the jurisdictions it applied in and the exposures it touched, in a form you can re-price against. Where the only artefact of a rate change is a deployment, on-levelling degrades into an approximation held in a spreadsheet somebody maintains by hand, and the rate indication silently inherits that uncertainty. A pricing platform that can replay historical quotes against a chosen rate version solves the problem outright, because on-levelling becomes a re-run rather than a judgement.
Recent periods mislead in a predictable direction
Incurred cost is paid plus outstanding case reserves. For a period that closed last month it is a small fraction of what will eventually be paid, because most claims have not been notified yet, and those that have are typically reserved cautiously at first and developed as the file matures. So the most recent period always looks like the most profitable one, and it looks that way most strongly in long-tailed classes where notification and settlement take years.
That is where this loop most often breaks, and it is a governance failure more often than a modelling one. Somebody pulls a loss ratio for the latest twelve months from a dashboard, finds it flattering, and argues for a rate reduction, which is then applied precisely to the business whose losses have yet to appear. The defence is procedural rather than clever: no figure representing a period's cost should be published without its development stage attached, and the pricing view must consume ultimate estimates rather than incurred-to-date. Where an ultimate estimate cannot be produced at the granularity the pricing model wants, the honest output is a wider uncertainty range and a lower credibility weight, not a tighter number squeezed out of immature data.
IBNR does not exist where the pricing model needs it
The gap between incurred and ultimate is IBNR, and it is an aggregate actuarial estimate held for a reserving segment rather than something a claims system carries per claim. A pricing model, by contrast, wants cost at the level of the factors it is fitting: vehicle group, trade, postcode band, limit and excess. Somebody therefore has to push an aggregate estimate down into cells, and the basis chosen changes the answer materially. Allocating in proportion to case incurred pulls the estimate towards whichever cells reported early. Allocating in proportion to exposure ignores that some segments genuinely develop more slowly than others.
Whichever basis is chosen, it needs to be recorded as data rather than performed inside a workbook, because otherwise nobody can explain a year later why one segment's indicated rate moved. The same holds for the two other adjustments that always sit on this path. Large losses are usually capped and their excess spread across segments, so that a single fire does not reprice a whole rating cell, and the cap and the spreading basis have to stay stable between reviews or the movement you observe is your own methodology.
And the reserve review is normally performed gross of reinsurance while the trading result is net, so any pricing exercise must state which side of the treaty it is measuring: a change to the reinsurance programme moves the net figure without any change in the underlying risk.
What to build so the loop can be audited
Treat every stage as a dated artefact rather than a report. Claim transactions carry the accident date, the notification date, the transaction date and the policy version they belong to, and they are never overwritten. Each reserve review is stored with its valuation date, its segmentation, its selected development pattern and its allocated output, so that a later review can be compared with an earlier one instead of merely replacing it. Rate versions are retained and re-runnable. The rate indication then becomes a query over those artefacts, which is what allows the recurring argument between the actuary who says the book is deteriorating and the underwriter who says the data is wrong to be settled by identifying which stage the two of them are reading differently.
Nothing in this loop moves faster than the claims develop, and any system that presents recent experience as though it were complete is quietly arguing for a rate cut on business whose losses have not arrived yet.