Proposal: Reserve rollforward workflow

[son1403]

I would like to discuss a reserve rollforward workflow.

A valuation review normally needs a clear bridge from opening IBNR to closing IBNR: expected emergence, actual development, changes from refreshed assumptions, and the impact of new origin periods. Today each team tends to reproduce this in a spreadsheet.

A useful first version would fit the same reserving approach at two valuations and return a detailed bridge plus a compact summary. The definition of each movement should be explicit, particularly for new origin periods, rather than hiding an accounting convention.

The closed prototype is #1249. I am opening this issue first to agree the definitions and whether this belongs in the library.

[henrydingliu]

can you lay out a visual example of such a bridge?

[kennethshsu]

There's currently this in the example. But I think it can be improved, are you thinking like a waterfall chart?

Prior booked -> actual vs expected development -> selections refinement -> new booked?

[son1403]

yeah, pretty much. i was thinking something like:

prior booked IBNR 100
expected runoff (20) -> 80
actual vs expected dev (5) -> 75
selection / refit 7 -> 82
new origin periods 3 -> 85 current booked

the PR has most of this already, but it puts the last bits into one estimate_change. splitting it out would make it clearer whether the move came from actual dev, changed selections, or new origins.

for the selections line, we'd prob need separate prior/current models or assumptions, not just refitting the same estimator twice.

[henrydingliu]

yeah, pretty much. i was thinking something like:

prior booked IBNR 100 expected runoff (20) -> 80 actual vs expected dev (5) -> 75 selection / refit 7 -> 82 new origin periods 3 -> 85 current booked

the PR has most of this already, but it puts the last bits into one estimate_change. splitting it out would make it clearer whether the move came from actual dev, changed selections, or new origins.

for the selections line, we'd prob need separate prior/current models or assumptions, not just refitting the same estimator twice.

from a process standpoint, we should be making design choices for the package that conforms to a standard sklearn-based workflow, rather than repeating traditional actuarial, spreadsheet-based approach. 'prior ibnr' and 'expected run-off' are outputs of a fitted model; therefore, they should be persisted rather than re-fitted.

'actual emergence' is already part of model_diagnostics output.

'selection/refit' can come from #1255.

that leaves 'new origin' as the only net new enhancement. we can implement via a new indicator column in model_diagnostics.