Defining a standard life model specification

[fumitoh]

Wouldn't it be nice if we had a bare-minimum standard life model specification of hypothetical, yet realistic "plain vanilla" products without any country-specific features?
Having the spec would be useful for benchmarking, case studies, prototyping etc...

I'v jotted down items to be discussed:
https://github.com/actuarialopensource/model-spec/wiki/Standard-Specification

This is just a draft outline and needs a lot of discussions to be concrete.

What do you think?

[paddyhoran]

I think this is a great idea. Although Actuaries use (abuse?) Excel too much it probably is the common tool that we all know and it is great for illustration.

We could add reference "models" in Excel and test data and results in csv. Each lib could then include this repo as a sub-module and use it in automated tests to ensure each lib "follows the standard".

We could start small with this but eventually if we want open source tools to be taken seriously and used in Actuarial circles conforming to a "standard" is a big selling point.

[lewisfogden]

That looks good, could generalise the product definition, to any product which has a series of cashflows in and out, which are contingent on external events (survival, death, retirement etc)?

Roughly, as a table (including a few long term "non insurance products" like mortgage lending):

Product Type	Cashflow In (Single) 🔽	Cashflow In (Regular) 🔽	Cashflow Out (Single) 🔼	Cashflow Out (Regular) 🔼	Benefit Amount
Annuity	Entry			Survival	Deterministic
Term Assurance (Life or Critical Illness)		Survival	Death < Expiry		Deterministic
Whole of Life Assurance		Survival	Death		Deterministic
Income Protection (aka PHI)		Survival		Sickness	Deterministic
Unit Linked (Accumulation)	Ad-hoc	Survival	Death / Surrender		Investment Linked
Mortgage	On Early Exit	Survival	Entry		Interest-Linked
Lifetime Mortgage / Equity Release	Death		Entry		Interest-Linked

[fumitoh]

IMHO, Term > WL > Unit linked or VA > Annuity or IP > Others , in order of prevalence.

Don't life insurers in your countries sell medical products, such as hospitalization, diagnosis, dread disease, cancer coverage?

Is UK Income Protection(PHI) the equivalent of US DI?
https://en.wikipedia.org/wiki/Income_protection_insurance
https://www.actuaries.org.uk/system/files/documents/pdf/0001-0057.pdf

Do all types of Unit-linked need dynamic asset-liability models?

[alecloudenback]

This is related: a formal way to specify financial contracts: https://www.microsoft.com/en-us/research/publication/composing-contracts-an-adventure-in-financial-engineering/

I think one relevant concept for this topic is the separation of the objective "if [x] then [y]" is separate from the valuation model, where the subjective assumptions lie.

Some related work: a Julia implementation that I've been meaning to see how well insurance works with, since I've had a hard time getting into Haskell.

More related work: defining a domain specific language for financial contracts where risk attributes are able to be assessed at compile time instead of needing to run sensitivity analysis https://www.youtube.com/watch?v=4vDub-yoX1E

[Houstonwp]

@alecloudenback - see the following for some work done in Denmark and allegedly getting used by Edlund.

Software Development for the Working Actuary
An Actuarial Programming Language for Life Insurance and Pensions
Pension Reserve Computations on GPUs

[fumitoh]

Let's start small in an agile way. I started creating the specs of the first model and its sample data. The output of this model is aggregated death benefit cashflows and their present values. It should implement a minimum set of basic functionalities, such as:

• Reading input data from files,
• Calculating death benefit cashflows and their present values,
• Aggregating the results
• Writing aggregated results to an output file.

The First Model - Aries

https://github.com/actuarialopensource/modelx-samples/blob/master/Aries.ipynb

Let me here your comments. Contribution is also appreciated.

[Houstonwp]

@fumitoh - I think you’re conflating a lot of different moving pieces here. Model implementation, importing, exporting, etc. are all different pieces that aren’t a specification IMO.

You need to start with defining what a product is from first principles. What cashflows happen when and why. The implementation of the why is up to the specific model used. For example, mortality decrements are used for a life annuity cashflow, but how those decrements come to be is separate, e.g. a table, stochastic, etc.

[lewisfogden]

@Houstonwp Agree (although interested to see where @fumitoh is going) - also the way we specific the problem can lead to different implementations, for example:

A: Object Oriented

Specify:

• Legal Entities (Ins Co, Policyholder)
• Contracts (Term Assurance)
• External Events (e.g. stockmarket variations)

Would then project each of these objects (allowing for the states they could be in), and obtain the contract cashflows.

B: Functional (Actuarial Notation)

Write in terms of Ax:n / etc - tends to lead to the recursive solution (as lx+1 is defined in terms of lx)

