Skip to main content
The Actuary: The magazine of the Institute and Faculty of Actuaries - return to the homepage Logo of The Actuary website
  • Search
  • Visit The Actuary Magazine on Facebook
  • Visit The Actuary Magazine on LinkedIn
  • Visit @TheActuaryMag on Twitter
Visit the website of the Institute and Faculty of Actuaries Logo of the Institute and Faculty of Actuaries

Main navigation

  • News
  • Features
    • General Features
    • Interviews
    • Students
    • Opinion
  • Topics
  • Knowledge
    • Business Skills
    • Careers
    • Events
    • Predictions by The Actuary
    • Whitepapers
  • Jobs
  • IFoA
    • CEO Comment
    • IFoA News
    • People & Social News
    • President Comment
  • Archive

Topics

  • Data Science
  • Investment
  • Risk & ERM
  • Pensions
  • Environment
  • Soft skills
  • General Insurance
  • Regulation Standards
  • Health care
  • Technology
  • Reinsurance
  • Global
  • Life insurance
Quick links:
  • Home
  • The Actuary Issues
  • April 2014
04

GI: A moving platform

Open-access content 26th March 2014

The prospect of changing your modelling platform is seen as a significant task by most capital modellers. Andrew Cox and Cameron Heath show how to have a smooth ride through the process

2

Be it as a result of a merger, acquisition, the software no longer being supported or simply a result of sheer frustration with your current solution, change is sometimes necessary. The thought of what's involved can send even the most seasoned actuary into the kind of spin Strictly's Len Goodman would be purring over. Changing your capital model platform doesn't have to be as daunting as it seems. Let us explain why.

All is not lost

The first point to remember is that changing model doesn't mean you're starting again from scratch. A great deal of the experience, understanding and insight that you gained while building the original model will be retained and used with the new model.

To demonstrate this point, it is worth distinguishing between the model - the mathematical representation of the entity being modelled - and the implementation of that model. The latter is the piece of software used to crunch the numbers. Often changing one of these does not involve changing 

the other.

An example might be turning a spreadsheet into code. However, it is often the case that the change of implementation is made for issues around the flexibility, clarity or speed of modelling. In such cases it is likely that the switch of modelling platform will involve some changes in the underlying mathematical model. In our experience, this is often the case around dependency modelling, which is approached differently in different pieces of software. Although this should not be seen as a bad thing - it forces you to think about the underlying assumptions that may have been made relatively quickly a long time ago. 

Indeed, changing model is also an opportunity to put right all those quick fixes you've learnt to live with but that secretly bug the living daylights out of you. This could also be seen as improving the governance of the model which can help to satisfy Solvency II requirements. 

Whatever the reason for changing the platform, the parameters that you used are still as valid in your new model as they are in the old one. So all the analysis that you did, all those discussions with underwriters, all those (expert judgment) picks that you made where you didn't have enough data can all be used again. As an aside, changing model is a great opportunity to review all those parameters and assumptions to make sure they are still valid (see figure 1).

Likewise, you'll know what the new model should look like - how it should be structured, which classes (and sub-classes) to split the business into, how the reinsurance programme functions, the format of the output reports needed and so on.


A journey of a thousand miles begins with a single step

