<p><div><div><div><div data-show-faces="false" data-height="21" data-width="100" data-layout="button_count" data-send="true" data-href="https://www.r-bloggers.com/machine-learning-for-insurance-claims/"></div></div><div></div></div><div></div></div>
<div>
(This article was first published on <strong><a href="https://www.tychobra.com/posts/claims-ml/"> Posts on Tychobra</a></strong>, and kindly contributed to <a rel="nofollow" href="https://www.r-bloggers.com/">R-bloggers)</a> </div>
<p></p>
<p>We are pleased to announce <a rel="nofollow" href="https://tychobra.shinyapps.io/claims-ml/" target="_blank">a new demo Shiny application</a> that uses machine learning to predict annual payments on individual insurance claims for 10 years into the future.</p>
<p><iframe width="450" allowfullscreen src="https://www.youtube.com/embed/3KNlT3evDkc"><br>
</iframe></p>
<p>This post describes the basics of the model behind the above Shiny app, and walks through the model fitting, prediction, and simulation ideas using a single claim as an example.</p>
<div>
<h3>Background</h3>
<p>Insurance is the business of selling promises (insurance policies) to pay for potential future claims. After insurance policies are sold, it can be many years before a claim is reported to the insurer and many more years before all payments are made on the claim. Insurers carry a liability on their balance sheet to account for future payments on claims on previously sold policies. This liability is known as the <em>Unpaid Claims Reserve</em>, or just the <em>Reserve</em>. Since the Reserve is a liability for uncertain future payments, it’s exact value is not known and must be estimated. Insurers are very interested in estimating their Reserve as accurately as possible.</p>
<p>Traditionally insurers estimate their Reserve by grouping similar claims and exposures together and analyzing historical loss development patterns across the different groups. They apply the historical loss development patterns of the older groups (with adjustments) to the younger groups of claims and exposures to arrive at a Reserve estimate. This method does not accurately predict individual claim behavior, but, in aggregate, it can accurately estimate the expected value of the total Reserve.</p>
<p>Rather than using the traditional grouping methods, we predict payments on individual insurance claims using machine learning in R. Our goal is to model individual claim behavior as accurately as possible. We want our claim predictions to be indistinguishable from actual claims on an individual claim level, both in expected value and variance. If we can achieve this goal, we can come up with expected values and confidence levels for individual claims. We can aggregate the individual claims to determine the expected value and confidence levels for the total Reserve. There are many other insights we can gather from individual claim predictions, but let’s not get ahead of ourselves. Let’s start with an example.</p>
</div>
<div>
<h3>Example – Predict Payments and Status for a Single Claim 1 Year into the Future</h3>
<p>We will look at reported Workers’ Compensation claims. We will not predict losses on unreported claims (i.e. for our claim predictions, we already have 1 observation of the claim and we will predict future payments on this existing/reported claim). We will not predict future claims on policies that have not reported a claim to the insurer.</p>
<p>So our simplified model for 1 claims is:</p>
<p><img src="https://i1.wp.com/res.cloudinary.com/dxqnb8xjb/image/upload/v1536432933/claim_single_01_tsltj3.png?w=456&ssl=1" data-recalc-dims="1"></p>
<p>We start with data for a single claim. Our goal is to predict the payments on our claim for 1 year into the future. We do this by feeding the claim to our payment model (which we will train later), and the model predicts the payments. Simple enough right? But we want to predict the status (“Open” or “Closed”) of the claim. We could do something like this:</p>
<p><img src="https://i0.wp.com/res.cloudinary.com/dxqnb8xjb/image/upload/v1536693933/claim_single_02_sy12pk.png?w=456&ssl=1" data-recalc-dims="1"></p>
<p>Now we first predict the status, and then we predict the payments. We are getting closer to our goal now, but we also want to capture the variability in our prediction. We do this by adding a simulation after each model prediction:</p>
<p><img src="https://i2.wp.com/res.cloudinary.com/dxqnb8xjb/image/upload/v1536692666/claim_single_03_xskjnq.png?w=456&ssl=1" data-recalc-dims="1"></p>
<p>The prediction returned by the above status model is the probability that the claim will be open at age 2 (e.g. our model might predict a 25% probability that our claim will be open at age 2. Since there are only 2 possible status states, “Open” or “Closed”, a 25% probability of being open implies a 75% probability the claim is closed at age 2). We use this probability to simulate open and closed observations of the claim. We then feed the observations (with simulated status) to our trained payment model. The payment model predicts an expected payment, and finally we simulate the variation in this expected payment based on the distribution of the payment model’s residuals.</p>
<p>If this sounds confusing, bear with me. I think a coded example will show it is actually pretty strait forward. Let’s get started:</p>
<p><strong>Step 1: Load the data</strong></p>
<p>Each claim has 10 variables. We have 3,296 claims in the training data and we pulled out 1 claim. We will make predictions for this 1 claim once we fit the models.</p>
<pre><code>library(knitr)
library(kableExtra)
library(dplyr)

