For a while now, I have toyed with the ChainLadder package in R, which is developed and maintained by a good friend of mine, Markus Gesmann.  If you’re an actuary, or an R aficionado, you’ve probably seen Markus’s blog here.

Anyway, the “Chainladder-method” is probably the most basic tool that an actuary has for forecasting how the current level of an insurer’s reported claims will evolve over future periods.  In establishing this forecast, an actuary is able to determine the level of reserves that the insurer needs to hold now on their balance sheet in order to finance the actual cost of claims as they fall due.

There are many reasons why an insurer can’t be 100% sure what level of claims they will eventually need to pay out.  In marine insurance, for example, shipowners may continue to operate vessels (despite minor levels of damage) until they arrive back at port and are laid-up in a dry-dock for repairs.  Alternatively, the eventual impact of an insurable event may simply be hard to quantify due to effects taking time to manifest. Examples of this variety include payments to workers suffering from the ill-effects of prolonged asbestos exposure.

The Chainladder package contains a number of in-built tools for manipulating data and forecasting loss development or “runoff” as it’s technically called. These include point-estimate assessment of the required claims payments (i.e. the forecast produces a single forecast value) as well as methods that generate a range of potential outcomes, viz. stochastic methods, which are helpful for evaluating reserve volatility and associated regulatory capital.

This post will be the first in an ongoing series in which I explore how Chainladder and related coding libraries available in R can be harnessed by practicing actuaries.

My goal is not to provide details of the most sophisticated forecast methods available. Specifically, as much as cutting edge methods intrigue me; I’ve always tended to the pragmatic and, as such, I want to provide enough insight to help others apply methods so that they can solve practical issues from the get-go; for example, how does one handle the reality of “small data”?

In undertaking this task, I hope to up-skill my own technical repertoire and I welcome your input and thoughts on things as I move forward. The more explicit programming and statistical nature of these musings explain why I will be posting my thoughts and explorations via a Wordpress blog, rather than directly sharing things on my LinkedIn account.

Lastly, any views expressed on this blog represent my thoughts rather than those of my employer.  If you’re still reading (!) thanks for your time and watch this space…

D