​Inflation adjusted chain ladder

Before we dive in too far, what is the IACL?

The IACL is an extension to the standard chain ladder method which adjusts for claims inflation explicitly rather than implicitly [1]

The high-level steps are:

1. Convert a cumulative paid triangle to an incremental paid triangle
2. Inflate all the incremental payments to a consistent year (typically the most recent calendar year)
3. Convert the triangle in step 2 back to a cumulative triangle
4. Apply a standard chain ladder to the cumulative triangle in step 3 to estimate future payments
5. Then apply an assumption about future inflation to the future payments estimated in step 4

Calendar year inflation

Typically, this technique is taught in such a way that assumes that claims inflation is always a calendar year of payment effect. See the CM2 notes from IFoA for example [2]:

“Claims inflation will affect the payments in the run-off triangle by calendar year of payment.”

And this approach has propagated, for example see the following guidance note from Lloyd’s [3]:

“Future inflation should be considered on a calendar year basis until all claims are run-off to understand the impact on ultimate claims estimates.”

If we go back to the original paper however, by Richards and Cappers[4], the authors are quite clear that one step of their IACL model is “Determine the timing of the inflationary impact. (i.e., accident date, report date, paid date ... etc.)”. They consider it an empirical question whether inflation manifests according to paid date and not some other timing, and this is listed as just one possible option among a few.
​
Hindley in his excellent book, Claims Reserving in General Insurance [1], appears to be quite careful in his wording when writing the section on IACL. He consistently refers to it as a model for explicitly dealing with ‘calendar year’ effects (which is 100% true), he doesn’t refer to this as adjusting for inflation, and he cautions against naively using inflation indices when adjusting.

Why would inflation not be a calendar year effect?

Let’s look at an example from motor own damage.

If your vehicle is involved in a crash and is written off, from a legal perspective in the UK, the amount you are owed is the ‘fair value of your vehicle at the date of accident’. [5]

Let’s compare two claims, both involving identical vehicles.

1 – DOL = 1/10/2019, it is reported 1 week after the accident, the car is a write off, so 1 week later the claimant receives the fair value of the car. Claim closed for £1000 on 14/10/19.

2 – DOL = 1/10/2019, this claim however is reported 2 months late, the insurer disputes it for 4 months, but eventually the claim is paid, lets suppose the claim is not closed until 1/4/2020, but is also closed at £1000. Which was the fair value of the vehicle at the date of accident.

There has been an additional 6 months of inflation between these two dates. However in terms of legal rights, both claimaints are entitled to  the same amount of money.

Our inflation adjusted chain ladder however, would put these two amounts in different development cells, which would be in different calendar years, and then apply whatever our assumed inflation rate was to the 1st claim to bring it on level with the second claim. Obviously this is not correct, and actually for this head of damage technically we should inflate according to accident year, not calendar year.

Now this is where it gets messy. In practice, the amount from claim 2 might drift up. Most claims do not settle in a court, and are instead negotiated, if the fair value of a vehicle has gone up since the loss, this may influence the negotiation.

For other lines of business, this dynamic does play out on a calendar year basis. For example, if the car was not a total loss, but instead needed repair. Then the entitlement would be to the cost of repair, and if repair costs went up between the two dates, then there would be inflation between the different dates of repair. Given the delay in reporting claim 2, this would probably result in a delay to the repair, and inflation coming through.

In this case, we should inflate according to the calendar year of payment. Or strictly speaking, the calendar date of repair, which is likely to be almost the same thing in pratice.

For bodily injury, most components increase over time, and this will also generally be in line with when payments are made.

Really the moral of the story is that each line of business, and each head of damage within the line of business will have a different relationship to inflation and timing. And we can’t just assume that the calendar year version of the IACL is the right one.

How do these nuances get lost as they work their way through the system?

I’m also interested in how these errors propagate, because clearly the original paper by Richard and Cappers, and Hindley’s book are quite precise in their framing.

Most actuaries working today, are not deriving the techniques they are using from first principles, they’re also not reading original research, and to be honest that’s as things should be. Most people do not have the time or interest. Instead, there is a natural pipeline from original published research, which is distilled into course material as either textbooks or notes for actuarial exams, which then is taught and becomes the body of practice that actuaries use.

​What became apparent with IACL is that it became the go-to technique post-covid when we saw an uptick in claims inflation, and most actuaries having not touched it since their exams, basically went back and brushed up on their IFoA notes. Therefore the slight simplifications in the IFoA material, in what was a fairly niche part of the syllabus that hardly anyone was using in practice, suddenly became quite important. 

Claude/LLMs

Claude Opus 4.7, as of April 2026, also explains IACL with reference to the fact that claims inflation is as calendar year effect. Perhaps not surprising given things like the IFoA notes are in the training data.

Interestingly, Claude describes step 2 of the method (inflating the losses) in a slightly quirky way. It refers to ‘deflating to the most recent year’ which I would argue is an incorrect use of the word deflate. It should either say deflate to a base year (in the past), or it should say ‘inflate to most recent year’.

I couldn’t find this particular use of the word deflate in any of the academic papers. But interestingly, I could find a couple of recently written articles which do use the term ‘deflate’ this way, and which also repeat the ‘claims inflation = calendar year effect’ assumption.

You can quite clearly see how for new generations of LLMs, the latest versions of which are going to be trained on those articles for example, are in danger of some form of model collapse, and potentially new content on the internet may become less valuable to them.

How to use IACL properly?

I’d encourage you when using the ICAL method, to go back to Capper and Richard’s initial approach, and to attempt to understand the mechanics of a loss and settlement, and what this implies for how inflation feeds through to the claims triangle. Is the legal entitlement set at date of loss, date of reporting, date paid etc. And how does this legal entitlement play out in practice? It may manifest in your triangle as a calendar year effect, or it may not. It will generally vary by head of damage and line of business, but really we should treat this as an empirical question.

The above example I gave from motor own damage was based on a really interesting chat I had with our head of claims about one of our motor books that made me rethink how I was approaching a particular model. The best actuaries I’ve met, generally don’t use anything more complicated than the basics taught in the exam, but they’re plugged in to everyone else’s expertise in the company, and they use what they know well.
 
  
[1] Claims Reserving in General Insurance – David Hindley (2018)
[2] Subject CM2 Financial Engineering and Loss Reserving Core Principles Core Reading for the 2021 exams
[3] Lloyd’s -Allowing for Inflation in Reserving – August 2022
[4] ‘EVALUATING THE IMPACT OF INFLATION ON LOSS RESERVES’ , Richards and Cappers
[5] ​https://www.financial-ombudsman.org.uk/consumers/complaints-can-help/insurance/motor-insurance/vehicle-valuations-write-offs