# This .RDS can be found at https://github.com/Tychobra/claims_ml_blog_post_data
data_training &lt;- readRDS(&quot;../../static/data/model_fit_data.RDS&quot;)

test_claim_num &lt;- &quot;WC-114870&quot;

# select one claim that we will make predictions for
test_claim &lt;- data_training %>%
  filter(claim_num == test_claim_num)

# remove the one claim that we will predict from the training data
data_training &lt;- data_training %>%
  filter(claim_num != test_claim_num)

knitr::kable(
  head(data_training)
) %>%
  kableExtra::kable_styling(bootstrap_options = &quot;striped&quot;, font_size = 12) %>%
  kableExtra::scroll_box(width = &quot;100%&quot;) </code></pre>
<div>
<table>
<thead>
<tr>
<th>
claim_num
</th>
<th>
mem_num
</th>
<th>
cause_code
</th>
<th>
body_part_code
</th>
<th>
nature_code
</th>
<th>
class_code
</th>
<th>
status
</th>
<th>
paid_total
</th>
<th>
status_2
</th>
<th>
paid_incre_2
</th>
</tr>
</thead>
<tbody>
<tr>
<td>
WC-163290
</td>
<td>
Member A
</td>
<td>
Struck Or Injured
</td>
<td>
Skull
</td>
<td>
Amputation
</td>
<td>
7720
</td>
<td>
C
</td>
<td>
6893.6947
</td>
<td>
C
</td>
<td>
451.3185
</td>
</tr>
<tr>
<td>
WC-923705
</td>
<td>
Member A
</td>
<td>
Struck Or Injured
</td>
<td>
Brain
</td>
<td>
Amputation
</td>
<td>
9101
</td>
<td>
C
</td>
<td>
60247.1871
</td>
<td>
C
</td>
<td>
0.0000
</td>
</tr>
<tr>
<td>
WC-808299
</td>
<td>
Member A
</td>
<td>
Fall – On Same Level
</td>
<td>
Skull
</td>
<td>
Burn
</td>
<td>
9101
</td>
<td>
O
</td>
<td>
34240.6365
</td>
<td>
O
</td>
<td>
2201.1637
</td>
</tr>
<tr>
<td>
WC-536953
</td>
<td>
Member A
</td>
<td>
Struck Or Injured
</td>
<td>
Skull
</td>
<td>
Contusion
</td>
<td>
9015
</td>
<td>
C
</td>
<td>
599.8090
</td>
<td>
C
</td>
<td>
0.0000
</td>
</tr>
<tr>
<td>
WC-146535
</td>
<td>
Member A
</td>
<td>
Struck Or Injured
</td>
<td>
Skull
</td>
<td>
Contusion
</td>
<td>
7720
</td>
<td>
C
</td>
<td>
265.5697
</td>
<td>
C
</td>
<td>
0.0000
</td>
</tr>
<tr>
<td>
WC-523720
</td>
<td>
Member A
</td>
<td>
Strain – Lifting
</td>
<td>
Skull
</td>
<td>
Concussion
</td>
<td>
7720
</td>
<td>
C
</td>
<td>
85.8200
</td>
<td>
C
</td>
<td>
0.0000
</td>
</tr>
</tbody>
</table>
</div>
<p></p>
<p>The first column (“claim_num”) is the claim identifier and will not be used as a predictor variable in the model training. The 7 predictor variables (columns 2 through 8) represent the claim at age 1. The last 2 columns (“status_2” and “paid_incre_2”) are the variables we will predict. “status_2” is the claim’s status (“O” for Open and “C” for Closed) at age 2. “paid_incre_2” is the incremental payments made on the claim between age 1 and 2.</p>
<p><strong>Step 2: Fit the Status Model</strong></p>
<p>Our status model is a logistic regression, and we train it with the <code>caret</code> package. We use the step AIC method to perform feature selection.</p>
<pre><code>library(caret)

