I’ll share my approach for sure
3 Likes
I ended up just using elastic net GLMs and weighting together an all-coverage GLM with by-coverage GLMs for all coverages, it ended up being about 50/50 for each one except Max which just used the all-coverage model. Some important features that I engineered:
(To create these features on year 5 data I saved the training set within the model object and appended it within the predict function , then deleted the training observations after the features were made. )
When you group by policy id, if the number of unique pol pay freq is > 1 it correlates with loss potential.
These people had some instability in their financial situation that seems correlated with loss potential.
When you group by policy id, if the number of unique town surface area > 1 it also correlates with loss potential.
My reasoning for this was that if someone switched the town they live in then they’d be at greater risk due to being less familiar with the area they are driving in.
I used pol_no_claims_discount like this to create an indicator for losses in the past 2 years:
x_clean = x_clean %>% arrange(id_policy,year)
if(num_years > 2){
for(i in 3:num_years){
df = x_clean[x_clean$year == i | x_clean$year == i - 2,]
df = df %>% group_by(id_policy) %>% mutate(first_pd = first(pol_no_claims_discount),
last_pd = last(pol_no_claims_discount)) %>% mutate(diff2 = last_pd - first_pd)
x_clean[x_clean$year == i,]$diff2 = df[df$year == i,]$diff2
}
}
x_clean$ind2 = x_clean$diff2 > 0, then ind2 goes into GLM.
In practice, we know that geography correlates strongly with socioeconomic factors like credit score which indicate loss potential, so I thought the best way to deal with this was to treat town surface area as categorical and assume that there are not very many unique towns with the same surface area. I don’t think this is fully true since some towns had really different population counts, but overall it seemed to work and I couldn’t group by town surface area and population because population changes over time for a given town surface area. So:
I treated town surface area as categorical and created clusters with similar frequences which had enough credibility to be stable across folds and also across an out-of-time sample.
Since Max was composed of many claim types, I created clusters based on severity by town surface area, the idea being that some areas would have more theft, some would have more windshield damage, etc.
I created clusters of vh_make_model and also of town_surface_area based on the residuals of my initial modeling. I also tried using generalized linear mixed models but no luck with that.
Two-step modeling like this with residuals is common in practice and is recommended for territorial modeling.
Since pol_no_claims_discount has a floor at 0, an indicator for pol_no_claims_discount == 0 is very good since the nature of that value is distinct. Also, this indicator interacted with drv_age1 is very good, my reasoning being that younger people who have a value of 0 have never been in a crash at all in their lives, and that this is more meaningful than an older person who may have been in one but had enough time for it to go down. This variable was really satisfying because my reasoning perfectly aligned with my fitting plot when I made it.
Other than these features I have listed, I fit a few variables using splines while viewing predicted vs. actual plots and modeled each gender separately for age. I modeled the interaction mentioned above using a spline to capture the favorable lower ages,
The weirdest feature I made that worked although wasn’t too strong was made like this:
By town surface area, create a dummy variable for each vh_make_model and get the average value of each one, then use PCA on these ~4000 columns to reduce the dimension. The idea behind this is that it captures the composition of vehicles by area which may tell you something about the region.
Another weird one that I ended up using was whether or not a risk owned the most popular vehicle for the area.
x_clean = x_clean %>% group_by(town_surface_area) %>% mutate(most_popular_vehicle = names(which.max(table(vh_make_model)))) %>% mutate(has_most_popular = vh_make_model == most_popular_vehicle)
I used 5-fold cross validation and also did out-of-time validation using years <=3 to predict year 4 and using years <= 2 to predict years 3 and 4.
For my pricing I made some underwriting rules like:
I do not insure Quarterly (meaning I multiply their premium by 10), AllTrips, risks who have a male secondary drive for coverages Max or Med 2, anyone who switched towns or payment plans ( even if one of them wasn’t quarterly), I made a large loss model for over 10k and anyone in the top 1% probability isn’t insured, and anyone with certain vh_make_models which had a really high percentage of excess claims, or people in certain towns that had really high % of excess claims. These last two were a bit judgemental because some of the groups clearly lacked the credibility to say they have high excess potential, but I didn’t want to take the chance.
I didn’t try to skim the cream on any high risk segment, but it is reasonable that an insurer could charge these risks appropriately and make a profit while competing for them. Did any of you try and compete for all trips or Quarterly with a really high risk load?
Finally I varied my profit loading by coverage and went with this in the end:
Max - 1.55
Min - 1.45
Med1 - 1.4
Med2 - 1.45
Good luck to all!
7 Likes
I would like to express my sincere thanks to the organisers. This competition for me is a game and I love game theory.
Here is my approach.
Machine model: Very simple
- Features: All features as they are except for “vh_make_model” variable. For this feature, I use OOF target encoding.
- Frequency model: RandomForestClassifier
- Severity models: 2 GradientBoostingRegressor models with quantile loss 0.2 and 0.8
- Claim = Frequency * (Severity 0.2 + Severity 0.8) / 2
Pricing strategy: This part is the one on which I spent most of my time.
Price = a * Claim + b
I did not do any simulations but changed these 2 elements (a, b) very single week. For week 10, I was at the 5th position, a = 1.04 and b = 100.
I started with 1, 10, 50, 100 but the lower b is the less profitable I am. For the final round a = 1.05 and b = 100. Hope that the best is to sell expensive. 
4 Likes
Thank you for sharing your ideas! It is very enlightening and for me this is the the most important aspect of this competition.
Here are some of my approaches:
Feature engineering
Just one thing I haven’t seen being discussed yet: I used kinetic energy (proportional to mass * velocity^2) which proved to give some gain in gradient boosting models. The idea being that this should correlate to the damage a car may cause.
Pricing
I went with a NN model that maximizes profit w.r.t. price increase in the form
profit(price increase) = (expected claim + price increase) * (1-probability of winning a contract)
Obviously, I had to make assumptions about the “price elasticity” = (1-probability of winning a contract) part of the equation.
I was surprised how well this model took care of assigning higher price increases (relative to expected claim amount) for policies with lower claim probabilities. Meaning that if two policies have the same expected claim amount but one of them has a lower claim probability (and thus higher severity) - that policy deserves a higher price increase as the variance is higher.
Unfortunately, I joined somewhat late and it took weeks 7 and 8 before I learned that the average price loading has to be some 20-40% in order to make profit.
Good luck to all of you!
3 Likes
When the differece in RMSE between the best claims model and the default one is not very being big i figured a claims model with a reasonably ok RMSE would probably be good enough.
My pricing strategy was based around the winners curse. I fitted a large number of xgboost models throwing out parts of the data to get an idea of the parameter error in the model. I got the average of the models and applied a loading depending on the standard deviation of the estimates each model produced for a policy, so that the policies with the highest parameter uncertainty got the highest price. I was hoping this would mean i would be more competitve for the policies producing the lowest parameter error, so that if i won them there was an increased chance the model estimate was more accurate and the profit is more certain.
I also did some underwriting. I identified policies at high risk of having large claims, and other high risk categories, and deliberatly gave them a very high price to make sure i didn’t write them.
I tried some price optimising, looking at market shares, profitability and how i changed my prices over time to guesstimate the optimal market share, and appropriate level of profit loading. I guesstimated a loss ratio range of 85-105% for my final submission depending on the claims, probably not good enough to win, but at least i learnt quite alot along the way.
Best of luck everyone!
3 Likes
What seems to have worked for me is the binning and capping of numerical variables usually in 10 approximately equal buckets. I didn’t want the model to overfit on small portion of the data. (split on top_speed 175 and then a split on top speed 177. Which would mean basically one hot encoding the speed 176).
I also created indicators variables for the 20 most popular cars. I wasn’t sure how to do target encoding without overfitting on the make_model with not a lot of exposure.
I created a indicator variable for weight = 0. Not sure what those were but they were behaving differently.
For the final week, at the cost of worsening my RMSE a bit on the public leaderboard, I included real claim_count and yrs_since_last_claim features (by opposition to claim discount which is not affected by all claims). Fingers crossed that this will provide an edge. It was quite predictive, however will only be available for ~60% of the final dataset. And the average prediction for those with 0 (which would be the case for the ~40% new in the final dataset) was not decreased by too much… The future will tell us.
Since I was first in the week 10 leaderboard, I decided not to touch the pricing layer. Didn’t want to jinx it.
2 Likes
That is smart, it for sure can help decrease some instability in the profit. I clearly didn’t spend enough time in those analysis.
1 Like
in OP, @simon_coulombe said:
I didnt create any variable dependend on the previous years, because (to this day) I still don’t know if we get years 1-5 for “new business” for the final leaderboard or just year 5 data. I assume it’s only year 5
Hmmm, good point. I assumed we would be getting the history.
The RMSE calculation is pretty clear that it does include it, however the final evaluation is more ambiguous…
The final test dataset, where the final evaluation takes place, includes 100K policies for the 5th year (100K rows). To simulate a real insurance company, your training data will contain the history for some of these policies, while others will be entirely new to you.
(Emphasis mine)
Given that RMSE was clear, and this bold phrase in the final dataset, I expected we’d get historical data points.
I’d like if the organizers can clarify this?
2 Likes
There’s been lots of talk where they said this would be to represent that an insurer gets renewals and new business where you don’t know the history. We’ll see
1 Like
Thanks for everyone sharing their approach!
Mine:
Feature
- Similar to Simon I have a vh_current_value which is exponentially decayed yearly with factor 0.2 and a floor value of 500
- Claim history:
- Aggregated total claim count, total claim amount and years from last claim (10 if no claims before)
- Change in no claim discount, number of years with no claim discount increased
- Interaction variables (not all but some)
- Binning (Good for GLM as it is quite sensitive to outliers)
- I dropped the vh_make_model as I think the vehicle information is mostly reflected by vh_value, vh_weights etc., the noise-to-information ratio is too high for that
- I grouped Med1 with Med2 as they are very similar
- Population per town surface area ratio
- Some log-transform / power transform of numerical variables
I use same feature sets for large-claim detection model and claim estimation model.
Large Claim detection model:
A XGBoost and Logistic regression model to predict whether a claim would be >3k.
Claim estimation model:
I stacked 7 base models using a Tweedie GLM as the meta-learner under 5 fold CV.
Base models:
- Tweedie GLM
- Light GBM
- DeepForest
- XGBoost
- CatBoost
- Neural Network with Tweedie deviance as loss function
- A neural network with log-normal distribution likelihood as loss function (learning the mu and sigma of the loss)
Pricing
Price = (1 + loading) * (estimated claim) + fixed_loading
If predicted to be large claim, loading = 1
If not: loading = 0.15
fixed_loading = 5
Since I filter out most of the predicted large-claim policies, my average premium is quite low (~65). So the estimated profit ratio is about 15% + (5/65) = ~22%.
4 Likes
Right, but for those policies that we know, question is:
are we being fed the 1-5 years in the preprocess function, or are we only given year 5.
1 Like
Just to clarify this one, you are only given year 5. The test data will only include 100K rows all with year = 5.
If we run into errors because of this we’ll let you know!
4 Likes
Hmm, bugger! I assumed we’d get access to the previous 4 years, akin to the RMSE leaderboard.
I played it safe and included a csv with the number of claims per id_policy (https://github.com/SimonCoulombe/aicrowd_insurancepricing_last_week/blob/main/prod/n_claim_year1_to_year4.csv)
2 Likes
I assumed we would only get fed year 5 data, so consciously made decisions for the preprocessing step and modeling (I would’ve submitted a different model if we were going to get years 1-4 in the final evaluation). I assume the only way you get years 1-4 is if you save them with your submission, but even then you can only do it for the 57k policies in the training data.
2 Likes
That’s interesting!
My quick understanding from this is that you sell very expensive policies to people other insurer deemed “too risky” but that you hope are worthy of a second chance.
There’s definitely lot of money there, and I left it on the table. If anyone similar to you has ever made a claim, I probably won’t sell to you…
Given your profit leaderboard position it worked at least once!
2 Likes
Same 
1 Like
I’m actually a bit miffed tbh, I get that it’s an oversight on our part given the ambiguous wording, but I’ve got a few “NCD history” features embedded in my pre-processing - why would we spend 10 weeks with one data structure (requiring the pre-processing code to calculate these features on the fly), and then have to refactor this for the final submission …
Luckily I’ve got a “claim history” data frame as part of my final “model” which was added last minute and gives some sizeable loadings (over and above my ncd change history feats), so I’ll have some mitigation from that.
I understand that this was not as clear as it could have been. Can I ask how exactly were you and @michael_bordeleau (and potentially others) expecting the final dataset to look like?
We could make a few exceptions and make it work 
1 Like
I’m guessing the admins maybe didn’t foresee the use of prior history features? This is obviously super common in actual insurance rating plans, but I can’t really think of another reason. My prior year variables were also quite predictive, but knowing that I would only have them for a little over half the final policies, I thought about having two sets of models:
- For the 57K in our training set, use the best models which have the prior year features, and
- For the other policies, use a subpar set of models trained without using any of the prior year features.
Ultimately, probably from running out of steam, I decided to just use the subpar models for all policies. I did something similar to @simon_coulombe and saved a simple list of policies with the number of years they had claims in our training data. I ended up doing some kind of out there feature engineering and with the new set of variables, got pretty close to the accuracy of the models using prior year features.
I definitely think a different process probably makes more sense for the final evaluation and I have my gripes with the preprocessing function, but I don’t think the explanation about the final data set was ambiguous though: “The final test dataset, where the final evaluation takes place, includes 100K policies for the 5th year (100K rows).”
3 Likes