Earnings By Source - Capturing Actual Policy Movement Data

Capturing Actual Policy Movement Data

An existing DataLink database of seriatim inforce can be used to generate an historical EBS projection for traditional products merely by adding in seriatim new business records and a table of basic seriatim policy movement transaction records. (When preparing data for a fund-based EBS analysis such as for Universal Life products, there will likely be additional transaction information to be added to the database, as discussed in Capturing Actual Fund Movement Data .)

The Policy Movement transaction records will be primarily terminations, such as deaths, lapses and other benefit decrements, but transaction records can also include new issues in order to specify the reporting date at which the new issues appeared on the inforce file.

There are a number of additional transactions that are supported in specific modules:

In the Disability module, specific transactions to record the movement into and out of claim payout status are also available, as well as to adjust the claim in the course of payment.
In the Regular Life and Par Products modules, two new transaction types (Miscellaneous Offs and Miscellaneous Ons) have been added to reflect movements in inforce business arising from various policy changes. These transactions may be extended to other modules.
The Reinstatement transaction is now supported in the Regular Life, Par Products and Disability modules. Other policy movement transaction types like RPU and ETI may also be added in future.

For transactions that involve adding a policy back to the inforce file, it may be necessary to add full policy information records to the Policy Information table, similar to those required for new business or for the starting inforce file, so that AXIS can attach these records to the appropriate cells, and project appropriate cashflows and reserves following the reporting of the transaction.

Adding Seriatim New Business, Reinstatement and Miscellaneous Ons

A complete seriatim file of new business during the projection period is necessary in order to properly reconcile to the ending inforce file and to support termination transactions on policies added since the start of the reporting period. Similarly, policies added by Miscellaneous On policy change transactions must also be reflected in the seriatim extract file. Reinstatement has the same requirement that a corresponding policy information record must also be added if not already in the seriatim file.

The ending inforce valuation extract may be a good source of new business, reinstatement and miscellaneous on records which can be selected by testing the date of issue and date of processing, or by comparison of two inforce files. A key issue, however, may be how to also obtain the records that terminated before the ending valuation date. If the administration system can capture records that are no longer in force with relevant status codes and other information, this may be a simple task. If this is not possible, it may be necessary to capture as much as possible from monthly inforce files during the period studied, and approximate the missing records as necessary.

Provided that the inforce extract file format is used, it is likely the same DataLink loading and mapping process as is used for the starting inforce may be useable with little change.

Creating the Policy Movement Transactions Table

Create a new DataLink Table from the DataLink Table view list. In the New DataLink Table wizard, select “Policy Movement Transactions” table as the table type. The field to enter a name for the table will be disabled as the name is predefined.

The new table will have the following mandatory fields:

Policy ID - must match the Policy IDs in the Policy Information table so that transactions can be associated with specific inforce or new business coverages.
Transaction type - choose from the following options:

deaths (including disabled life deaths in DI module)
lapses
other benefit (with decrements)
new business
annuitization (reserved for future use in accumulation annuity)
death of life 1 (joint life cases in Annuity module )
death of life 2 (joint life cases in Annuity module)
annuity certain commutation (for annuities)
miscellaneous off (for Regular and Par only)
miscellaneous on (for Regular and Par only)
DI claim - cause 1 (DI active lives only)
DI claim - cause 2 (DI active lives only)
DI recovery (DI disabled lives only)
DI settlement (DI disabled lives only)
reinstatement (for Regular, Par and DI only)
claim adjustment (DI only)
used for output only
used for output only
DI claim – cause 3 (DI active lives only)

Effective Date of transaction – (year, month and day)

This table will be loaded from a source file that you would normally obtain from the admin system. Sometimes, current inforce files contain previously terminated records, which can be queried as to date and cause of termination. Sometimes, it is necessary to assemble this file in more complicated ways such as by comparing successive inforce files for new or deleted records and obtaining termination cause and date information from other sources. In creating the DataLink File object used to load the Policy Movement Transactions table, take care to properly define the Status Date of the File which is used by AXIS to determine the date when actual transaction history stops.