# train the model
tr_control &lt;- caret::trainControl(
  method = &quot;none&quot;,
  classProbs = TRUE,
  summaryFunction = twoClassSummary
)

status_model_fit &lt;- caret::train(
  status_2 ~ .,
  data = data_training[, !(names(data_training) %in% c(&quot;claim_num&quot;, &quot;paid_incre_2&quot;))],
  method = &quot;glmStepAIC&quot;,
  preProcess = c(&quot;center&quot;, &quot;scale&quot;),
  trace = FALSE,
  trControl = tr_control
)


# create a summary to assess the model
smry &lt;- summary(status_model_fit)[[&quot;coefficients&quot;]]
smry_rownames &lt;- rownames(smry)
out &lt;- cbind(
  &quot;Variable&quot; = smry_rownames,
  as_data_frame(smry)
)
  
# display a table of the predictive variables used in the model
knitr::kable(
  out,
  digits = 3,
  row.names = FALSE
) %>%
  kableExtra::kable_styling(bootstrap_options = &quot;striped&quot;, font_size = 12) %>%
  kableExtra::scroll_box(width = &quot;100%&quot;) </code></pre>
<div>
<table>
<thead>
<tr>
<th>
Variable
</th>
<th>
Estimate
</th>
<th>
Std. Error
</th>
<th>
z value
</th>
<th>
Pr(>|z|)
</th>
</tr>
</thead>
<tbody>
<tr>
<td>
(Intercept)
</td>
<td>
-6.293
</td>
<td>
27.188
</td>
<td>
-0.231
</td>
<td>
0.817
</td>
</tr>
<tr>
<td>
cause_codeStrain
</td>
<td>
0.174
</td>
<td>
0.057
</td>
<td>
3.036
</td>
<td>
0.002
</td>
</tr>
<tr>
<td>
cause_codeStrike
</td>
<td>
0.268
</td>
<td>
0.111
</td>
<td>
2.423
</td>
<td>
0.015
</td>
</tr>
<tr>
<td>
<code>cause_codeStruck Or Injured</code>
</td>
<td>
0.301
</td>
<td>
0.140
</td>
<td>
2.151
</td>
<td>
0.031
</td>
</tr>
<tr>
<td>
body_part_codeSkull
</td>
<td>
-0.312
</td>
<td>
0.122
</td>
<td>
-2.559
</td>
<td>
0.011
</td>
</tr>
<tr>
<td>
nature_codeBurn
</td>
<td>
0.266
</td>
<td>
0.123
</td>
<td>
2.168
</td>
<td>
0.030
</td>
</tr>
<tr>
<td>
nature_codeContusion
</td>
<td>
-0.430
</td>
<td>
0.271
</td>
<td>
-1.589
</td>
<td>
0.112
</td>
</tr>
<tr>
<td>
nature_codeLaceration
</td>
<td>
0.179
</td>
<td>
0.093
</td>
<td>
1.914
</td>
<td>
0.056
</td>
</tr>
<tr>
<td>
nature_codeStrain
</td>
<td>
0.156
</td>
<td>
0.066
</td>
<td>
2.365
</td>
<td>
0.018
</td>
</tr>
<tr>
<td>
class_code8810
</td>
<td>
0.228
</td>
<td>
0.113
</td>
<td>
2.024
</td>
<td>
0.043
</td>
</tr>
<tr>
<td>
class_code9102
</td>
<td>
-2.706
</td>
<td>
144.101
</td>
<td>
-0.019
</td>
<td>
0.985
</td>
</tr>
<tr>
<td>
class_codeOther
</td>
<td>
0.198
</td>
<td>
0.119
</td>
<td>
1.666
</td>
<td>
0.096
</td>
</tr>
<tr>
<td>
statusO
</td>
<td>
1.264
</td>
<td>
0.118
</td>
<td>
10.742
</td>
<td>
0.000
</td>
</tr>
<tr>
<td>
paid_total
</td>
<td>
0.184
</td>
<td>
0.048
</td>
<td>
3.862
</td>
<td>
0.000
</td>
</tr>
</tbody>
</table>
</div>
<p></p>
<p>The above table shows the variables that our step AIC method decided were predictive enough to keep around. The lower the p-value in the “Pr(>|z|)” column, the more statistically significant the variable. Not surprisingly “statusO” (the status at age 1) is highly predictive of the status at age 2.</p>
<p><strong>Step 3: Fit the payment model</strong></p>
<p>Next we use the <code>xgboost</code> R package along with <code>caret</code> to fit our payment model. We search through many possible tuning parameter values to find to the best values to tune the boosted tree. We perform cross validation to try to avoid over fitting the model.</p>
<pre><code>library(xgboost)

