Is "Claim Contingency Reserve" Necessary for Takaful Business?

When I worked with one of my previous client, I came across "Claim Contingency Reserve" (CCR) in their operation model. According to "Takaful and Retakaful - Principles and Practices" written by Tobias Frenz, CCR (also known as Special Reserves or Equalisation Reserves in some markets) acts as a buffer against an adverse or volatile claims experience.

My client and I have a few discussions on CCR, especially on whether it is necessary to establish CCR in the participant risk funds. Normally, CCR is funded by surplus arising during the year and setup as a % of tabarru' or technical provision (This reminded me of the old days when I calculated solvency margin using 4% of reserves, ...). It was a a challenge to determine an appropriate % to be used and the approach to releasing CCR over time. Well, there is no prescribed % or approach available. 15% or 10%, which is better? Should we release over 3 years or 5 years? Should we release linearly or staggered (like commission payment pattern)? I'm afraid no one can really give you a good answer...

In my view, CCR has the same purpose as the solvency margin or capital (such as Risk-based Capital (RBC) Framework practised by the conventional insurers in Malaysia). Previously, there was no regulatory solvency framework (I was quite surprise when I found this during the employment with my first takaful employer), which required the takaful operators to setup solvency margin to protect the participants against adverse deviation. Hence, it might make sense to establish buffer and call it as CCR. (Personally I don't prefer to call this buffer as "reserve" - for me, this is not a form of "reserve" like the technical provisions we setup for the takaful liabilities).

Recently, Bank Negara Malaysia (BNM) has issued concept paper for RBC Framework for Takaful Operators - I was quite excited as I have been expecting this for some years! Once takaful operators adopt RBC Framework, I would think it is no longer necessary to have CCR in their operation model (otherwise you will have double provision).

Time to say goodbye to CCR! (Remember to revisit your surplus management policy, OK?)

Movement of Policy (5): Termination / Alteration

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

Among the three statistical reporting forms (L6, L7 & L8 for life insurers; FT5, FT6, FT7 for takaful operators), the termination / alteration statistics are considered as the most complicated. As all three forms need to be reconciled (please refer to the above diagram), many people have no choice to put the differences that cannot be reconciled as "Others" (another popular word to be used is "balancing item").

In fact, it is not complicated if you follow the correct approach to do these termination / alteration statistics. If you re-arrange the formulas in the above diagram, you can easily see that actually these statistics intend to explain the changes/movements occur previous month in force policies and new business incepted in current month, by comparing to the current month in force policies.

So, what is the best way to do termination / alteration statistics? I guess you already get the correct answer by now, i.e. comparing current month in force data (DATA 1) to previous month in force data plus current month new business data (DATA 2 + DATA 3) and the differences between DATA 1 and DAT 2 & DATA 3 are the statistics you need:

• Termination: The base plan / riders available in DATA 2 & DATA 3, but NOT available in DATA 1.
• Reinstatement / Addition of new riders: The base plan / riders NOT available in DATA 2 & DATA 3, but available in DATA 1.
• Alteration: The base plan / riders available in both DATA 1 and DATA 2 & DATA 3, but the sum assured, premiums or product code are different in DATA 1 and DATA 2 & DATA 3.

If we would like to split reinstatement and addition of new riders, we may need to have an additional step to check whether the attaching base plan are available in DATA 2 - if yes, we can consider those riders are newly added riders to an existing base plan.

In order to do the above-mentioned comparison, we need to first understand the base plan / rider's unique identification used in our policy admin system - i.e. unique field or combination of fields that differentiate one base plan / rider from others:

• Base Plan: Normally, policy number is the main identification (like "primary key" in MS Access table) that we can use to differentiate one base plan from others. If we have yearly renewable products, we may need to find out whether the system will use the existing policy number upon renewal (Hopefully your system will use the existing policy number, otherwise you will run out of policy number very soon...).
   
• Rider: We may need to use combination of multiple fields to form the unique identification. In one of the system I use previously, each rider has a unique "sequence code" - all riders under attached to a base plan have different sequence code. I used combination of policy number and rider code (e.g. "1234567A" (policy number) + "01" (rider code) for the 1st rider under base plan with policy number 1234567A)

How frequent we should prepare the statistics?
Similar to the in force statistics, termination / alteration statistics are rarely used for production performance or decision making. Hence, if our process is properly automated and it only take little resources & time to prepare the statistics, it will be nice to have the termination / alteration statistics on monthly basis. You may not need to submit the report to the Management if they don't really want to look at the statistics (they already have plenty of reports to go through).

So what's the point we spend so much efforts preparing the termination / alteration statistics? Well, let's think how we can make use of the statistics (the reports will remain as papers if we do not use them). Actually we can use these statistics as "early warning" system in order to trace any unusual trends promptly - we can use these statistics to do some quick calculation to get rough estimates on surrender / lapse rates or claim rates.

It will only be useful to the Management if we derive meaningful conclusions from the statistics.

How should the termination / alteration statistics to be reported?
Internally, I would recommend to list out all types of termination / alteration - please do NOT have a category called "Others" (Only for external reporting like L7 or FT6). Different from the new business statistics and in force statistics, we may not need to report the statistics by product (Otherwise our tables will be very big and difficult to study).

However, it will be useful if we can breakdown by base plan / riders and major product class (as investment-linked products may have different experience from the traditional products). The statistics may not be meaningful if we combine all products together (which we normally call "rojak").

What are the source data?
Apart from the new business data and in force data mentioned above, we need another set of data from our Data Warehouse / MIS for the policy statuses of the policies terminated during current month - so that we are able to identify why a policy is terminated (such as death / TPD / Critical illness, surrender, lapse, maturity / expiry, … - please refer to "Back to Basic - Movement of Policy (MOP)" for detailed discussion).

What is the tool?
Similarly, the first choice I would recommend is FoxPro. So far I have no idea how to use Data Conversion System (DCS) to easily compare 2 different sets of data (i.e. "LEFT OUTER JOIN" in FoxPro).

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.

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:

• 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).

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):

