Built for the future. Ready today.MG-ALFA Built for the future. Ready today. Best Practices by Tim Deitz , ASA, MAAA Director, MG-ALFA Client Management September 18, 2014 2 Naming

MG-ALFABuilt for the future. Ready today.

Best Practices

by

Tim Deitz , ASA, MAAA

Director, MG-ALFA Client Management

September 18, 2014

2

Naming Best Practices

Document and ENFORCE strict naming conventions

– Check reserved words

Short names (acronyms) – clean and simple

Distinguish valuation dates with consistent folder names

September 11, 2014

3

Input Structure

Well thought out use of user-defined keys

– Legacy cell keys should be avoided, unless needed for pricing

– Factor files should use ffilekey to avoid the use of legacy cell keys

– Well-structured keys should facilitate minimal use of secondary

varies-by

Avoid varies-by issue year (unless absolutely necessary)

Tables should be used for all dynamic (i.e., changes from period

to period) data

– Separate product specs and assumptions

– Use table files to organize tables by ownership

Factor files should be used for reserve factors

September 11, 2014

4

Model Structure

Maximize cycle length and minimize projection periods

Only use audit reports and data capture when

debugging/analyzing

Use a seriatim model as the core model

Use cluster modeling to develop compressed models,

particularly for stochastic applications

Use caution when defining new business cells

– Use Ail, if possible

Use Policy-by-policy projections when possible

Define scenarios in a separate Ain

Use Scenario sets to link multiple scenario files to a single Ain

September 11, 2014

5

Database Coding

DOCUMENTATION!!!

Appoint Model Steward and respect the position

Develop standards of practice and follow

September 11, 2014

6

Database Standards of Practice

Make good use of white space

Use where clauses to make easier to read

Fill in all fields for new variables

Use reasonable names, common prefixes, etc.

– Improve understanding

– Locate related variables

– Group related variables under a logical Group Heading

September 11, 2014

7

Database Coding to Minimize Run Time

Use (t,h) and (y,m) only when necessary. Try to use (t) and (y)

Minimize back references – retains all instances

Use recursion (accumulation variable) instead of summation

Minimize use of expi (mRV module) – number and references

Avoid unused or duplicate “where” clauses

Order “if” statements. So simple formulas are at the top

– Ex. 0 if (GMDBType=NA), so following lines are not executed

Eliminate unneeded code

Avoid repetitive calls to UDFs and PDFs

Avoid unnecessary time 0 processing

September 11, 2014

8

Database Coding to Minimize Run Time

Use (y), (y,m) and (c) indexed variables, if practical

– Not calculated at time 0

Avoid using the mRV module, unless necessary

– Calculated for every basis

Financial and semi-financial formulas only in applicable LoBs

– Leave undefined in other LoBs

September 11, 2014

9

Database Coding Standards of Practice

Variable names are important – spend some time

Helpful naming rules

– Capitalization: first letter of each word or abbreviation

– Short but clear

– Common prefixes for related variables (ex. Div for dividend vars)

– Consistency (ex. Ave in OthMod for average rates)

September 11, 2014

10

Adding New Database Variables

Fill in all fields

– Description

– Comment

– Group Header

– Print Attributes (appropriate widths, decimals, scaling)

– Option List – try to use an existing one

Define only for LoBs or Asset Classes where they are used

September 11, 2014

11

Formula Coding

Use lots of white space

Reverse syntax is preferred

Use:

– Nx(t)/Dx(t) if (Dx(t) > 0)

0 otherwise

Not:

– If (Dx(t) >0) Nx(t)/Dx(t)

else 0

Justify “if” conditions underneath each other

Use “where” clauses to allow formula to be on a single line

September 11, 2014

12

Reports

Use TotalTemp, SubtotalTemp2, and Inventory reports where

possible.

– Especially when sending results to a downstream data warehouse

If using post-runtime reports, minimize the use of rv variables

The Excel Reporting tool provides a flexible method for reporting

– Pull from multiple models

– Flexible stochastic analysis

Avoid the use of Runtime reports

September 11, 2014

13

What is an efficient model?

Easy to understand

Easy to maintain/update

Runs fast!

14

What is an efficient model?

Easy to understand

– Line up lseg/proj/run #