xg_grid &lt;- expand.grid(
  nrounds = 200, #the maximum number of iterations
  max_depth = c(2, 6),
  eta = c(0.1, 0.3), # shrinkage range (0, 1)
  gamma = c(0, 0.1, 0.2), # &quot;pseudo-regularization hyperparameter&quot; (complexity control) 
  # range [0, inf]
  # higher gamma means higher rate of regularization.  default is 0
  # 20 would be an extremely high gamma and would not be recommended
  colsample_bytree = c(0.5, 0.75, 1), # range [0, 1]
  min_child_weight = 1,
  subsample = 1
)


payment_model_fit &lt;- caret::train(
  paid_incre_2 ~ .,
  data = data_training[, !(names(test_claim) %in% c(&quot;claim_num&quot;))],
  method = &quot;xgbTree&quot;,
  tuneGrid = xg_grid,
  trControl = caret::trainControl(
    method = &quot;repeatedcv&quot;, 
    repeats = 1
  )
)</code></pre>
<p>This trained model can predict payments on an individual claim like so:</p>
<pre><code>test_claim_2 &lt;- test_claim
test_claim_2$predicted_payment &lt;- predict(
  payment_model_fit, 
  newdata = test_claim_2[, !(names(test_claim_2) %in% c(&quot;claim_num&quot;, &quot;paid_incre_2&quot;))]
)

knitr::kable(
  test_claim_2
) %>%
  kableExtra::kable_styling(font_size = 12) %>%
  kableExtra::scroll_box(width = &quot;100%&quot;)</code></pre>
<div>
<table>
<thead>
<tr>
<th>
claim_num
</th>
<th>
mem_num
</th>
<th>
cause_code
</th>
<th>
body_part_code
</th>
<th>
nature_code
</th>
<th>
class_code
</th>
<th>
status
</th>
<th>
paid_total
</th>
<th>
status_2
</th>
<th>
paid_incre_2
</th>
<th>
predicted_payment
</th>
</tr>
</thead>
<tbody>
<tr>
<td>
WC-114870
</td>
<td>
Member A
</td>
<td>
Chemicals Burn
</td>
<td>
Skull
</td>
<td>
Burn
</td>
<td>
Other
</td>
<td>
O
</td>
<td>
5517.135
</td>
<td>
C
</td>
<td>
1748.148
</td>
<td>
4103.079
</td>
</tr>
</tbody>
</table>
</div>
<p></p>
<p>The predicted payment (shown in the last column named “predicted_payment”) for our above claim was 4,103, and the actual payment between age 1 and 2 was 1,748. Our prediction was not extremely accurate, but it was at least within a reasonable range (or so it seems to me). Due to the inherent uncertainty in workers’ compensation claims, it is unlikely we will ever be able to predict each individual insurance claim with a high degree of accuracy. Our aim is to instead predict payments within a certain range with high accuracy. We use the following simulation technique to quantify this range.</p>
<p><strong>Step 4: Use probility of being open to simulate the status</strong></p>
<p>In our above prediction we used status at age 2 as a variable to predict the payment between age 1 and 2. Of course the actual status at age 2 will not yet be known when the claim is at age 1. Instead we can use our claim status model to simulate the status at age 2. We can then use this simulated status as a predictor variable.</p>
<pre><code># use status model to get the predicted probability that our test claim will be open
test_claim_3 &lt;- test_claim

