Handling compound trends, supplying trends to estimators

[genedan]

I have a question on trends, actually several, but they all kind of tie in together:

Compound Trends

How are compound trends are currently handled? It's typical in pricing work to receive multiple trend types and then compound them together (such a CPI trend blended with a LOB specific trend). I currently multiply them together after fitting, resulting in a DataFrame after extracting cl.Trend().trend_.

However, this results in a data type other than an estimator. Should we augment an estimator to allow for compound trends prior to fitting? Especially if they move in different directions (origin vs. valuation). If we implement this, how? Something like cl.Trend() * cl.Trend() -> cl.Trend(), while preserving the ability to extract both components after the operation?

I ask this because...

Supplying Trends to Estimators

How are trends supplied to reserving method estimators? What data types should they accept? For a simple trend, you may be able to supply a cl.Trend() estimator, but for a compound trend, you can't, you'd have to supply a DataFrame.

Maybe trend parameters should be able to accept several types (like a scalar if it's simple enough), a cl.Trend() for simple trends, and a list of trends [trend1, trend2] for compound trends? Or a DataFrame? If we enhance cl.Trend() to enable compound trending, we can just supply the estimator.

I believe supplying a post-fit DataFrame in the case of compound trending would be suboptimal because cl.Trend() attributes and methods cannot be accessed from a DataFrame.

Exposure/Premium vs. Loss trends

Some methods might need separate trends applied to different components (premium, loss, expenses, etc.), how should we name the arguments, are premium_trend, loss_trend, etc., ok?

[henrydingliu]

can you please provide a more concrete example of a compound trend?

[genedan]

The first is a trend in the origin direction, the second is a calendar year trend, then they get multiplied together to form a compound trend:

[henrydingliu]

I currently multiply them together after fitting, resulting in a DataFrame after extracting cl.Trend().trend_
However, this results in a data type other than an estimator. Should we augment an estimator to allow for compound trends prior to fitting?
How are trends supplied to reserving method estimators? What data types should they accept? For a simple trend, you may be able to supply a cl.Trend() estimator, but for a compound trend, you can't, you'd have to supply a DataFrame.

the package today is pretty inconsistent with regards to trend. what you are thinking of is only available through Triangle.trend(). I believe it's chainable, i.e. you can do Triangle.trend(trend=origin_trend).trend(trend=calendar_trend, axis="valuation").

what we probably should do is to enhance cl.Trend to be an actual transformer, i.e. doing cl.Trend().transform will actually apply the trend to the triangle. then you can chain cl.Trend to compound trend, or add multiple cl.Trend as steps in a pipeline.

[henrydingliu]

Some methods might need separate trends applied to different components (premium, loss, expenses, etc.), how should we name the arguments, are premium_trend, loss_trend, etc., ok?

take a look at the capecod implementation. it's applying olf on loss and exposure during estimation. it know it's not trend, but it's a reference point. basically, the precedent appears to be that we would apply premium trend on the sample_weight and apply the loss trend on X

[kennethshsu]

I think compound trend is useful, and not only that

We should be able to supply trends like this
3% from 2010/1/1 - 2013/1/1, by rows (origins)
2% from 2012/1/1 - 2015/1/1 (overlapping the 1st one), by rows (origins)
5% diagonally, from valuation 2011/1/1 - 2018/1/1
trend to date, maybe somewhere in between like 2014/1/1, or somewhere in the future, like 2025/1/1 that will restate the overall trend

That said, I don't think supplying a pd.DataFrame() is the right solution, but it's going to get so messy. Maybe chaining like @henrydingliu said is the right way to go, so just .Trend(3%, dates by row, trend_to_date).Trend(2%, dates by row, trend_to_Date).Trend(5%, by valuation, trend_to_date)?

[genedan]

I would support chaining. At work, we have a big database full of trends that we can pull out and use in a pricing e.g., 500k x 500k commercial auto, 500k x 500k general liability, and we can blend them together and apply them to losses. I would guess that in the software we use, they are defined as objects as some class and that can be multiplied together.

The chaining would help keep these concepts as distinct inputs.