Movement of Policy (3): New Business
Note: Please note that the following discussion is only for movement of policy (MOP) of individual life/family takaful products only.
When we create a new entry in a policy admin system, normally we will create a "proposal" - so that the underwriters can perform necessary assessments and decide the proposed life can be accepted or request for additional information (such as medical checkup). After all the underwriting requirements have been fulfilled (and of course we have received "adequate" premiums), the proposal will be converted to an "in force" policy - and our agents will be happily informed their clients: "Congratulation! You are now covered by Company ABC!"
In simple words, our "new business" statistics are used to report the proposals that have been converted to in force policies in a particular period (month/quarter/year).
How frequent we should prepare the statistics?
I would recommend to prepare new business statistics on monthly basis. The statistics should consist of 2 sections, i.e. "Monthly" and "Year-to-date (YTD)". For better comparison, we need to ensure that both sections should have exactly the same format (I really cannot think of any good reason why we should have different formats).
Normally, the Management & Sales Department are more concern on YTD statistics.
How should the new business statistics to be reported?
Normally, the new business statistics required by internal (e.g. Management & Sales Department) and external (e.g. regulator) are different:
The "Internal" report should serve as the "base" report which contain the detailed new business statistics; the "external" statistics should be summarized from the "internal" report and adjusted based on the reporting requirements. The "external" report may need to combine several "internal" reports (if you have separate reports for different lines of business).
"I spend so much time preparing the statistics, but they don't even read it!"
Frustrated of you readers who don't read your reports? Sometimes it's our fault for the target readers not reading the reports we produce.
Normally, the non-actuarial readers will face difficulties to digest a report containing multiple large tables with many rows & columns - our report are "useless" if they cannot be read & digested by the target readers, especially those who are involved in making decisions. Hence, we should prepare a 1-page summary (with some graphs for better clarification if possible) explaining how the company performs during this quarter/financial year - and our favorite statistics in large tables should serve as appendices for those who are looking for details.
The compilation process can be complicated, but the results should be addressed in a user friendly way.
What are the source data?
Ideally, we should request a separate set of monthly new business data from our MIS / Data Warehouse, instead of using the in force policy data. The new business data should extract all policies set in force during the reporting month, regardless of their month-end statuses.
If our policy admin system are setup properly, the new business can be easily identified by referring to the "issue date" instead of "effective date" / "risk commencement date" (RCD):
The advantage of using a separate set of new business data is we are able to capture the new business set in force and terminated in the same month (i.e. not available in our month-end in force policy data).
If MIS / Data Warehouse is unable to produce new business data, we have no choice but to compare the current month and previous month month-end in force policy data:
I would recommend you to still include the new business withdrawn during free-look period in your report - as excluding them will make the process remarkably complex. Alternatively, in order to provide better picture to the readers, you may want to include some info related to free-look cancellation in the summary of new business report.
What is the tool?
I would recommend you to use FoxPro (instead of Data Conversion System (DCS)) - especially its ability to do data matching.
We need to always remember that Actuarial executives are NOT IT programmers - they do not need to learn the programming language in much depth. The program written by an actuarial executive should be systematic and easy to understand (I will be very upset if I read a program that is without comment...)
For my previous employment, I have set up a set of training manuals used to train the juniors how to use FoxPro and do programming using SQL. I reminded my juniors that we should do the programming according to the approaches recommended in the manuals - so that the future successors will be able to pick up the program easily. If they find out any new command/approach which are useful in making the compilation process more efficient, they should revise the training manuals accordingly.
Additional notes...
We need to always note that among all actuarial reports, the new business statistics have the most readers - the Management & Sales Department use these statistics to measure their production performance. For life insurance industry in Malaysia, the life insurance companies submit the statistics to LIAM (Life Insurance Association Malaysia), in order to produce a consolidated report for industry production comparisons.
When we create a new entry in a policy admin system, normally we will create a "proposal" - so that the underwriters can perform necessary assessments and decide the proposed life can be accepted or request for additional information (such as medical checkup). After all the underwriting requirements have been fulfilled (and of course we have received "adequate" premiums), the proposal will be converted to an "in force" policy - and our agents will be happily informed their clients: "Congratulation! You are now covered by Company ABC!"
In simple words, our "new business" statistics are used to report the proposals that have been converted to in force policies in a particular period (month/quarter/year).
How frequent we should prepare the statistics?
I would recommend to prepare new business statistics on monthly basis. The statistics should consist of 2 sections, i.e. "Monthly" and "Year-to-date (YTD)". For better comparison, we need to ensure that both sections should have exactly the same format (I really cannot think of any good reason why we should have different formats).
Normally, the Management & Sales Department are more concern on YTD statistics.
How should the new business statistics to be reported?
Normally, the new business statistics required by internal (e.g. Management & Sales Department) and external (e.g. regulator) are different:
- Internal: Require the new business statistics to be reported by product / product groups.
- External: Require the new business statistics to be reported by product class (such as "Endowment", "Term", …). We need to take note of additional reporting requirements (e.g. in L6 / FT5, we do not need to report the sum covered for personal accident riders).
"I spend so much time preparing the statistics, but they don't even read it!"
Frustrated of you readers who don't read your reports? Sometimes it's our fault for the target readers not reading the reports we produce.
Normally, the non-actuarial readers will face difficulties to digest a report containing multiple large tables with many rows & columns - our report are "useless" if they cannot be read & digested by the target readers, especially those who are involved in making decisions. Hence, we should prepare a 1-page summary (with some graphs for better clarification if possible) explaining how the company performs during this quarter/financial year - and our favorite statistics in large tables should serve as appendices for those who are looking for details.
The compilation process can be complicated, but the results should be addressed in a user friendly way.
What are the source data?
If our policy admin system are setup properly, the new business can be easily identified by referring to the "issue date" instead of "effective date" / "risk commencement date" (RCD):
- Issue date: Date of a proposal is converted into an in force policy.
- RCD: Date of the coverage starts. For backdated policies, the "RCD < Issue Date". However, if you find out "RCD > Issue Date", it is either the data are incorrect or the logic in our system is not defined properly.
The advantage of using a separate set of new business data is we are able to capture the new business set in force and terminated in the same month (i.e. not available in our month-end in force policy data).
If MIS / Data Warehouse is unable to produce new business data, we have no choice but to compare the current month and previous month month-end in force policy data:
- Identify new records: Identify the policies that appear in current month data and NOT previous month data.
- Check issue date: The new records with issue date in current month are considered as "new business". The remaining records are considered as "reinstatements".
- This method is valid if the new business terminated in the same month is minimal or insignificant. You may want to do a study (say once a year) to validate your assumptions.
I would recommend you to still include the new business withdrawn during free-look period in your report - as excluding them will make the process remarkably complex. Alternatively, in order to provide better picture to the readers, you may want to include some info related to free-look cancellation in the summary of new business report.
What is the tool?
I would recommend you to use FoxPro (instead of Data Conversion System (DCS)) - especially its ability to do data matching.
We need to always remember that Actuarial executives are NOT IT programmers - they do not need to learn the programming language in much depth. The program written by an actuarial executive should be systematic and easy to understand (I will be very upset if I read a program that is without comment...)
For my previous employment, I have set up a set of training manuals used to train the juniors how to use FoxPro and do programming using SQL. I reminded my juniors that we should do the programming according to the approaches recommended in the manuals - so that the future successors will be able to pick up the program easily. If they find out any new command/approach which are useful in making the compilation process more efficient, they should revise the training manuals accordingly.
Additional notes...
We need to always note that among all actuarial reports, the new business statistics have the most readers - the Management & Sales Department use these statistics to measure their production performance. For life insurance industry in Malaysia, the life insurance companies submit the statistics to LIAM (Life Insurance Association Malaysia), in order to produce a consolidated report for industry production comparisons.
Comments
Post a Comment