onlevel factors not matching CAS example

[vdunaway]

I am testing the ParallelogramOLF feature in this python package. I have the code to replicate p. 75-76 of the following: https://www.casact.org/sites/default/files/2021-03/5_Werner_Modlin.pdf

I would expect the onlevel factor produced by this package for CY2011 to = 1.0431. But I am getting 1.0462. Am I missing something?

##testing CAS example
rate_history = pd.DataFrame({
    'EffDate': ['2010-07-01', '2011-01-01', '2012-04-01'],
    'RateChange': [.05, 0.10, -.01]})
rate_history


data = pd.DataFrame({
    'Year': list(range(2005,2015)),
    'EarnedPremium': [10_000]*10})
prem_tri = cl.Triangle(data, origin='Year', columns='EarnedPremium')
prem_tri = cl.ParallelogramOLF(rate_history, change_col='RateChange', date_col='EffDate', vertical_line = False).fit_transform(prem_tri)
prem_tri.olf_

Output:
2014
2005 1.143450
2006 1.143450
2007 1.143450
2008 1.143450
2009 1.143450
2010 1.136531
2011 1.046195
2012 0.992838
2013 0.999696
2014 1.000000

[kennethshsu]

Hi @vdunaway,

This is because the chainladder package actually calculates the OLF at the daily level. It calcualte the OLF for each day in the year, then takes the straight average for the exposure grain that you need. However, Werner and Modlin makes this calculation by using an approximation at the monthly level.

Let's look at the parallelogram chart at the top of page 76 of the text, we see that Werner and Modlin assumes area 1 has an area of 0.125 for year 2011, however, this is actually not exactly true, it is only approximately true assuming all months have an equal number of days. 0.125 = 0.5 ^ 2 * 0.5