ActEd Flashcards?
You might ask – what about the ActEd Flashcards? Can't you just use those? Firstly, these are not on Anki, but more fundamentally the flashcards are just not designed in adherence with the practice of good flashcard design [2], for example, they consistently break the rule that each card should be an atomic fact. Instead the flashcards are effectively just the core material, divided into chunks and put onto A6 index cards.

And while it’s true that many people rely heavily on acronyms for the exam, you still need to learn the basic concepts in the first place. Such as what is the difference between a defined benefit and a defined contribution scheme, what is asset-liability matching, and so on and so on. etc.

I therefore decided to make my own deck, which you can download using the link below to the Anki website, or if you prefer I’ve added a csv with the same info to the Github link. It covers 283 defined terms across all the course notes.

Github: github.com/Lewis-Walsh/CP1_IFoA_glossary/blob/main/CP1_glossary_anki.csv
Anki: ankiweb.net/shared/info/2079220336

How the glossary was created

​Unfortunately, the core reading and combined materials pack are copyrighted, so while it's probably fine to create your own deck for personal use from this material, it didn’t feel appropriate for me to create a glossary I was putting out into the public domain based on this material. I decided to build my glossary around the past papers instead, here’s an outline of the process I followed:

1. Downloaded all the CA1 and CP1 past papers from the IFoA website.
2. Converted past papers from pdf format to markdown using PyMuPdf
3. Then got Claude to write a python script to loop through and pass each question for review individually via Ollama to a copy of Ministral-3 which was running locally.
4. Ministral was prompted to review the question being sent to it and return a list of any ‘actuarial, finance, or technical terms’ used in the question. I tested a few prompts and tweaked until I got answers I was happy with.
5. The Python script processed all 10 questions, across the 40 or so past papers (400 questions), and also all the questions in the paper 2, generally 1-2 per paper (another 80 or so questions). Collecting the technical terms and outputting the list as a csv.
6. Claude then reviewed the list to look for obvious gaps (e.g. when limit of a reinsurance contract was included, was the excess of a reinsurance contract included?)
7. Then Claude did another pass to remove all duplicates 
8. Then Claude did a final pass to review the list and add any terms which appeared to be missing based on a comparison to the IFoA CP1 syllabus
9. Claude then wrote short definitions for the terms, relying on public knowledge of the general terms. I reviewed samples of these initially, and then left Claude Code ticking away running batches until all the terms had been defined.
10. I then reviewed the list by hand myself to check for accuracy and completeness.

Why use the exam papers to generate the terms?

By building the glossary from the past papers, firstly, we're building the deck around what the exams are actually testing which is what we should care about when studying, but also it puts it firmly in fair-usage territory.

You might ask, why use Ministral at all?

The obvious way to approach this project is to just get Claude/ChatGPT/Gemini to run the whole thing. I quickly found however I was butting up against their usage limits. I was repeatedly hitting the usage limits on my pro plan, while barely making a dent in the papers I needed to process. This was because I was sending massive amounts text to Claude, lots of it redundant, for it to carry out a relatively simple and repetitive task that a less capable LLM could have managed. Because Ministral-3 was running locally (on my own GPU), I effectively have as much usage as I needed. It ran fairly quickly, but I could have for example if needed just left it running overnight. By outsourcing the high volume but fairly straightforward task to my local GPU, we neatly side stepped this problem.

As an aside, it’s also really interesting that this usage would effectively not have been possible (or at least would have taken weeks of compute) even 12 months ago . You can now have a pretty decent LLM running on a home gaming computer, completing tasks that previously would have been intractable or requiring specialised NLP. Maybe you could have tried to train a machine learning model to select terms from text by passing it large numbers of samples of questions and the terms it should return. Now you don't need to, all you need to do is download a 10GB file from the internet, run some open-source software (Ollama) to set it up (nothing complicated) and you’ve got an out of the box solution.

I offer tutoring for IFoA exams and actuarial modules. Details here www.lewiswalsh.net/tutoring.html
 
[1] https://gwern.net/spaced-repetition
[2] https://www.supermemo.com/en/blog/twenty-rules-of-formulating-knowledge

​​The models we are going to build are quite straightforward, and we’ll put both in the same Jupyter notebook (mainly because I still can’t figure out how to properly embed two notebooks into the same blog post…).

The modelling part 1 - sanity check

The first model validates the methodology we used in the previous post by running it against synthetic data. Just to briefly recap what we looked at, we analysed the change in volatility over time by tracking  5 different metrics, 5 and 10 year CoV, 5 and 10 year MAD, and CDF percentile over time. Intuitively, it certainly felt like if the volatility had reduced, that our methodology would have captured that change. But I wasn’t 100% comfortable until I ran the same tests on synthetic data in which the change in volatility had been baked in. 

What does this look like in practice? We are going to simulate a 30 year window of losses from a loss distribution (which I’ve picked to have a sensible shape, but the exact parameterisation doesn’t really matter) with a constant known increase in volatility across the 30 years. This time series is then simulated 5k times, we then apply the methods from the previous post of tracking the 5 metrics to each of the time series, and check on average whether we detect the volatility increase.

I sometimes run sanity checks like these, it’s not really a taught actuarial technique, you see it much more in machine learning, but I think when you are using methods that are new to you, or developing your own, it's rarely a bad idea.

The modelling part 2 - are the last 5 years unusual?

Then the next model we will build will attempt to answer the question of whether the last 5 years have been statistically unusual or not. I should probably say that I started to go down a route of effectively p-hacking myself before I had to reassess what I was doing.

My reasoning was – I’ve got this distribution of 30 years of on-levelled losses, why not run 5k simulations from this time series and then test what is the prob of having such a low 5 year rolling CV? I ran this, and it came out at like a 0.2% chance. And I thought wow that’s interesting, it really is very unusual. But then I realized I’d broken one of the cardinal rules of statistics which is that you can’t test a hypothesis against the same data you used to generate it.
​
Of course my model should tell me that the CV in last 5 years was unusually low, because I only ran the model because I thought it was in the first place. It’s the equivalent of being surprised to see 5 red cars in a row,  and then building a model to test the probability of seeing exactly 5 red cars. Really, to test if what I saw was unusual I need to model the probability of all unusual things involving multiple cars, which would be something more like seeing 4 or more cars of the same colour in a row, which is probably much more likely.

Having seen the nat cat data, I can’t then forget it. So what can we do? At a push I am comfortable testing very generic hypotheses, which is where I settled.

With that in mind, in the below model, we are going to look at the probability of not having any ‘large’ (defined as a year exceeding \$300bn on a revalued basis), in the last 5 years. I tested a few different thresholds, which I don't show below, and the answer was not very sensitive. I chose \$300bn as that is roughly a revalued 2017 (HIM) year, which to me feels 'large'.