– Sensible descriptions

– Lots of comments for custom coding in Adb

– Use consistent naming conventions and short names

– Fill in all the fields in a formula variable definition

– Use group heading to categorize variables

– Set proper scaling and decimal places

15

What is an efficient model?

Easy to maintain/refresh

– This is the hardest part!

– Do things in a controlled fashion

– Least amount of manual work possible

– Externalize dynamic data to tables

– Avoid dates in model and segment files

• Use the folder to identify the valuation period.

16

What is an efficient model?

Runs fast – how?

• Avoid back reference

• Avoid inefficient “if-then” loop

• No repetitive and unused where clause – create a separate

variable

• Uncheck time zero calculation if not needed

• Do not call UDF/PDF more often than needed

• What formulas are evaluated? All in the LOB you are running

• Avoid monthly indices when possible

17

Analyzing Models for Inefficiencies

A2d tables

– Time Hog

– Use Alternate cell keys

– (i,j), flexible (i,j) and Lookup (i,j)

Excessive varies-by

– Space Hog, but probably doesn’t hurt runtime

– Some impact when running on a grid

Look at Sum and Prod functions

– If not used correctly, can be a time sink and create forward

reference problems

September 11, 2014

18

Analyzing Models for Inefficiencies

Examine database for back-references

– Force translate database

– Go to Temp folder

– Open TempL.c in a text editor

– Search for itable

– Look in column after book basis (ex. BOOKS_NONE)

– The number is the number of back-references and -1 means all

– A few “-1”’s (5-6) are okay, but a lot of them is bad.

September 11, 2014

19

Analyzing Models for Inefficiencies

Turn off all UDFs and run to see impact

– Typically source of long runtime

– Might be necessary, but maybe not

Look at size of formula database

– More financial variables = longer runtime (rollups)

– More variables (nones) = longer runtime

Projection mode

– Annual will run fastest

Check time zero runtime

– Capture values to a factor file. Reuse rather than rerun.

September 11, 2014

20

Best Practices in Input Management

What are the problems?

HOLES

• Input data holes during refresh to next valuation date due to new

cells, new plan codes, etc.

What can you do?

– Can’t avoid it altogether

– Key is doing it in “controlled” fashion

• Put as many as practical in Ail for linking to Ain, so that inputs

can be generated during Ail2/Aia2 generation process

• Define less granular assumptions if possible

21

Best Practices in Input Management

What are the problems?

Different assumptions for different purposes –

CFT/EV/forecast

What can you do?

– Use Projection Keys

22

Best Practices in Input Management

Some suggested solutions for inforce modeling:

– The pricing team maintains an “all-combination” Ain after pricing

work and creates “all-combo” Afd files

– Or, utilize the data being supplied to admin system which would

have all possible cells

– Build factor files as a part of the inforce file building process

23

Projection Keys

Allows the user to efficiently manage data through the varies-by

structure a the projection level

Can create assumption sets for multiple purposes

– Reporting key - MCEV, IFRC, EC

– Projection Type – AG43, C3P2

Define projection keys and a set of projection characteristics for

each key (Proj tab, ProjKey button)

Set projection key for each projection (Proj tab, Parameters

button)

Once defined, the projection key becomes available as a new

varies-by hook

September 11, 2014

24

Projection Keys - continued

More flexible and explicit than varying by projection ID. Driver is

the differentiating feature, not the projection ID.

With this structure, the common practice of having different

Table files for functional use (MCEV vs. IFRS vs. Solvency II) is

no longer necessary. Instead, it is now very easy to have three

Projections each with a different parameterization (a different

Projection Characteristic) of a single Projection Key.

September 11, 2014

25

Scenario Sets

Defined on Proj tab

Avoids redundant data in multiple models

Easier to manage shared scenario data

Select scenario set for each projection (Proj tab, Parameters

button)

September 11, 2014

26

Proj Key Edit Tool

Allows for consolidated viewing and editing of projections and

their associated keys and scenario sets

September 11, 2014

The projections are listed as the columns and the scenario file (ScenFile) is listed as the first row, followed by the projection keys. Clicking on a square in the grid provides the ability to edit the scenario file or projection key associated with a given Proj.###.

27

Questions ?

September 11, 2014