Migration with history

When a life insurance company installs a new policy management system, all its existing policies are usually migrated to this new (target) system. Why, then, do companies often consider how much “history” should be migrated to the new system?

The life cycle of a policy

Every time a life insurance policy is processed, a “policy status” is created. Since life insurance policies are processed in clearly-defined sequences, all the scheduled and unscheduled processing of an individual policy generates a clearly-defined sequence of policy statuses. This is referred to as the “life cycle of a policy.”

If a policy is processed with retroactive effect, then the policy management system retrieves the policy status from a date in the past and the life cycle is recreated from this status. If this “retroactive processing” occurs frequently and draws from statuses that go back several years, then a great deal of history must be made available or the processing would not be feasible.

Standard migration procedure

The migration itself is also part of the processing (transfer of policies). If the effective date of the policy lies in the past, then the life cycle of the policy must be recreated in the target management system. However, a problem often arises here: while the scheduled processing of a policy (in particular, the recording of excess benefits) is defined by business plans and other legal and regulatory specifications (and therefore mapped in the same way in the target system), the same cannot always be said for the various unscheduled processing elements. In fact, the functional limitations and inability of unscheduled processing elements to be used in the future are often some of the reasons why companies decide to opt for a new system. It is unreasonable to expect statuses to be reproduced only to fully recreate the life cycle of policies in the target system. As a rule, therefore, the retroactive effect is never set before the latest technical modification to a policy, and rarely before the expiration date of the latter, such that the history reaches back no more than 12 months from the date of the migration.

Prerequisites for migrating more history

Assuming the policy statuses in the source system are error-free (i.e., most of the unscheduled technical changes are mathematically correct and mapped according to current procedures), then it should be possible to migrate a longer history. After all, all the required processing in the new policy management system is mathematically correct, flexible, and complete.

Processing is considered “flexible” if similar transactions are mapped in uniform templates that break down complex algorithms into individual, modular, reusable steps (“code fragments”). Since many modular steps can be reused, it quickly becomes possible to not only provide most of the required actuarial algorithms by simply “clicking” them together, but also to provide for new processing methods that can be adjusted to the transactions of the source system.

With the right calculation module, you can also group multiple processing elements and implement them successively as part of a processing list. Such a module can even be used to emulate certain transactions of the source system.

In order to migrate a longer history, it must be possible to unambiguously identify the traceable policy processing elements of the source system. This is a difficult task, as the processing lists to be modeled in the target system can often only be defined on the basis of the data in the source system. It is therefore necessary to determine which changes in the underlying policy data led to a transaction in the source system, which processing list is mapped by the respective change in the target system, and which default data (at the very least) is required.

Unscheduled processing

Whether or not (and to what degree) the migration can include unscheduled processing depends on the capabilities of the target system. The following features are extremely helpful in this respect:

• For each processing element, there is a processing request that essentially contains the “modifiable policy” and the required management information.
• “Calculation module” services are available for initializing, completing, and synchronizing each processing request. These services make it possible to reduce the required amount of default data to an absolute minimum.
• Processing elements can be postdated (i.e., commissioned), then retrieved during the respective step of the scheduled updating of the policies and processed accordingly. The list of commissioned processing elements remains connected to the policy.
• A centralized software solution (migration tool) is available for audit-proof data transformation based on a migration process certified by auditors.

In addition to the processing request for the actual transfer of the policy, the migration tool generates basic requests for the processing to be included, or more precisely, for each processing element in a processing list.

The calculation module creates complete, synchronized processing requests from these basic requests during the migration of the policy, and stores them as commissioned processing elements on the migrated policy. During the first update in the target system (which is performed by the migration tool), these processing requests are implemented and the policy history is recreated retroactively.

Since the migration process described above occurs during a single technical transaction, it is possible to control the amount of policy history that is included.

Control mechanisms

Each migration project is structured around controlling and the guaranteed values provided by the policyholder.

In particular, the guaranteed performance values and histories agreed upon or anticipated by the policyholder must be maintained during the migration. The performance histories are therefore adopted as part of the migration, made available for the purpose of the tracking of technical changes, and used to calculate the chargeable values.

The purpose of controlling is to verify that policies are migrated properly. Individual actuarial values can be used to ensure the policy has arrived in the target system exactly as it left the source system, i.e., by comparing (at the very least) the last policy status from the source system with the most recent policy status in the target system. Subsequent processing can help provide additional control values, provided earlier policy statuses have also been saved from the source system.

A practical example

As part of a migration with MIGSuite to the policy management system in|sure PSLife, hundreds of thousands of policies were migrated with a history of 36 months each. The migrated transactions required processing lists with up to six processing elements.

Additional control mechanisms were not required for policies with traceable processing elements as these elements were controlled simultaneously. Appropriate guaranteed values were applied.

The migration was so successful that a new project is now in the works involving the migration of 1.5 million policies with a complete history (including transitional pension benefits).

Would you like to learn more about how to use our migration tool? Register free of charge for our Virtual Ecosphere, where you will find case studies as well as a “DeTECHtive – the in|sure Tech Talk.”