• 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.

Movement of Policy (2): Actuarial? Data Warehouse?

If someone asks me: "Who should be the most appropriate person in charge in doing movement of policy (MOP) reporting - Actuarial or Data Warehouse (or IT Department)?" After some hesitation, I shrug my shoulders: "Frankly, I'm sorry that I don't know..."

Ideally, MOP reporting is basically summarizing & categorizing the data available in the policy admin system. If the system data are "clean" (what a luxurious wish), we can just apply some rules to segregate the available policies into "new business", "termination/alteration" and "in force" - just like what we do using Excel, FoxPro or DCS (Data Conversion System). Furthermore, the rules are actually easily understood by even non-actuarial colleagues. Now, it sounds like it is a bit too expensive to as Actuarial Department to do MOP reporting.

However, in reality, the data in the policy admin system in many companies are not clean - especially those with group insurance/takaful business. There are so many types of erratic data until it requires Actuarial to decide whether a policy is considered "valid" in MOP's perspective. Furthermore, some companies may have more than one policy admin system and MOP reporting requires combination of the policy data from multiple systems.

Sounds a bit tricky now? Not yet until you hear this: to make the matter worse, the policy data for some group insurance/takaful may not exist in any of the policy admin system! Some products may be manually managed by the Group Insurance/Takaful Department or Employee Benefit Department. Sometimes you may be informed by the sales personnels: "I'm sorry that the data you require are available at the third party's server and we haven't received those data yet..." (You may feel like screaming at him: "What? I thought the policy has been issued 6 months ago???")

We have to accept that the real life is imperfect. "By right, it should be simple, correct?" You're correct, "by right" it is. Sometimes the way we manage a supposed-to-be simple thing makes it becomes complicated.