Note that in the case of new business, reinstatement and miscellaneous on transactions, there must be a complete seriatim policy record in the Policy Information table with the appropriate Issue Date for the policy. A New Business transaction record is not necessary for AXIS to include the New Issue at the Policy Issue date. You may use a transaction record, however, to specify a later Reporting Date for the New Issue as described below. If a New Issue Transaction record is present, the Effective Date of the Transaction must the same as the policy issue date in the Policy Information Table record.

Policy Movements in the Disability module include movements to and from disabled status. Active lives and disabled lives in force can be modelled in the same policy information table or in multiple policy information tables; however, only one Policy Movement Transaction table is allowed, and it must contain all transactions for both active and disabled lives.

Late Reporting Adjustments

The transaction “Reporting” Date is offered as a set of three optional fields in the Policy Movement Transaction table, for use with most transactions. If used, this allows the timing of the transaction to be deferred to an EBS period beyond the effective date (the actual date the transaction occurred). This permits you to reconcile the inforce volumes and reserves calculated by AXIS at any reporting date to the volumes and reserves actually reported at that time based on transactions processed.

When the Reporting Date and the Effective Date of a transaction fall in the same EBS period, AXIS ignores the Processing Date and uses the Effective Date to determine the amount and timing of benefit cash flows and the resulting movement in the inforce. This is consistent with a presumption that any interest adjustment arising from delayed reporting has insignificant impact on earnings. Deaths, other benefit terminations and new issues are assumed to occur on the actual effective date, but lapses, reinstatement and miscellaneous on and off movements will occur on the monthly anniversary of the policy issue date falling in the same financial month as the effective date of the transactions. All policy cashflows related to the continuation of surviving policies (premiums, commissions, expense, etc.) will cease as of the effective date of a decrement transaction. Reserves released on termination are based on the projected reserves at the end of the EBS period in which the termination occurs.

When the Reporting Date and the Effective Date of a transaction fall in the different EBS periods, AXIS continues to project regular inforce cashflows, and defers recognition of all benefit cash flows, policy movement and reserve change implications of the transaction until the EBS period in which it is reported. The late reported cashflows are accumulated from the transaction effective date, and will be reversed at the adjusted transaction date (i.e. the first day of the EBS period in which the Reporting Date falls).

Exact treatment of late reporting differs according to the type of transaction, as follows:

a) Deaths and Other Benefit Decrements

All policy related cashflows continue during the EBS periods prior to the EBS period in which the transaction is reported, and reserves and policy values continue to accumulate consistent with survivorship.
The policy is assumed to terminate, and related benefit cashflows are assumed to occur on the first day of the EBS period in which the Reporting Date falls.
Amount of benefit cashflow is based on the amount payable at the actual transaction effective date regardless of the duration of the delay in reporting.
The amount of reserve released is the reserve at the end of the EBS period in which the termination is reported.
Late report after maturity is only allowed for death and other benefit decrements. Upon maturity, all maturity related cashflows would be paid accordingly on maturity date. The difference of cashflows between maturity and decrements (death or other benefit) occurs on the first day of the EBS period in which the Reporting Date falls.
Death transactions in the DI module may only be used to terminate claim payments on disabled lives; the mortality assumption is not currently specifically supported in the DI module for active lives, although other benefit decrements may be used for this purpose.
Other benefit decrements may only be used for active lives in the DI module.

b) Lapse/surrender Decrements

All policy related cashflows continue during the EBS periods prior to the EBS period in which the transaction is reported, and reserves and policy values continue to accumulate consistent with survivorship.
The policy is assumed to terminate, and related benefit cashflows are assumed to occur on the monthly anniversary of the policy issue date in the first month of the EBS period in which the Reporting Date falls.
Amount of benefit cashflow is based on the amount payable at the actual transaction effective date regardless of the duration of the delay in reporting.
The amount of reserve released is the reserve at the end of the EBS period in which the termination is reported.
Late report after maturity is not allowed for lapse/surrender decrements.
Lapse transactions may only be processed for active lives in the DI module.

c) New Issues