When we - Barnett Waddingham and Guy Carpenter - were asked to look at the feasibility of switching models for a London Market insurer, we started by carrying out a proof of concept on one typical class of business. Our first task was to understand the current model (hopefully, but not certainly, a straightforward task if it's your own). Then we had to choose the class; we picked one that contained attritional, large and cat losses (from a vendor model), which had stand-alone reinsurance and old years. This way we could check underwriting and reserve risk at gross and net levels.

Having built the basic structure in the new platform we then selected the existing distributions and input the parameters. It's worth remembering that many distributions have variations, or different parameterisations, and it's just as well to check you're using the same one as your old model or at least something that is going to give a comparable answer. Likewise, if there are quick fixes or peculiarities of how your old model deals with different situations, you'll either need to replicate them or have an understanding of how you expect the results to change. For example, conversion from underwriting to accident years can be done before or after the losses have been generated; if the parameters are split before modelling the aggregate variability will be lower unless there is a 100% correlation between accident years.

Talking of variability, you'll need to decide which metrics you're interested in comparing, as we did. Clearly, you'll start with the mean, and you'll no doubt be interested in the 99.5%, but you may also want to focus on other points on the curve for internal reporting purposes - we also looked at 1-in-5 or 1-in-10.

Having run our new model and made sure the results were in the same ballpark (made sure we hadn't fundamentally messed something up), we reconciled the differences and understood what was driving them.  This can be any number of reasons - the way the parameters are used, the distribution (many of them have numerous variations), different approaches to inflation and the like. All models will come up with different results but the key is whether the difference is significant. If you have taken the opportunity to change the mathematical model, you will be expecting there to be differences. Indeed, it may be necessary to replicate some of your quick fixes, in order to show that it's these changes - driven by the maths - and not the software that is driving the difference. Whatever you do, it is important to keep in mind that results do not need to be exactly the same to be considered statistically equivalent - all outputs of models are estimators with an associated error.


Buy one get one free

The proof of concept process is similar to another trend we are observing: companies supporting multiple platforms. This can be to leverage the relative strengths of different pieces of software. For example, using one or more platform(s) to analyse catastrophe risk, the results of which are fed into another where other risks are modelled; alternatively, using a second model as a validation of the primary one. Clearly, this is only part of the full validation process, but it can certainly increase users' confidence in the model. 

This validation approach is especially useful when it covers areas that the two platforms approach differently - as mentioned above, dependency modelling is a common example of this. Different platforms approach interactions in different ways - some using correlation matrices and others using underlying drivers. 

So by reconciling the results of multiple classes separately and together you're also able to understand better the impact of hidden assumptions you have been forced to make by your choice of software platform, and which it is impossible to stress from within that modelling paradigm.


A final thought

As you can see, there's plenty to do in order to change your modelling platform, but the challenge is not insurmountable and there are additional benefits of going through the process.

We couldn't talk about capital models without mentioning Solvency II. It may have taken a backseat of late, but it will soon be back, 1 January 2016 to be precise. If you are not ready by then, it will be more frightening than a Halloween episode of The Simpsons, repeated on Friday 13th. So it's worth thinking about this thorny issue sooner rather than later.

Table1- A moving platform
This article appeared in our April 2014 issue of The Actuary.
Click here to view this issue
Filed in:
04
Topics:
Risk & ERM
Share
  • Twitter
  • Facebook
  • Linked in
  • Mail
  • Print

Latest Jobs

Actuarial Analyst - Lloyd's Pricing

London (Central)
£40000 - £60000 per annum + benefits
Reference
119072

Move from Reserving/Capital to Lloyd's Pricing? Get in touch...

London (Central)
£40000 - £55000 per annum + benefits
Reference
119071

Senior Validation Actuary - Lloyd's

London (Central)
£100000 - £140000 per annum + benefits
Reference
119070
See all jobs »
 
 
 
 

Sign up to our newsletter

News, jobs and updates

Sign up

Subscribe to The Actuary

Receive the print edition straight to your door

Subscribe
Spread-iPad-slantB-june.png
​
FOLLOW US
The Actuary on LinkedIn
@TheActuaryMag on Twitter
Facebook: The Actuary Magazine
CONTACT US
The Actuary
Tel: (+44) 020 7880 6200
​

IFoA

About IFoA
Become an actuary
IFoA Events
About membership

Information

Privacy Policy
Terms & Conditions
Cookie Policy
Think Green

Get in touch

Contact us
Advertise with us
Subscribe to The Actuary Magazine
Contribute

The Actuary Jobs

Actuarial job search
Pensions jobs
General insurance jobs
Solvency II jobs

© 2020 The Actuary. The Actuary is published on behalf of the Institute and Faculty of Actuaries by Redactive Publishing Limited, Level 5, 78 Chamber Street, London, E1 8BL. Tel: 020 7880 6200