I've worked more in terms (B) as that is the way we are generally taught, have tried in the past to come up with a specification like (A) but it becomes quite code heavy quickly. It works quite nicely for mortality risk, but I don't find behavioural risks (like lapse) to be as easy to define.

[cjager]

Hi!

Great to see that it starting to take place.

Just one thing regarding policy term, how is you view regarding policyholder options regarding the term?, would it be possible to add an transition from whole life to temporary and maybe other transitions as well at retirement age? E.g. from 20yrs -> 7.5 with x% probability.

Would be interesting to here your view on this is this someting that is usually in the modelling

[ekuo70]

I believe OOP approach to design an open-source actuarial modeling tool is the way to go. I posted an article on LinkedIn discussing this topic last year. Welcome to take a look and give your comment if you are interest.

OOP Approach to Actuarial Modeling

[fumitoh]

@Houstonwp Thanks for your comment. Yes, I am conflating:

1. The first product (and what items of the product) to model
2. Model as a software specification (or requirements i.e. what the model should do)
3. Model as an implementation of the specification
4. Sample data to make the above 3 a concrete instance

For #1, I proposed the death benefits of term policies and their PVs, because that's the most basic cashflows that anyone can start modeling. I expect discussions as to what items should be in the spec (#2) or left as implementation details (#3), but at least I/O should be specified to some extent.
I haven't specified projection logic, but there must be lots of items to discuss, even for such a simple model, for example, how time steps should be treated (e.g. annual/monthly, day count, etc..).
What I'm proposing above is our common goal for the first exercise that we aim to implement using our own tools and approaches and yield the same result. Like most open source projects, starting implementation before having a complete spec is a lot easier than the other way around. We could refine the spec along the way.

What you and some others seem to be interested in discussing is how to generalize the representation of insurance contracts as an object model or what programing paradigm (such as OOP) can be employed to model and generalize insurance contracts. I think these are a subset of #3, but will get more important as we consider more products and patterns. I have no objection to continue these discussions further as well.

[paddyhoran]

I think I'm with @Houstonwp on this. IMHO there are 3 ways to establish a "standard":

The best and most formal way is to define a DSL for describing contracts. This is what is described in the links @Houstonwp provided. I've looked at learning MPS in order to do this but it's a lot of work, I think this might be ambitious for this group to take on at this point.

Write a formal specification. This would look something like a very simple policy document but the target audience would be different. The idea here is that there should be a sufficient detail so that someone can implement the standard. This is the approach Arrow has taken to memory layouts, although Arrow does have integration tests also.

The third is a "reference implementation". This can be in any language but the focus should be simplicity and demonstration of the calculation. This is my reason for suggesting Excel.

The first two options are a lot of work and something we could aspire to but the last option would allow us to get started. We could have a repo of simple "reference implementations", we should give the standard a name and then each library that any of us create could put a banner on their implementation say "Supports the XXX standard for Actuarial Modeling".

[keluc]

In a "previous life" I also worked with the classical actuarial approach for life products (endowments, term life,credit life...) but since then I moved to an universal life/unit linked approach. I don't know what the situation is in every country but I think that the "universal life/unit linked" productmodel (managing all sort of investment types in one contract in an unitized approach) is the most generic model. Classical life products can be treated as a special version of the more generic "universal life/unit linked" product model. The last 20 years I only know one productmodel and based on my migration experience of moving contracts from legacy systems to a universal life system I'm convinced of the "universal life/unit linked" product model.

[fumitoh]

@paddyhoran
Your 3rd option sounds not much different from my idea, but what I'm still not clear about it are:

1. Whether you're proposing to build "the" refernece implementation in Excel

2. What the reference implementation should target to model initially

If #1 is yes, is it worth tyring to implement what you can do with Excel? Or are you referring to a collection of Excel files each of which is only for showing calculation logic to be conformed to? In my understanding, the reference implementaion is to a spec what CPython is to Python.

For #2, are you suggesting a sample product, or an abstraction of all life insurance products? because the latter seems to be a long shot. I want to suggest the first sprint should be a few months....

[fumitoh]

@cjager That's a very interesting example.
I know it's common for some products to have multiple states, like premium waiver or disability, or to transition from one product to another like deferred annuities, but I've never seen a product model forking into 2 or more separate products.

[lewisfogden]

When I was developing heavymodel, I built an excel spreadsheet to test a model against - I've saved it here: Excel Term Model. Happy to use this as a reference. My only minor improvement would be to add term dependent lapse rates. (In practice would also have sex/smoker specific rates from CMI tables, and gender neutral assumptions.)

I have a working implementation of this in heavymodel but it is for an older version, will drop it into the implementations folder once I've made sure it works in the pypi version (along with the tables).

