A Short Note on How to Model Liabilities in Prophet

By

Manoj Bhatt

1 September 2023

1
Contents
Introduction ............................................................................................................................................ 3
Model Office............................................................................................................................................ 3
Definitions ............................................................................................................................................... 3
Categories of Input Variables .................................................................................................................. 4
Primary Input Variables........................................................................................................................... 4
Secondary Input Variables ...................................................................................................................... 4
Custom Indicators ................................................................................................................................... 4
Custom Variables..................................................................................................................................... 4
Variable Properties.................................................................................................................................. 5
Input Definitions ..................................................................................................................................... 5
Not Using a New Indicator .................................................................................................................. 5
Using a New Indicator ......................................................................................................................... 5
Using a New Default Indicator ............................................................................................................ 5
Changing the Input Variable to Core ................................................................................................... 6
Core Definitions ...................................................................................................................................... 6
Code Simplicity........................................................................................................................................ 6
Extended Formulas ................................................................................................................................. 6
Runtime ................................................................................................................................................... 6
Products .................................................................................................................................................. 6
Product Specs .......................................................................................................................................... 7
Testing ..................................................................................................................................................... 7
Results ..................................................................................................................................................... 8
Library Development............................................................................................................................... 8
Library Upgrade....................................................................................................................................... 8
Standards ................................................................................................................................................ 8
Dedicated Team....................................................................................................................................... 9
Conclusions ............................................................................................................................................. 9

2
Introduction
This is a short note on how to model liabilities in Prophet. New users or those rewriting their models
from scratch might find this note useful. The ideas here are of course my own. Therefore, if you are
going to use any of them, please do so of your own accord.

I have assumed that you are familiar with Prophet. At the time of writing, I do not have access to
Prophet. So, some of the items may not appear like what you would see in the user interface. The
principles however remain the same.

The starting point is to write a deterministic model which can then be extended to a stochastic and
dynamic one.

Model Office
The first task is to specify the model office. Here is an example:
Level
Model Office
Number

50 ALSPROD3

40 ALSPROD1 ALSPROD2

30 SPROD1 SPROD2 SPROD3 SPROD4

20 ACC1 ACC2 ACC3 ACC4 ACC5 ACC6

10 CPROD1 CPROD2 CPROD3 PPROD1 PPROD2 PPROD3 UPROD1 UPROD2 UPROD3 CPROD4 CPROD5 CPROD6 PPROD4 PPROD5 PPROD6 UPROD4 UPROD5 UPROD6

In this example, there are:

• 5 level numbers
• 2 companies in the group
• 5 libraries, Conventional, PHI, Unit Linked, Summary, ALS
• 18 liability products, 6 accumulations, 4 summary products, 3 ALS products

It is with the specification of the liability products at level 10 that this note is concerned.

Definitions
Each liability library of Prophet has two sets of variables, input variables and core variables. Each
variable has one or more definitions. Each definition has a unique indicator expression assigned to it.
The exception to this is a secondary input definition which does not normally have an indicator
expression assigned to it.

The difference between input and core definitions can be looked upon as follows:

• An input definition is user defined

• A core definition is not user defined

Another way of looking at it is this:

• An input definition is an “input” to the model

• A core definition is not an “input” to the model

This applies to all modelling platforms, not just Prophet, in that there must be a distinction between
what is an input and what is not an input to a mathematical model. I used the following guidelines in
coming up with my definitions:

3
 • Science cannot vary by geographical location of the user
• Law cannot vary by user within a geographical location
• Products and their features can vary by user

Given the above, it follows that the bulk of the task is to work out how to specify the input definitions.

Categories of Input Variables

Input variables are subdivided into many categories, the main ones of which are as follows:

• Product features
• Assumptions
• Data

Data usually comes from the model point file and assumptions are normally read from tables. It is the
product features that are typically the more complex to specify.

Primary Input Variables

Primary input variables are those that are brought into the product depending upon the indicators
selected for the product. They must be defined because they are used by the core variables for the
product.

The idea therefore is to target the primary input variables by creating as many secondary input
variables as are necessary leaving the core variables unchanged. For example:

• Target ANN_PREM_PP, leaving PREM_INC unchanged

• Target DEATH_BEN_PP, leaving DEATH_OUTGO unchanged

Secondary Input Variables

Secondary input variables are those that are brought into the product only if they are required by the
primary input variables. Their definitions do not normally have any indicator expressions assigned to
them.

Custom Indicators
Custom indicators should be created to track the changes you make to the standard definitions. One
may usually be enough. It can be called {?}_CODE where {?} is your preferred prefix. It should not be a
prefix that is already in use in the standard libraries. If you are going to use a default indicator, you can
call it DEFAULT_{?}_CODE.

