When we think about an actuarial modelling system, it includes many stages, platforms, and steps. We can think of it as a timeline: the left-most point is receiving raw data, then cleaning it, and the right-most is outputting results from the model and compiling them for reporting. In between these points are a number of steps, including projection and calculation models, assumption setting and input, and other automations and steps that are all part of this end-to-end “System”.

The steps of a typical actuarial modelling system

Below, we share some tried and tested principles to follow when designing and developing one of these systems, that will put you in the best position to create a sustainable, accurate, and extensible system.

To the Left, To the Left, All the logic that you own in a box to the left

Taking a cue from Queen B, this principle is to move as much of your product-specific logic as far left on the “timeline” as possible. This refers to logic that is specific to particular datasets, records or whatever else is relevant.

Rule of Thumb: The less often this piece of code or logic is used, the further left it should be moved. A piece of code or logic intended solely for a single small batch of records should be moved to the data cleaning stage if possible.

Reason: The further right you place a piece of code, the more likely it is that it will inadvertently be forgotten and applied where it shouldn’t be or create situations where big blocks of code are used to separate which code should apply where.

Standardise I/O (input and output)

Taking a cue from Queen B, this principle is to move as much of your product-specific logic as far left on the “timeline” as possible. This refers to logic that is specific to particular datasets, records or whatever else is relevant.

Rule of Thumb: The less often this piece of code or logic is used, the further left it should be moved. A piece of code or logic intended solely for a single small batch of records should be moved to the data cleaning stage if possible.

Reason: The further right you place a piece of code, the more likely it is that it will inadvertently be forgotten and applied where it shouldn’t be or create situations where big blocks of code are used to separate which code should apply where.

No Hard-Coding Values

Don’t hard-code values unless your life  tends to the ability to create a standardised results repository, which makes for powerful reporting.

Avoid “IF” driven logic

A common pitfall in systems design is encountering code blocks that apply different sets of logic based on the outcome of a series of IF statements. This principle is often applied by adhering to the “To The Left” principle, but deserves its own spot.

Rule of Thumb: If you find yourself with any IF statement where you apply different logic sets on the various outcomes, consider whether that actually requires a program/model/module per logic set, and whether the data should be split between them earlier on.

Reason: This makes code difficult to work with, hard to extend, and inefficient.

Building Blocks

Build your models with modules and building blocks. The idea is to group as much repeatable logic as possible, and to inherit and override code when necessary. Your code should cascade from a simple, basic model to more specific, complex models with small, simple overrides, rather than creating entirely new models. For example, age and duration routines should be standard and generic, housed in a building block used by all models.

Rule of Thumb: When creating some code or logic, ask yourself: “If this piece of code needs to change for some reason in the future, how many times will I need to repeat that same change across my system?” You should create your system so that the answer is “once”. In the basic example, if you rewrote your age and duration routines in each model, and for some reason you change that logic, you would have to make that change in every model you have.

Reason: As the system grows, it’s almost impossible to keep track of all the areas you will need to update when logic changes are necessary, leading to disjointed and inconsistent models and code.

Time Complexity

Don’t forget about time complexity when coding. Avoid creating exponential (O(n^a)) time complexities. These occur when you start adding For loops within projection models or nested loops elsewhere.

Rule of Thumb: Avoiding nesting loops and loops in projection model variables that would happen at each projection step.

Reason: Exponential time complexity quickly runs away with you, and suddenly your model may become unusable as your data grows or as compounding nesting logic gets added. Try to keep it linear.

Our systems actuaries have extensive experience in designing, building and improving actuarial systems.  Please reach out to me at garritn@insight.co.za to discuss how we could apply our best practice systems thinking to your environment.