test_claim_3$prob_open &lt;- predict(
  status_model_fit, 
  newdata = test_claim_3, 
  type = &quot;prob&quot;
)$O

# set the number of simulation to run
n_sims &lt;- 200

set.seed(1235)
out &lt;- data_frame(
  &quot;sim_num&quot; = 1:n_sims,
  &quot;claim_num&quot; = test_claim_3$claim_num,
  # run a binomial simulation to simulate the claim status `n_sims` times
  # this binomial simulation will return a 0 for close and 1 for open
  &quot;status_sim&quot; = rbinom(test_claim_3$prob_open, n = n_sims, size = 1)
)

# convert 0s and 1s to &quot;C&quot;s and &quot;O&quot;s
out &lt;- out %>%
  mutate(status_sim = ifelse(status_sim == 0, &quot;C&quot;, &quot;O&quot;)) 

kable(head(out)) %>%
  kableExtra::kable_styling(font_size = 12)</code></pre>
<table>
<thead>
<tr>
<th>
sim_num
</th>
<th>
claim_num
</th>
<th>
status_sim
</th>
</tr>
</thead>
<tbody>
<tr>
<td>
1
</td>
<td>
WC-114870
</td>
<td>
C
</td>
</tr>
<tr>
<td>
2
</td>
<td>
WC-114870
</td>
<td>
C
</td>
</tr>
<tr>
<td>
3
</td>
<td>
WC-114870
</td>
<td>
C
</td>
</tr>
<tr>
<td>
4
</td>
<td>
WC-114870
</td>
<td>
O
</td>
</tr>
<tr>
<td>
5
</td>
<td>
WC-114870
</td>
<td>
C
</td>
</tr>
<tr>
<td>
6
</td>
<td>
WC-114870
</td>
<td>
C
</td>
</tr>
</tbody>
</table>
<p>The third column “status_sim” shows our simulated status. These are the values we pass the payment model (along with the 6 other predictor variables from age 1. We now have 200 observations of our single claim because we simulated the status 200 times. We can look at the number of times our claim was simulated to be open and closed like so:</p>
<pre><code>table(out$status_sim)</code></pre>
<pre><code>## 
##   C   O 
## 168  32</code></pre>
<p><strong>Step 5: Predict a Payment for each of the simulated statuses</strong></p>
<pre><code>out &lt;- left_join(out, test_claim, by = &quot;claim_num&quot;) %>%
  mutate(status_2 = status_sim) %>%
  select(-status_sim)

out$paid_incre_fit &lt;- predict(payment_model_fit, newdata = out)

knitr::kable(
  head(out)
) %>%
  kableExtra::kable_styling(font_size = 12) %>%
  kableExtra::scroll_box(width = &quot;100%&quot;)</code></pre>
<div>
<table>
<thead>
<tr>
<th>
sim_num
</th>
<th>
claim_num
</th>
<th>
mem_num
</th>
<th>
cause_code
</th>
<th>
body_part_code
</th>
<th>
nature_code
</th>
<th>
class_code
</th>
<th>
status
</th>
<th>
paid_total
</th>
<th>
status_2
</th>
<th>
paid_incre_2
</th>
<th>
paid_incre_fit
</th>
</tr>
</thead>
<tbody>
<tr>
<td>
1
</td>
<td>
WC-114870
</td>
<td>
Member A
</td>
<td>
Chemicals Burn
</td>
<td>
Skull
</td>
<td>
Burn
</td>
<td>
Other
</td>
<td>
O
</td>
<td>
5517.135
</td>
<td>
C
</td>
<td>
1748.148
</td>
<td>
4103.079
</td>
</tr>
<tr>
<td>
2
</td>
<td>
WC-114870
</td>
<td>
Member A
</td>
<td>
Chemicals Burn
</td>
<td>
Skull
</td>
<td>
Burn
</td>
<td>
Other
</td>
<td>
O
</td>
<td>
5517.135
</td>
<td>
C
</td>
<td>
1748.148
</td>
<td>
4103.079
</td>
</tr>
<tr>
<td>
3
</td>
<td>
WC-114870
</td>
<td>
Member A
</td>
<td>
Chemicals Burn
</td>
<td>
Skull
</td>
<td>
Burn
</td>
<td>
Other
</td>
<td>
O
</td>
<td>
5517.135
</td>
<td>
C
</td>
<td>
1748.148
</td>
<td>
4103.079
</td>
</tr>
<tr>
<td>
4
</td>
<td>
WC-114870
</td>
<td>
Member A
</td>
<td>
Chemicals Burn
</td>
<td>
Skull
</td>
<td>
Burn
</td>
<td>
Other
</td>
<td>
O
</td>
<td>
5517.135
</td>
<td>
O
</td>
<td>
1748.148
</td>
<td>
23163.445
</td>
</tr>
<tr>
<td>
5
</td>
<td>
WC-114870
</td>
<td>
Member A
</td>
<td>
Chemicals Burn
</td>
<td>
Skull
</td>
<td>
Burn
</td>
<td>
Other
</td>
<td>
O
</td>
<td>
5517.135
</td>
<td>
C
</td>
<td>
1748.148
</td>
<td>
4103.079
</td>
</tr>
<tr>
<td>
6
</td>
<td>
WC-114870
</td>
<td>
Member A
</td>
<td>
Chemicals Burn
</td>
<td>
Skull
</td>
<td>
Burn
</td>
<td>
Other
</td>
<td>
O
</td>
<td>
5517.135
</td>
<td>
C
</td>
<td>
1748.148
</td>
<td>
4103.079
</td>
</tr>
</tbody>
</table>
</div>
<p>The predicted payments are in the last column above. There predicted payment values differ depending on if the claim status was simulated to be open or closed. This gives us a little variability in our predicted payment, but it still does not capture the random variability of real world claims.</p>
<p><strong>Step 6: Simulate Variability Around the Predicted Payment</strong></p>
<p>Next we apply random variation to the predicted payment. For the sake of brevity here, we arbitrarily choose the negative binomial distribution, but in a real world analysis we would fit different distributions to the residuals to determine an appropriate model for the payment variability.</p>
<pre><code>out$paid_incre_sim &lt;- sapply(
  out$paid_incre_fit,
  function(x) {
    rnbinom(n = 1, size = x ^ (1 / 10), prob = 1 / (1 + x ^ (9 / 10)))
  }
)

knitr::kable(
  head(out)
) %>%
  kableExtra::kable_styling(font_size = 12) %>%
  kableExtra::scroll_box(width = &quot;100%&quot;)</code></pre>
<div>
<table>
<thead>
<tr>
<th>
sim_num
</th>
<th>
claim_num
</th>
<th>
mem_num
</th>
<th>
cause_code
</th>
<th>
body_part_code
</th>
<th>
nature_code
</th>
<th>
class_code
</th>
<th>
status
</th>
<th>
paid_total
</th>
<th>
status_2
</th>
<th>
paid_incre_2
</th>
<th>
paid_incre_fit
</th>
<th>
paid_incre_sim
</th>
</tr>
</thead>
<tbody>
<tr>
<td>
1
</td>
<td>
WC-114870
</td>
<td>
Member A
</td>
<td>
Chemicals Burn
</td>
<td>
Skull
</td>
<td>
Burn
</td>
<td>
Other
</td>
<td>
O
</td>
<td>
5517.135
</td>
<td>
C
</td>
<td>
1748.148
</td>
<td>
4103.079
</td>
<td>
12706
</td>
</tr>
<tr>
<td>
2
</td>
<td>
WC-114870
</td>
<td>
Member A
</td>
<td>
Chemicals Burn
</td>
<td>
Skull
</td>
<td>
Burn
</td>
<td>
Other
</td>
<td>
O
</td>
<td>
5517.135
</td>
<td>
C
</td>
<td>
1748.148
</td>
<td>
4103.079
</td>
<td>
4133
</td>
</tr>
<tr>
<td>
3
</td>
<td>
WC-114870
</td>
<td>
Member A
</td>
<td>
Chemicals Burn
</td>
<td>
Skull
</td>
<td>
Burn
</td>
<td>
Other
</td>
<td>
O
</td>
<td>
5517.135
</td>
<td>
C
</td>
<td>
1748.148
</td>
<td>
4103.079
</td>
<td>
1120
</td>
</tr>
<tr>
<td>
4
</td>
<td>
WC-114870
</td>
<td>
Member A
</td>
<td>
Chemicals Burn
</td>
<td>
Skull
</td>
<td>
Burn
</td>
<td>
Other
</td>
<td>
O
</td>
<td>
5517.135
</td>
<td>
O
</td>
<td>
1748.148
</td>
<td>
23163.445
</td>
<td>
15793
</td>
</tr>
<tr>
<td>
5
</td>
<td>
WC-114870
</td>
<td>
Member A
</td>
<td>
Chemicals Burn
</td>
<td>
Skull
</td>
<td>
Burn
</td>
<td>
Other
</td>
<td>
O
</td>
<td>
5517.135
</td>
<td>
C
</td>
<td>
1748.148
</td>
<td>
4103.079
</td>
<td>
2015
</td>
</tr>
<tr>
<td>
6
</td>
<td>
WC-114870
</td>
<td>
Member A
</td>
<td>
Chemicals Burn
</td>
<td>
Skull
</td>
<td>
Burn
</td>
<td>
Other
</td>
<td>
O
</td>
<td>
5517.135
</td>
<td>
C
</td>
<td>
1748.148
</td>
<td>
4103.079
</td>
<td>
1655
</td>
</tr>
</tbody>
</table>
</div>
<p>The payment we just simulated above (column “paid_incre_sim”) contains significantly more variability than our previously predicted payments. We can get a better sense of this variability with a histogram:</p>
<pre><code>library(ggplot2)
library(scales)

payment_mean &lt;- round(mean(out$paid_incre_sim), 0)
payment_mean_display &lt;- format(payment_mean, big.mark = &quot;,&quot;)
    
ggplot(out, aes(x = paid_incre_sim))+
  geom_histogram(color = &quot;darkblue&quot;, fill = &quot;white&quot;) +
  ylab(&quot;Number of Observations&quot;) +
  xlab(&quot;Predicted Payment&quot;) +
  ggtitle(&quot;Simulated Predicted Payments Between Age 1 and 2&quot;) +
  scale_x_continuous(labels = scales::comma) +
  geom_vline(
    xintercept = payment_mean,
    color = &quot;#FF0000&quot;
  ) +
  geom_text(
    aes(
      x = payment_mean, 
      label = paste0(&quot;Simulation Mean = &quot;, payment_mean_display), 
      y = 10
    ), 
    colour = &quot;#FF0000&quot;, 
    angle = 90, 
    vjust = -0.7
  )</code></pre>
<p><img src="https://i2.wp.com/www.tychobra.com/posts/claims-ml_files/figure-html/plot_predicted-1.png?w=450&ssl=1" data-recalc-dims="1"></p>
<p>In the above plot we see our claim is predicted to have a payment anywhere from 0 to a little less than 80,000. The mean of the simulated prediction is 7,146 and the actual payments between age 1 and 2 now falls within our predicted range of possible payments. From a quick glance this distribution of possible claim payment values seems to be a reasonable representation of real world claim development.</p>
<p>There is still one additional easy alteration to make our simulated claim behave more like an actual claim. Actual claims have a fairly high probability of experiencing zero incremental payment over the upcoming year. We can test for the number of zero payment claims in our training data:</p>
<pre><code>zero_paid &lt;- data_training %>%
  filter(paid_incre_2 == 0)

# calculate the probability that a claim does not have any payement
prob_zero_paid &lt;- nrow(zero_paid) / nrow(data_training)</code></pre>
<p>69.9% of our claims have zero payment between ages 1 and 2. Our model currently does not make a clear distinction between claims with payment and claims with zero payment. A next step would be to fit another logistic regression to the probability of zero payment between age 1 and 2, and run a binomial simulation (just like our claim status simulation) to determine if the claim will have an incremental payment of zero or a positive incremental payment. We would also need to retrain our payment model using only the claims that had a positive payment between age 1 and 2 in the training set.</p>
<p>We will leave the zero payment model for you to try out on your own.</p>
</div>
<div>
<h3>Why Run the Simulations</h3>
<p>Often models are concerned with predicting the most likely outcome, the probability of an outcome, or the mean expected value. However, in insurance, we often are not as concerned with the mean, median, or mode outcome as we are with the largest loss we would expect with a high degree of confidence (e.g. We expect to pay no more than x at a 99% confidence level). Additionally, insurers are concerned with the loss payments they can expect to pay under various risk transfer alternatives (e.g. what is the expected loss if cumulative per claim payments are limited to 250,000 and aggregate losses per accident year over 1,000,000 are split 50%/50% between the insurer and a reinsurer). And what are the confidence levels for these risk transfer losses? With per claim predictions and simulations we can answer these questions for all risk transfer options at all confidence levels.</p>
<p>There is plenty of room for further improvement to this model, and there is a wide range of insights we could explore using individual claim simulations. Let me know your ideas in the comments.</p>
</div>
	<p>
<div>
<div>To <strong>leave a comment</strong> for the author, please follow the link and comment on their blog: <strong><a href="https://www.tychobra.com/posts/claims-ml/"> Posts on Tychobra</a></strong>.</div>
<hr>
<a rel="nofollow" href="https://www.r-bloggers.com/">R-bloggers.com</a> offers <strong><a rel="nofollow" href="https://feedburner.google.com/fb/a/mailverify?uri=RBloggers">daily e-mail updates</a></strong> about <a rel="nofollow" href="https://www.r-project.org/" title="The R Project for Statistical Computing">R</a> news and <a rel="nofollow" href="https://www.r-bloggers.com/search/tutorial" title="R tutorials">tutorials</a> on topics such as: <a rel="nofollow" href="https://www.r-bloggers.com/search/data%20science" title="Data science">Data science</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/Big%20Data" title="Big Data">Big Data, <a rel="nofollow" href="https://www.r-users.com/" title="R jobs">R jobs</a>, visualization (<a rel="nofollow" href="https://www.r-bloggers.com/search/ggplot2" title="ggplot and ggplot2 tutorials">ggplot2</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/boxplot" title="Boxplots using lattice and ggplot2 tutorials">Boxplots</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/map" title="Maps and gis">maps</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/animation" title="Animation in R">animation</a>), programming (<a rel="nofollow" href="https://www.r-bloggers.com/search/RStudio" title="RStudio IDE for R">RStudio</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/sweave" title="Sweave and literate programming">Sweave</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/LaTeX" title="LaTeX in R">LaTeX</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/SQL" title="SQL and databases">SQL</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/eclipse" title="Eclipse IDE for R">Eclipse</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/git" title="git and github, Version Control System">git</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/hadoop" title="Large data in R using Hadoop">hadoop</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/Web+Scraping" title="Web Scraping of google, facebook, yahoo, twitter and more using R">Web Scraping</a>) statistics (<a rel="nofollow" href="https://www.r-bloggers.com/search/regression" title="Regressions and ANOVA analysis tutorials">regression</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/PCA" title="principal component analysis tutorial">PCA</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/time+series" title="Time series">time series</a>, <a rel="nofollow" href="https://www.r-bloggers.com/search/trading" title="finance trading">trading</a>) and more...
<img width="1" alt="" src="http://feeds.feedburner.com/~r/RBloggers/~4/eHxHprZx76c" height="1"></a></div>