It turns out when we run this test, the answer is that it is actually not very unusual to see this. While not definitive, it is one piece of evidence to suggest that the low volatility for the last 5 years is just not that remarkable. Because by inference, had we had a large loss in the last 5, the CoV would be much higher. It's partly the absence of large years which has caused the low CoV, and this absence is unremarkable. Due to concerns over p-hacking, it's really hard to say anything more concrete than this, but I would mention, if we just eyeball the bottom graph, it does seem to support the same conclusion.

​Conclusions
​
We saw from part 1 of the Jupyter notebook that our method of tracking CoV, MAD, and percentiles did work. So that’s good, sanity check passed.

And then in part 2, we saw that the probability of not having any $300bn+ years in the last 5 was 41%. Lower numbers are more surprising, so in this context 41% is not that remarkable. If we look at the final graph, it's hard not to find ourselves making judgements about the last 5 years, but I have to remind myself that it's a bit weak to make strong conclusions from just eye balling a graph. One of the takeaways I want to leave you with is that it's actually really hard to say anything with conviction about what has happened yet. The real test now, and this would be in line with best statistical practice, is to note the phenomenon as per our current data, and then see if it continues to occur in 2026 and 2027.


[1] sigma 1/2025: Natural catastrophes: insured losses on trend to USD 145 billion in 2025 | Swiss Re

Model 

To test the hypothesis, we are going to plot three volatility metrics over time using the on leveled data.

Metric 1 – 5 and 10 year rolling coefficient of variation (CoV). If volatility has been increasing, we should see an upward trend in this metric. I've used 5 and 10 year windows to see if the answer is sensitive to the choice of numbers of years. (Jumping ahead, this choice doesn't seem to matter too much.)

Metric 2 – 5 and 10 year rolling mean average deviation (MAD). MAD should be more robust to outliers, which is good as we know our data has a number of outsized years.

Metric 3 – We're going to fit a Lognormal to the whole series, and then plot where each year falls in percentile terms against this distribution. If volatility were constant, these percentiles should look random, but if we have increasing volatility, then we should see more extreme percentiles (both high and low) over time.

I’ve carried out the analysis in a Juypter notebook, so you can copy and paste or extend yourself. Like most actuaries, I do most of my work in Excel, but it’s just much easier to embed a notebook onto a website. Don't want anyone to take away the wrong impression that I'm always using python!

​Results

There you go, despite claims to the contrary, the Swiss Re data actually seems to show that the volatility of annual losses has been decreasing in the last 15 years or so. All three metrics tell a similar story, but looking at the CoV graphs, there is an upward trend from 1980 with volatility peaking around 2011 (with a CoV around 1), and there has been a downward trend in volatility since then, with a low around 0.2 in 2024. Actually not what I was expecting at all, but sometimes surprising results are the most interesting!

The first two graphs show broadly the same story, but I think it’s good to test using a couple of metrics, and also vary the number of years in the rolling window.

This is telling us that in some ways, the annual global insured losses are actually more predictable  than they were in previous years. Previously we could expect relatively clean years, followed by outsized events. What we've seen in the last 5 years is annual losses clustering around the 100bn-150bn range on a revalued basis rather than swinging wildly as they did in older years.

Why might volatility have decreased post-2011?

I don’t have a definite answer for you here.