[lewisfogden]

I've added a heavymodel implementation here: heavymodel example caveat that I've not checked it works in a clean environment. For calculating the model points I think I'll use pandas and apply. Feel free to take the assumption files for your own implementations.

I think it might worth us agreeing a common format for data / assumptions? I wrote a rough spec typed csv as an example, main point is making sure to use a standard encoding like UTF8.

For non model-point data - I've also used YAML as the assumption file format, might be worth looking at TOML and other formats though, as YAML has some downsides?

[fumitoh]

@lewisfogden This is great. For mortality using selection tables is common practice in UK?
We use ultimate base mortality rates and scalars by duration.
I agree lapse rates by duration should be allowed.
For data format, I would use Excel for assumptions. For large input like model points and stochastic scenarios, csv is probably everyone's choice.

[lewisfogden]

@fumitoh: yep duration based tables, with male|female & smoker|non smoker variants.

I think csv for everything is probably best - Excel is quite slow to read/write and not sure if Excel spreadsheets can be written from rust / julia etc.

[lewisfogden]

Note -the tables I shared were inadvertently from CMI (I had renamed them) - I have deleted from repo for now and will replace with randomised tables that will work for reference. (I'm assuming not all members here are CMI subscribers). Grateful if you can update your local repos to remove them and remove any copies outside.

Thanks @fumitoh for pointing out.

[lewisfogden]

New mortality tables (made up by me so free to use) uploaded along with a new generic excel model.

I've also written a version of the heavymodel code which takes a dataframe of model points and adds the result column.
https://github.com/actuarialopensource/standard-model/blob/main/implementations/heavymodel/run_model_points.py

(Seems to calculate about 250 rows per second)

[fumitoh]

I added a first modelx implementation. Running the notebook in the modelx dir creates a model "TermAssurance.zip"
https://github.com/actuarialopensource/standard-model/blob/main/implementations/modelx/build_model.ipynb
It's still awfully slow so I'm going to add a parallel version.
I pushed --force to remove the older mortality tables completely so pull the remote repo and make changes to the updated repo.

[fumitoh]

I reworked on the modelx implementaion:
https://github.com/actuarialopensource/standard-model/blob/main/implementations/modelx/TimeitParallel.ipynb

The new parallel model calculates monthly_risk_premium for 1000 model points in 1.57secs, for 10000 model point (10x the original set) in 2.55 secs on my 5-year old PC.
This improvement is extreme given the first implementation which takes 75 secs for 1000 model points.

[fumitoh]

Forgot to mention that the code is originated from @lewisfogden 's heavymodel implementation

[lewisfogden]

Sorry for very late reply on this - very impressed with your coding/speed up fumitoh, I'm still working through the code (and looking at modelx a bit more).

[fumitoh]

Meanwhile, we should also start thinking about the "universal life/unit linked" product model. @keluc do you have a good example to be the reference model?

[fumitoh]

I made a generic saving model in Excel by updating the protection model: https://github.com/actuarialopensource/standard-model/tree/main/reference-implementation

The model is based on my experience in VA but I believe the product is generic enough to be interpreted as UL in other countries. Any comments are appreciated.

[keluc]

@fumitoh , I've taken a look at the generic saving model. Based on my experience (continental europe) I'm thinking of some elements that could been taken into account:

• risk cover: normally this is financed by a tariff risk premium periodically taken out of the contract's reserve

• risk cover: possible options are an insured amount on top of reserves vs reserves included. Your example (reserves included) occurs most of the times

• surrender charges: typically a charge is applied in case of surrender which creates a additional margin

• investment return: a mixed form is observed frequently, meaning a (renewable) intrest rate guarantee (with/without profit sharing) next to investment funds (unit linked)

• commission and admin loadings on can not only be set on the (recurring) premiums but also taken out of the contract's reserve or periodically withdrawn risk premiums

• cross check could be foreseen in the base model: the calculated "margin" result should be suported with an "accounting"-style result

[fumitoh]

@keluc Thank you for your comments. All of them make sense. I'll make a copy of the current sheet and make another model to reflect your points.

[fumitoh]

Updated the saving model to reflect @keluc 's comments except for(the 4the and 5th bullets)

• COI charge (mortality x 1.1) is now deducted from account value in addition to M&E fee
• 2 death benefit types available now: max(AV, sum assured), AV + sum assured
• Add a product spec table to define combinations of DB type, surrender charge pattern & premium loadings %
• "margin"-style result is added to cross check "accounting"-style result

https://github.com/actuarialopensource/standard-model/blob/main/reference-implementation/saving_model_generic.xlsx