Custom Variables
You can use the same prefix as above to create custom variables so that they are easy to identify either
in diagram view or in the library. For example:

• {?}_AP_* for the secondary inputs to ANN_PREM_PP

• {?}_DB_* for the secondary inputs to DEATH_BEN_PP

You can create the new custom variables either as secondary input variables or as primary input
variables. However, by definition, they will continue to be secondary inputs to the standard primary
input variable.

4
Variable Properties
Variable properties for each secondary input variable you create can initially be a copy of the primary
input variable into which the secondary inputs feed. You can then decide what changes are required
to them. Here are a couple of examples:

• The sequence code for the secondary input variable is usually such that it follows the standard
primary one into which it feeds
• The dynamic properties for the secondary input variable will depend on whether the standard
primary input variable into which it feeds changes dynamically

Input Definitions
Input definitions should be changed in the library rather than in the products such that when you
delete all the input variables from the product and rescan it, you get the input definitions that you
want. This also makes it easier to maintain the changes as you only need to maintain them in the library
rather than in the products. Some examples of how to make the changes are provided below.

Not Using a New Indicator

You can make the change directly to the default input definition without making use of a new indicator.

Using a New Indicator

Alternatively, you can use the new indicator you created to make the change as follows:

• Change the indicator expression of the existing default input definition to:
o {existing indicator expression} AND NOT {?}_CODE
• Create the new default input definition as follows:
o {?}_CODE AND {existing indicator expression}

The lead indicator normally reflects the need for the creation of the new definition and the new
definition is usually added at the end of the list of standard input definitions. This way when you
compare your library against the standard one in definition order, your new definitions will appear at
the bottom of the compare listing.

Using a New Default Indicator

You can also use the new default indicator you created to make the change as follows:

• Change the indicator expression of the existing default input definition to:
o {existing indicator expression} AND NOT {?}_CODE
• Create the new default input definition as follows:
o {?}_CODE AND {existing indicator expression} AND NOT DEFAULT_{?}_CODE

The default indicator is normally added at the end of the indicator expression and works as follows:

• If the default indicator is selected for the product, the new input definition is brought into the
product during code generation like all other core definitions
• If the default indicator is not selected for the product, the new input definition is brought into
the product for specification like all other input definitions

5
Changing the Input Variable to Core
You can change the input variable to core and make the changes using the new indicator. However, the
meaning of the variable as defined above does not change simply by making it core. It continues to
remain an input to the mathematical model.

Core Definitions
Core definitions can only be changed in the library by using the new indicator as they are brought into
the product during code generation.

Code Simplicity
You should keep any changes you make simple so that they are easy for others to follow. For example,
rather than writing 40 lines of code for a single variable, you should see if you can break it down into
fewer lines of code spread across several variables.

Extended Formulas
Extended formulas are normally used for the following reasons:

• To get around the limitations of the standard programming language, for example when you
need to reference a value outside the calculation array
• To reduce runtime

Again, you should keep the code simple for others to follow. For example, rather than writing 1,000
lines of code for a single variable, you should see if you can break it down into fewer lines of code
spread across several variables.

Runtime
Runtime concerns should ideally be addressed using technology rather than labour as the former is
usually cheaper than the latter. Some tips on how to write the code to reduce runtime are already
provided in the user guide, for example:

• How to write the first IF statement depending upon the time reference in the formula to an
earlier (t-) or a later (t+) time period
• How to ensure that a table is not read more often than it needs to

There will always be a balance to be struck between:

• Writing a model that everybody understands, but takes longer to run

• Writing a model that only a few understand, but is quicker to run

Products
The number of master products you create should not be a concern as code generation is now split
across cores. Each master product should have a unique set of indicators and you should aim to have
consistency in their selection across all products. You can use the product schedule to ensure this
consistency. An example is shown below:

6
 Indicators
Category Name CPROD1 CPROD2 CPROD3 CPROD4 CPROD5 CPROD6 PPROD1 PPROD2 PPROD3 PPROD4 PPROD5 PPROD6 UPROD1 UPROD2 UPROD3 UPROD4 UPROD5 UPROD6
CAT_A IND_A * * * * * * * * * * * * * * * * * *
CAT_A IND_B * * * * * *
CAT_A IND_C *
CAT_B IND_D * *
CAT_B IND_E * *
…

* Indicator Selected

You should also aim to name the master and same as products such that they are easily recognisable
in accordance with where and how they fit into the model office, allowing for among other things the
following:

• Tax type, for example life or pension