Since the effective date of the 5% rate change is from 7/1/2010, Area 1 is actually [181/365] ^2 / 2, which is ~0.12295 instead of 0.1250. (181 is the number of days between 1/1/2011 to 6/30/2011, basically the height, and length, of area 1's triangle).

Area 3 has an area of 365/365 ^2 *0.5 = 0.5 (same as in the text).

Area 2 would be 1 - 0.500 - 0.12295 = 0.37705.

I didn't spend the time to verify the rest of the calculation, but this should hopefully be convincing enough that the Werner and Modlin's version of OLF is understated. Note that chainladder will even take care of leap years when counting the number of days (especially for this year, 2024), whereas Werner and Modlin wouldn't since they make the calculation at the monthly level.

Does this help?

[vdunaway]

Here is another simple example using rate changes eff. on 1/1, so days v. months shouldn't matter?

rate_history = pd.DataFrame({
    'EffDate': ['2009-01-01','2010-01-01', '2011-01-01', '2012-01-01'],
    'RateChange': [.035,.05, 0.10, -.01]})
rate_history

data = pd.DataFrame({
    'Year': list(range(2005,2015)),
    'EarnedPremium': [10_000]*10})
prem_tri = cl.Triangle(data, origin='Year', columns='EarnedPremium')
prem_tri = cl.ParallelogramOLF(rate_history, change_col='RateChange', date_col='EffDate', vertical_line = False).fit_transform(prem_tri)
prem_tri.olf_

Output is:

Out[136]: 
          2014
2005  1.183471
2006  1.183471
2007  1.183471
2008  1.183471
2009  1.163460
2010  1.116225
2011  1.039500
2012  0.995000
2013  1.000000
2014  1.000000

If I follow the W&M approach, then I would get the following:

<style> </style>

	Cumulative Rate Chg Index
0	1.000000
1	1.035000
2	1.086750
3	1.195425
4	1.183471

<style> </style>

	[1]	[2]	[3] = [2] / [1]
	Average Rate Level Index	Current Rate Level Index	Onlevel Factor
2005	1.000000	1.183471	1.183471
2006	1.000000	1.183471	1.183471
2007	1.000000	1.183471	1.183471
2008	1.000000	1.183471	1.183471
2009	1.017500	1.183471	1.163116
2010	1.060875	1.183471	1.115561
2011	1.141088	1.183471	1.037143
2012	1.189448	1.183471	0.994975
2013	1.183471	1.183471	1.000000
2014	1.183471	1.183471	1.000000

[kennethshsu]

Hi @vdunaway, I think I identified a bug!

But before I push the fix for review, would you be interested in trying to reproduce the results with another example using rates not always effective on 1/1? Perhaps go back to the example from the text by W&M?

It will be good to compare the 2 methods discussed above:

1. The W&M approach, assuming that all months are of equal days.
2. The daily approach, reflecting the different number of days in a month. For this, let's assume all Februaries only have 28 days (i.e. ignore Leap Years).

Let me know what you get as the factors to current rate level using 2 approaches for each exposure year. We can then translate this as test cases after!

[vdunaway]

@kennethshsu - Here is an excel file with the calculations of the 2 examples you propose. Please feel free to check my math.
OLF example_mthly v daily v2024-03-22.xlsx

Corresponding to those examples is the python code and result using chainladder below.

rate_history = pd.DataFrame({
    'EffDate': ['2010-07-01', '2011-01-01', '2012-07-01', '2013-04-01'],
    'RateChange': [.035,.05, 0.10, -.01]})
rate_history

data = pd.DataFrame({
    'Year': list(range(2006,2016)),
    'EarnedPremium': [10_000]*10})
prem_tri = cl.Triangle(data, origin='Year', columns='EarnedPremium')
prem_tri = cl.ParallelogramOLF(rate_history, change_col='RateChange', date_col='EffDate', vertical_line = False).fit_transform(prem_tri)
prem_tri.olf_

Out[144]: 
          2015
2006  1.183471
2007  1.183471
2008  1.183471
2009  1.183471
2010  1.178386
2011  1.121146
2012  1.076421
2013  1.005011
2014  0.999696
2015  1.000000

[kennethshsu]

@vdunaway thanks for sharing the excel workbook, everything looks great!

Now, the last piece of the puzzle is the leap year issue. I think if we consider leap years, the only number that should change is the 2012's OLF should be 1.075410, do you agree with that?

Here is a list of leap years.

[vdunaway]

Correct. That is what I get as well. Attached is a revised excel file that adds that scenario as scenario #3.
OLF example_mthly v daily v2024-03-25.xlsx

[kennethshsu]

These two blocks of code should work correctly now.

Monthly approximation scenario:

rate_history = pd.DataFrame(
    {
        "EffDate": ["2010-07-01", "2011-01-01", "2012-07-01", "2013-04-01"],
        "RateChange": [0.035, 0.05, 0.10, -0.01],
    }
)
rate_history

data = pd.DataFrame({"Year": list(range(2006, 2016)), "EarnedPremium": [10_000] * 10})
prem_tri = cl.Triangle(data, origin="Year", columns="EarnedPremium", cumulative=True)
prem_tri = cl.ParallelogramOLF(
    rate_history,
    change_col="RateChange",
    date_col="EffDate",
    approximation_grain="M",
    vertical_line=False,
).fit_transform(prem_tri)
(
    np.round(prem_tri.olf_.to_frame().values, 6).flatten()
    == [
        1.183471,
        1.183471,
        1.183471,
        1.183471,
        1.178316,
        1.120181,
        1.075556,
        1.004236,
        0.999684,
        1.000000,
    ]
).all()

And daily approximation scenario, includes consideration of leap years:

rate_history = pd.DataFrame(
    {
        "EffDate": ["2010-07-01", "2011-01-01", "2012-07-01", "2013-04-01"],
        "RateChange": [0.035, 0.05, 0.10, -0.01],
    }
)
rate_history

data = pd.DataFrame({"Year": list(range(2006, 2016)), "EarnedPremium": [10_000] * 10})
prem_tri = cl.Triangle(data, origin="Year", columns="EarnedPremium", cumulative=True)
prem_tri = cl.ParallelogramOLF(
    rate_history,
    change_col="RateChange",
    date_col="EffDate",
    approximation_grain="D",
    vertical_line=False,
).fit_transform(prem_tri)
(
    np.round(prem_tri.olf_.to_frame().values, 6).flatten()
    == [
        1.183471,
        1.183471,
        1.183471,
        1.183471,
        1.178231,
        1.120105,
        1.075410,
        1.004073,
        0.999693,
        1.000000,
    ]
).all()

Now, I think we just have one final decision to make. As you can see above, I will be introducing a new parameter, named approximation_grain inside chainladder.ParallelogramOLF(). This approximation_grain takes in a character, it has to be either M for monthly approximation (scenario 1), or D for daily approximation (scenario 3 - with leap year consideration). I did not bother implementing scenario 2 (daily approximation but assuming Februaries always have 28 days, ignoring leap years).

I think the default value should be D as it is more accurate, but I don't think this is commonly discussed in the literatures. This is also basically the extension of exposure method, right? So strictly speaking, Parallelogram method should be Y only.

What are your thoughts?

[vdunaway]

Hmm.. that's a good question. I would think that most people would use Y just because that seems to be the most common, but I think I like the idea of D as the default since it does promote better accuracy when the exposure method isn't actually available. Both still assume uniform policy writing which I think is essentially what most actuaries have to assume given the level of detail required for the full-exposure method is typically unavailable (or not easily obtained).

[kennethshsu]

Ok, I've decided to keep the default value of approximation_grain as M. You'll see the bug fix and enhancement in an upcoming version of chainladder soon. Thank you for the help with this!

By the way, did you test other functionality of the package against the W&M text? This is something that I wanted to do but never got around to.

[vdunaway]

@kennethshsu - thanks for the update! I have not tested everything.

I work in the reinsurance space, particularly, reinsurance broker actuary pricing reinsurance treaties and I'm building tools for our team to use. Now that we've solved this particular discussion, phase 1 of my build will be focused more immediately on the following:

1. tail fitting. I built an Excel-based LDF tail and interpolation tool. When testing the chainladder package, the 'attachment_age' parameter doesn't appear to be working correctly. Admittedly, I haven't spent as much time with this as I was focused on the onleveling.
2. test onleveling flexibility. I want to challenge how flexible the ParallelogramOLF() function is. In reinsurance, it's common that you need to onlevel to a treaty year that is for example 7/1/24-6/30/23 v. the traditional calendar year 1/1-12/31. If you expect a prospective rate change that say is effective 10/1/24, you are trying to onlevel to treaty year 7/1/24-6/30/23 and you would want to reflect that part of that year will see some portion of the rate change effective 10/1/24. I have not seen, on the surface, that chainladder can currently handle a more complex onleveling need... yet.
3. processing large triangle datasets. I will be working a lot with triangles, including trending, select loss development factors for a large triangle dataset (i.e., large number of indicies), interpolation, tail fitting, incorporation of a LDF benchmark into selection process. On the surface, evaluating each triangle within a large data set seems cumbersome but will be further testing.

Those are just a few that I'll be focused on in the coming days as I build and test.

[kennethshsu]

@jbogaardt, there's a calculation error with one of the test cases in chainladder/utils/tests/test_utilities.py::test_non_vertical_line.

In this example, the rate change is effective 7/1/2017 and we want the on-level factor for 2017, I propose that the OLF should be calculated as:

• Area of new rate = 0.5*((31+31+30+31+30+31)/365)^2 = 0.127063
• Area of old rate = 1 - 0.5*((31+31+30+31+30+31)/365)^2 = 0.872937
• 2017 average rate level = 0.872937* 1.0 + 0.127063 * 1.2 = 1.025413
• 2017 OLF = 1.20 / 1.025413 = 1.170261 (vs what is currently coded in the test case 1.174622)

or, with everything chained together (no rounding):

• 2017 OLF = 1.20 / ((1 - 0.5*((31+31+30+31+30+31)/365)^2)* 1.0 + (0.5*((31+31+30+31+30+31)/365)^2) * 1.2) = 1.170261

Basically, the last line should replace line 8.

In addition, we can now use approximation_grain = 'D' to get the exact value.

@jbogaardt, do you agree? Perhaps @vdunaway can peer-review this? Since we are trying to pass a unit test case by modifying the unit test.

[vdunaway]

@kennethshsu confirming that I agree with your calculations and results outlined above, including the vertical_line = True test

[jbogaardt]

Sounds like you two agree so I'm good with altering the tests.

[vdunaway]

@kennethshsu - I just upgraded my chainladder package from 8.18 to 8.20 and I just tried re-running the examples above and now I get this error message at the prem_tri line. I cannot find what the issue is. I'd appreciate the help!

[kennethshsu]

Pretty sure it's because of pandas, what version are you on?

Try upgrading your pandas too and let me know if that fixes it.

[vdunaway]

@kennethshsu ah, that was it. Silly mistake on my part thank you!