A few possible effects are that these large events (Andrew, Katrina, etc.) really were quite extraordinary, and we’ve had some reversion to the mean since. (I'm planning to examine this in a future post).

It’s also possible that with more data we will look back and the effect we are seeing is just random noise, and there was somewhat of an upward trend in volatility.

It’s also possible that climate change has increased the volatility of weather, but that both good and bad weather (say extremely hot summers and cold winters) both lead to higher insurance losses on average. Meaning the increased volatility in weather just doesn't really feed through to increased volatility in annual losses.

Extensions

I think I’m going to do one more post on the Swiss Re data before moving on. Next time I’m planning to do two things, firstly, I want to back-test the above methods on synthetic data, to ensure that they do actually work (these seem sensible intutitively, but sometimes you never know until you actually test them). I’m then going to try to look at running a Bayesian analysis against the synthetic data, and examine given the historic volatility, what’s the likelihood that what we are seeing is just random variation vs.  an actual trend.

[1] https://www.aon.com/unitedkingdom/insights/weather-volatility-and-chronic-climate-risk.jsp
 
[2] https://www.bbc.co.uk/news/articles/c0ewe4p9128o
​​
[3] www.lewiswalsh.net/blog/impact-of-climate-change-loading-on-property-cat-insurance

Source: A pretty gnarly photo of the bobcat fire in Sep 2020, CA wildfire is definitely a region and peril in which climate change appears to be having an effect. @Eddiem360  https://upload.wikimedia.org/wikipedia/commons/c/c1/Bobcat_Fire%2C_Los_Angeles%2C_San_Gabriel_Mountains.jpg

Building a model

By ‘climate change loading’, my working definition is the additional % trend factor that needs to be added on top of ‘standard’ property claims inflation to capture the deterioration in weather related losses in recent years.
​
The starting point of the analysis is the same Swiss Re aggregate cat loss info, going back to 1970, which I used in the last post from their 01/2025 Sigma report. [1]

We are going to approach the problems in two complimentary ways.

Method 1

Method 1 takes the Swiss Re dataset, and looks at the difference between the increase in weather related losses and the increase in EQ/Tsunami losses, with the assumption that the difference between the two is primarily driven by climate change. That is, we will take EQ/Tsunami losses as our base line, and any increase in weather related losses on top of this we will assume are caused by climate change. We assume social inflation on EQ/Tsunami and weather related have been roughly equal so this should remove that as a possible cause, and the same with changes in insurance penetration over time.

Method 1 assumes: 

Weather inflation = EQ inflation + climate change inflation 

We can estimate the first two components, and the third will be the difference between the two
​
Method 2

Method 2 uses just the weather data, but this time we derive the total inflation in the data, and then subtract out monetary inflation and asset build up, with the assumption that what remains is due to climate change. Other include effects not stripped out, such as social inflation, changes in insurance penetration, may skew this, but it’s very hard to come up with robust estimates of these effects in order to remove them, and my working assumption would be that climate change is the single biggest driver of the residual inflation.

Method 2 assumes: 

Weather inflation = CPI inflation + real gdp growth + climate change inflation 

We can estimate the first three components, which will give us a view on the climate change component.
​
As a measure of monetary inflation, in line with Swiss Re, I have used US cpi because the single largest peril is US windstorm. For asset build up, I have used US real gdp growth, this feels a little weak, but is consistent with what I’ve seen from other models, and is hard to beat as an objective measure.

Below is a Jupyter notebook which we are going to use to build our two models, 

​Results
Summary table of results.

We see that using the variations of the two methods, but stripping out versions which appeared unstable to small changes, we've got a minimum of 3.3% and a maximum of 4.3%. I'd suspect we haven't fully captured the uncertainty in the estimate with our variations, so let's assign this method a range of about 3-5%.

So there we have it, our model is suggesting that in order to capture the effects of climate change, we should be adding something like an additional 3-5% trend to our historical losses. Slightly heavier than the 2-3% I've seen being used before, but not miles away.

Additional caveats/uncertainties (not already mentioned)​

• Just because this was the correct historic factor, does not mean it will continue to be the correct factor going forward
• Analysis is primarily driven by the effects of US windstorms, other climate change exposed perils may have a higher or lower loading than implied by this analysis
• Effects such as social inflation, or an increase in assets in exposed areas (e.g. east coast), relative to the rest of the US, and various other effects, may be skewing both methods
• I’ve combined all weather and non-weather perils together which may be masking changes within any given peril. May be worth trying to examine different weather perils separately, but then we end up with issues around having a sufficient amount of data to do something credible.

I used an LLM (Claude Sonnet 4.5) to edit and proof read this post, but all words were written by myself, and all ideas (good and bad) were my own.

[1] sigma 1/2025: Natural catastrophes: insured losses on trend to USD 145 billion in 2025 | Swiss Re

Firstly, let’s collect data on historic years. Helpfully Swiss Re provide data for this metric in their 01/2025 Sigma report [2]. 

​The above graph is taken from that report, and we can see that the losses are in 2024 dollar prices, but reading the fine print in the report tells us they have just revalued using US cpi. As the graph highlights, there is still a clear upwards trend in the data. This represents a number of factors; social inflation (i.e. the increase in inflation excess of CPI inflation), asset build up in exposed areas, and also probably an element of climate change.

Let’s get this data into a Jupyter notebook and proceed from there, and see if we can arrive at a similar value.

Conclusion
​
There we go, we were actually able to fairly easily arrive at a similar estimate of the 1-in-10 global nat cat value of $300bn by just leveraging Swiss Re's public data in a fairly transparent way.
​
​ 
[1] Baden-Baden: Swiss Re warns of $300bn cat year as geopolitical and civil unrest risks rise | Global Reinsurance
[2] sigma 1/2025: Natural catastrophes: insured losses on trend to USD 145 billion in 2025 | Swiss Re

​​The issue with the code is the html path has changed since the code was created, so you need to replace the source.txt file in the /config folder with the following. I've left in the old html path below but just commented them out, but they are not strictly needed any more.

# Configuration file for gistemp, describing the# location and form of all source datasets.## Nick Barnes, Climate Code Foundation, 2012-05-24# Avi Persin, Revision 2016-01-06# For the syntax and usage of this file, see## python tool/fetch.py --help.# GHCNv4 data# OLD = file: http://datadev.giss.nasa.gov/pub/gistemp/ghcnm.tavg.qcf.datfile: http://data.giss.nasa.gov/pub/gistemp/ghcnm.tavg.qcf.dat# ERRSTv5 data# OLD = bundle: http://datadev.giss.nasa.gov/pub/gistemp/SBBX.ERSSTv5.gzbundle: http://data.giss.nasa.gov/pub/gistemp/SBBX.ERSSTv5.gzmember: SBBX.ERSSTv5# station metadata# OLD = file: http://datadev.giss.nasa.gov/pub/gistemp/v4.invfile: http://data.giss.nasa.gov/pub/gistemp/v4.inv# Configuration for code to discard some suspect ('strange') data.# OLD = file: http://datadev.giss.nasa.gov/pub/gistemp/Ts.strange.v4.list.IN_fullfile: http://data.giss.nasa.gov/pub/gistemp/Ts.strange.v4.list.IN_full# brightness index data# OLD = file: http://datadev.giss.nasa.gov/pub/gistemp/wrld-rad.data.txtfile: http://data.giss.nasa.gov/pub/gistemp/wrld-rad.data.txt

​The first thing to note is that we are looking at the 2 parameter (or type 2) Pareto, and we are going to be following Klugman in using alpha and theta to represent our parameters. This is not universal usage though and Wikipedia for example uses alpha and sigma. The alpha parameter determines the tail weight, and a lower value of alpha gives us a heavier tailed distribution. Theta just determines the rest of the shape of the curve, but generally for a Pareto it's the alpha which is the most important value, particularly if we are projecting out into a part of the curve which is beyond our previous largest loss.

Klugman [2] gives us the domain on which the moments of a Pareto Type 2 distribution are defined, and looking at the formulas in the table below gives us the clue to the first problem :

Based on this table, we can see that the mean is only defined when alpha > 1, and the variance is only defined when alpha > 2. (which we can see when we insert k=1 or k=2 into the third formula)

Now why is this important? You might reason that for any given data, the sample mean and sample variance always exist and are always finite, so we will always be able to fit a well defined pareto to our data, no problem.

The issue is that for many situations, we expect an alpha value below 2, and we will never produce such a fitted distribution when using the method of moments. In fact, in certain situations we expect an alpha below 1, which we will definitely not produce. Therefore, even though we are using a heavy tailed distribution, we are limiting ourselves to only be able to generate alpha values which are likely to be too light.

What is a reasonable prior range for our alpha value to fall in? Fackler [3], for example talks about MTPL curves often having alpha values less than 2, and property cat severity curves having alpha values which are often below 1. And just to note, this is consistent with datasets I've modeled. So when fitting a Pareto using a method of moments to property cat data, we are almost guaranteeing ourselves a fit which is too light, and which is likely to lose us money if we were to rely on it.

We see in the final output that the median of the means is about 40% lower than the mean of the means. So 50% of samples are going to have a mean which is 40% or more lower than the mean for the underlying loss generation process. This is a big deal, and we are going to be massively underestimating our loss cost in these cases.

And then the variance is even more extreme, for our c value of 1.3, we should actually have an infinite variance, the mean is coming in around 20 million, so definitely exhibiting traits of being extremely big compared to the other values, the median on the other hand is a paltry 2k, much much smaller, and we are potentially going to be tricking ourselves into using a much too small alpha value here.

Here is the extract from the exam. I think the reason that its a popular exam question is that the algebra works quite nicely, and it requires you to show some understanding of what the moments of the distribution are. Plus in a written exam it would be way too fiddly to ask someone to attempt a maximum likelihood method instead.
​

ADC pricing

Suppose we are looking at an at-the-money ADC where carried reserves are \$​500m. To keep the maths simple, let’s suppose the reinsurer has completed their reserve review, and the best estimate reserve is also equal \$500m. If there’s a shortfall or surplus, the maths doesn’t change too much anyway. We’re also going to ignore investment returns for the time being.

We are going to model the distribution of ultimate reserves with a lognormal distribution, so we need to determine two parameters – $\mu$ and $\sigma$​​. We already set the mean of the distribution to \$​​500m, which gives us $\mu$, so we just need to determine the volatility. Let’s stick in 15% as our value for the CV for the time being, and revisit this part later (the CV pick ends up having an interesting effect, so let’s save that discussion for later)

Next up, we need to think about what a sensible ADC structure would be. This is an at-the-money, so we know the attachment, but we don’t know the limit. Ideally the cedant would like maximum capital relief, so one sensible limit is to buy up to the 1-in-200 percentile of the ultimate reserve. i.e. limit = (99.5th percentile – attach) & attach = mean
​
Here’s our summary table so far.

​And that’s all we need to put an expected loss cost against the contract. I wrote a quick Python script to do just that, and then ran it for a grid with mean running from \$​500m – 3bn, in 500m increments, and CV running in 5% increments from 5% - 25%. The final table then outputs the expected loss, expressed as a % of limit.

import numpy as npfrom scipy.stats import lognormfrom scipy.integrate import quadimport pandas as pdfrom math import expfrom math import logfrom math import sqrt

def integrand(x, excess, limit):    return min(limit, max(x - excess, 0)) * lognorm.pdf(x, s=sigma, scale=np.exp(mu))means = []cvs = []outputs = []for mean in [500,1000,1500,2000,2500,3000]:    for cv in [0.05,0.1,0.15,0.2,0.25]:                means.append(mean)        cvs.append(cv)                stddev = mean*cv        mu = log(mean/(sqrt(1+stddev **2/mean**2)))        sigma = sqrt(log(1+stddev**2/mean**2))        excess = mean        limit = lognorm.ppf(0.995, s=sigma, scale=np.exp(mu)) - mean        result, _ = quad(integrand, excess, excess+limit, args=(excess, limit))        outputs.append(result/limit)# Create DataFramedf = pd.DataFrame({    'Mean': means,    'Coefficient of Variation': cvs,    'Output': outputs})df_pivot = df.pivot(index='Mean', columns='Coefficient of Variation', values='Output')# Print the DataFrameprint(df_pivot)

Coefficient of Variation      0.05      0.10      0.15      0.20      0.25Mean                                                                      500                       0.140955  0.133088  0.125675  0.118723  0.1122291000                      0.140955  0.133088  0.125675  0.118723  0.1122291500                      0.140955  0.133088  0.125675  0.118723  0.1122292000                      0.140955  0.133088  0.125675  0.118723  0.1122292500                      0.140955  0.133088  0.125675  0.118723  0.1122293000                      0.140955  0.133088  0.125675  0.118723  0.112229

​Observation 1 - mean invariance

The pricing is invariant to changes in the mean – i.e. assuming we update all the other values in line with changes to the mean, for a given CV, the loss on line does not change at all. We can see that from the table by the fact that the columns all have identical values for a given CV. Perhaps not too surprising? Effectively we are saying that we would charge twice as much for a transaction which is twice the size.

​Observation 2 - cv invariance?
​
The more interesting observation, is that actually the loss on line does not really change too much as the coefficient of variation changes, and that it actually reduces as the CV increases... this was more surprising to me. When the CV increases from 5% to 25%, which is a factor of 5, and represents the difference between a fairly stable book at 5% CV, to a fairly volatile book at 25% CV, the loss on line only changes by less then 3 percentage points.

Now why is this surprising, and why does it happen?

The reason we might expect the loss on line to increase rather than decrease as the CV goes up is that we are offering non-linear protection on a more volatile book, so surely this should cost more? But actually what happens is that as the CV increases, the limit that a client is likely buy increases due to the 99.5th percentile moving out, and this increase in limit more than offsets the increase in loss cost due to increased volatility.

Analytical approach

We figured out the above using a numerical integration package in python, but we could have also attempted to approach it analytically, by showing that the expected loss on line for the ADC, as expressed by the following integral, is a (slowly) decreasing function of the CV. 

The proxy statement

First step, we need to figure out the precise details of the package. Various news articles give the basic outline as 'Musk would be awarded 1% of the outstanding shares if the market cap got above /$100bn, and then an additional 1% of the shares for each additional of /$50bn market cap, up to a max of 12% of the shares'. i.e. If the market cap only grew to /$110bn, he would have just got 1%, but if it grew to /$650bn, then he gets the full 12%.

The proxy statement [4] explains in full detail, and the specific mechanics are that Musk was to be awarded vanilla call options with a exercise price set to be the current stock price in 2018. Based on the informal description in various news sources, I initially thought that he was going to just be awarded that number of shares, rather than being given a call option (i.e. an asset-or-nothing call option). If he has just been awarded the shares, in the most optimistic scenario he would effectively be paid 12%*/$650bn = /$78bn, whereas with the vanilla call options he would effectively be paid 12%*(/$650bn - /$57bn) = /$63bn instead. So it's important we value these as vanilla call options, not as asset-or-nothing call options.

Another adjustment then needs to account for the effect of dilution, even though Musk could be awarded up to 12% of shares, this would be closer to an effective 10% of the company once dilution is accounted for. The post-trial opinion from Judge McCormick [5] contains values for these (as far as I’m aware I don’t think you could calculate them just based on public info). I’ve pasted the relevant section below.

To sense check this, the proxy statement gives a value of /$56bn if the market cap hits /$650bn. We can recreate this using the following calc:

9.6%*(/$650bn-/$57bn) = /$57bn, which is close enough.

No upper limit
​
Another point to make is that there is no upper limit to what these options might be worth. If Tesla’s share price had hit /$2trillion, then the options would have been worth /$186bn! I found some articles from the time, for example this one in the Guardian [6], which seem to imply that the maximum possible pay out was /$56bn, which is incorrect, this is the payout when the final tranche of options are released, which is the highest value mentioned in the proxy statement, but the sky is the limit with these things.

Okay, so now let’s actually value the stock options, I used a Black-Scholes model in a Spreadsheet to price the 12 tranches of options (and I know Black-Scholes doesn’t really work, and caused the 2008 financial crisis, but I’m not going to be trading trillions of dollars of derivatives based on it, and it should work reasonably well as a first approximation.)

Here is a screenshot of the model, but you can also download it from the following link:
github.com/Lewis-Walsh/Valuation_of_2018_Musk_pay_deal

​Based on my model, the options were worth around /$1.8bn at the time they were awarded. Given this might have been the only compensation that Musk would have received in 10 years, we should then spread the cost of the options across the 10 years, so we could say they were worth /$180m pa. There’s probably an argument for using a period shorter than 10 years, as really this should be the average duration of the options given they might be exercised early, but let’s just keep the maths simple and use 10 years.

So this means, that Tesla could have purchased call options in the open market which replicated the payout pattern of those granted to Musk for /$1.8bn plus some sort of margin, and Musk's mean expected compensation per year is around /$180m.

Benchmarking

Now let’s benchmark the /$180m against what other CEOs are being paid. The highest paid CEOs in 2022 were the following (I used 2022 as it's approx. 50% through the contract length, and we want to recognize the impact of some inflation across the 10 years)
​

/$180m puts Musk basically joint 3rd highest paid CEO when compared to 2022 remuneration. This definitely benchmarks as a high package, but certainly not anything unprecedented in generosity. 

Conclusions

Just to preempt possible comments on the above analysis, I'm acutely aware that there are many considerations I haven't incorporated, e.g. should anyway ever get paid /$56bn? Was this package really needed to incentivise  Musk given he already have a material equity stake, did Tesla appropriately inform shareholders of the process which was used to arrive at the pay deal, etc. etc. But I do think the above perspective on the deal, thinking about what we would have thought before we knew how things turned out, is an important perspective when thinking about fairness. 

​[1] https://www.theguardian.com/technology/2024/jan/30/elon-musk-tesla-pay-package-too-much-judge-rules
[2] https://www.bbc.co.uk/news/business-68150306
[3] https://www.bloomberg.com/opinion/articles/2024-01-31/elon-musk-is-overpaid
[4] https://www.sec.gov/Archives/edgar/data//1318605/000119312518035345/d524719ddef14a.htm
[5] https://courts.delaware.gov/Opinions/Download.aspx?id=359340
[6] https://www.theguardian.com/technology/2018/jan/23/elon-musk-aiming-for-worlds-biggest-bonus-40bn

Maybe it's obvious to you straight away, maybe not. If we look at age-to-age factors though I think the issue jumps out in a much clearer way.
​

When looking at these factors, we can see that something weird is happening in the 2005 year. It looks like maybe a case reserve was put up and then taken down in the next development period. Ideally we don't want to incorporate this up and down effect when projecting the more recent years to ultimate. You might think to yourself - given the chain ladder is multiplicative, it doesn't much matter having an up and then a down as the two will cancel each other out when the two factors are multiplied together, i.e. 1.16 *0.86 = 1.

A problem does creep in here though because when we use the chain ladder method, we don't just multiply the individual factors. The down factor (0.86), is given a greater weighting in the weighted average calc when determining the incremental ldf than the up factor (1.16). This is partly due to there being an additional year of data in the upper calc, but also particularly acute in this example, as the additional year that drops off is outsized compared to the other years - it's about 4 times bigger than the average of the other years. So whereas the 1.16 is given 17% weighting in the incremental ldf calc, the 0.86 is given 34% weighting, which means the two definitely do not cancel each other out.

In fact, a 'standard' chain ladder is nothing more than a weighted average of the individual age-to-age factors, weighted by incurred loss. There's some reasons to prefer this approach as opposed to using a straight average or something else, but there's certainly nothing wrong with deviating from the weighted average if the method is not performing correctly.

By including this feature of our data, the cml ldf for 2010 ends up being a factor of 0.95. By correcting for this feature, the ldf to ult for 2010 ends up only being 0.98. 

Let the data speak

I think there's an increased awareness in actuarial modelling, possibly driven by the influence of machine learning, of not making arbitrary adjustments to our data in an attempt to correct perceived issues, but instead just letting the data 'speak for itself'. I think the above is a clear example of a case where this approach of just letting the data speak for itself is probably not serving us well, as our model is simply not working as intended.

Here I have specifically used a LogN distribution, and I compare the ruin probability I derive using a monte carlo simulation, with the value from the Cramer-Lundberg theorem, to understand the extent to which it under-estimates the ruin probability.

import numpy as npimport timeimport matplotlib.pyplot as pltimport math

# Set parametersmean_poisson = 1mean_lognormal = 1std_dev_lognormal = 1.5u = 15c = 1.1num_simulations = 10000max_poisson_samples = 500# Calculate parameters mu and sigmamu = np.log(mean_lognormal**2 / np.sqrt(std_dev_lognormal**2 + mean_lognormal**2))sigma = np.sqrt(np.log(1 + std_dev_lognormal**2 / mean_lognormal**2))

# Initialize arrays to record resultsresults = []poisson_sims_before_stop = []# Start timing for simulationsstart_time_simulations = time.time()for _ in range(num_simulations):    t = 0    S_t = 0    poisson_sims = 0        while t < max_poisson_samples:        poisson_sample = np.random.poisson(mean_poisson)        lognormal_samples = np.random.lognormal(mu, sigma, poisson_sample)        S_t += np.sum(lognormal_samples)                f_t = u + c*t - S_t                if f_t < 0:            results.append(1)            poisson_sims_before_stop.append(poisson_sims)            break                t += 1        poisson_sims += 1        if t == max_poisson_samples:        results.append(0)        poisson_sims_before_stop.append(poisson_sims)

# Filter out values less than max_poisson_samples (500)filtered_poisson_sims = [sims for sims in poisson_sims_before_stop if sims < max_poisson_samples]# Calculate average number of Poisson simulations before stoppingavg_poisson_sims = np.mean(filtered_poisson_sims)#Calculate the ruin probabilityruin_prob = len(filtered_poisson_sims) / len(poisson_sims_before_stop)# Calculate total execution time in minutes and secondsend_time_total = time.time()execution_time_total = end_time_total - start_time_simulationsminutes_total = int(execution_time_total // 60)seconds_total = int(execution_time_total % 60)

print(f"Ruin probability - monte carlo")print(ruin_prob)print(f"Ruin probability - Cramer-Lundberg")theta = c/(mean_poisson*mean_lognormal)-1print(1/(1+theta)*math.exp((-1*theta*u)/(1+theta)))# Create a histogram to visualize the distributionplt.hist(filtered_poisson_sims, bins=30, density=True, alpha=0.6, color='g', edgecolor='black')plt.xlabel('Number of Poisson simulations before stopping')plt.ylabel('Frequency')plt.title('Distribution of Poisson Simulations Before Stopping')plt.show()

Ruin probability - monte carlo0.3703Ruin probability - Cramer-Lundberg0.23248105446645487

We see the output from the Monte Carlo and Cramer-Lundberg (CL) at the bottom. The monte carlo is our 'correct' value and gives us a 37% chance of ruin, whereas the CL method only thinks there is a 23% chance of ruin. So, by using the CL method, we'd be quite materially underestimating the risk of ruin.

Let’s start by looking at exactly what the chart is showing - in this context, a ‘nuclear verdict’ is defined as a US corporate civil verdict, which exceeds a fixed dollar value of $10m. You should hopefully be aware (for example see the paper by Brazauskas et al. (2009)) [1] that as a measure of trend, examining the increase in average claim excess of a fixed dollar threshold does not accurately reflect the underlying trend. It can be geared so as to cause a ‘greater than underlying’ trend, and it can also be less than the underlying trend (or even give a value of 0) depending on the exact shape of the distribution. For example, if our underlying trend is 8%, then the increase in average claim excess $10m may present itself in the data as 12%, as 4%, or even as 0% depending on the exact shape of the data. And this is not a ‘lack of data’ issue, i.e. the real answer will converge over time with more data, there is an inherent bias in the methodology.

The intuition behind the phenomenon is that we might have a whole bunch of losses just under the threshold, which when inflated are pushed to just above the threshold, and thereby adding a whole load of new small claims, bringing down the average of the losses above the threshold.

To be exact, the paper by Brazauskas et al. referenced above, shows that analysing the *mean* excess value does not accurately reflect trend, but our chart uses the *median* excess value. The obvious follow up question is does the median also have the same issue as the mean? Intuitively, the same arguments relating to verdicts just under the threshold seems to apply, but let’s run a quick python script to check.

The following script runs 50k monte carlo simulations, each simulation generates values from a lognormal distribution. We then inflate the simulated values by 5% pa, and then restrict ourselves to just the 'nuclear' verdicts, i.e. those above the threshold of 10m. Finally we analyse the median of these nuclear verdicts and assess the trend in the median over time. Here's our Python code:

import numpy as npimport pandas as pdimport scipy.stats as scipyfrom math import expfrom math import logfrom math import sqrtfrom scipy.stats import lognormfrom scipy.stats import poissonfrom scipy.stats import linregress

Distmean = 10000000.0DistStdDev = Distmean*1.5AverageFreq = 100years = 10ExposureGrowth = 0.0Mu = log(Distmean/(sqrt(1+DistStdDev**2/Distmean**2)))Sigma = sqrt(log(1+DistStdDev**2/Distmean**2))LLThreshold = 1e7Inflation = 0.05s = Sigmascale= exp(Mu)

MedianLL = []AllLnOutput = []for sim in range(50000):    SimOutputFGU = []    SimOutputLL = []    year = 0    Frequency= []    for year in range(years):        FrequencyInc = poisson.rvs(AverageFreq*(1+ExposureGrowth)**year,size = 1)        Frequency.append(FrequencyInc)        r = lognorm.rvs(s,scale = scale, size = FrequencyInc[0])        r = np.multiply(r,(1+Inflation)**year)        r = np.sort(r)[::-1]        r_LLOnly = r[(r>= LLThreshold)]        SimOutputFGU.append(np.transpose(r))        SimOutputLL.append(np.transpose(r_LLOnly))            SimOutputFGU = pd.DataFrame(SimOutputFGU).transpose()    SimOutputLL = pd.DataFrame(SimOutputLL).transpose()        a = np.log(SimOutputLL.median())    AllLnOutput.append(a)    b = linregress(a.index,a).slope    MedianLL.append(b)AllLnOutputdf = pd.DataFrame(AllLnOutput)dfMedianLL = pd.DataFrame(MedianLL)dfMedianLL['Exp-1'] = np.exp(dfMedianLL[0]) -1print(np.mean(dfMedianLL['Exp-1']))print(np.std(dfMedianLL['Exp-1']))

0.014141991399513090.013860637023388517

The value of 1.4% we have outputted at the bottom is the average trend in the median of the nuclear verdicts. We can see that based on this analysis, even though we know that the underlying data has a trend of 5%, the median of the values greater than 10m, only increases by 1.4% pa.

What could we have done instead? We could have analysed the median of the top X verdicts, where X could for example be 10, 20, 50, 100. For a write up of this method, see the following:
www.lewiswalsh.net/blog/backtesting-inflation-modelling-median-of-top-x-losses

They were used by IBNR Weekly [2], Insurance Insider [3], Munich Re [4], Lockton Re [5], and those were just the ones I could remember or which I found with a 5 minute search. The graphs themselves are originally from a report on US social inflation by an organisation called Marathon Strategies (MS for short in the rest of the post) [1].

It's an interesting way of analyzing social inflation, so I recreated their analysis, which lead me to realize MS may have been a little creative in how they’ve presented the data, let me explain.

Recreating the graphs

Firstly, can we recreate the analysis? 

According MS’s report, the data is based on “The National Law Review, LexisNexis, various state and federal court records databases, legal journals, white papers, and media reports, among other sources”. 

In Blue Peter fashion, I also had a similar dataset of reported US verdicts. I sorted this dataset by year, filtered to just verdicts greater than \$10m, and excluded any verdicts which were not involving a corporate client. I’ve put my version, and MS’s version in the same graph below so you can see the similarity.

As a first step this is good, and everything looks as it should! My data is in orange, and MS's is in blue.

MS have based their analysis on data which is ultimately sourced from public court info, so we should expect to get something similar when trying to recreate it. For full disclosure, the only manual adjustment I made was to exclude the \$300bn verdict from Texas in 2021, which was so outsized it was completely throwing off my data. I’m assuming MS did the same as they also don't have a \$300bn spike in that year.

Now what about the creativity on the part of MS I mentioned earlier? My question - is there anything to the fact that MS have used 8 years of data to create their graph? What happens if we include 9 years instead? Since I've got the underlying data and have recreated their analysis, I can answer that question, here’s the graph:

​Well that’s a different story! We’ve got a huge year in 2014, and our graph no longer supports the narrative of exponentially increasing awards from 2015 onwards. Firstly, why is 2014 so high? It turns out 2014 was largely driven by a \$25bn tobacco related verdict. Let’s make a couple of adjustments, let's exclude the tobacco verdict as an outlier, and also bump our window up to a more robust 10 years. Here's the updated graph.

The point at which MS decided to start the graph, 2015, was the joint-lowest year in the 10 year window. The only year at the same level was a covid year. Of course it’s going to look like a dramatic increase when you are making design choices like that.
​
Just for ease of comparison, here is the graph presented by MS, side by side, with my 10 year graph based on the same data:

​But what about Social Inflation?

Does that mean that there is no such thing as social inflation? Definitely not. Social inflation is very much present in emerging loss data we're all seeing. It's just the specific presentation of this graph that I'm disputing.
​
Conclusions

I guess the moral of the story, is be careful taking reports at face value, when you are not able to kick the tires yourself. And also, pay attention to who wrote the report.

MS are described as “…an independent PR firm ... We specialize in reputation management, communications, crisis and issues management, creative content, and digital strategy.” [6]. They are very much *not* an academic research outfit. They appear to have done exactly what you would expect such a company to do - they’ve come up with interesting research, using a sensible methodology, and moreover the analysis appears to have been done correctly based on my replication. What they have done on top of that is be quite creative with how they’ve presented the data.

If you were looking for a company to hire to do PR communication based on quant research for you, this is exactly what you are looking for! Analysis which is technically correct, but which works in the grey area a bit to tell the story you want told. Would they have made such a splash in the insurance press, had they gone with the possibly more ‘representative of ground truth’ chart which I created using the 10 year view? Probably not. 
 
Should Insurance Insider, IBNR weekly, etc. have uncritically copy and pasted the graphs in their reporting? The answer to that is also probably not.
 
[1] Corporate Verdicts go Thermonuclear - https://marathonstrategies.com/wp-content/uploads/2023/03/Corporate-Verdicts-Go-Thermonuclear-0313.pdf
[2] IBNR Weekly #41, 2023 - https://www.dowling.com/ibnr_weekly.htm#
[3] Insider P&C, 25th April  2023 - https://www.insidepandc.com/article/2bkw885xqkgueh59td91c/commercial-lines/nuclear-verdict-fears-lead-to-caution-as-excess-casualty-rate-rises-taper
[4] https://www.munichre.com/en/company/media-relations/media-information-and-corporate-news/media-information/2023/media-information-2023-09-10.html#:~:text=Social%20inflation%20in%20the%20US,US%24%2018.3bn%20in%202022.
[5] https://global.lockton.com/us/en/news-insights/why-are-liability-rates-continuing-to-rise
[6] https://marathonstrategies.com/

Here is our python code:

import numpy as npimport pandas as pdimport scipy.stats as scipyfrom math import expfrom math import logfrom math import sqrtfrom scipy.stats import lognormfrom scipy.stats import poissonfrom scipy.stats import linregressimport matplotlib.pyplot as plt

Distmean = 1000000.0DistStdDev = Distmean*1.5AverageFreq = 100years = 20ExposureGrowth = 0.0Mu = log(Distmean/(sqrt(1+DistStdDev**2/Distmean**2)))Sigma = sqrt(log(1+DistStdDev**2/Distmean**2))LLThreshold = 1e6Inflation = 0.05s = Sigmascale = exp(Mu)MedianTop10Method = []AllLnOutput = []

for sim in range(10000):    SimOutputLL = []    year = 0    Frequency= []    for year in range(years):        FrequencyInc = poisson.rvs(AverageFreq*(1+ExposureGrowth)**year,size = 1)        Frequency.append(FrequencyInc)        r = lognorm.rvs(s,scale = scale, size = FrequencyInc[0])        r = np.multiply(r,(1+Inflation)**year)        r = np.sort(r)[::-1]        r_LLOnly = r[(r>= LLThreshold)]        SimOutputLL.append(np.transpose(r_LLOnly))            SimOutputLL = pd.DataFrame(SimOutputLL).transpose()        AllLnOutputSim = []    MedianTop10MethodSim = []    for iRow in range(1,21):        a = np.log(SimOutputLL.iloc[iRow])        AllLnOutputSim.append(a)        b = linregress(a.index,a).slope        MedianTop10MethodSim.append(b)    AllLnOutput.append(AllLnOutputSim)    MedianTop10Method.append(MedianTop10MethodSim)    AllLnOutputdf = pd.DataFrame(AllLnOutput)OutputMean = []OutputStdDev = []dfMedianTop10Method= pd.DataFrame(MedianTop10Method)for iRow in range(0,20):    OutputMean.append(np.mean(np.exp(dfMedianTop10Method[iRow]) -1))    OutputStdDev.append(np.std(np.exp(dfMedianTop10Method[iRow]) -1))    print(OutputMean)print(OutputStdDev)plt.plot(OutputStdDev)plt.xlabel('Nth value to use')plt.ylabel('Standard Deviation')plt.title('Standard Deviation vs Nth large loss')

[0.050145087623911413, 0.050114063936035846, 0.05008171646318982, 0.05004295735703755, 0.050032712657938, 0.050014427471083624, 0.05001184154389972, 0.05002322239170273, 0.05000059530333641, 0.04998014653293243, 0.05002513041036643, 0.049987258053581535, 0.049978122421359926, 0.04999577129950346, 0.04997788849739706, 0.04992582226827509, 0.04988217239699916, 0.049813271987513466, 0.0497039041388662, 0.04951880036014647][0.013745415886517658, 0.011764812681484629, 0.010643862238651042, 0.009893413918701141, 0.00929811434851868, 0.008829621751760679, 0.00852287511743378, 0.00827148148117868, 0.008059106267070865, 0.007896990729065285, 0.0077614481203254, 0.007619604123042998, 0.007507459106587108, 0.00741696242472465, 0.007320604159513552, 0.007224126566330418, 0.0071451595403478, 0.0070669619394482614, 0.007013056254295168, 0.0069269062482146026]

Text(0.5, 1.0, 'Standard Deviation vs Nth large loss')

Let's check this graph against our previous runs. We know that when looking at the 5th largest loss, i.e. the median of the top 10, we had a standard deviation of around 0.9%. We can see in the above graph, when reading off 5 from the x-axis, that this matches. So far so good.

What is the graph telling us? It's saying that as we increase the value of N, we get a decrease in the standard deviation of our estimate. It's initially quite a big reduction, going from the largest loss by year against the 5th largest loss results in a 35% reduction in standard deviation, but then it levels off as we continue. Going from the 5th largest loss to the 10 largest loss only results in an approx. 15% reduction.

This is good info to know! It means that we can immediately improve our estimate of claims inflation, just by using a lower attachment. You sometimes see people comparing the 'largest inflated loss' by year as a sense check on their inflation rate, but what this chart is telling us is actually that's the most volatile metric you can pick out of this range, and even the 2nd largest loss would be an improvement.

So why do we have a lower standard deviation of estimate when we use a higher Nth value? I suspect this is driven by the lower volatility inherent in the metric. i.e. the 10th largest claim in a dataset, should have lower volatility than the 9th largest claim, and the 8th largest claim, etc.. So as we move down the distribution, we are implicitly reducing the noise in our data, and that means our estimate will be more accurate.

Next time I'm going to examine this phenomenon further. It would be really cool if we could somehow link this improved accuracy, with the results we obtain previously around the improvement in accuracy related to the reduction in volatility of the ground-up loss distribution.