• Product type, for example endowment or whole life
• Profit sharing type, for example with-profit or non-profit

Product Specs
Product specs would form the starting position for coming up with the input definitions. A first attempt
can be made to set up master products and bring them into a product schedule with input variables in
sequence code order as shown in the example below:
Input Variables
Category Name CPROD1 CPROD2 CPROD3 CPROD4 CPROD5 CPROD6 PPROD1 PPROD2 PPROD3 PPROD4 PPROD5 PPROD6 UPROD1 UPROD2 UPROD3 UPROD4 UPROD5 UPROD6
CAT_A VAR_A * * * * * * * * * * * * * * * * * *
CAT_A VAR_B * * * * * *
CAT_A VAR_C *
CAT_B VAR_D * *
CAT_B VAR_E * *
…

* Variable Brought In

The grid can then be filled with the information from the product specs to start figuring out how each
primary input definition should be defined to keep it simple and consistent across all products.

Testing
An independent tool should be used to test the Prophet code. This could be a spreadsheet developed
independently to perform the same calculations. There will invariably be differences which you would
need to reconcile. You can do this by creating an audit trail copy of your model. In the copy, you can
create audit trail variables called AUD_{n} and use them as follows in the definitions of the variables
giving the differences:

IF AUD_{n} = 0 THEN
{ProphetCode}
ELSE IF AUD_{n} = 1 THEN
{IndependentToolCode}
ELSE
0

The AUD variables should be coded such that their values are read from a table varying by run number.
As an example, if there are 10 such variables, the table would look like this:

7
 Name RUN_01 RUN_02 RUN_03 RUN_04 RUN_05 RUN_06 RUN_07 RUN_08 RUN_09 RUN_10 RUN_11
AUD_1 1 0 0 0 0 0 0 0 0 0 0
AUD_2 1 1 0 0 0 0 0 0 0 0 0
AUD_3 1 1 1 0 0 0 0 0 0 0 0
AUD_4 1 1 1 1 0 0 0 0 0 0 0
AUD_5 1 1 1 1 1 0 0 0 0 0 0
AUD_6 1 1 1 1 1 1 0 0 0 0 0
AUD_7 1 1 1 1 1 1 1 0 0 0 0
AUD_8 1 1 1 1 1 1 1 1 0 0 0
AUD_9 1 1 1 1 1 1 1 1 1 0 0
AUD_10 1 1 1 1 1 1 1 1 1 1 0

In this example, RUN_01 will reproduce the results of the independent tool and RUN_11 will reproduce
the Prophet results. The stepped results from runs 1 to 11 can then be investigated to understand the
differences between the two sets of results and decide which are the correct ones to use.

Results
Results for products are grouped by sub-product codes in each run folder. There are 9,999 sub-product
codes and 999 run numbers that you can use. How you use them will depend upon where and how
they fit into the model office. If possible, you should try and keep their use flexible so that they can be
changed if necessary. This however will depend upon the flexibility provided in your front-end and
back-end systems.

Library Development
The standard library you are using may not always provide for the calculations you want to carry out.
In this case, you would need to develop it. The starting point for this is to see if any of the other libraries
you have licensed provides for the calculations you want.

If another library does provide the calculations you want, then you can copy them into your library. If
not, then you should start formulating how you would make the changes based upon how the standard
libraries have been developed. It is important to document how the development is going to be done
before actually doing it. If the development is such that it is likely to be useful to other Prophet users,
then you may have a case for it to be included in a future release of the standard library.

Once you have completed your development, you should validate your library to ensure that there are
no errors in it.

Library Upgrade
Standard documentation is already available on how to upgrade libraries. The decision to upgrade will
depend upon how far away you have moved from the standard code. It is possible that your model is
so heavily customised that there would be little or no point in upgrading it.

You should note however that the licence fee you pay includes the upkeep of the libraries. Therefore,
the more you use it the more you get in return for your money.

Standards
Standards are only as good as they are followed. It should be clear from this note that coming up with
something that is simple to use and maintain is not a small job. It requires standards to be laid down
and followed. So, whilst the initial task of building the model is time consuming, its subsequent
maintenance is simple.

8
Dedicated Team
A dedicated team should be established to develop and maintain the model. There will always be
demands from the users of the model for a quick turnaround of changes required to it, especially
during busy reporting periods. There are no issues in meeting with such requirements. However, once
the pressure period has subsided, the model should be brought back up to the standards laid down.

Conclusions
I shall leave you to come to your own conclusions on how easy or difficult it would have been for you
to make your developments and maintain or enhance them, including upgrading to and using the latest
versions of the libraries, were you to have adopted some of the ideas mentioned herein.