Movement of Policy (4): In Force


Note: Please note that the following discussion is only for movement of policy (MOP) of individual life/family takaful products only.

Compared to new business statistics, in force statistics are much simpler - basically, what we need to report are the policies as at end of particular period (month-end / quarter-end / year-end) which are considered as "in force" (i.e. the coverage is still valid).

Depending on the policy admin system we use, we can identify the in force policies by referring to their policy statuses. In one of the system I used previously, the "in force" business are those policies having the following policy statuses:

  • In Force: Normal premium paying policies.
  • Paid up: Applicable to the limited payment products only; policies which all required premiums have been paid.
  • Reduced Paid Up (RPU): The policyholders decide not to continue paying the remaining premiums (or by other scenarios defined in the contracts) and covert the policies to "paid up" policies based on the available cash values - the sum assumed is reduced but the policy term remains the same.  If a RPU policy is previously a participating (Par) policy, it will cease from participating (i.e. change to non-participating (Non Par) policies)
  • Extended Term Insurance (ETI): The difference between RPU and ETI is ETI remains the original sum assured, but the policy term is shorten.

Some systems may use different policy statuses for policies which the future premiums have been waived. However, in my view, instead of using policy status, it will be better to use "premium payment method" as indication - if you study the waiver of premiums carefully, you will find out the waiver policies are actually still "premium paying policies", just the premiums are paid from the provision account. Hence, it should be considered as changing "payment method".

Similarly, if our system uses different policy status for policies in grace period, we should also consider those policies as "in force". However, in my view, having different policy status for policies in grace period (or like "pre-lapse" status you heard previously) will unnecessary increase system workload - the system needs to change the policy status once the grace period starts and revert to the original status once the required payment is received (Please also remember that system will need to record the changes in the transaction history for audit trail).

How frequent we should prepare the statistics?
In force statistics are not as "popular" as new business statistics, as they are rarely used for production performance or decision making (the Management is more interested to see the Embedded Value (EV) rather than merely statistics) - furthermore, for an established company, the composition of in force business in the book do not vary significantly from one month to another.

If our process is properly automated and it only take little resources & time to prepare the statistics, it will be nice to have the in force statistics on monthly basis - especially if our valuation colleagues need to do valuation monthly (to provide additional comfort on the data quality, i.e. we can use the in force statistics to detect the usual changes in the composition of in force business or no. of policies / sum assured (total & average) / premiums(total & average)).

Of course, the regulatory reporting requirements will influence how frequent we need to prepare the statistics.

How should the in force statistics to be reported?
I would recommend to use the same formats as new business statistics, for easy comparison. Please refer to the discussions in "Movement of Certificate (3): New Business" - there are similar considerations for new business statistics and in force statistics.

What are the source data?
Our Data Warehouse / MIS should provide us data as at month-end, or account closing date (if the account closing date < month-end). The SAME data should be used for both reporting & valuation purposes - otherwise we will be wasting our time in doing reconciliation.

We should have in force data on monthly basis. The in force data are the most widely used data in Actuarial Department - apart from actuarial reporting & valuation, other functions

What is the tool?
Similarly, the first choice I would recommend is FoxPro. In my one of my previous assignment, my client has discarded Data Conversion System (DCS) and use FoxPro to prepare the model point files for Prophet runs. Frankly, it will be more efficient to use only one tool to carry task from manipulating the source data to producing model point files.

Please refer to the discussions in "Movement of Certificate (3): New Business" for details.

Comments

Post a Comment

Popular posts from this blog

Other Ways to Prepare Prophet Model Point Files? Try FoxPro!

Image
If you are a frequent Prophet user, you must be definitely familiar with "Model Point Files" ("MPF"), i.e. the policy data that you compile in a specific format that Prophet can recognize as inputs for Prophet runs. If my guess is right, most probably you use Data Conversion System ("DCS") to convert the source data you download from your policy administration system (may be in various format, e.g. fixed ASCII / fixed width, comma delimited, tab delimited, etc.) into the required MPF, based on the definitions you specified in your DCS programs. In case your source data are divided into various files, you may need to carry out more steps to prepare MPF, for example: Open different source files in Excel Combine required fields from different source files by using commands (such as) VLOOKUP, SUMIF & MATCH. You may have automated this process by using VBA. Convert the required files into text files Use DCS to convert those text files into MPF  How...
Read more

How do You Setup Indicators in Your Prophet Model?

Image
In my previous post, I have discussed areas that you may consider in setting up input variables . Before I proceed my discussion on core variables, I would think that it is good for use to take a look on indicators - as indicators play an important role in setting core variables with various formulas (known as "variable definitions" in a Prophet model).  The funny thing about indicators is: it DOES NOT carry any formulas that you need to use in calculating a variable! Basically, they are just some texts that you can combine using different logical operators (AND, OR, NOT), such as "ORD_PAR AND SING_PREM" for a single premium ordinary participating product. 
Read more

How Should I Do My UAT? (1): Program / Spreadsheet / Model

Image
If you are working in the actuarial department of an insurance company, it may not be uncommon to you involving in various testing exercises, which are known as User Acceptance Testing ("UAT") in general. Some of us may think that UAT is only applicable to the policy administration system implementation project (Oops... Do I remind on the non-stop follow-ups from your Project Manager?), but in fact UAT is also needed for the programs, spreadsheet templates or actuarial model we use to perform various actuarial studies - whether they are developed internally or by external consultant. It is particularly important for those tools which we are going to use to perform regular studies. In my view, there is no one right answer for the approach to be used in performing UAT on program / spreadsheet / model - most importantly, the approach that you adopt should allow the required testing to be carried out in a structured manner, and it should not create too much "processes...
Read more