No policy related cashflows are reported during the EBS periods prior to the EBS period in which the new issue transaction is reported, and reserves and inforce statistics ignore the new policy.
The policy is added to inforce statistics as a new issue on the first day of the EBS period in which the Reporting Date falls. All normal policy cashflows are projected from that date forward subject to any actual termination transactions.
A time zero reserve increase and a time zero PFAD increase are calculated as at the true Issue Date and included in the usual Gain from New Business component lines along with new issues reported during the current EBS period.
There will also be an adjustment to revenues and expenses to reflect all the past due policy-based cashflows (premiums, commissions, expenses, etc.) that will be recognized in earnings in the period in which the new issue is processed. This late reporting adjustment to cashflows, plus the increase in expected reserve and PFAD from the true issue date to the beginning of the EBS period in which the new issue is reported, are shown as a separate Late Reporting Gain item.

d) Disablement/terminations in the DI Module

Policy related cashflows on policies modelled as active in the opening reserves are continued, subject to terminations by lapse or other benefit, until a new claim (incurral transaction) transfers the policy to disabled status. This transfer is assumed to occur at the date of disablement, and results in a notional transfer of the present value of the projected claim payments and costs on the DLR basis to a "new claim" record.
If the reporting date of a new claim falls in a later reporting period than the effective date of disablement, then the transfer occurs at the beginning of the reporting period, and any active status cashflows between the date of disablement and the date of transfer are reversed as a late reporting cashflow adjustment.
An actual release of ALR is determined based on the projected ALR for the active policy at the end of the reporting period.
Regular monthly benefits and associated claims admin expenses are projected for all seriatim claim records from the opening file, and for all newly disabled lives, subject to the initial elimination period, the maximum benefit period defined, and any subsequent termination transactions.
A termination (by death, recovery or settlement) of a disabled life results in monthly benefits and claims admin expenses being terminated as of the effective date of the termination (partial months are payable pro-rata). Late reporting is not supported for terminations.
The projected DLR at the end of the reporting period is released for all actual terminations; if the termination is a recovery, and if recovery to active status is allowed for seriatim disabled lives in the cell assumptions, then an ALR is set up as of the end of the reporting period, normal cashflows related to active life status will resume immediately, and subsequent claim incurrals are allowed.
A subsequent incurral on a previously disabled life that has recovered may be from the same cause or a different cause, but in both cases AXIS will treat it as a new claim and reapply the elimination period. Future enhancements are planned to handle resumed claims, and adjustments to the claim parameters.
The above assumes that disablements are treated as decrements, and that recoveries to active status are allowed. Where cell assumptions specify otherwise, the release of ALR on disablement and setup of ALR on recovery may not apply.

Miscellaneous Off / On Transactions

Miscellaneous Off and On transactions (currently only available in Regular Life and Par) may be used to reflect movements arising from policy changes, such as changes in the plan, face amount or risk class. Such changes normally occur in pairs at the same effective date, but since the changed policy may well be modelled in a different cell, it is necessary to make sure that two seriatim records are loaded into the Policy Information table with different policy IDs corresponding to the Policy IDs of the two transaction records. Miscellaneous Off records will terminate a previously inforce policy at the date of change (no other terminations may be processed for that policy) while Miscellaneous On transactions result in the inforce policy being ignored in AXIS processing until the transaction effective date, at which point the reserve is set up and cashflows commence. Miscellaneous On records are eligible for subsequent termination like other inforce records.

The effective dates of miscellaneous off and on records will be adjusted if necessary to coincide with the policy monthiversary in the month that the transaction occurs. Both miscellaneous off and on transactions do not currently support late reporting adjustment; if the optional reporting date fields are used for these transactions, the dates must be the same as the transaction effective dates.

An optional Cashflow adjustment field is available to record any additional cashflow in or out that would offset the earnings impact of the net change in reserves.

In summary,

Miscellaneous off transaction is similar to other termination transactions, except the release of reserve is assumed to occur at the policy month end instead of EBS period end.
Miscellaneous on transaction is similar to a new business transaction but there is no cashflow from inforce to transaction date. An increase in reserve is also assumed to occur at the policy month end at which the policy is added.

Reinstatement

Each reinstatement must be used together with a corresponding prior lapse transaction. If both transactions are processed in the same EBS period, then AXIS will ignore both transactions and the policy will be projected as continuously inforce during the whole EBS period.

After a reinstatement, the policy is eligible for any subsequent decrements including lapses; therefore, there can be multiple pairs of lapse / reinstatement transactions.

The Reinstatement transaction does not support late reporting.