Professional Documents
Culture Documents
Version 8.1.1
April 2008
Life Settlement Individual Policy Valuation Model v8.1.1
Copyright
Information in this document is subject to change without notice. Companies, names and data
used in examples herein are fictitious unless otherwise noted.
This document comprises confidential information and copyright material belonging to Milliman,
Inc. No part of this document may be reproduced, transmitted, used, published or disclosed to
third parties without the prior written consent of Milliman, Inc.
Milliman, Inc.
Consultants & Actuaries
Two Conway Park
150 Field Drive, Suite 180
Lake Forest, IL 60045
Telephone: 312.499.5725
Fax: 847.604.8671
2.0 Overview
The model consists of a Microsoft Excel workbook and two Access databases. The Excel
workbook collects all inputs, performs the analysis and formats the results for printing.
Calculations are performed by code modules written in Visual Basic and results of the analysis
are written to worksheets for display and printing.
Cases are built by entering data into the model through a series of screens. After a case is built, it
is first saved to a Microsoft Access database and then retrieved for analysis. The parameters
associated with a valuation run may be saved independently of the base case which allows a
variety of valuation scenarios to be saved and re-run without the need to re-input the assumptions.
Installation requires a few steps, but is quite simple. The components of the model (an Excel file
and two Access databases) are copied to a location of the user’s choice. (Refer to Appendix E for
model installation instructions.) The Excel file typically resides on the local drive of the user’s
machine. The database may also reside on the local drive, or it may be stored on a network file
share and be accessed by multiple users. After placing the files in the desired locations, the Excel
file is opened, and the database files are selected (detailed instructions in Appendix B) from the
Options screen. At this point, the model is ready to run.
The process of valuing a Universal Life policy is a three step procedure. First, the carrier’s
illustration is used to solve for current Cost of Insurance (COI) rates. The COI’s are used to
estimate a schedule of premiums that are just sufficient to keep the policy in force under current
conditions. Finally, the expected cash flows are generated based on the life expectancy or
mortality rating of the insured. The present value of the expected cash flows is the estimated
policy value.
The model calculates values on a monthly basis. Most reports are then summarized to an annual
format, but the monthly detail is also available.
Reports are available to give the user full details on policy mechanics and assumptions. Reports
include:
• Summary report showing policy values under several mortality and interest rate scenarios
• Input summary report
• Cash Flow and value calculations, Annual basis
• Cash Flow and value calculations, Monthly basis
• Policy Illustration from carrier
• Policy Illustration reflecting modified funding
• COIs determined by the model to match illustration
This section assumes that you have already installed the software on your computer. If this is not
the case, refer to Appendix E for detailed installation procedures.
When using the model for the first time, there are a few initialization steps to complete.
Since the model contains program code, it is necessary to set Macro Security to the Medium level
or less before the model will run. Begin by opening the model in Excel. If security is set to
Medium, the following message will appear (click Enable Macros to continue):
The entry point to all model functionality is found on the Milliman menu item:
Choosing sub-items from this menu opens a series of screens from which the model is configured
and executed.
3.2.1 About
Select About… to display the About box which reports both the model version and the contact
information for model support. When calling with questions about the model, you are usually
asked which version of the model you are running – the About box is the easiest way to determine
the version number.
3.2.2 Options
The Options… menu item is used for setting up the database connection, specifying default
parameters, and setting certain validation limits. Refer to Appendix B for more information.
Before building cases, you must connect the model to two Access databases, the Case database
and the System database. This step is done the first time you run the model or any time you wish
to direct the model to a different database. Since in most cases you will not be changing
databases, you will usually only have to complete this step once.
The first database that you will connect to the model is the Case database. This is the database
that holds the policy data and Valuation Assumptions that you input for cases. Select Options…
from the menu and click the Database… button to enter the filepath to the Case database. The
default Case database file is C:\Documents and Settings\All Users\Documents\Milliman\Life
Settlement\Database\CurrentCases.mdb.
The System database holds global information such as mortality tables. The System database will
be described in greater detail in Appendix B. To connect to the System database, Select
Options… from the menu and click the System… button to enter the filepath to the System
Database. The default System database is C:\Documents and Settings\All
Users\Documents\Milliman\Life Settlement\Database\PricingSystem.mdb.
After selecting the database, you must click OK to dismiss this dialog or your settings will not be
saved – pressing Cancel closes the screen and abandons your changes. When OK is clicked a
message is displayed reminding you to save the model file:
When this message is dismissed, the Options screen closes and you are returned to the model
spreadsheet. Press Ctl-S to save the spreadsheet so that the changes you just made are retained
for future sessions. Note that the save operation takes a moment since the model file is fairly
large.
You have the option of entering a new case using Form input or Worksheet input. Form input
refers to the custom-built user interface that accepts input data and validates that data. Form
input is helpful to users by organizing the input and projection process in an orderly fashion.
Worksheet input is for users who prefer to enter illustration data directly into Excel. (Note that
only base case input can be entered in this manner – projection parameters must still be entered
through the Projection form.) The advantage of using Worksheet input is access to Excel’s cut
and paste capabilities. The disadvantage is that it does not provide all of the guidance of Form
input. Refer to Section 4.7 for information on how to use Worksheet input.
To create a new case using Form input select Form Input… from the Milliman menu.
The Create or Edit Case screen (below) will be opened and the Case tab displayed. There are
two basic ways to build a new case using Form input:
• Click the New button and enter all values from scratch.
• Load an existing case, modify settings and save to a new name.
We will create our case from scratch in the following steps, but it should be noted that the ability
to load and modify an existing case gives you an extremely powerful tool for quickly building
cases.
If you find that you are repeatedly entering similar parameters for your cases, you can create and
save a template case. When you need to create a new case, simply load your template, change the
appropriate values and save the template to a new name. In fact, because the model makes no
restrictions on the number or types of cases that you can save, it is possible to build multiple
templates as needed. When constructing templates, if you place the Last Name and Case ID in
parentheses, they will sort to the top of the list and be readily available when you wish to use
them.
The first step in creating a case is to provide values for Last Name and Case ID. The combination
of these two fields determines a unique Case Identifier for each case – i.e., no two cases may be
built with exactly the same Last Name and Case ID.
Before building a portfolio of cases (especially if more than one user is building cases), it is
worthwhile developing a policy for how these fields are to be filled out. The model sorts cases
first by Last Name and then by Case ID. The model was designed this way under the assumption
that a given individual may have one or more cases – e.g., multiple policies or multiple modeling
assumptions. You can make use of this assumption to organize your portfolio efficiently.
If we assume Last Name is usually entered as given, the Case ID field becomes the place where
we have choices for values. A few examples of ways to construct Case ID include:
Case ID will accept any text string you input (with the exception of “<none>” and
“System Default” which are reserved), so you can simply enter whatever comes to mind.
This may be appropriate if you really only care about organizing your portfolio by Last
Name. Under this method Case ID becomes a sort of free form comment field. Before
adapting this approach, you might consider using the Projection Notes field (below) to
capture comments and use a shorter and more structured approach for Case ID.
Enter the date in year:month:day format and then some descriptive text. This has the
effect of sorting the cases chronologically. The date may be the policy date, the date you
build the case, the purchase date or some other date. This approach is similar to the first
case with a little more organization.
Enter the initials of the person who builds the case and then some descriptive text. This
approach is quite useful when your database is stored on the network and multiple users
are building cases. Cases built by the same individual are sorted together – it’s easy to
keep track of who built the case. This method also allows two different users to build
cases for the same individual which can be quite handy if you are building and storing
multiple cases to test various analytic scenarios. Note: After being saved, cases can
subsequently be edited and run by any user – not just the person who built the case.
Enter the user’s initials, the name or abbreviation of the insurance carrier and the policy
number of the insurance contract. This structured approach may be the preferred method
in the long run - it packs a lot of useful information into the Case ID field; it partitions
the database among users and it provides tracking back to the user who creates or owns
the case. This method also has the advantage of completely specifying the form of the
Case ID which results in consistency across databases and users.
The main consideration in using this approach is not to make the Case ID too long. Even
though you are allowed up to 255 characters, the most effective Case ID will be much
shorter. In practice, fields longer than 50 characters are rarely seen. In fact, the model
displays only about 40 characters in its drop-down lists. You can see the full width by
scrolling to the right, but this rapidly becomes very inconvenient.
Click the New… button. This causes the model to reset all of the input parameters to default
values – usually 0 for numeric quantities and “/” or “<none>” for text fields. The Create New
Case box will open, allowing you to enter a Last Name and Case ID.
After providing the Last Name and Case ID, click the Create button. Enter the case data in all
tabs, return to the Case tab, and click Save As….
The Save As… button causes the model to first check the database to ensure that no cases exist
with the requested Last Name and Case ID. If a matching case is found, an error message is
displayed and no case is created. Either specify unique values for your case or click Cancel to
exit without creating the case.
You can save your case at intermediate points during the input processes by pressing the Save
button, however, the case will only be saved if you have entered enough fields to fulfill the data
validation checks. These minimum inputs include the insured’s date of birth, the policy face
amount, maturity age, issue date and illustration date. The system will not allow the case to be
saved if the checks fail.
Notice that the first time you press Save after creating a new case, the Save As box is displayed
and the system saves your case without asking you for confirmation, since there is no existing
case to replace in the database. After the first time you save your case, the system will prompt
you for confirmation to overwrite the existing saved values.
See Section 5 for a more complete discussion of the Save and Save As buttons.
The use of the fields on the Carrier tab is optional and will not affect the valuation. They may be
useful if the model output is to be used in a portfolio valuation. The Carrier and Case Status lists
can be modified. Refer to Appendix C for instructions on customizing either list.
Select from a list of carriers stored in the System database. See Appendix C for instructions on
adding carrier names to the list.
Indicative only. Enter any combination of letter and numbers up to 50 characters in length.
Indicative only. Enter any combination of letter and numbers up to 50 characters in length.
Select from a list of status codes stored in the System database. See Appendix C for instructions
on adding status values to the list.
Enter a valid date. The value entered in this field will not be used directly by the model. The
intent of the Purchase Date field is to store the actual date the contract was purchased for
informational purposes.
There is another Purchase Date value stored by the model as a valuation parameter which is used
to determine the starting point to apply expenses to the valuation. The value entered in this field
will be used as the default for new valuation assumptions entered in the Projection screen.
The amount for which the contract was purchased. Not used by the model in the valuation
calculation. For indicative purposes only. May be used by the Portfolio model in the future.
The model supports Single or Joint (second-to-die) life policies. Selecting Joint in this field will
reveal an additional set of input boxes for the Secondary Insured.
This refers to the age basis used by the carrier and is used for displaying the “insurance age” in
the reports. Select one of:
This field is carried forward from the Case tab and is not editable. It is presented again on this
tab for convenience and is shown with a gray background to indicate that it cannot be changed.
The model follows the convention of showing locked fields in gray to clearly denote fields which
cannot be edited.
Enter the insured’s first name if desired. This field is used for display only – the model does not
identify cases by First Name.
Enter the insured’s date of birth in mm/dd/yyyy format. Please enter all years using 4 digits to
avoid any subsequent errors in date logic caused by assuming the century.
Before saving the case, the model will check that all values entered in the date fields are valid
dates. It will also check some basic relationships among the dates:
In addition, you cannot enter a combination of dates and Maturity Age that results in an attained
age greater than the policy Maturity Age (below).
4.3.6 Gender
The model recognizes differences in mortality patterns between smokers and non-smokers.
Select from the drop-down list either Smoker or Non-Smoker.
4.3.8 Diagnosis
This is an optional field that may be used for recordkeeping. Select the primary diagnosis or
medical condition from the drop-down list. This list can be modified. Refer to Appendix C for
instructions.
These are optional fields that may be used for reference. If applicable, enter the date that the
death claim was paid and the amount of the claim. This model does not use this information for
valuing the case, however, it can be used in the Portfolio Valuation model.
Basic contract and policy illustration parameters are entered on this screen.
Select either Universal Life or Non-UL. The contents of the Illustration tab will change to reflect
appropriate values for the selected product type. In addition, various fields on the Contract tab
will be enabled or disabled with changes to the Product Type.
Selecting Universal Life will cause the model to reverse engineer the contract illustration and
solve for modified premiums during the valuation step. When you select Non-UL, the model will
value the policy using the carrier’s premium and death benefits exactly as illustrated.
We caution that UL policies with illustrations that never build significant cash value or account
values are normally modeled more effectively as Non-UL. These policies ofter contain secondary
guarantees for minimum premium no lapse guarantees. Policies of this type are difficult to model
as Universal Life contracts since without cash values or account values, the model has no basis
for calculating a modified premium stream. The resulting COI’s may be calculated incorrectly.
For Option A plans, the Face Amount is carried forward as the default value when using the Fill
button for the Death Benefit column of the policy illustration.
For Option B plans, the Face Amount is the base death benefit to which the end of year account
value will be added to obtain the end of year death benefit shown in the policy illustration.
For Option C plans, the Face Amount is not used to fill the Death Benefit column of the
illustration. It must be entered however, since it is used as the denominator when calculating the
surrender charge per $1,000 of coverage used internally by the model.
Enter the attained age at which the contract matures, typically at age 100. Some policies mature
at age 95. A maturity age older than 100 is becoming more common.
For purposes of policy valuation, the Maturity Age is defined as the age when policy charges
(including cost of insurance) are no longer deducted from the policy and when premiums are no
longer accepted by the carrier. The model projects premiums to the Maturity Age. The
maximum maturity age that the model will support is 120, which corresponds with the last age of
the mortality tables used.
The Policy Issue Date is readily available from most policy illustrations. The model will not
allow an Issue Date prior to the insured’s birth date.
Enter the effective date of the illustration. The model calculates values on a monthly basis on the
day of the month corresponding with the Issue Date, also known as the policy “monthaversary”.
The Illustration Date that is entered will be interpreted by the model as the most recent
monthaversary. The model will not allow an Illustration Date prior to the Issue Date.
Check this field if the contract remains in force and the death benefit is payable beyond the
Maturity Age. If this option is selected, the model will continue to project death benefits until the
Extended Death Benefit Age (below) is reached.
For the period between the Maturity Age and the Extended Death Benefit Age, the model will
pay no premium and will deduct no Cost of Insurance charges or policy loads.
Note that selecting this option implies that the contract will not pay a maturity benefit when it
reaches the Maturity Age since the contract continues in force.
Enter the age at which the Extended Death Benefit expires. The maximum allowable value is 120
which is the common age for contracts with this benefit, although some contracts terminate the
benefit at age 110 or 115.
Select the issue state from the drop down box. This parameter is optional and is not used in the
valuation. However, this information is used by the Milliman Life Settlement Portfolio Valuation
model for reporting.
UL Illustration Parameters
Specify the death benefit option shown on the policy illustration. The choices are:
The use of the terms Option A and Option B is common in the industry to denote level death
benefit and increasing death benefit plans, respectively. Note that some carriers use Option B to
refer to level death benefit and Option A for increasing death benefit, while others use the terms
Option I and Option II. Level death benefit plans pay an amount specified at issue for the life of
the contract (ignoring any death benefit increases mandated by tax laws). Increasing death
benefit plans pay the specified amount plus the current account value at the time of death.
Assuming the account value increases over time, the death benefit payable does also.
These plans are also sometimes discussed in terms of the Net Amount at Risk (NAR) which is
defined as the difference between the amount payable at death and the current account value. For
Option A contracts, the NAR varies over time since the specified amount remains constant and
the account value changes. For Option B contracts, the NAR remains level over time since the
amount payable at death and the current account value both increase by the same amount.
Option C plans pay the specified amount plus a return of all the premium paid over the life of the
contract (less partial withdrawals and surrenders.) Option C death benefit increases may be
subject to limits based on maximum benefit amount or maximum attained age of insured. See
Option C Expiry Age and Option C Maximum Amount below.
The attained age at which the Option C death benefit amount stops increasing and is held level
thereafter. A value of zero here is treated as an indicator that there is no upper age limit on the
death benefit increase.
The death benefit payable under Option C plans may be limited by the terms of the contract to a
maximum amount. If so, enter the maximum benefit amount in this field. Entering a value of
zero here signals the model that there is no ceiling and that the benefit amount can grow without
limit.
The premium mode is the premium payment frequency used in the policy illustration from which
you are obtaining the current case parameters. This will usually be Annual, although the model
also supports Semi-Annual, Quarterly and Monthly modes. It is important to select the
appropriate illustrated premium mode in order to more accurately solve for COI’s. You will be
able to select a different premium mode for the projection when you run the case.
UL Illustrated Rates
The current crediting rate is the annual interest rate that the carrier is currently crediting as shown
on the policy illustration. It may also be referred to as the non-guaranteed crediting rate. It is
important not to confuse this rate with the projection Crediting Rate (6.3.4). The UL Current
Crediting Rate is used to reverse engineer the policy and must be consistent with all other values
entered from the policy illustration.
In contrast to the Current Crediting Rate, the Guaranteed Crediting Rate is the minimum annual
interest rate that the carrier is obliged to credit, as shown on the policy illustration. This rate is
used by the model in reverse engineering the cost of insurance rates. In the absence of exact
information, a reasonable estimate is 3% or 4%.
The annual interest rate earned by the loaned portion of the Account Value. This rate is between
the Guaranteed Crediting Rate and the Policy Loan Accrual Rate. If the policy does not have a
loan and you do not anticipate modeling a new loan, you can leave this rate at 0.
The annual interest rate charged to the loaned portion of the Account Value. This rate is usually
0% to 2% higher than the Policy Loan Crediting Rate. If the policy does not have a loan and you
do not anticipate modeling a new loan, you can leave this rate at 0.
UL Minimum Premiums
Some carriers require a minimum premium to be paid during the policy’s initial years to keep the
policy in force. This premium must be paid even if the policy has positive cash surrender value.
As the model calculates reduced premium levels from the Valuation Date forward, it will not
allow the premium to fall below the amount entered here as long as the contract remains in its
minimum premium period (below). Enter the annualized Minimum Premium Amount, if any.
The number of policy years from issue for which the Minimum Premium Amount must be paid.
The mode at which minimum premiums will be paid during the required period is not a separate
input item. It is assumed that minimum required premiums are paid on the same mode as those of
the policy illustration. (4.3.10)
Policy Value data is assumed to be as of the Illustration Date. These are the policy values that are
based upon actual premiums and other policy activity up to the date of the illustration. They are
often found in the text of the illustration. In contrast, the tabular values shown in the illustration
are policy values projected to the end of the current and future policy years. The tabular values
will be input on the Illustration tab (4.4).
Enter the policy’s Account Value as of the Illustration Date. The model uses this Account Value
to solve for the Cost of Insurance (COI) rate corresponding to the first policy year in the
illustration.
For illustrations that do not provide the Account Value as of the Illustration Date, you can input
an estimate. If you take this approach, it is a good idea to review the output to make sure that the
solved COI looks reasonable. Generally, the COI rates increase by policy year. Therefore,
estimating the Account Value might require several iterations. An alternative approach is to
leave the Account Value equal to zero. In this case, the model will often give an estimate for the
Account Value. This is discussed in more detail in Appendix H.
Enter the policy’s Cash Surrender Value as of the Illustration Date. The Cash Surrender Value is
the Account Value minus the Surrender Charge. Most, but not all, carriers provide this data on
the policy illustration.
If the policy has an outstanding loan, enter the amount of the loan as of the Illustration Date.
The amount entered in this field will be applied to the policy illustration on the Illustration Date.
It is a one time payment made at the start of the illustration. This is the value shown on some
policy illustrations as an initial premium payment in addition to the first year illustrated modal
premiums. Often a lump sum premium indicates that the policy has low balances and needs an
immediate infusion of cash.
Some carriers display illustrated account values and cash surrender values net of outstanding
policy loans and some carriers display gross amounts. If your illustration displays net amounts,
enter the amounts as shown and check this box. The model will then properly incorporate the
Policy Loan Value in its calculations.
Note that this box also affects values entered on the Illustration tab. If you check this box, the
model expects the Account Value, Cash Value and Death Benefit streams to be entered net of the
policy loan as well.
Enter the Premiums, Account Values, Cash Surrender Values, Policy Loads and Death Benefits
from the Policy Illustration. The model accommodates up to 40 years of illustrated values. The
model uses this data to solve for the Cost of Insurance (COI) rates. Carriers are required to show
values on both a guaranteed and non-guaranteed, or current, basis. Input the non-guaranteed
values.
4.5.1.1 Formats
Input the Annualized Premiums, Account Values, and Cash Surrender Values as numbers,
without commas or dollar signs. The system will add formatting when you are done entering
data.
Annual Per Unit and Monthly Per Policy loads should also be input without commas or dollar
signs. Decimal places are fine, in fact they are required to capture dollars and cents.
Example: 1234.56 is ok
1,234.56 is not ok
Input Crediting Rates and Percent of Premium Loads without the percent sign.
Example: 4.75 is ok
4.75% is not ok
0.0475 is not ok
The values that you enter on this screen are taken directly from tabular data displayed on the
policy illustration. The first row of the screen corresponds to the first row of the table shown in
the illustration.
The policy illustration projects the beginning values forward from the Illustration Date to each
subsequent policy anniversary. The values shown in the first row of the table are as of the next
policy anniversary even if the anniversary occurs less than one year from the Illustration Date.
In our example, the Illustration Date is 5/20/2004. The beginning values that were input in
Sections 4.3.18 – 4.3.22 (described earlier) are as of this date. The values shown in the first row
of the Illustration tab are as of 5/20/2005, which is the next policy anniversary after the
Illustration Date.
Our example Illustration Date happens to be a policy anniversary. Had it been another date, say
11/20/2004, the values that you would enter in row 1 would still be as of 5/20/2005 and would
represent the value of the contract at the next policy anniversary.
Because many illustrations include repeating values, there are “Fill” buttons to simplify the effort.
Pressing the Fill button above any column will open the screen below which collects input for the
column it was opened on.
If you forget which Fill button you pressed, just refer to the title bar to identify the column – Per
Unit Load in this case.
In this example, the Per Unit Policy Loads are a level $18.60 from year 1 to year 3.
4.5.2 Premium
The premium amounts as shown in the illustration. Do not adjust for non-annual modes – the
model does this for you. For example, if the value $12,000 is entered, the model assumes:
• Annual Mode: $12,000 on anniversary dates (i.e., policy month 1 of each year).
• Monthly Mode: $1,000 on each month’s anniversary date.
• Quarterly mode: $3,000 every 3 months (i.e., policy months 1, 4, 7 and 10 of each year).
When the illustration date is not an anniversary date, the first line of data represents a partial
policy year. In this case, please enter the full annual premium for the year - the model will divide
the premium by the number of regular payment dates remaining in the partial year and apportion
the premium equally between those dates.
Example:
The model divides by four and assumes $3,000 remains to be paid at the start of policy month 7
and another 3,000 is paid at the start of policy month 10. The model knows that the first two
quarterly payments were in the past and ignores them.
Dollar values (without formatting) for the next 40 years, or to policy maturity if maturity is
reached in less than 40 years.
Dollar values available to insured if the policy is surrendered. After some number of years, the
surrender charge period will expire and Cash Surrender Value (CSV) will equal Account Value
(AV).
To minimize the amount of typing needed, first enter the column of Account Values. Note the
policy year in which CSV first becomes equal to AV. Press the Fill button above the CSV
column and enter the projection year in which CSV = AV in the Fill box. The model will fill the
CSV column from this year forward with values from the AV column.
Pressing the Fill button for this column causes the model to display the fill dialog with the
Current Crediting Rate from (4.3.11) already entered for years 1 to 40. You can accept these
default values or adjust them as needed.
Policy loads are amounts that carriers deduct from the Account Value each month to cover certain
benefits and expenses associated with the policy. These charges are in addition to the COI
charges that are also deducted from the Account Value. The model handles three types of policy
loads: Percent of Premium, Annual Per Unit, and Monthly Per Policy.
Many carriers deduct a percentage of every premium dollar before crediting the remainder of the
premium to the Account Value. If the policy illustration provides this information, enter it here
remembering to enter 5.5% as 5.5 (without the “%” sign).
Some carriers charge a fixed amount per $1,000 of coverage per year. While these fees are
typically deducted monthly, they are typically expressed as an annual figure. Enter the annual
amount in this column. The model will convert it to a monthly amount.
It is also common for these loads to drop to zero after some number of years.
Many carriers deduct a fixed amount each month to cover their costs of policy administration.
Enter the monthly amount.
The appearance of this column will differ based upon the Death Benefit Option selected on the
Contract Tab. Any cells that are gray are locked for input. Pressing the Fill button will generate
the death benefit schedule based on the selected Death Benefit Option and the illustrated
Premium and Account Value as appropriate. It is therefore a good idea to input the values in the
Illustration tab starting from the left and working right.
All of the cells of the column will be white and allow for input. For level death benefits, use the
Fill button.
For policies with scheduled death benefit increases, enter the death benefit in each year. In the
example below, the death benefit increases in Projection year 3 from $5M to $7.5M. Note that
you can use the Fill button to quickly input the stream of remaining 7,500,000 values.
In some cases, the illustration for an Option A plan will show increasing death benefits that are
the result of rapidly increasing Account Values. The death benefit increases reflect the “Death
Benefit Corridor” requirement in federal tax law. A tell-tale sign that the Death Benefit Corridor
is in effect is that the Account Values increase in every year to maturity and eventually grow
larger than the original Death Benefit. In this situation, tax law requires that the Death Benefit be
increased so that it is at least as great as the Account Value. Illustrations like this are the result of
projecting high premiums such that the policy becomes “over-funded.”
This type of illustration is not well-suited to the purposes of the model, as it is difficult to solve
for COI’s in the years when the Account Value and Death Benefit are close in amount. It is
therefore a good idea to obtain a new illustration based on level premiums sufficient to keep the
policy in force to maturity, ending with a $0 or small, positive account value at the maturity age.
If you decide to evaluate the case based on an illustration with the Death Benefit Corridor in
effect, do not enter the death benefits as illustrated. Instead, use the Fill button to enter the death
benefits as a level schedule. The model automatically tests for the Death Benefit Corridor
condition. However, it may still error out due to the condition. In this case, the best approach is
to obtain an illustration with lower premiums. An alternative (less desirable) approach is to
shorten the illustration by a few years. The model will estimate COI’s from the point at which
the illustration ends to the maturity date. However, we urge caution because the result will not be
the same as if you had used an illustration with lower premiums.
For Option B, all of the cells of the column will be gray. The death benefit in each year will be
equal to the Face Amount plus the end of year Account Value for that year. Make sure that the
Account Values have been entered in the Illustration before pressing the Fill button.
For Option C, only the first cell will be unlocked for input. The death benefit in each year will be
equal to the prior year death benefit plus the current year premium. Before pressing the Fill
button, enter the illustrated premiums and the first year illustrated death benefit. If Death Benefit
Option C is selected, the first year Death Benefit cell on the Illustration tab is enabled for input:
In this example, the first year death benefit of 5,172,824 must be entered before pressing the Fill
button. This example also illustrates the importance of entering the full annual premium in the
first row. You can tell that the Illustration Date does not occur on a policy anniversary because
the model has colored the first year premium cell yellow to remind you that even though the first
year is a partial policy year, the full annual premium should still be entered.
To get an Option C starting death benefit as of the Illustration Date, the model subtracts the
premium paid from the Illustration Date through the end of the first year from the end of the first
year death benefit. The model includes the Lump Sum Premium amount (4.3.21) in this
subtraction.
If you have selected Product Type = “Non-UL”, the screen below will appear on the Illustration
tab. For Traditional products, the model collects only the schedule of Premiums, Death Benefits,
and Dividends.
4.6.1 Premium
Enter the annual premiums here. The model will adjust them to payment mode equivalents,
including the addition of payment fees. As with UL policies, enter the full annualized premium
for projection year 1, even if some of this premium has already been paid.
4.6.3 Dividend
If dividends are used to reduce the out-of-pocket premium payments, enter the annual dividend
amount here. If dividends are used to increase the death benefit, enter the total death benefit in
the Death Benefit column.
The Fixed Product frame will be disabled when a Universal Life product is being built, as in the
current example.
Choices are
• Whole Life
• Term
Whole Life products pay a maturity benefit equal to the policy face amount if the policy reaches
maturity age and extended death benefits are not selected. Term plans do not pay a maturity
benefit.
Choices are
• Annual
• Semi-Annual
• Quarterly
• Monthly
Enter the dollars charged per modal payment for administration. This amount is in addition to the
premium payment. For example, assume that the policy has an annual premium of $24,000 and a
collection fee of $420 per premium for quarterly payment mode. Enter $24,000 in the premium
column, select Quarterly premium mode, and enter $420 in the Premium Collection Fee. The
total premium for each year will equal $25,680 ($24,000 + $420 x 4).
Illustrated dividends are not guaranteed into the future. Therefore, you might choose to apply a
“confidence factor” to the dividend amount. The factor may range from 0 to 100, where 100
means 100%. For example, enter a factor of 100 if the full dividend will be used to offset the
premium payment. Alternatively, enter a factor of 80 if you expect only 80% of the dividend will
be available to be used to offset the premium payment.
This tab collects basic information about the assumed Life Expectancy (LE) of the insured. In
lieu of or in addition to LE’s, you may input a Mortality Factor (multiplier) which will be applied
to the chosen mortality table to project mortality. You will select whether to use LE or Mortality
Factor at the time that you set up Valuation Assumptions. Refer to Section 6.3 for more
discussion.
4.7.1 Underwriter
Enter Life Expectancy estimates by first selecting the underwriter associated with the estimate.
The model supports up to 5 LE estimates which are tagged by the value in the Underwriter field.
The system currently ships with the following predefined values:
• AVS
• EMSI
• Fasano
• 21st Services
• Other
The values displayed in the Underwriter field are stored in a table in the database and can be
expanded to any number of additional values. See Appendix C for more information about
adding additional underwriters.
4.7.2 Months
Enter each estimate of Life Expectancy (in whole months) that you have available. Enter values
even if you are not sure you wish to use them in valuation. Later, when you run the case (6.0),
you will be given the opportunity to select one or more LE estimates to actually use.
4.7.3 Date
Enter the effective date of each underwriter’s Life Expectancy (LE). Each LE may have its own
life expectancy date. Enter values even if you are not sure you wish to use them in valuation.
Later, when you run the case (6.0), you will be given the opportunity to select one or more LE
estimates to actually use.
The model will adjust the LE downward (i.e., age the life expectancy estimate) with the passage
of time from underwriting date to the Valuation Date.
In the following example, the LE has been entered as 86 months for the Primary Insured and 47
months for the Secondary Insured as of 12/9/2004. The model will reflect the survival of both
insureds from the Underwriting Date to the Valuation Date and shorten their LE’s accordingly
because an Underwriting Date was provided. In the example shown below, the Valuation Date is
6/5/2005, almost six months after underwriting. As you can see in the output, the model
shortened the LE of each insured by approximately three months as of 6/5/2005.
You can disable the actuarial aging of Life Expectancy to the Valuation Date by leaving the LE
Date field empty. But be aware that if you do not provide an LE date, the model will not reduce
the LE for the passage of time, even if many months or even years pass between underwriting and
purchase.
Entering 0 implies that no mortality will be assumed and the insured will live forever. Entering
100 means that 100% of the mortality table will be applied. Entering 200 would tell the model to
double all of the tabular mortality rates, consistent with a noticeable impairment.
Please be aware that entering 100 as a mortality factor does not imply that the insured is
“standard”. In fact, most carriers would expect that “standard” insureds purchasing underwritten
policies will have mortality below 100% of the 2001 VBT (Valuation Basic Table). In other
words, 100% of VBT is consistent with some level of impairment. From this perspective, a table
rating of, say, 200% is intended to reflect 200% of the carrier’s pricing expectation, not 200% of
the unadjusted table. Of course, the same caution applies to the newly released 2008 VBT as well
as the 2001 VBT.
The user must ascertain the appropriate desired mortality level in setting the mortality factor.
If a Mortality Factor is not desired, a value can still be entered as a default without affecting the
model. This is because the Mortality Factor is only applied if the model is instructed to use it
rather than the Life Expectancy estimate. The switch for this choice is set in the Projection
screen which is described in Section 6.
Entering a positive/negative value for Flat Extra Deaths shifts the mortality curve up/down by a
constant amount for the number of years specified in the Flat Extra Duration field. Enter an extra
number of deaths per 1,000 insureds. For example, entering 50 implies 50 extra deaths per 1,000
insureds per year, i.e., 5%.
If a Flat Extra is specified above, the period in years (starting from the LE date, not the Valuation
Date) for which it will be applied. If no period is entered, the model assumes the value 0 and no
Flat Extra will be applied.
Worksheet Input can be used as an alternative to Form Input to create a new case or edit an
existing one.
To create a new case using Worksheet input select Worksheet Input from the Milliman menu and
select New. The model will automatically tab over to the Base Case Input worksheet. Each of
the input cells in this worksheet corresponds to an input item in the Create or Edit Case screen.
In general, text in input cells appears in blue. Many of the input cells have prompts, which can be
seen by clicking on the cell.
In this example, the user is entering Carrier Name by selecting from a drop-down embedded on
the worksheet. A number of fields are entered using drop-down lists. You will not see the drop-
down arrow until you enter the field, at which time it will become visible. The lists for fields
Carrier Name, Case Status and Diagnosis are populated from tables in the System database. See
Appendix C for instructions on entering your preferred values in these tables.
A few fields require that you input codes, the meaning of which is not obvious. In the example
below, the user is selecting the Product Type by entering a 0 for Non-UL or a 1 for Universal
Life. In cases of this type, a yellow prompt appears to remind you of the allowable code values.
The model will not allow invalid values to be entered in these fields.
Enter the basic data for the case where indicated in columns C and D. Next, input the illustration
data in columns I through P for UL policies and T through U for non-UL policies.
To save your newly created case select Worksheet input, from the Milliman menu and then Save.
You must input a LastName and CaseID in the appropriate cells in the upper right of the
worksheet in order to save your case. Note that in Worksheet Input you cannot see a list of
existing case names. If you attempt to save a case with the same name as an existing case, a
message will appear that asks whether you want to replace the existing case with the one you just
created.
Changes to existing records are made through the command buttons found on the Case tab of the
Create or Edit Case screen. An existing case can also be modified using Worksheet Input. Refer
to Section 5.8 for more details.
See Section 4.0 for step by step instructions for creating a new case.
When the Create or Edit Case screen opens, it first makes a connection to the database and
retrieves a complete list of stored Last Names and their associated Case IDs. This list is
displayed in the Case List on the Case tab.
The first case in the list will be highlighted and the corresponding Last Name and Case ID will be
displayed in the lower left of the screen. At this point, no cases have been loaded. Scroll through
the Case List until you have located your case. Click Load to retrieve the case from the database.
You can also load the case by double clicking on the highlighted case or pressing the Enter key.
You can also type the first character of the Last Name to drop down the list to the first case
beginning with that character. For example, if you are trying to find “Schmidt” in the Last Name
list, typing “S” will take you to the beginning of the S’s.
Use the Page Down or Page Up keys for quicker scrolling. As you move through the list, the Last
Name and Case ID will be displayed in blue in the area below the Case List as each case is
highlighted. This can be helpful if your Last Name or Case ID are wider than the column width
of the Case List.
When the case is loaded successfully, the Last Name and Case ID will be displayed in the title bar
at the top of the screen.
After loading a case you may scroll to another case in the list and select it. It is important to be
aware that the previously loaded case remains in memory until you have loaded another case as
described above. You can always refer to the displayed Last Name and Case ID in the title bar of
the form to remind you which case is currently loaded.
Click Save to write an existing case to the database. An existing case is one whose Last Name
and Case ID are currently available from the Case List. If you click Save for a newly created case
that has not been saved previously, it will behave like the Save As button and prompt you for a
Last Name and Case ID. The Save As button is discussed in the next section.
When you click Save, the model will check to see if your case exists in the database and warn you
if you are about to overwrite an existing case. This behavior differs from standard commercial
software like Excel or Word which save existing documents to the same name without prompting
you for confirmation.
The Save button also checks that the Last Name and Case ID selected match the values from the
currently loaded case. Since it is possible to load a case and then scroll to another case in the
Case List, this check is done to ensure that you are saving the case you expect to save. If the
values do not match the following message is displayed:
This message indicates that (Doe, Sample Case) was loaded and is currently in memory, but
(Doe, Sample Whole Life) is selected in the Case List. If you dismiss this message with Yes,
(Doe, Sample Case) will be saved.
This button is handy when you plan to create a new case by modifying a current case and you
also wish to retain the current case. First Load the case you wish to use. Then click Save As.
You are presented with the screen below, where you can specify a new Last Name / Case ID
combination. The input boxes are initially populated with the case you have loaded.
Specify a new Last Name / Case ID and click Save or click Cancel to exit without saving.
The model will check the database before saving - if you have specified a combination which
already exists, a confirmation message will be displayed before overwriting the existing case.
Occasionally you may wish to rename an existing case. Scroll through the Case List until you
have located your case. Click Rename. You are presented with the screen below where you can
specify a new Last Name / Case ID combination.
Specify a new Last Name / Case ID and click Rename or click Cancel to exit without renaming.
The model will check the database before renaming - if you have specified a combination which
already exists, an error message will be displayed and the case will not be renamed.
The behavior of the Save As and Rename buttons are similar but not identical. The Rename
button is provided as a convenience – you can rename a case without using the Rename button by
following the steps below:
The Rename button simply allows you to perform the above sequence in one step instead of four.
Scroll through the Case List until you have located your case. Click Delete to remove the case
from the database. A confirmation message will be displayed. Click OK to continue and Cancel
to exit without deleting.
This button takes you from the database functions (building or editing a case) to the Projection
module. In this process, several steps are taken. Values are validated by the database module,
just as they would be if you saved the record. Next, the projection screen is activated, giving you
the choice of recalling Valuation Assumptions from previous projections or of setting new
assumptions. As with the Rename button, this button does what you could do in several steps in
one step. It is not required, but is provided for your convenience.
Worksheet Input can be used in conjunction with Form Input to edit an existing case.
Begin with Form input… and load the case that you wish to modify. Press the Cancel button to
close the form.
Next, tab over to the Base Case Input worksheet, immediately to the right of the COI Trend
worksheet. The worksheet has been filled with the data for your case.
You can proceed to update any of the cells directly. To save your changes, select Worksheet
input and Save.
To use the valuation module select Projection… from the Milliman menu. The Projection screen
is where you will create or modify a set of valuation assumptions for your case. It is also where
you will run your case. There is not a worksheet input counterpart to the Projection screen.
6.1.1 Overview
When the Projection screen opens, it first connects to the database and retrieves a list of all saved
cases with which it populates the Case List. A case can only be run if it was first built and saved
to the database as described in Section 4. If you wish to make a change to a base case, you must
close the Projection screen and return to the Create or Edit Record screen to do so.
As you scroll the Case List, the Last Name, Case ID, and Valuation ID are displayed in the lower
left of the screen.
6.1.2 Valuation ID
The Projection screens allow you to set all parameters which control the characteristics of the
premium funding pattern calculations, the net present value and IRR calculations. The
parameters are collectively referred to as the Valuation Assumptions. Following our interface
convention, fields which may be changed are displayed with white backgrounds.
A set of assumptions may be saved to the database and retrieved later if you wish to re-run the
case. Each set of Valuation Assumptions is saved under a unique Valuation ID and is attached to
a specific base case. There is no restriction (other than disk space) on the number of Valuation
Assumption sets you can save for each base case.
On the other hand, it is not required that any Valuation Assumptions be saved for a given case
unless you also wish for the output to be saved (see Save Output Checkbox below). If no
Valuation Assumptions have been saved, (e.g., you are valuing a case for the first time) the model
is initialized with a default set of assumptions and the Valuation ID is set to “<none>”.
The ability to save sets of Valuation Assumptions can be quite handy. As you make changes to
the assumptions and run the model, you can save assumption sets which are of particular interest.
By saving assumptions, you make it easy to re-create a valuation run at a later date. Please be
aware that the model does not save valuation output, it only saves Valuation Assumptions. By
saving these assumptions as a Valuation ID, you can recreate a useful valuation run in just a few
seconds, without the challenge of re-establishing every field and button exactly as you did the
first time.
The Load button retrieves both the base case and any associated Valuation Assumptions. To load
a case, select the Last Name, Case ID and Valuation ID combination from the Case List. Click
Load to retrieve the case. Double clicking on the highlighted case, or pressing the Enter key, will
also load the case. After the case is loaded the Last Name, Case ID and Valuation ID appear at
the top of the screen in the title bar, and the other buttons on the Projection screen become
activated.
As a case is loaded, various parameters are validated. (See Appendix A for validation rules.) For
cases built and saved under the current version of the model, this process should not typically find
errors.
For older versions of the model, particularly versions prior to v2.3.5, less input validation was
performed in the Create or Edit Case screen and it may happen that an older case is loaded which
fails the validation. If this occurs, the model will present a series of error messages culminating
with the following message:
In this case, the Valuation button will be disabled until the error is cleared. In order to clear the
error, return to the Create or Edit Case screen, load the case and attempt to save it. The data
validation checks will be invoked, and you will be presented with an error message directing you
to the cause of the error. You will only be allowed to save the case after you have corrected the
problem.
The behavior of the Load button changes depending on the values selected in the Case List. If the
Valuation ID is “<none>”, the Load button retrieves the base case and a set of default Valuation
Assumptions so that no assumption settings are left over from the last case loaded. If the
Valuation ID contains a valid value, the Load button retrieves the base case and the Valuation
Assumptions.
When you load a Universal Life case, the model will automatically reverse engineer the policy to
obtain Cost of Insurance rates. This should present no problems with cases built and saved under
the current version of the model, since input data is validated before it can be saved to the
database.
If the model loads a case from an older version of the model in which less input validation was
performed, the validation checks may fail. In this case the COI’s will not be calculated.
If you load a case with zero illustrated account values or zero illustrated cash surrender values,
the model will run, but any results should be interpreted skeptically. The model will not calculate
reliable COI rates if it does not have sufficient information to do so. Please see section 4.4.1 for
further discussion of this topic.
You can verify that the model was able to complete its COI calculations by referring to the status
bar at the bottom of the screen where the model will display a message after the COI run
completes:
Occasionally you may wish to rename an existing Valuation ID. This button works similarly to
the Rename button in the Create or Edit Case screen. Scroll through the Case List until you have
located your case. Select the case and click Rename. You are presented with an input screen
where you can specify a new Valuation ID name.
Note that the dialog box displays a status line informing you of the maximum allowable length of
the field and the number of characters you have used.
The Delete button deletes a single set of saved Valuation Assumptions identified by the Last
Name, Case ID and Valuation ID. The base case values are not affected.
Scroll through the Case List until you have located your case. Select the case and press Delete.
Before deleting, the system will ask you to confirm your request.
The New button resets the currently loaded Valuation Assumptions to their default values. No
stored Valuation Assumptions are affected, and the currently loaded base case is not affected.
This can be handy when you have changed many of the Valuation Assumptions and wish to start
over with a standard set of assumptions.
The Save button saves only the Valuation Assumptions - the base case values are not adjusted.
The Valuation Assumptions are saved under the currently selected Last Name, Case ID and
Valuation ID and are thus attached only to the specific case. This implies that you cannot save a
set of general Valuation Assumptions and apply them to every case that you load – you must
build and save sets of Valuation Assumptions for each case.
Before writing to the database, the system will check to see if the requested Valuation ID already
exists for the given base case. If it does, you will be prompted to confirm that you wish to replace
the existing Valuation Assumptions with your current values.
If you are creating a set of Valuation Assumptions for the first time (and therefore do not have an
existing Valuation ID), the pressing Save button will cause the model to pass control to the Save
As button described below.
The Save As button may be used when saving a case for the first time, or if you want to save a
modified version of an existing Valuation ID.
Before saving, a valid Valuation ID must be provided. Note that the system will not accept
“<none>” or “System Default” as a Valuation ID as these are reserved for use by the system.
The following screen will be presented to collect the name you wish to use:
The Valuation button initiates the projection process. Pressing the Valuation button causes the
survivorship table to be constructed from the mortality parameters, future premium and death
benefit cash flows to be built and weighted by the probability of survival and the income
statements (annual and monthly) to be constructed. After the model has completed its
calculations, the user will be returned to the Scenario Results sheet.
Premiums are automatically calculated when the Valuation button is pressed. (In versions prior
to 2.4.1, it was necessary to press a separate button to calculate the premiums which fund the
policy.) Note that the premium calculation step is only executed for Universal Life cases. For a
Non-UL case, the premium schedule is fixed. As the Premiums are processed, the status bar will
display the projection year currently being calculated.
The Cancel button closes the Projection screen with no further action.
Check this box if you wish to save your projection output to the database for use later in a
portfolio valuation. The output data that will be saved are the projected premiums and death
benefits.
When this box is checked, each time you press the Valuation button the model will save both
your current Valuation Assumptions and the output data. The reason for this is to ensure that
there is consistency between the model input and saved output. Note that each time you run the
same case, the new output will be copied over the previous run.
If you do not plan to save output, the simplest approach is to leave this box unchecked.
The Policy Tab is an informational page that carries over and displays data input in the Create or
Edit Case screen.
The Projection tab is the first place where you enter your projection assumptions for the current
case. The screen is initially displayed with all parameters set to default values or to any values
that were saved in the database and retrieved when the case was loaded. In many cases the values
already loaded will be appropriate and few changes will need to be made to this screen.
Projection Parameters
The Valuation Date is the date at which you would like to calculate the net present value (“NPV”)
of future policy cash flows. It is customary and advisable to select the same day of the month as
the policy was originally issued. For example, if the policy was issued on September 10, 2001,
select the 10th day of the month for the projection.
If the model cannot find a stored Valuation Date to load, it will default to the later of the
Illustration Date or the LE Date.
Note that the Valuation Date is validated before each of the calculation buttons is executed. A
Valuation Date preceding the Illustration Date or occurring after the policy maturity date will
trigger an error message and the model will not run until the date is corrected.
The model is a monthly model with each new month beginning on the Day of the policy issue
date. (This day is commonly called the policy monthaversary.) As carriers typically credit policy
transactions on the monthaversary, the model follows the same standard.
For example, if the contract was issued on April 16, all transactions will be assumed to take place
on the 16th of future months. If an Illustration or Valuation Date is entered with a day that is not
the issue day, the model will adjust the dates to begin processing on the most recent prior
monthaversary. For example, if the illustration is entered as of the 21st of the month, the model
will assume that these values were accurate on the 16th, 5 days earlier, as well.
The Projection Horizon is the maximum number of years the model will project Premium and
Death Benefit cash flows forward for the purpose of determining the net present value (“NPV”).
The maximum period the model supports is 40 years and you generally want the model set at that.
If you use a value less than 40, the model will truncate the cash flow projections and you won't
get the full stream of premium payments and death benefits. This will affect the calculated NPV -
either positively or negatively depending on other factors such as the LE, the number of years to
maturity and the number of future years for which you have a policy illustration.
The period (in months) between the time the insured dies and the carrier processes the death
claim and delivers the benefit check. Many carriers accrue interest, usually at the minimum
guaranteed rate or a rate required by the state, from the date of death (or death report) to the date
of claim payment. The model assumes no interest accrual. Therefore, the longer the assumed
collection delay, the more conservative the valuation.
This is the percentage of the death benefit that is assumed to be retained by the seller of the
insurance policy. The investor’s cash flows will be based upon receiving the death benefit minus
this percentage. The net present value of the policy will be reduced to reflect this reduction in
positive cash flow. For example, assume that the seller of the policy retains 5% of the death
benefit. Then the projected cash flows for the investor will be based upon receiving 95% of the
death benefit.
The annual interest rate assumed to be credited by the carrier in the future. This rate is used to
accumulate account values from the Valuation Date forward and therefore affects cash flow and
value calculations.
The projection Crediting Rate is an estimated number and some judgment on the user’s part must
be employed to set it. The UL Current Crediting Rate (4.3.11) provides an initial estimate. If the
carrier’s Current Crediting Rate appears high or low relative to similar policies from other
carriers, you may wish to set the projection Crediting Rate down or up a bit. Having said this, in
most cases the effect of this parameter is overshadowed by the effect of mortality so small
changes in this parameter do not have large impact on the resulting valuation.
The death benefit option for values calculated from the Valuation Date forward. If the policy is
currently an Option A (level) or Option B (Increasing) policy, the model is preset to Option A.
This is because the investor will benefit from this choice and does not need to make a decision.
However, if the policy is currently an Option C (Return of Premium) policy, the user must decide
whether to continue this pattern or revert to Option A. While it is generally true that the most
attractive answer for the investor is to continue the policy under Option C, this is an owner option
and the model will allow either choice.
The Purchase Date is the date that the policy is first acquired. The Purchase Date must be the
same as the Valuation Date or earlier. This field is used with the selections on the Expenses tab
to properly reflect the costs of acquiring and servicing a policy in the net present value. If the
model cannot find a Purchase Date to load, it will default to the Valuation Date.
6.3.8 Portfolio
This is an optional field that can be used for identifying policies by portfolio grouping. The
model has a list of generic portfolio identifiers, but you may modify them to serve your purposes.
(See Appendix C.) This field does not affect the valuation of the case.
Discount Rates
The model calculates a net present value (“NPV”) of policy cash flows at three different discount
rates of your choice, referred to here as Primary or Alternate IRR. Enter these in the format
shown. The three values displayed on this screen begin as default values, but can be changed
with each run. You may change the default values from the Options screen (Appendix B).
Income statements are built only for values calculated with this rate.
The model displays an NPV based on this IRR in the Scenario Results sheet. An income
statement is not built for this rate.
The model displays an NPV based on this IRR in the Scenario Results sheet. An income
statement is not built for this rate.
Use the Projection Notes field to enter a note about the case that you wish to save. You will find
that when running multiple scenarios for a single case it can be quite handy to keep a short note to
remind yourself (or others) of why the case was modeled as it was.
You are allowed a maximum of 255 characters in this field. When you reach the limit, the field
will not accept further input - in other words, you don’t have to calculate how many characters
you’ve typed – the system will do that for you. As a convenience, the number of characters you
have typed is displayed in the status bar in the lower left corner of the screen:
6.4.1 Overview
The Expenses tab provides you with the option of reflecting the costs associated with purchasing
and servicing a policy in your cash flow analysis. In this tab you select the expense assumptions
to be used from a list of expense factors that have been stored in the System database. We make
the assumption that expense factors are firm-specific and therefore we do not supply a set of
sample factors with the model. You can save sets of expense assumptions that are appropriate to
your business by using the Options screen (see Appendix B).
It is important to note that the expense factors that you build and save to the System database will
not be shared in the event that you use the DB combo utility to extract and share case data with
others. This is because the System database consists of values that users are able to modify
(expense factors, carrier names, status codes, portfolio groupings, etc.), making the System
database unique to your company.
In addition to the stored expense factors, you have the option of entering a set of User Input
expense factors directly in the Expenses tab for one-time use. Note that the User Input expense
factors will not be saved with your case.
We have provided some flexibility in the way the expense factors can be expressed. They can be
defined as a percent of policy face amount and as a flat dollar (per case) amount. In addition,
they can be expressed as purchase year (e.g., commission) or maintenance (ongoing) expenses,
and can be paid on an annual, quarterly, or monthly frequency. You can also specify an inflation
factor to be applied to flat dollar renewal expenses.
Each set of expense factors saved to the model is identified by its Expense Group name. Select
the appropriate Expense Group for the case you are evaluating from the drop down list. The
boxes in the lower part of the screen will be filled with the corresponding expense factors for the
Expense Group selected.
You can define a default Expense Group for your cases. As with other default settings in the
model, you are able to override the default for individual cases. Note that if you have cases in
your database from a prior version of the model (v7.1 or earlier), the default Expense Group will
automatically be assigned to these cases. Refer to Appendix B for instructions on setting the
default Expense Group.
The model is shipped with two Expense Groups: Zero Expenses and User Input. As the name
implies, Zero Expenses has all expense factors set to zero. If you do not use expenses in your
valuations, this Expense Group is an appropriate one to set as the default.
If you select User Input, the expense boxes will be unlocked and all factors will default to zeroes,
which you can overwrite with other values. These factors can be used to run your case, but they
will not be saved with the case. This feature may be useful for doing what-if testing.
The Expense Group and the actual expense factors that you used in your valuation, including
User Input, will be displayed in the Input Parameters report when you run the case.
6.4.3 Purchase
Purchase expenses are assumed to be paid only in the year that the policy was acquired. If you
select a Valuation Date that is after the first year of purchase, Purchase expense factors will not
be applied to the projection.
Purchase expenses can be defined as occurring annually, quarterly, or monthly during the first
year since the Purchase Date. The following table shows the timing of Purchase expenses based
on the specified frequency:
Timing of Purchase Expenses
6.4.4 Maintenance
Maintenance expenses are assumed to be paid beginning 1 year after the Purchase Date and they
continue indefinitely. The timing of Maintenance expenses during the year are assumed to follow
a similar pattern as shown for Purchase expenses.
Expense factors can be defined as a combination of annual, quarterly, and monthly factors. The
Total box displays the sum of the annualized expense factors.
For example, assume that the Purchase expenses for the policy include a one-time fee of 0.50% of
face amount plus quarterly fees of 0.025% of face amount. In addition, the Maintenance
expenses are defined as 0.001% of face amount per month. The expense boxes will display the
following values:
6.4.5 Purchase
Purchase expenses are assumed to be paid only in the year that the policy was purchased. If you
select a Valuation Date that is after the first year of purchase, Purchase expense factors will not
be applied to the projection.
Purchase expenses can be defined as occurring annually, quarterly, or monthly during the first
year since the Purchase Date, as described above for Purchase Percent of Face Amount expenses.
6.4.6 Maintenance
Maintenance expenses are assumed to be paid beginning 1 year after the Purchase Date and
continue indefinitely. The timing of Maintenance expenses during the year are assumed to follow
the same pattern as described above for Maintenance Percent of Face Amount expenses.
Per case expenses can also be expressed as a combination of annual, quarterly, and monthly
factors. The Total box will display the sum of the annualized expense factors.
For example, assume that the Purchase expenses for the policy include a quarterly fee of $100
and the Maintenance expenses are $200 annually plus $10 monthly. The expense boxes will
display the following values:
This field contains the annual rate of inflation applied to the Flat Dollar Maintenance expense
factors. The inflation rate is applied beginning 2 years after the Purchase Date, which is the
second Maintenance year, and is compounded annually each year thereafter.
For example, assume that the Maintenance expense factors of the previous example and that the
inflation rate is 3% per year. The following expenses will be applied:
In the Starting tab you will first select whether to begin with illustrated values or VOC values.
Next, you will specify the amount of premium assumed to have been paid between the Starting
Date and the Valuation Date. (Unless otherwise indicated, we will use Starting Date as a generic
name for the Illustration Date and VOC Date in this document.) At the bottom of the screen the
model displays the policy values as of the Valuation Date, given the selections you made above.
In order to project premiums, the model must first establish a starting point for policy values as of
the Valuation Date. The starting values have a direct effect on the premiums projected by the
model. That is because the model will not begin to pay premiums until it has drawn down the
starting account value to the threshold level specified by the user. As a consequence, the choice
of starting values will also have a direct effect on the net present value of policy cash flows. The
two choice for this option are Illustration and VOC.
6.5.1 Illustration
Select this option to indicate that the starting point for policy values is the Illustration. The
illustrated Account Value, Cash Surrender Value, Policy Loan balance, and Death Benefit as of
the Illustration Date will be displayed. These are the same values that were entered in the
Contract tab, under UL Policy Values as of Illustration Date (4.3.18 – 4.3.22).
6.5.2 VOC
VOC stands for Verification of Coverage. VOC values are generally obtained from the carrier
and represent policy values that are more recent than the illustration. VOC values, therefore,
reflect activity in the policy such as premium payments and withdrawals that have occurred since
the illustration was run. Select this option to indicate that the starting point for policy values is
VOC. By selecting VOC, the input boxes will be unlocked and you can input the VOC Date and
the appropriate VOC values.
Note that if there is a policy loan, you must specify whether the VOC values are net of policy
loan using the checkbox.
The Starting Date referred to in the heading will be displayed as either Illustration Date or VOC
Date, depending on which starting point was selected above.
In this section of the Starting Values tab, you specify the amount of premium assumed to have
been paid between the Starting Date and the Valuation Date.
Select this option if the premiums assumed in the illustration were paid between the Starting Date
and the Valuation Date.
Select this option if the amount of premium paid between the Starting Date and Valuation Date is
less than the illustrated premium assumed for that period.
Select this option if no premiums have been paid between the Starting Date and Valuation Date.
This field is where the model displays the amount of premium scheduled to have been paid
between the Starting Date and Valuation Date, according to the illustration.
The appearance of this box will depend upon which of the three premium payment assumptions
you selected:
• If you choose Illustrated Premium Paid, the model will display the illustrated premium in
this box. The amount will be the same as is displayed in the Due Amount box.
• If you choose Partial Premium Paid, this box will be unlocked and you will be able to
input the amount of premium paid between the Starting Date and Valuation Date. The
partial premium payment cannot be greater than the value shown in the Due Amount box.
• If you choose No Premium Paid, the model will display a zero in this box.
A simplifying assumption is made regarding the timing and mode of the partial premium. If
Partial Premium Paid is selected, the modal illustrated premium will be assumed to have been
paid on the premium due dates, beginning with the premium due date that is nearest to the
Valuation Date and working backward in time until the partial premium amount has been fully
allocated.
For example, assume that the illustrated premium is $12,500 per quarter. The policy anniversary
is September 20, the Illustration Date is November 20, 2006, and the Valuation Date is August
20, 2007. If starting values are based on Illustration and Illustrated Premium Paid, then the total
amount of premium assumed paid between the Illustration Date and Valuation Date is $37,500.
For this example, we will assume that starting values are based on Illustration and Partial
Premium Paid in the amount of $30,000. The following chart illustrates how the partial premium
will be applied:
Application of
Date Description Illustrated Premiums Partial Premiums Paid
9/20/06 Policy Anniversary
10/20/06
11/20/06 Illustration Date
12/20/06 Premium Due Date $12,500 $5,000
1/20/07
2/20/07
3/20/07 Premium Due Date $12,500 $12,500
4/20/07
5/20/07
6/20/07 Premium Due Date $12,500 $12,500
7/20/07
8/20/07 Valuation Date
In this example, the $30,000 of partial premium is assumed to have been paid in three quarterly
installments, beginning with the most recent premium due date. The third installment of $5,000
is equal to $30,000 - $12,500 - $12,500.
Under certain conditions, the model will estimate a lump sum payment, due on the Valuation
Date, to make up for premiums that were due but not paid according to the illustration. Refer to
Section 15.4 for more information on how this lump sum payment is determined.
In this section, the policy values are displayed as of the Valuation Date based upon the choices
made above. There values are carried over to the next tab, Options. If you do not make any
selections in the Options tab, then these are the values that the model will use to begin the
projection.
Refer to Section 15.3 for more explanation of the Starting Values Assumptions.
If the policy to be purchased has a large current Cash Surrender Value, you may wish to initiate a
policy loan or a cash withdrawal to take funds out of the policy. This tab collects the required
inputs. If the policy has an existing loan, you may opt to repay the loan as of the Valuation Date.
Note that it is important to first complete the steps on the Starting tab before finalizing your
choices on this tab as the starting policy values do not appear until you have made your choices
on the previous tab.
Before entering information on this screen, take a minute to familiarize yourself with the flow of
information displayed. At the top of the screen are three fields which carry forward your choices
from the previous tab. The middle section of the screen displays a number of options you can
select to determine how the model uses these starting values. The bottom section of the screen
displays three fields which show the effects of your choices on the policy values as of the
Valuation Date.
If you wish to assume a new policy loan going forward, enter an amount in the box. If you enter
a negative value, the system will not accept your input.
Enter an amount that you wish to withdraw from the policy before starting the projection. If you
enter a negative value, the system will not accept your input. If you enter a value that exceeds the
starting Cash Surrender Value, the system will automatically reduce your withdrawal to the
amount of available cash value.
The model will calculate a surrender charge amount using the values in the Account Value and
Cash Surrender Value fields above and the selected Surrender Charge Type.
where the Initial Death Benefit is $5 million and the Surrender Charge type has been selected as
Per Unit of Face Amount. For information about other surrender charge amounts, see the
discussion of surrender charge types (6.6.7 - 6.6.10) below.
Upon changing the Cash Withdrawal or Surrender Charge Type values, the system will calculate
the net cash withdrawal as New Loan + Withdrawal – Surrender Charge.
By checking this box the model assumes that cash will be used to pay any existing loan balance at
the time of purchase. The unloaned account value will be increased by the amount repaid. The
loan balance will be set to $0 for projection of future premiums. The amount of cash necessary to
pay the loan will be identified separately in the Monthly Income Statement and recognized in the
determination of a final Net present value.
When making a cash withdrawal from a policy, the death benefit is reduced by the amount of the
withdrawal. Some carriers reduce the death benefit by the net withdrawal - the gross withdrawal
less the surrender charge - rather than the full withdrawal. This effectively restores the surrender
charge to the death benefit. If this is the case, select Yes.
If this option is selected, the surrender charge is calculated by assuming that the policy defines
the surrender charge as an amount per $1,000 of face amount. This amount per unit can then be
applied to the number of units withdrawn to determine a surrender charge amount.
Surrender Charge Amount = (Amount Withdrawn / Death Benefit) × (Current Account Value –
Current Cash Surrender Value)
If this option is selected, the surrender charge is calculated by assuming that the policy defines
the surrender charge as a percent of the account value. This percentage can then be applied to the
amount withdrawn to determine a surrender charge amount.
Surrender Charge Amount = (Amount Withdrawn / Current Account Value) × (Current Account
Value – Current Cash Surrender Value)
In the current example, if Percent of Account Value were selected, the surrender charge would
be:
If this option is selected, no surrender charge will be applied to the amount withdrawn and the
Net Cash Withdrawal will reflect the full amount of the New Loan plus the Cash Withdrawal.
If this option is selected, the SC Amount field is enabled and you can enter a fixed dollar amount.
The amount entered is checked against the amount of the requested cash withdrawal and the
smaller value is used. The amount entered is also checked against the maximum required
surrender charge (Current Account Value – Current Cash Surrender Value) and the smaller value
is used.
6.7.1 Overview
The model solves for the premiums necessary to fund the contract to the standard of your choice.
You can choose to have values based on Cash Surrender Value or Account Value. Your choice
should be based on the policy’s lapse provision.
If in doubt, select Cash Surrender Value, as this is by far the more common standard, as well as
being the more conservative assumption. Premiums can be projected such that the Cash
Surrender Value (or Account Value) always exceeds $0 by a fixed dollar amount or by a fixed
number of months of COI’s or both. The specific amounts chosen on this page are generally
related to
Some purchasers are comfortable with very low balances, while other prefer a greater margin of
error.
If the loads and expenses in the carrier’s illustration are clearly defined, policy projections are
generally quite accurate and lower margins are needed. If the expense components are not clear,
then educated guesses become necessary. Future projections are less exact when this is the case.
Higher tolerances are recommended to reflect this.
If the carrier has a history of significant changes in COIs, loads or interest rates, accurate
projections are more difficult. Higher tolerances will help to reflect the cash flow uncertainty.
If this option is selected, premiums will be projected so as to maintain sufficient Cash Surrender
Value in the policy. That is, premiums will be calculated to maintain the Cash Surrender Value
above zero plus any Fixed Dollar Threshold plus any COI Threshold specified. Another way to
think of this is that the premiums will be projected so that the Account Value is greater than or
equal to the surrender charge plus the specified Fixed Dollar and COI Thresholds. Surrender
charges typically decrease by policy year and eventually reach zero.
If this option is selected, premiums will be projected so as to maintain sufficient Account Value
in the policy. Premiums will be calculated to maintain the Account Value above zero plus any
Fixed Dollar Threshold plus any COI Threshold specified.
The minimum amount by which the purchaser wishes to have the Cash Surrender Value (or
Account Value if policy lapse is so defined) exceed zero. Projected premiums will be set to
maintain at least this value in the account. This parameter allows you to specify a tolerance with
which to protect against some inevitable variation between modeled and actual results.
In this example, the model assumes that the purchaser will not pay any premiums until needed to
keep the policy Cash Surrender Value at $500. From that date forward, premiums will be paid as
necessary to sustain a $500 Cash Surrender Value.
The contract can also be maintained so that the Cash Surrender Value (or Account Value)
exceeds the Fixed Dollar Threshold by a chosen number of months of COIs. This is an increasing
dollar standard, as COIs generally increase with age.
Enter the number of months of COIs to include in the threshold. Entering a value of zero implies
that no COI Threshold is desired.
Also, please be aware that the use of this feature can cause some unevenness in funding patterns
when paired with level premium options.
The parameters on this tab control the method of calculation and modality of the premium
payments necessary to fund the contract from the Valuation Date forward.
The model allows the user to calculate premiums under several methods:
Under this assumption, the model assumes no premiums are paid until they must be to maintain
the contract in force. Once the contract requires premiums to meet minimum standards, the
minimum will be solved for each month to meet the account value or cash surrender value
definition of sufficiency. This method generally develops the greatest financial value, but at the
cost of the greatest administrative workload as premium amounts can vary monthly.
Under this assumption, the model will solve for the minimum premium per policy year to
maintain the contract in force. The premium will reflect the Payment Mode (Annual, Semi-
Annual, Quarterly or Monthly) chosen by the user. With this assumption, premium levels only
change once per policy year. Choosing this option will generally result in a higher total premium
amount each policy year compared to the total annual premium under the Monthly option. The
result will be a lower the financial value of the contract relative to the Monthly option.
This assumption is similar to Level modal premium (adjusted annually), except that the modal
premium will remain level for the number of months specified by the user. At the end of the
specified period, the Model will switch to the annually adjusted modal premium option for the
remainder of the projection.
Note that the number of months for which the modal premium remains level might not match
exactly with the number n specified by the user. The reason for this is that the model solves for
future premiums on a policy year basis, with the only partial policy year being the first year of the
projection (if the Valuation Date is not a policy anniversary). In other words, the model will
solve for the level modal premium up to the last complete policy year that falls within n months
beyond the Valuation Date. An example might make this point clearer:
Example
Assume a policy issue date of 5/20/2005 and that level quarterly premiums for 25 months has
been selected. If the Valuation Date is 3/20/2008, then 25 months beyond this date is 4/20/2010.
The last complete policy year that falls within this period ends on 5/19/2009. Therefore, the
model will solve for level quarterly premiums from 3/20/2008 to 5/19/2009, which is only 14
months.
Variation 1
Similarly, if the Valuation Date is 5/20/2008, then the model will solve for level quarterly
premiums to 5/19/2010, or 24 months from the Valuation Date.
Variation 2
If the Valuation Date is 7/20/2008, the model will solve for level quarterly premiums to
5/19/2010, or 21 months from the Valuation Date.
Another important point to keep in mind is that as the model solves for future premiums, the
prevailing constraint is keeping the policy in force. Therefore, if the illustrated cash surrender
values are zero for a period of time, the model will use the illustrated premiums in those years on
the assumption that they are the minimum levels required to keep the policy from lapsing. The
premium solving logic, including user requested mode, will resume after the end-of-year cash
surrender value has reached a positive value.
As the name implies, under this assumption the model uses the premiums and Payment Mode
specified by the user. Selecting this option enables the Premium button. Click on the button to
input the desired premium schedule. Annualized premiums should be entered regardless of the
premium mode selected. The model will adjust accordingly.
For any funding pattern other than minimum monthly premiums, the user must also select a
payment mode. There are four options: Annual, Semiannual, Quarterly and Monthly.
Note that many users set this value to a mode other than Annual since premiums paid in the year
of death are not refundable under the terms of many contracts. If you assume Annual premium
payments, you can expect to pay (on average) an extra half year of premium in the year of death.
In some cases, you may not wish the model to reduce the projected premium immediately. By
entering a non-zero value in this field, you can force the model to pay the illustrated premium for
a number of years before beginning to solve for a reduced premium.
Note that this field cannot be used to override the model’s automatic treatment of cases with zero
Cash or Account Value in early years of the illustration. If the model would otherwise force
illustrated premiums to be paid for n years due to zero policy values, entering a value less than n
in this field will have no effect.
This tab collects the inputs necessary to construct the survivorship table with which future cash
flows are weighted to arrive at the current contract value.
There are two mutually exclusive ways of specifying mortality patterns – either specify an
estimate of Life Expectancy or specify a percentage of the mortality table. When Specify Life
Expectancy is selected, the Life Expectancy frame is enabled and the Mortality Factor frame is
disabled. The reverse occurs when Specify Mortality Factor is selected.
When Specify Life Expectancy is selected, the model solves for a uniform percentage of the
selected mortality table to match the underwriter’s Life Expectancy (LE).
When Specify Mortality Factor is selected, the model applies the input mortality multiple to the
selected mortality table. In this case, the resulting LE very likely will not match the underwriter’s
LE unless the selected mortality table and mortality assumptions are the same as those used by
the underwriter.
The Life Expectancy values that were entered from the Create or Edit Case screen appear here.
See (4.6) for a discussion of LE inputs. On this screen you are allowed to choose how the model
uses your LE values.
The model calculates NPV’s for each LE that you have input plus a selected LE, in a single run.
The Annual Income Statement and Monthly Income Statement reports will be based upon the
selected LE. You may choose either Average or User Input as the selected LE.
In this example, the model will calculate the average of all checked LE’s. Again, the model only
applies this function to the LE’s that are checked and does not consider LE values that are not
unchecked.
6.9.2.1 Average
Select one or more LE values by clicking the checkboxes next to each LE. The model calculates
the arithmetic mean of the checked items and displays the results in the Month and Date boxes to
the right of the drop-down. Note that the model does not average the LE dates. Rather, it simply
uses the most recent date. Since the model (not the user) is calculating the requested statistic, the
statistic boxes are disabled for editing.
If you would like to have the Income Statement and other reports to be based on a specific input
LE, click on that box only and then choose Average as your selected LE.
This option allows you to model any LE that you wish to input. When this option is selected, the
model first clears the statistic boxes and then enables them for editing so that you can enter the
desired values.
The Date field may be left empty, in which case the model will not age the Life Expectancy
estimate. See (4.6.3) for a discussion of LE Aging.
If you selected Specify Mortality Factor (above), this frame will be enabled and the model will
determine the survivorship table by applying the mortality factor to the selected mortality table
rather than by using an estimate of Life Expectancy. See (4.6.4) for a discussion of the Mortality
Factor.
The Flat Extra field is available for use under both of the Mortality Development options above.
See (4.6.5) for a discussion of the Flat Extra Mortality value.
Mortality Table
The model features the ability to choose the mortality table and a number of parameters for
projecting mortality.
The model is shipped with two sets of mortality tables, the 2001 and 2008 Valuation Basic Tables
(VBT). In order to specify the exact table that you wish to use in the mortality projection you
will make two selections. First, select either the 2001 VBT or 2008 VBT from the list in the
Mortality Table drop down box. Note that you must also choose between Age-Nearest-Birthday
(ANB) and Age-Last-Birthday (ALB) versions of the tables. The second selection you must
make is described below in 6.10.2.
Both the 2001 and 2008 VBT distinguish between males and females, smokers and nonsmokers.
You have already specified the gender and smoker class of the insured in the Create or Edit Case
screen and, therefore, do not have to specify them again here.
The VBT are “Select & Ultimate” mortality tables, meaning that mortality rates depend upon the
age of the insured at time of underwriting and the time that has passed since underwriting. The
insured’s date of birth and the LE dates are used for determining which rates are read from the
chosen mortality table.
You may add other mortality tables, although at this time, we are not providing an automated way
to do so. If you would like an additional custom table added to the model, please contact us. We
will be happy to update your model with the table at a small additional cost. Please note that the
inclusion of custom tables is not intended to express a specific recommendation by Milliman nor
an opinion regarding the appropriateness of the tables to any specific case.
The second parameter for specifying the mortality table to use in your projection is selected from
the Relative Risk drop down box. If there are two insureds, then you must select the Relative
Risk table for each insured. The choices that are displayed in this list will depend upon the
selection you made in the Mortality Table list and the smoker class that you specified in the
Insured tab of the Create or Edit Case screen. The choices are summarized as follows:
If you selected 2001 VBT or any set of tables other than 2008 VBT, the Relative Risk box will
not be active. The effective choice is “Primary”.
The 2008 VBT is a set of mortality tables that not only reflect differences based on gender and
smoker class, but also distinguish by degree of underwriting and by rating classifications.
Mortality experience for fully underwritten insureds is reflected in the Primary table, whereas
experience for insureds that were not fully underwritten is reflected in the Limited Underwriting
table. The Limited Underwriting table would most likely be used for policies with small face
amounts.
The Primary table has been further subdivided by rating classification into Relative Risk tables.
For nonsmokers, there are 10 Relative Risk tables that reflect risk classifications ranging from
70% to 160% of aggregate nonsmoker mortality. For smokers, there are 4 Relative Risk tables
that represent risk classifications ranging from 75% to 150% of aggregate smoker mortality.
Please refer to the FAQ in Appendix I for more information on the mortality tables.
The Blending Factor provides the option of modifying the chosen mortality table by blending the
Select rates with the Ultimate rates, using a weighted average calculation. Input the percentage
weighting to apply to the Ultimate rates in the Blending Factor box, ranging from 0 to 100%. The
weight applied to the Select rates will be 100% minus Blending Factor.
Using a Blending Factor that is greater that 0 has the effect of increasing mortality rates in early
durations, making the pattern of mortality rates less steep than the base table in those years.
Mortality Adjustments
After selecting the mortality table and applying a Blending Factor, the table can be further
modified for mortality improvement and/or selectively modified by duration since underwriting.
For purposes of describing the following mortality adjustments, we will use the term
Underwriting Date to refer to the LE Date, if Specify Life Expectancy is selected, or the
Valuation Date, if Specify Mortality Factor is selected.
The mortality improvement factors supplied with the base model are:
If the Specify Life Expectancy option is chosen, the use of mortality improvement factors will
change the slope of the mortality curve (i.e., the relative timing of deaths), and may change the
overall life expectancy, depending on the order in which the adjustments are applied. Refer to
6.10.11 below for a discussion of this. The user should discuss with the life expectancy provider
whether and to what degree mortality improvement was considered in the evaluation and choose
assumptions consistent with this response.
If the Specify Mortality Factor option is chosen, the use of mortality improvement factors will
change the slope of the mortality curve and will result in a different life expectancy than if no
mortality improvement is applied.
You may add other mortality improvement factors. The model provides an easy way of creating
and managing mortality improvement factors in the Options screen. Refer to 9.3.9 for details.
The selected improvement factors will be displayed below in the Mortality Improvement section
of the screen.
The Origin Date is the effective date of the selected mortality table. For example, the 2001 VBT
has an Origin Date of January 1, 2001. The 2008 VBT has an Origin Date of January 1, 2008.
Improvement Factors
The mortality improvement factors you selected are shown in read only mode below the group
drop-down. For Joint life cases, a second line of values for the Secondary Insured appears below
the Primary Insured. Currently, these factors cannot be modified directly in this screen.
However, they can be modified from the Options screen.
The rate at which the mortality rates have improved (decreased) between the Origin Date and the
Underwriting Date.
The mortality improvement rate that applies in the first year following the Underwriting Date.
The rate at which the mortality rates are improving (decreasing) during the first era (years 2 to
15) after the Underwriting Date.
The rate at which the mortality rates are improving (decreasing) during the second era (years 16
and later) after the Underwriting Date.
You may choose to modify the mortality table selectively by age, duration, gender, and smoker
class. To do so, select the set of duration adjustment factors from the Grid Name drop down box.
No particular set of duration adjustments are supplied with the model. You may create or manage
your sets of duration adjustments in the Options screen. Refer to 9.3.7 for details.
Mortality duration adjustments are applied to the selected mortality table after any Blending
Factor has been applied.
If the Specify Life Expectancy option is chosen, the use of duration adjustment factors will
change the slope of the mortality curve (i.e., the relative timing of deaths), and may change the
overall life expectancy, depending on the order in which the adjustments are applied. Refer to
6.10.11 below for a discussion of this.
If the Specify Mortality Factor option is chosen, the use of mortality duration adjustments will
change the slope of the mortality curve and will result in a different life expectancy than if no
such adjustments were made.
The use of mortality improvement and mortality duration adjustments changes the slope of the
mortality curve and therefore changes the life expectancy resulting from a specified Mortality
Factor. Alternatively, if a Life Expectancy has been specified, then the effect on the modeled life
expectancy will depend upon the choice you make regarding Adjustment Order.
In general, for a specified Life Expectancy, the model derives a multiplier, or scaling factor, to
apply to the mortality table so that the input Life Expectancy is reproduced. Adjustment Order
determines whether the multiplier is derived before or after the mortality table has been modified
for mortality improvement and duration adjustments.
If the mortality improvement and mortality duration adjustments are applied to the
mortality table before this multiplier is derived, then the modeled life expectancy will
match the input life expectancy.
If the mortality improvement and mortality duration adjustments are applied to the
mortality table after this multiplier is derived, then the modeled life expectancy will be
different than the input life expectancy. It will be longer if mortality improvement is
used and/or duration adjustments are less than 100%. It will be shorter if duration
adjustments are greater than 100%.
You might choose to test the effect of Adjustment Order on your valuations as a means of
sensitivity testing.
7.0 Reports
Once the model has completed the valuation calculations, the results are reported in the first 7
worksheets of the model. Any combination of these reports can be printed by selecting Reports…
from the Milliman menu item.
At the top of each report you will find information to identify the case that was run. This includes
the Insured Last Name, Case ID, Valuation ID, and Valuation Date. Reports that show valuation
results will also display information about the mortality assumptions used in the projection.
These can be found in the gray border across the top of the page. The information includes the
mortality table and mortality improvement factors selected, as well as whether the mortality
development was based on input LE or input mortality multiplier.
This report is intended to be an executive summary of the valuation results, displaying the NPV
for each combination of IRR and mortality specification (LE or Mortality Multiplier). If
Mortality Multiplier was specified, the report will show NPV’s based on the multiplier as well as
those based on 80%, 90%, 110%, and 120% of the multiplier.
Selected policy values as of the Valuation Date are displayed in the upper section of the report;
these include the Death Benefit, Account Value, and Policy Loan Balance. Also displayed are
transactions assumed on the Valuation Date such as repayment of a loan, a new loan, and cash
withdrawal. The lump sum payment due on the Valuation Date, as a result of premium payments
being less than those assumed in the illustration (Sections 6.5, 15.3-15.4), is shown as Immediate
Premium.
This report includes a useful feature that allows the user to input a hypothetical value and quickly
calculate the IRR based on this value. You can do this by typing a new value in the Net Present
Value field (in blue). Then, select IRR from the Milliman menu. Note that doing this
regenerates the Annual Income Statement and Monthly Income Statement under the new IRR
assumption.
The Annual Income Statement report shows expected cash flows summarized by policy year.
The model performs its calculations on a monthly basis and therefore the Monthly Income
Statement is the appropriate report to review for an understanding of the cash flow calculations.
This section will provide an overview of the cash flow reports. A more detailed treatment can be
found in the next section covering the Monthly Income Statement.
The major sections of the report are described below; the letters correspond with the labels shown
in the sample report.
E
B
C
A. The banner displays some of the assumptions used for the valuation, including the selected
mortality table and mortality improvement factors, and the mortality specification (LE or
Mortality Multiplier). It also shows the case and valuation assumption identifiers along with the
Valuation Date.
In the sample shown above, the valuation was run using the 2001 VBT ANB table with Sample
Factors for mortality improvement. The mortality was calculated using an Input Life Expectancy.
We can also see that the Valuation Date is March 20, 2008 and the case is identified by its Last
Name, Case ID, and Valuation ID.
B. Below the banner, on the left, we show the face amount and death benefit as of the Valuation
Date, gross and net of any outstanding policy loan. The selected premium mode for the
projection, the collection delay, and the actual projection period are also shown.
In this example, the face amount is $5 million, as are the gross and net death benefit amounts on
the Valuation Date. If the policy had been projected assuming a policy loan going forward, the
Net Death Benefit would be the $5 million decreased by the policy loan balance as of the
Valuation Date.
C. To the right of the face amount the report shows LE as of the underwriting date and as of the
Valuation Date.
The insured in this example has an LE of 52 months with an underwriting date of February 20,
2008. This LE is reduced to 51.3 months on the Valuation Date of March 20, 2008.
D. The tabular values shown in the report, reading from left to right, include projected premiums,
mortality rates, survivorship curve, and cash flow components by policy year. The first policy
year displayed is usually a partial year because it begins on the Valuation Date. The tabular
values will be discussed in some detail in the next section.
E. The NPV of each of the cash flow components, discounted at the Primary IRR, is shown to the
right of the LE information. The NPV’s will be covered in the next section.
The Monthly Income Statement report shows the same information as in the Annual Income
Statement, except at a monthly level of detail. In this report, one can see how the expected cash
flows are developed based upon the projected premiums and benefits and the mortality
assumptions used.
The focus of this section is to provide more detailed explanation of the tabular values. The
descriptions that follow correspond with the column headings shown in the sample report.
The model calculates the cash flows on a policy monthaversary basis. The first Start Date is
always the Valuation Date. Thereafter, the Start Date is the policy monthaversary date. The End
Date is the day before the next policy monthaversary.
The policy in the sample report was issued on May 20, 2005 and therefore has monthaversaries
on the 20th of each month. The Valuation Date is March 20, 2008.
The Policy Year and Month reflect the time since the policy was issued. In the sample report, the
projection begins in the 11th month of the 3rd year since the policy was issued.
Original Insurance Age is the attained age of the insured as determined on the policy issue date.
From the carrier’s perspective, the insured’s age is assumed to change on the policy anniversary
and not on his/her birthday. The Original Insurance Age is displayed as reference back to the
carrier illustration. Otherwise, it is not used in the valuation. If there are two insureds, the age of
the younger insured is displayed.
Newly UW Insurance Age is the attained age of the insured as determined on the underwriting
date. The underwriting date is the latest LE date. If no LE date was entered, or if Mortality
Multiplier is assumed, the underwriting date is the Valuation Date. The insured’s age is assumed
to change on the anniversary of the underwriting date. The Newly UW Insurance Age is the
reference age used in development of the mortality rates. If there are two insureds, the age of the
younger insured is displayed.
In the sample report, the insured was deemed to be 80 years old on the policy issue date, May 20,
2005 and is assumed to increase in age on May 20 of each succeeding year. On the underwriting
date, February 20, 2008, the insured’s age based on nearest birthday is 83 and is assumed to
increase in age on February 20 of each succeeding year.
The Modal Projected Premium column shows the schedule of premiums projected by the model
on the payment mode assumed in the valuation. The Annual Projected Premium column is the
sum of the modal premiums for the policy year.
In the example shown, the premiums were projected on a Minimum Monthly basis. The
projection begins in policy year 3 and the projected premium in the two months remaining in that
policy year is $0. In policy year 4, the projected premium is $0 in the first month, $11,137 in the
second month, and $24,634 in the remaining 10 months of the year, for a total annual premium of
$257,476.
The Scaled Monthly Mortality Rate is the probability of death based on the selected mortality
table, mortality improvement factors and mortality specification (LE or Mortality Multiplier).
The model first calculates annual mortality rates and converts them to a monthly basis.
Scaled Inforce Lives represents the number of lives expected to survive to the end of the month
and is calculated as (number of inforce lives at the end of the previous month) x (1- mortality rate
for the current month). We assume that the insured is living on the Valuation Date and therefore
the number of inforce living at the beginning of the first month is always assumed to be 1.0.
Scaled Inforce Lives is also known as the survivorship curve where each value in the column
represents the probability of survival from the Valuation Date to the end of that particular month.
Units Inforce represents the unpaid death benefit covering the surviving lives, where a unit of
death benefit is $1,000. It is calculated as the (death benefit/1000) x (number of lives expected to
survive to the end of the month).
In the example, probability of death (monthly mortality rate) in the first month is 0.00619.
Therefore, the probability of survival to the end of the first month is 1 x (1 – 0.00619) = 0.99381,
and the probability of survival to the end of the second month is 0.99381 x (1 – 0.00619) =
0.98766. The inforce units at the end of projection month 2 can be calculated as
$5,000,000/1,000 x 0.98766 = 4,938.3 (ignoring rounding).
The next five columns show the detail for the main components of the cash flows. The first three
are assumed to occur at the beginning of the month, while the last two are end-of-month cash
flows.
If a new policy loan, cash withdrawal, or policy loan repayment is assumed to take place on the
Valuation Date, the amount of that transaction will be displayed in the first month of the
projection. The value in all remaining months will be zero. A new policy loan and a cash
withdrawal are assumed to be positive cash flows, while a policy loan repayment is considered to
be a negative cash flow item (or, cash outflow).
The Expected Premium Paid is the Modal Projected Premium times the probability of survival to
the beginning of the month. Premium payment is assumed to occur at the beginning of the month
in which it is due.
In the example, the Modal Projected Premium is zero until projection month 4. The Expected
Premium Paid in that month is $11,137 x 0.98154 = $10,931. This is displayed as a negative
value because it is a cash outflow.
Expected Expenses Paid is equal to the calculated management expenses times the probability of
survival to the beginning of the month. Like Premium, Expenses are assumed to be incurred at
the beginning of the month in which they are due. Expected Expenses Paid appear as a negative
cash flow item.
Expected Benefit Received represents death benefit payments as well as the payment of the
maturity benefit, if the projection extends to the maturity date of the policy. For any given
month, the Expected Benefit Received is equal to the (Units Inforce at the beginning of the
month) x 1,000 x (monthly mortality rate). There are two timing assumptions made with respect
to Benefits. First, they are assumed to be an end of month cash flow item. Second, the receipt of
the Benefit will depend upon the number of months assumed for the Collection Delay. If there is
a Collection Delay of n months, the Expected Benefit Received calculated for a given month is
shown n months later in the schedule. Expected Benefit Received is a positive cash flow item.
The expected maturity benefit is any benefit due upon maturity of the policy x the beginning of
month inforce lives x the mortality rate. It is assumed this amount is received at the end of the
month.
In this example, the expected death benefit in the first month of the projection is $5,000.000 x
1,000 x 0.00619 = $30,957 (ignore rounding). There is a 2 month Collection Delay. Therefore,
the Expected Benefit Received for month 1 is shown in month 3 of the projection. The Expected
Benefit Received for month 2 appears in month 4, and so on.
In any given month, the Expected Net Cash Flow is the result of summing the values in the four
previous columns, after adjusting the beginning of month cash flows to an end of month basis.
The adjustment is equal to one month of interest, using the Primary IRR.
In this example, the Expected Net Cash Flow in month 4 of the projection is equal to -$10,931 x
1.141/12 + $30,765 = $19,714.
This columns shows the annual COI rates per $1,000 of death benefit. The model solved for
these COI rate using the information that was input from the carrier’s illustration. Values are
solved for and then smoothed to more closely mirror standard industry practices. The annual COI
rates are converted to monthly rates, which are used in the Account Value calculations.
The tabular columns display valuation periods and values on a monthly basis beginning with
Projection Date.
The Projected Illustration shows the development of policy values based on the premiums
projected by the model. It is a direct counterpart to the carrier illustration that was input. This
report is useful for checking that policy loads were input correctly.
The Input Parameters report provides a one-page summary of the data input for the case as well
as the Valuation Assumptions. This report, along with the Carrier Illustration, contains the
information you used to build and evaluate the case. Therefore, it can be a useful source of
documentation.
This page shows the values that were entered from the carrier’s own illustration. This is both a
convenient data accuracy checkpoint and a valuable source of file documentation.
This page shows the Cost of Insurance rates that were solved for, using the Illustration as the
basis of calculation. Values are solved for and then smoothed to more closely mirror standard
industry practices. The yellow column of COI rates (Column V) are those used in future product
performance calculations.
This tab shows detailed results from the COI reverse engineering process. This tab and the Solve
Premium tab below can be quite useful if you are interested in reviewing the details of the COI
and premium calculations performed by the model.
The Solved COI tab will only appear if you have enabled calculation auditing in the Options
screen:
This tab shows detailed results from the premium projection calculation. This tab and the Solve
COI tab above can be quite useful if you are interested in reviewing the details of the COI and
premium calculations performed by the model. As with the COI tab, this tab will only appear if
you enable calculation auditing in the Options screen.
After calculations have been completed, user control will be returned to the Scenario Results
worksheet. Select Reports… from the menu to open the print menu.
This brings up a sub-menu of choices, which allows the user to print the reports of their choosing.
In this example, the Scenario Results, Annual Income Statement, the Projected Illustration, Input
Parameters, and Carrier Illustration will be printed.
Note that you can quickly print all reports by pressing the Print All button rather than clicking the
individual check boxes one at a time. This can be very handy especially when you are running a
series of cases and printing to an Adobe PDF file for record retention.
The model performs a number of checks of the input parameters before allowing a case to be
saved or run. The checks are performed in three places:
If checks 1 or 3 fail, the model will refuse to save or run the case respectively. If check 2 fails,
the model displays an error message, but does not prevent the case from loading.
The model was designed this way to accommodate cases built in older versions before extensive
input validation was available. Going forward, new cases must be internally consistent before
they can be saved. On the other hand, if an older case is loaded to the current model, it may fail
one or more validation checks. If so, you will be alerted immediately and can correct the error.
The following table summarizes the validation rules currently enforced by the model:
You can connect to any valid model database by entering its file location in this box. Enter the
path by clicking the Database button rather than typing. A standard Windows file dialog will be
opened. This dialog will display only Access database files (*.mdb). Navigate to the database
you wish to use and select it. (The default case database is named CurrentCases.mdb) The path
will appear in the input box.
It can be helpful to locate the case database in a shared network location in order to give all users
in your office access to the same policies.
Upon selecting a database, the model will automatically check that the database is in v8.1.x
format. If not, the model will prompt you for permission to update the database. Database
updates have always gone smoothly, but it is always a good idea to make sure you have a backup
of your existing database before running an update.
The Update button is provided as a means of running the database update process in the event that
the file dialog invoked by the Database button fails to execute. This occurs in some cases in older
versions of MS Office or versions of Windows prior to XP. In this case, you must type the path
to the database into the form and press the Update button in order to use the database. See
Appendix F for a discussion of database updates.
Press the System button to select a system database. By default, the system database is named
PricingSystem.mdb and is located in the same folder as the cases database file. Both the name
and location of the file can be changed if needed.
It can be helpful to locate the system database in a shared location in order to give all users in
your office access to the same mortality tables, improvement factors, carrier names, status codes
and diagnosis codes – all of which are stored in this database.
The Update button is provided as a means of running the database update process in the event that
the file dialog invoked by the Database button fails to execute. This occurs in some cases in older
versions of MS Office or versions of Windows prior to XP. In this case, you must type the path
to the database into the form and press the Update button in order to use the database. See
Appendix F for a discussion of database updates.
You may specify certain parameters as default values, which will be used each time that you
create a new case or set of Valuation Assumptions. Parameters are organized by whether they
affect premium projections (Projection tab) or the final valuation calculation (Valuation tab).
Note that settings made on these tabs do not make blanket changes to existing saved valuation
assumptions – they are only used to set the parameters to a defined initial state when a set of
valuation assumptions is created for the first time. They are a convenience to users who are
creating a large number of valuation assumptions with similar settings.
You may set a specific default value, such as 4.0%, for the projected crediting rate. This value
will be used for new cases and for existing cases when you clear the Valuation Assumptions
(select New in the Projection screen).
There is another way that you can use this default option. If you set the default Projected
Crediting Rate to zero, the model will use the Current Credited Rate that you input on the
Contract tab in the Created or Edit a Case screen (4.3.11) for new cases and for existing cases
when you clear the Valuation Assumptions.
Default assumption for the policy values on the Starting Date. If Illustration is selected, then the
Starting Date is Illustration Date. If VOC is selected, then Starting Date is the VOC Date.
Default assumption for premiums paid between Starting Values Date and Valuation Date.
Default fixed dollar account value threshold. This value will be used for new cases and for
existing cases when Valuation Assumptions are cleared.
Select a default mortality table from the drop-down list. Use 2001 VBT ANB to match cases that
were run in Versions 2.5.3 and prior.
Select a default grid name from the drop-down. Use No Adjustment to match cases run in
Versions 7.2 and prior.
Press this button to create or edit sets of mortality duration adjustment factors. The following
screen will open:
The model ships with one set of factors (No Adjustment) already loaded. All factors in this set are
equal to 100% implying that they will not modify the mortality table. The No Adjustment set is
locked against changes so you are not able to edit the grid or save or delete it. This was done so
that the model can count on at least this set of factors being available as a default.
Pressing the New button opens a dialog prompting you for a name for your new factor set:
After accepting the name you provide, the model opens the grid for editing and enables the
remaining buttons. All values are set to 100% by default.
Entering data in this grid works as you would expect, although there is one item for you to be
aware of. The form actually manages four identically sized grids which you can work with
concurrently. At any one time, only one of the grids is visible. Grids are shifted in and out of the
display by changing the values in the Gender and Risk Class drop-downs. Together, the set of
four grids is identified by one Grid Name.
When running the model you choose a grid by its Grid Name on the Mortality tab of the
Projection screen. The model automatically loads the correct set of factors according to the
values you set for Gender and Risk Class when you built the case.
When adding data to this form it’s important to remember that you need to provide values for all
four sets of factors. Press Save before leaving the form to save your edits to the System database.
You can now select the grid from the Mortality tab of the Projection screen. If you later wish to
change your duration factors, you can open the Duration Adjustment Manager and select your
grid for editing.
If you have a grid that has been in use for valuation, you should carefully consider whether or not
you want to change existing factors. The entire grid structure is not saved with each case – only
the name of the grid is saved. When the case is retrieved for valuation, the Grid Name is used to
load the grid of factors. If the values in the grid have changed since the last time the case was
valued, the valuations will not match.
You may wish to establish a policy of only adding new grids as your need for duration
adjustments change over time. In this way, you preserve your ability to reproduce existing
valuations as well as run the same case with your new adjustment factors.
Select a set of default mortality improvement factors from the drop-down list. Use Sample
Factors to match cases run using Versions 2.5.3 and prior.
Press this button to create or edit sets of mortality improvement factors. The following screen
will open:
The model ships with several sets of factors already loaded. All pre-loaded factors are locked
against changes so you are not able to edit them or save or delete them. This was done so that a
few consistent base sets of factors are available to all users.
The model refers to a set of improvement factors as a group. Pressing the New button opens a
dialog prompting you for a new group name:
After accepting the name you provide, the model opens the form for editing and enables the
remaining buttons. All factor values are set to 0 by default.
Improvement factors vary by Gender and Risk Class and are divided durationally into Future
Eras. Eras are defined by specifying the year in which they start. An era ends when the next era
begins.
The first Era (Era 0) always starts in Year 1 which is the year beginning on the date of the input
LE estimate or mortality factor. To define a set of improvement factors, you first specify values
for Era 1 and Era 2. Default values for these items are 2 and 16.
The base improvement rate is applied from the origin date of the mortality table to the start of Era
0 (either the LE date or the Valuation Date depending upon how underwriting was specified).
For example, if the 2001 VBT is used with an LE date of 1/1/2008, base improvement will be
calculated from 1/1/2001 to 1/1/2008 or 84 months. If a base rate of 0.5% is entered, the base
improvement factor will be (1 – 0.005) ^ 84 = 0.656355.
Future improvement rates are applied over the years defined by the eras. If the default era years
are used, the Era 0 rate will be applied in year 1, the Era 1 rate will be applied in years 2-15 and
the Era 2 rate will be applied thereafter.
You can now select the improvement group from the Mortality tab of the Projection screen. If
you later wish to change your improvement factors, you can open the Improvement Manager and
select your group for editing.
If you have a group that has been in use for valuation, you should carefully consider whether or
not you want to change existing factors. The entire group structure is not saved with each case –
only the name of the group is saved. When the case is retrieved for valuation, the improvement
group name is used to load the factors. If the factors have changed since the last time the case
was valued, the valuations will not match.
You may wish to establish a policy of only adding new groups as your need for improvement
factors changes over time. In this way, you preserve your ability to reproduce existing valuations
as well as run the same case with your new improvement factors.
Select the default set of expense factors to use in valuation. There are no sample expenses
supplied with the model. Instead, there are two pre-set Expense Groups: User Input and Zero
Expenses. These are described in detail in section 6.4.
Pressing the Manage Expenses button opens a new screen that allows you to create and save new
Expense Groups. You can also rename or delete Expense Groups. Refer to section 6.4 for an
explanation of the expense factor fields.
The model ships with two pre-defined expense groups – User Input and Zero Expenses. You are
not allowed to edit these groups, but you can review them in the Expense Manager screen.
The New, Save, Save As, Rename and Delete buttons all work as you would expect. Briefly, you
create a new expense group by pressing the New button and providing a name for the group. The
model adds your name to the drop down menu, populates the new group with zeros and opens the
input boxes for editing.
Add the desired expense items and press Save to store the new expense group in the System
database. You can now select the group from the Expenses tab of the Projection screen. If you
later wish to change your expense parameters, you can open the Expense Manager and select your
expense group for editing.
If you have an expense group that has been in use for valuation, you should carefully consider
whether or not you want to change expense parameters. The entire expense structure is not saved
with each case – only the name of the group is saved. When the case is retrieved for valuation,
the expense group name is used to load the table of expense parameters. If the table has changed
since the last time the case was valued, the valuations will not match.
You may wish to establish a policy of only adding new expense groups as your expense
parameters change over time. In this way, you preserve your ability to reproduce existing
valuations as well as run the same case with your new expenses.
The model validates many of the inputs. In this tab you may specify validation limits for
minimum attained age, minimum face amount, and minimum and maximum life expectancies.
The model will issue a warning if the Primary or Secondary Insured attained age is less than this
value. The model ships with this parameter set to 65. If you encounter a case for which you need
a younger minimum age, (or if you wish to set the limit higher) you can reset the parameter by
selecting Options from the Milliman menu and then clicking on the Validation tab.
The model will issue a warning if the Initial Death Benefit is less than this value. The model
ships with this parameter set to 100,000. If you encounter a case for which you need a lower
amount, (or if you wish to set the limit higher) you can reset the parameter by selecting Options
from the Milliman menu and then clicking on the Validation tab.
The Enable calculation auditing checkbox serves as a toggle switch for displaying values related
to the COI and premium solving processes. Check this box to reveal the worksheets Solve COI
and Solve Premium after a valuation run.
The Retain Manual recalc at exit checkbox allows you to choose the recalculation mode that the
model is left in when it exits. The model sets the recalculation mode to manual while it is open.
Clicking this box causes the model to stay in manual mode. Leaving the box unchecked causes
the model to set the recalculation mode to Automatic upon exit.
Checking this box causes the model to turn off the message that appears asking you for approval
to save your Valuation Assumptions before running a case when the Save Output switch is on.
The message can be a needless distraction if you have the Projection screen open and are
scrolling through a set of cases running each one and saving output. In a situation such as this,
you can be sure that you wish to respond to the save confirmation in the affirmative each time, so
turning it off can be quite convenient.
There are several codes that are stored by the model for informational purposes, but are not used
for any processing. These include Underwriter, Carrier, Case Status, Diagnosis and Portfolio
codes. You may wish to modify or add to one or more of these lists.
A general rule that you should keep in mind when managing your set of descriptive codes is that
once a code has been entered into the system and has been in use in your organization, you should
probably not change or delete it. As you build cases using your codes, selected code values are
stored with each case that is saved to the database. When the case is later retrieved, the saved
code is matched against the current list of available codes in the system. If it is not found, it will
not be displayed on the input forms and you will essentially have lost the use of it.
You must first open the appropriate database (usually PricingSystem.mdb) using Microsoft
Access. The database should open with the word Tables highlighted in the list of database
Objects to the left of the screen. Click Tables if it is not already selected. You will see a list of
all the tables in the database.
When working with tables in the system database, please note that only the tables specified in the
discussion below should be modified. The system database contains a number of tables that are
not currently used, but which have been added in anticipation of future needs – these tables
should not be changed. (In particular, the Underwriter tables found in this database are not
currently in use by the system.)
Double click the table you wish to change and it will open in datasheet view:
Most reference tables have as their first column, an integer ID field. In most cases, this field
updates automatically and you do not have to enter a value for it. You can confirm that the
column is automatically filled by looking for the text (AutoNumber) in the last row of the table.
If (AutoNumber) does not appear, you will need to type a value for this field – just use the next
sequential integer.
Move to the last row in the table (denoted by *) and begin typing your new entry.
The little pencil icon to the left of the row being edited indicates that the changes being made to
that row have not been saved. In Access, unlike Excel, changes are saved to the database
immediately upon leaving a row being edited. You don’t have to do anything special to save your
changes – just enter them and move off the row.
Note that most reference tables also have a record_date field which is updated automatically with
the current date and time when a new record is added.
The model supports the storage and retrieval of up to 5 Life Expectancy estimates. Each LE
value can be tagged with the name of the underwriter supplying the estimate.
• AVS
• EMSI
• Fasano
• 21st Services
• Other
To add a new underwriter code, start Access and open the Cases database (CurrentCases.mdb).
Note that the underwriter codes are now the only reference codes still stored in the Cases
database. All other codes such as Carrier, Status, etc. are found in the System database.
Select the table tblUnderwriter and double click it. The contents of the table will be displayed:
Move to the last row in the table (denoted by *) and begin typing your new entry:
You must enter two values – a numeric code (UnderwriterID) and a text value (Name) which will
be displayed in the drop-down. For the code, just pick the next available integer between the last
defined ID and 99 (in this example 5). Type a short text value – it can’t be longer than about 20
characters, or it won’t fit in the drop-down.
After you have entered a new underwriter, you may wish to have it displayed by default in one of
the five LE rows on the Mortality tab. To do so, you must make a change to the table
tblUnderwriterIndex.
From the main Access screen, highlight tblUnderwriterIndex and double click it. The contents of
the table will be displayed:
No new rows should be added to this table. Instead, you make a change to existing values in the
table.
The first column (UwIndex) determines which row (1-5) of the Mortality tab the underwriter code
appears in. The second column (DefaultID) contains the code for the underwriter that you wish
to appear by default in the drop-down. The third column (DefaultName) contains the name of
the underwriter that you wish to appear by default in the drop-down.
Suppose you have added a new underwriter (say UnderwriterID = 5 and Name = ”New UW”) and
you want ”New UW” to appear as the default in the fourth row of the Mortality tab for all new
cases. Move to the row of the table containing UwIndex = 4. Change the value of DefaultID to 5
and DefaultName to “New UW”. Your new underwriter will now appear as the default value for
row 4. Of course, all other underwriters will still be available from the drop-down – your new
underwriter is just the default value.
Carrier codes are found in the Carrier table in the PricingSystem database. The model ships with
generic names. Enter values for the short_name field only. The model provides values for the
other fields automatically.
Status codes are found in the Status table in the PricingSystem database. The model ships with
the codes below. Values entered for the case_status field will appear in the drop-downs. You
may enter additional information for your own use in the description field, but it will not be
displayed by the model. The model provides values for the other fields automatically.
Diagnosis codes are found in the Diagnosis table in the PricingSystem database. The model ships
with the codes below. Values entered for the Diagnosis field will appear in the drop-downs. The
model provides values for the other fields automatically.
Portfolio codes are found in the Portfolio table in the PricingSystem database. The model ships
with generic names. Enter values for the short_name field only. The model provides values for
the other fields automatically.
From time to time (say once a week) it is a good idea to compact your Access database(s) to
ensure good system performance. The procedure to compact a database is very simple:
11.2 Step 1
Start Microsoft Access. Select File | Open and navigate to your database:
11.3 Step 2
From the menu, chose Tools | Database Utilities | Compact and Repair Database.
11.4 Step 3
Access will perform the compact operation and return you to a screen that looks like this:
The primary components of the model are an Excel file and an Access database. In versions of
the model prior to 7.2.1, it was possible to install the model by simply copying the files to any
location you wished. Beginning with v7.2.1, it is necessary to run the Setup routine on the
distribution CD to correctly install the model. Failure to run the Setup routine will result in a
model that does not function. Note that you do not need administrator rights to install the model.
If you are currently a model user with an existing database, you must update your database before
Version 8.1 will function correctly. Please see Section 9.1.1 and Appendix F for database Update
instructions.
The above procedure will work in most cases. However, in some cases, the database may not be
installed or the database may not work correctly after installation. If any of the following are
true, the model may not function properly:
• There is already a copy of the database (CurrentCases.mdb) in the install location. To ensure
that we do not destroy your data, we will not overwrite an existing database. If you wish, you
can perform the installation by copying the database file manually (12.4 below). Note that if
you are already a model user with an existing database, it is not necessary to install a new
database file. If this is the case, you can ignore this step.
• Microsoft Access is not installed on your machine. The model will not run without Access.
See (12.3.3) below.
• Access is installed, but it is a version prior to Access 2000. See (12.3.3) below.
As the installation runs, a DOS screen will appear with messages similar to those shown below.
The exact message text displayed will vary with the version of the model being installed.
If you are interested in interpreting the messages above, the installation script is simply reporting
its progress copying files. For each file that is copied, the complete source path name is first
displayed, and then a message indicating success or failure of the copy operation:
If the script encounters an existing database file, it will not overwrite it:
Although the text is crowded, you can see that the installation script is refusing to overwrite the
existing CurrentCase.mdb file as well as the existing PricingSystem.mdb file. This protects you
from losing your existing cases by inadvertently overwriting your database.
The model has been developed on Windows XP Professional. All updates from Microsoft are
applied as they become available including (as of this date) Service Pack 2.
The model has not been tested under less recent environments, but there seems to be no reason
that it will not function properly under Windows 2000 or Windows NT. (We recently had a client
install and execute the model on Windows 98 – apparently successfully.)
We have not extensively tested the model on Windows Vista or Microsoft Office 2007 although
we have several clients who are running the model on that platform. There are some differences
in installing the model under Vista / Office 2007. Please see the separate Vista installation
document included with the User Manual for help installing under Vista. (If you are running
Excel 2007, the Milliman menu will appear under AddIns when you open Excel.)
The current version of the model has been developed under Excel 2003, Service Pack 3. We have
also run the model without problems under Excel 2003 with no service packs installed. Although
the model has not been recently tested under other environments, we would expect it to run fine
under Office 2000, but perhaps not so well under Office 97 (see comments for Access below).
The model requires that Access be installed on each machine using the model. Access is
Microsoft’s desktop database application and is included as part of Office Professional, but not
included as part of the Standard version. If you’re using Office Standard and do not have a copy
of Access, you can buy it as a separate application – you do not have to purchase the entire Office
Professional suite.
The model is developed under Access 2003, but we have retained the Access 2000 file format
which is more widely in use. If you have Access 97, you will not be able to connect to the
model’s database. In this case you will have to upgrade to Access 2000 (if available) or Access
2003 in order to run the model.
Our development environment contains 1GB of RAM and a 1.7 GHz Pentium chip. The model
will run fine on a less robust platform, however we would recommend at least 512 MB of RAM.
Note that Windows XP with Service Pack 3 will not run in less than 512 MB of RAM.
During the installation process, the model files are copied to locations in:
If you are running Vista (see 12.3.1 above) the path becomes:
Contains various ancillary files included as part of the distribution. May be empty.
Contains the Access databases. The files are named CurrentCases.mdb and PricingSystem.mdb.
Contains the files User Manual v8.1.1.pdf, Database Utility v8.1.pdf and ODBC Setup.pdf (now
obsolete, but included for older versions). The directory also contains the output from the John
Doe example case used throughout the documentation.
Contains the model file: Model.xls. If revisions to the model become necessary, subsequent
model files will be placed in the v8.1.0 directory and will overwrite the current file. When the
next major release of the model ships, a new directory will be created to contain it.
You can create a desktop shortcut in order to quickly access the model as follows. Using the
Windows Explorer, navigate to C:\Documents and Settings\All Users\Documents\Milliman\Life
Settlement\v8.1.0 and place the cursor on the Model file. In this example, a v2.4.1 file is shown.
You can highlight the icon and press F2 to rename it to something slightly less verbose, e.g.:
It would also be a good idea at this time to create a shortcut to the model documentation. Follow
the procedure above to create a desktop shortcut to:
Before using the model, you must select a database. This is done from the Options screen. See
(9.1) for instructions.
As the model is upgraded with new features, the database must be modified to store additional
data elements. Typically, each new version of the model requires a database upgrade.
Each version of the model contains the programming necessary to upgrade the database to
support its features as well as the features supported by all previous versions. For example, if a
v2.3.0 database is upgraded using model v2.5.1, the database will be modified to support v2.3.5,
v2.4.2 and v2.5.1 of the model.
Prior to the upgrade to v2.5.1, the updates largely maintained backward compatibility with
previous versions of the model - older models could usually be run against a database after it was
been updated (subject to some constraints).
Beginning with v2.5.1 and continuing thereafter backward compatibility was lost as extensive
new structures were added to support enhanced model functionality. The v7.1.1 database is not
compatible with any version prior to 7.1.1.
Databases updated to v2.4.2 will continue to function with model Version 2.3.5 and prior with the
following caveats:
• Life Expectancy values and dates saved under v2.4.2 will not be retrieved when the case
is loaded into v2.3.5. You can still build and save a case under v2.4.2 and then load and
run it under v2.3.5, but you will need to re-enter the Life Expectancy parameters.
• Cases saved under v2.4.2, with the Extended Death Benefit Rider parameter set, will run
under v2.3.5 but will not reproduce the extended death benefit calculations.
The update to v2.5.1 from prior versions is more extensive than previous upgrades. The upgrade
destroys backward compatibility with v2.3.5 and v2.3.0 – those models will no longer work with
the upgraded database. Version 2.4.2 of the model will continue to work with the database after
the upgrade, but it is not advisable to do so for any length of time after the upgrade has been
performed:
• Life Expectancy Statistic values (Checked Item, Average, etc.) and the LE checkbox settings
on the Mortality tab saved under v2.5.1 will not be retrieved under v2.4.2.
• Verification of Contract values saved under v2.5.1 will not be retrieved under v2.4.2.
• Several additional valuation assumption values such as Collection Delay and Projected Death
Benefit Option saved under v2.5.1 will not be retrieved under v2.4.2.
After upgrading to v7.1.1, no prior version will work correctly with the database. Version 2.5.3
will in some cases be able to load and run cases, but only if the cases have not yet been saved
using v7.1.1 of the model.
Version 7.2 introduced a change in the methodology for calculating starting projection values
which resulted in database modifications. If you update the database to v7.2 and then try to run
v7.1 against the updated database, some of your cases may not retrieve the correct starting value
parameter (Illustrated Premium, No Premium or VOC).
Version 8.1 included the 2008 VBT tables which required extensive modifications to the System
database. Running model v7.2 against a v8.1 database will work if you select the 2001 VBT
table. If you select the 2008 VBT, the model will run – usually with the 2008 VBT Primary table
– but we do not guarantee the behavior of the model under these conditions.
Assuming you wish to perform acceptance testing of the model before rolling it out to your entire
shop, the following steps outline one possible procedure:
• Install v8.1.1 on the machine of the person or persons who will be doing the testing.
• Make a copy of your current Production databases (both Case and System) to be used for
testing. Ongoing office work will continue on the Production databases using your existing
model until testing is complete.
• Using v8.1.1, select the copy of your database and perform the upgrade.
• Perform testing using the copy of the database until you are comfortable with the new model.
• Halt all work using your current model and close all open models in your office.
• Make a backup copy of your current Production databases. Retain this backup in a safe
location. It represents a clean checkpoint – in a worst case data loss scenario, you could limit
your loss of data to changes made after this backup is created.
• Using v8.1.1, select your Production databases and perform the upgrade.
• Install v8.1.1 on all model user’s machines and configure it to point to the updated Production
databases. If everyone in the office will now use v8.1.1, you will avoid any problems caused
by operating in a mixed version environment.
• You may wish to uninstall your existing model from each user’s machine at this time, or you
may wish to retain it for occasional comparison runs. (Of course it will have to be run against
a saved copy of your current database which has not been updated to v8.1.1.)
From the user’s point of view, the upgrade process is simple – just open the Options screen and
select the database by pressing the Database button.
Please note: Before executing this button, you should make a backup copy of the database
you wish to update in the event that errors occur which result in loss of data.
On first attempting to connect to any database (when opening the Database screen, the Projection
screen or when selecting a new database from the Options screen), the model examines the table
structure to determine if it contains all expected tables and columns. If it does not, the model
presents the message below:
The model will not allow the Creator or Edit Case or the Projection screens to be opened until
the table structure is brought up to date.
Open the Options screen and click the Database… button to select your desired database. If the
database is not in v8.1.1 format, you will be presented with a dialog asking you to confirm your
request before proceeding.
Upon successful completion of the database update, you will receive a message indicating that the
update was performed properly.
During update processing, the model examines the data for duplicate cases. Cases are duplicates
if they share the same Last Name and Case ID values.
Since the model uses Last Name and Case ID to uniquely identify cases, records with matching
values become quite problematic. Essentially, the model is unable to distinguish between
multiple cases when this occurs which means that it cannot reliably retrieve stored duplicate
cases. Unfortunately, early versions of the model (prior to 2.3.5) allowed duplicate cases to be
stored in the database.
If duplicate cases are found during the update, the following message will be presented:
At this time we have no automated way to remove duplicate cases. If you discover that your
database contains some duplicate records, please give us a call and we’ll arrange to remove them.
When v8.1 updates the System database, it will attempt to load the rates for the 2008 VBT ANB
and ALB tables to the database. It will also load the 2001 VBT ALB tables at this time. In order
for the update to work correctly, the user must have installed v8.1 from the installation CD. (The
installation procedure copies the data files needed to load the rates to a specific location on the C:
drive.)
If the system cannot find the rate files in the expected location (because the installation procedure
was not run) , the update will fail and the rates will not be loaded. The system will not attempt to
load the rates again no matter how many times the Update process is run. If this situation
occurs, give us a call and we’ll help you update the database.
14.1 Overview
In order to support automated input to the new Milliman Portfolio Valuation Model, the Pricing
Model now allows the option of saving some of the output produced when a case is run. The
saved output is a subset of all the data produced during valuation and consists mainly of the
Premium and Death Benefit streams, the input Life Expectancy values and some basic census
information for each case saved.
Output is saved by checking the Save Output box on the Projection form before the projection is
run. When the Valuation button is clicked while the Save Output box is checked, the model
performs three steps:
Note that Step 1 means that if you load a case, modify the Valuation Assumptions and press
Valuation, your saved Valuation Assumptions will be updated. This is done in order to ensure
that any output saved in the database is consistent with the stored inputs that produced it.
Because of the Step 1 save operation, the model will now present you with a dialog box asking
for confirmation that you wish to replace existing Valuation Assumptions before running the
projection.
If this box is dismissed with No, the following message will appear:
As you can see, the model treated the refusal to allow the Valuation Assumptions to be saved as
an error and stopped all further processing. The valuation was not performed and the output was
not saved.
If Save Output is not checked, the model does not attempt to save input when the Valuation
button is pressed and the above messages will not appear.
All saved output is stored in the Cases database (CurrentCases.mdb) in the tables Pricing Run,
Pricing Run Life Expectancy and Policy Streams. The Policy Streams table holds projected
premium and death benefit streams which can be identified by their stream_type codes.
(Premium = 12 and Death Benefit = 13.)
The model attempts to maintain saved output data in a consistent state with the input data that
created it. It tries to ensure that any saved output can always be associated with an existing set of
input data – both base case and valuation assumption inputs.
The rules below are followed during Rename and Delete operations:
1. If a base case is deleted, associated Valuation Assumptions and output are deleted.
2. If a base case is renamed, associated Valuation Assumptions and output are renamed.
3. If Valuation Assumptions are deleted, associated output is deleted.
4. If Valuation Assumptions are renamed, associated output is renamed.
The model is not complete in its enforcement of consistency rules. It is possible to create a
database containing input data that does not correspond to the output data stored with it.
If you reload a base case and make changes to it after saving output, your base case inputs will be
inconsistent with the stored output. Similarly, you can change and save Valuation Assumptions
after saving output and create inconsistent input / output data.
The model was designed this way to give you the flexibility to save a set of outputs without
restricting your ability to continue to modify your base case. It does, however, leave you with the
responsibility for managing the internal consistency of your data.
At this time there is no additional output data management functionality implemented in the
model – you cannot (from the model interface) review stored cases, rename or delete individual
stored cases or modify stored cases without re-valuing them entirely.
The stored output feature thus provides minimal functionality for transferring data from the
pricing model to the Milliman Life Settlements Portfolio Valuation model. If you find that you
need to delete individual cases, you must do so by opening the database directly in Access and
deleting corresponding records from the three tables, or by importing the data to the portfolio
model and deleting cases there.
15.1 Overview
In this section we provide more detailed explanations of certain calculations and methods used by
the model.
Upon loading a case in Projection, the model solves for the COI rates. In some cases it will
display a message like the following:
This message is displayed when the model solves for a negative COI rate in the first year of the
illustration. This occurs when the amount input for the Account Value as of the Illustration Date
is insufficient to grow to the illustrated Account Value at the end of the policy year, given the
illustrated premium, Lump Sum Premium, credited interest, and policy loads. The only way for
the illustrated Account Value to be achieved is if there is an infusion of money – such as from a
negative COI charge.
When a negative first year COI rate is calculated, the model estimates a more reasonable value by
linearly extrapolating from the solved COI rates for years 2 and beyond. Using this estimated
COI rate, the model then calculates an estimated Account Value as of the Illustration Date. The
model will then display a message like the one above, which will require that you accept or
decline the estimated Account Value.
If you select Yes, the model will use the estimated Account Value and extrapolated COI rate to
arrive at an Account Value as of the Valuation Date. If, instead, you select No, the model will
use the input Account Value and the negative COI rate to arrive at the Account Value as of the
Valuation Date. The Account Value as of the Valuation Date is the starting point for the model to
solve for optimized premiums. Whether you select Yes or No, the model will use the
extrapolated COI rate to solve for premiums.
We can summarize this using the sample figures shown in the above diagram:
Model Uses:
Account Value at Illustration Date $570,782 $344,000
COI Rate to calculate Account Value as of Valuation Date 10.598 -0.238
COI Rate for Premium Solver 10.598 10.598
In this example, there is a difference of about $226,000 between the input and estimated Account
Values. Such a large difference usually results in a similarly large difference in the NPV.
For any given case, the decision to accept or decline the estimated Account Value can have a
significant effect on the Net present value calculated by the model. The magnitude of the impact
will depend on a number of factors, which are primarily Valuation Assumptions. These include:
• where the Valuation Date falls in relation to the policy anniversary date,
• the amount of premium assumed to be paid between the Illustration Date and Valuation
Date,
• and what Starting Values are assumed.
It is therefore a good idea to review your inputs to ensure that the illustrated values have been
input accurately. If you are satisfied with the inputs, you should review your results carefully and
perhaps run the case a number of different ways, selecting Yes and No, to assess the impact on
the policy’s NPV.
As mentioned earlier, if the illustration does not provide the policy values as of the Illustration
Date, this feature can sometimes be used to generate a reasonable estimate. Input zero for the
Account Value and if the model provides an estimate of the correct Account Value you can
decide whether or not to accept the estimate.
As described in Section 6.5, the starting point for policy values at the Valuation Date is a
combination of assumptions chosen in the Starting tab of the Projection screen. Each permitted
combination of assumptions is described below:
Policy values on the Valuation Date will be the result of projecting the illustrated values from the
Illustration Date to the Valuation Date, assuming that all illustrated premiums were paid between
those dates. This combination is the default assumption.
Policy values on the Valuation Date will be the result of projecting the illustrated values from the
Illustration Date to the Valuation Date, assuming that the premium amount entered as Premium
Paid was paid during that time period.
Policy values on the Valuation Date will be the result of projecting the illustrated values from the
Illustration Date to the Valuation Date, assuming that no premiums were paid between those
dates. This combination of assumptions corresponds with the Illustration No Premium option in
Versions 7.1 and earlier.
Policy values on the Valuation Date will be the result of projecting the VOC values from the
VOC Date to the Valuation Date, assuming that the premium amount entered as Premium Paid
was paid during that time period. The partial premium will be allocated in the same manner as
described in 6.5.9.2.
Policy values on the Valuation Date will be the result of projecting the VOC values from the
VOC Date to the Valuation Date, assuming that no premiums were paid between those dates.
This is the same assumption that was used in Versions 7.1 and earlier when VOC was selected as
the basis for starting values.
The choice of the basis for starting values will affect the premiums projected by the model. The
impact will depend upon whether the Valuation Date falls within a policy year in which the Cash
Surrender Value is zero at the beginning of that policy year. There are three situations to
consider:
Lapse Basis is Cash Surrender Value* and Valuation Date Falls Within A Policy Year
Where:
15.4.1 Condition 1 - Beginning and Ending Cash Surrender Values are Zero
In general, if the beginning and ending illustrated Cash Surrender Values are zero, there is not
enough information to determine the amount by which the illustrated premium can be reduced
without causing the policy to lapse. The assumption we make in the model is that the illustrated
premium will be paid in each year that the Cash Surrender Value is zero. The model will only
begin to solve for premiums in the first year when the ending illustrated Cash Surrender Value is
positive.
If you select a Valuation Date that falls within a policy year where beginning and ending Cash
Surrender Values are zero and if Partial Premium Paid or No Premium Paid is selected, the
model will assume that illustrated modal premiums are paid from the Valuation Date to the end of
the policy year. In addition, the model will estimate a lump sum payment, due on the Valuation
Date, so that the Account Value at the end of that policy year is consistent with Account Value on
the carrier illustration.
The estimated lump sum payment on the Valuation Date is calculated to reflect the loss of interest
and the deduction of extra COI’s that result from a smaller Account Value. In effect, the model is
treating the unpaid premium as a loan. The additional premium to be paid on the Valuation Date
is a repayment of that loan and will be an amount greater than simply subtracting the partial
premium paid from the illustrated premium.
The estimated additional premium will be included in the policy cash flows and, therefore, will be
included in the NPV. It will have the effect of reducing the NPV by the missing premium, lost
interest, and extra COI charge.
We refer to the policy year in which the Cash Surrender Value first becomes positive as the pivot
year. The model is able to solve for a premium amount that is less than the illustrated premium in
that year; however, it assumes that the pivot year premium is paid on the same mode as
illustrated.
If the Valuation Date falls within a pivot year and either Partial Premium Paid or No Premium
Paid is selected, the model will first solve for the pivot year premium for the entire year. It will
then estimate a lump sum payment due on the Valuation Date in the same manner as described
for Condition 1, except that the solved pivot year premium will replace illustrated premium as the
basis for determining the unpaid premium. The model will assume that pivot year modal
premium will be paid from the Valuation Date to the end of the policy year and the ending
Account Value matches what the Account Value would be if the pivot year premiums had been
paid on time.
As in the previous situation, the estimated additional premium will be treated as a policy cash
outflow on the Valuation Date. The NPV will therefore be reduced by the amount of the missing
premium, lost interest, and extra COI charge.
15.4.3 Condition 3 - Beginning and Ending Cash Surrender Values are Positive
If the Valuation Date falls within a policy year in which the beginning and ending Cash Surrender
Values are positive, the model will simply solve for premium required in that year to meet the
Cash Surrender Value threshold (see 6.7 for explanation of threshold). If Partial Premium Paid
or No Premium Paid is selected, there is no need to estimate a lump sum payment for premiums
past due. However, it is possible that the model will solve for a premium due on the Valuation
Date if it is required to meet the Cash Surrender Value threshold.
If the beginning and ending Account Values are zero, then Cash Surrender Values are also
presumed to equal zero. It does not matter whether the basis for lapse is Account Value or Cash
Surrender Value. This is therefore a special case of Condition 1.
If the basis for lapse is Cash Surrender Value, then Condition 1, 2, or 3 (15.4.1-15.4.3) applies
depending on the illustrated Cash Surrender Value amounts in the relevant policy years. If lapse
is based on Account Value, then the model solves for premiums in the same manner as for
Condition 3.
In Version 8.1 of Milliman’s Individual Policy Life Settlement Valuation Model and Version 4.1
of Milliman’s Portfolio Life Settlement Valuation Model, we have incorporated the 2008 VBT
mortality tables. The following is designed to answer questions you may have about the table and
its use in the system.
Over issue age 60, the table has $300 billion of face amount, 2.7 million policies exposed and
over 76,000 deaths.
For more information on the table, you can go to www.SOA.org and search on 2008 VBT.
The results are split into 72 different tables which differ by level of underwriting (more on that
below).
Also, the mortality is designed to represent mortality at January 1, 2008, so currently needs little
or no adjustment to make it current.
The above 16 are created separately for Male/Female and separately for Age Nearest/Age Last
Birthday dating, creating 64 total.
The Limited Underwriting tables are divided by Male/Female, Age Nearest/Age Last Birthday
and Smoker/Non-Smoker, creating 8 total.
The smoker tables are similar except that there are only four tables ranging from 75% to 150%
Relative Risk.
1. If you input LEs to the value calculation– and you do not change the LEs – often you will
notice little value change, but it depends on the policy. We tested this with a 300 life
portfolio and found that moving from the 2001 to 2008 VBT with the same LEs:
Solving for a mortality ratio using the new VBT will produce a different – usually higher
– mortality ratio, but for a given LE, the change of mortality slope introduced by the new
table does not change the values much.
2. If you use mortality ratios applied to a table, the LEs calculated using rates from the new
VBT will change – usually increase – if you switch to the new table from the old VBT. This
can have a significant effect on the resulting value.
Even with a mortality ratio, actual experience may not track with the indicated curve, but the
mortality slope can be adjusted to compensate for this. You can also consider adjusting to use flat
extra loads instead of or in combination with multiplicative loads. Your LE provider/underwriter
may have a different expected pattern of mortality for given cases and may be able to provide
specific adjustments by case to you.
Recall that life expectancy is a weighted average point estimate for a population group. When
dealing with individual policies, the use of LEs cannot be said to be “accurate” as individuals will
die before or after their LEs. So ultimately it is not the LEs, but their application to an
appropriate mortality curve which is important for deriving policy values.
Should I Use The Limited Underwriting Tables Since We Are Not Doing Medical
Underwriting?
Typically – no. The Limited Underwriting tables represent experience for smaller, under
$100,000 face amount policies that are underwritten with only an application and possibly some
non-invasive follow-up. This is not typical of the characteristics of the policies in the life
settlement market.
For specialty life settlement markets which are targeted on small policies without complete
underwriting reviews, the use of the Limited Underwriting tables may be reasonable.
However, emerging experience for a number of portfolios indicate lower mortality in early years
than would be expected from either the 2001 VBT or the 2008 VBT Primary table. This may be
because mortality is lower for high face amount policies. (Regarding high face amount policies,
we note that in total, over age 60 experience from the study underlying the 2008 VBT was 76%
of the 2001 VBT, but – for policy sizes $1,000,000 and above – mortality was only 65% of the
2001 VBT.)
Experience may also be different for other reasons. But if actual experience seems lower one
way to adjust for this would be to use one of the Relative Risk tables below 100. Alternatively, a
reduction to the mortality factor or an increase to the LE may be used. Any adjustment to lower
mortality will also lower projected values.
In the Portfolio Model the mortality tab allows you to select the table. The policy input tab of any
Version 4.1 portfolio data worksheet contains the Relative Risk factors, if used. These can be
imported from the Policy Model database.
The 2008 VBT Mortality Rate Never Hits 100%. How Does the Model Deal With This?
The 2008 VBT mortality caps at 45% at age 110 for all sex/smoker classifications. In the model
we extended this 45% mortality rate to age 119 then use 100% at age 120. At these ages, the
effect on policy valuations is very nearly zero.
Will Older Versions Of The Model Continue To Work With The New Table?
Due to changes in the database structure needed to accommodate the 2008 VBT, versions of the
Individual Policy Valuation Model prior to v8.1 may not work properly with a System database
that has been upgraded. Individual Policy Valuation Model users should give this some
consideration when upgrading to the new model. In particular, you will avoid incompatibility
issues if you upgrade everyone in your office to the new version at the same time. The user
manual has a suggested upgrade plan in Appendix F.
Portfolio Model users can still use previous versions of the model. However, those older versions
will not recognize the 2008 VBT and will still only offer 2001 VBT. Additionally, the Portfolio
Model v4.1 will automatically attemp to upgrade the system database if it detects an older
database. Please be aware of this in case you are delaying your upgrade of the Individual Policy
Valuation Model.
This FAQ is intended to provide general information about the 2008 VBT and its implementation
in the Models. Nothing in this FAQ should be construed as advice concerning use of a particular
mortality table or the appropriate treatment of mortality for a specific case or portfolio. You
should seek guidance from a competent advisor when evaluating mortality tables and other
mortality issues.