London

81 Chancery Lane
London
WC2A 1DD
01235 821 160
View map

Edinburgh

1 Lochrin Square
92 Fountainbridge
Edinburgh
EH3 9QA
01235 821 160
View map

Dublin Office

24A Baggot Street, Upper
Dublin 4
Ireland
D 04 N5 28
01235 821 160
View map

Administrative Office

BH Office
Church Street
Ardington
Wantage
Oxfordshire
OX12 8QA
01235 821 160
View map

Send us a message
CLOSE X
Contact Us

Capital Projection Model

Background

APR was engaged by an Insurtech firm who were operating as a managing agent and in the process of applying for a licence to write insurance business themselves.  An important part of the Insurance Licence Application (ILA) process is to produce financial projections to demonstrate the viability of the business.  The client had some spreadsheet models to look at certain aspects of pricing and business planning, but nothing to calculate insurance liabilities or capital requirements. The client had a team of talented engineers who had built some impressive tools in AWS, but had limited experience with finance and actuarial processes.

Project Aims

An important part of the Insurance Licence Application (ILA) process is to produce financial projections to demonstrate the viability of the business.

Although the client was planning to start by offering a fairly simple insurance product, the development of the capital model was complicated by the fact that there was no real experience data and great uncertainty about the various requirements and model assumptions.

APR's Role

APR’s role was to build and run a capital projection model that satisfied the following requirements:

  • The model should be able to project the Solvency II balance sheet over a 5 year planning horizon.
  • The model should be able to cope with a variety of time zero and future stress events, to help demonstrate the risk profile as part of the ILA.
  • The model and documentation should help explain the mechanics of the Solvency II balance sheet to a non-actuarial audience.
  • The model should be designed in a modular way so that it could be introduced into the existing AWS architecture.

Although the client was planning to start by offering a fairly simple insurance product, the development of the capital model was complicated by the fact that there was no real experience data and great uncertainty about the various requirements and model assumptions.

Outcome

A significant part of this project was to bridge the gap between two different views: the existing Tech firm’s view of priorities and capital resources, and; an actuarial view of the proposed insurance group’s capital requirement.

The development was an iterative, learning process:

APR provided an indication of the size and sensitivity of capital requirements so that the client’s management could make informed decisions about corporate structure, reinsurance arrangements, business mix and risk scenarios, which in turn fed into the design of the next iteration of the model.

APR delivered the following:

  • Excel models that provided initial estimates and demonstrated key sensitivities.
  • A bespoke actuarial modelling platform, built using Python, with a simple Excel interface.
  • Financial projections (i.e. model runs) used to inform management and to populate the various documents required as part of the ILA.
  • A technical specification and a series of workshops to ensure that the client understood every aspect of the model and the financial projections and sensitivities.

Although developing a model is not an unusual project for APR, there were two unusual aspects of the final model that make this a noteworthy project:

  • The model combined the below things, that would normally be split into separate models and processes so that it could produce a projected balance sheet, using a small collection of raw inputs, at the single click of a button.
    • Calculating the base and projected balance sheet
    • Deriving and aggregating all standard formula SCR stresses
    • Pricing current and future new business
    • Allowing for capital flows between Group entities
    • Allowing for future financial shocks
    • Calculating the risk margin using nested calculations rather than run-off profiles derived in a separate process.
  • The model was built using Python so that it would fit into the client’s existing technology stack.
    • Python is not a traditional actuarial choice, but one that is growing in popularity.
    • As a general purpose programming language it provided the opportunity to design a simple, scalable structure (see below).
    • The client’s team of engineers were very complimentary about the concise, well-structured, well-documented code.