In portfolio management software, such as in|sure PSLife, new features and functions are usually designed so that they work optimally in the system. This is logical, as the goal is to develop the product as optimally as possible. It is generally assumed that all relevant data is fully available at all times. Migrated life insurance portfolios therefore pose a particular challenge. A variety of reasons that are not always foreseeable can lead to gaps in the portfolio data and to not all data being available at all times (as one would assume). Or, based on the actual state of the system, certain data is deliberately omitted in order to prevent the migrated data volume from becoming too large. But what happens if data that was not originally required and therefore not migrated is needed later on?
New requirements for established functions
For example, contracts that have a special status at the time of migration impose new requirements for data volume. Over the course of the system's steady growth, in|sure PSLife has faced two such challenges. Specifically, in its past two releases. Firstly, because of non-contributory migrated contracts. Here the system requires two contract statuses instead of the usual one. This is so that the contract is fully functional within the target system after it has been migrated. Secondly, because of a retroactive obligation to pay benefits due to occupational disability. The problem here is that the clarification of the obligation to pay benefits often extends over a long period of time and may result in the contract having to pay benefits retroactively. Changes related to time must be made in the legacy system. In both cases, data that is normally not required suddenly becomes relevant.
Non-contributory migration: missing contract statuses
Non-contributory contracts at the time of migration are not uncommon. This is why they are migrated according to plan with two contract statuses instead of just one: the non-contributory status at the time of migration and a so-called "shadow contract status," the contract status immediately before the premium payment exemption. The system can thus access as usual the benefits and contributions prior to migration and thus calculate the contract status upon reinstatement in the target system. But sometimes this shadow contract status does not exist and the data for it is missing. So how does the data end up being processed?
Retroactive occupational disability: missing history
In the case of retroactive occupational disability, the contracts were indeed migrated perfectly and completely. But occupational disability is often discussed at length and ultimately decided in court. After such a lengthy decision-making process, a contract that has not been migrated with regard to benefits must become liable for benefits that are retroactively far in the past. Benefits must then be paid in arrears and contributions may still have to be offset. However, the time for this is before the migration - in other words, in the legacy system.
New processing for new cases
PSLife has already established processes with complex algorithms that are productively used by insurance companies for both retroactive obligation to pay benefits due to occupational disability and for reinstatement of non-contributory policies. But the new cases require a different approach, as values are missing that the "normal" processing otherwise automatically uses to calculate. The old processing is needed and used as is, so it would be inconvenient to change these proven processes. This means that new processing is needed for new cases. A new form of processing has been implemented for each of the two cases. This essentially does the same thing as the existing one. The difference is that there is now the option of manually entering default data that would otherwise be automatically used for the calculation. The data required for this can be taken from the legacy system's archive. Technically, there is no way to access it, as the archive cannot communicate with the PSLife target system. As a result, automated readout is no longer an option. However, the clerk can manually view and enter the required data. With a new form of a processing, this data can be entered directly, unlike the old data. The same algorithm can subsequently be used, and can calculate the correct contract status.
Both cases are examples of the fact that not all actual requirements can always be anticipated in theory prior to development. Procedures that are optimal for existing functions do not have to be optimal for new requirements. The same difference can exist when completely new designed functions have to interact with existing ones. As a result, dynamic requirements require a dynamic approach. The key here is to always weigh things up: How can we ensure with little effort that the optimal balance is found, so that both new and old features function in the best possible way? In both the described cases, the existing, proven processing was left as it was. Instead, new types of processing were created to meet the new requirements in a simple way without interfering with ongoing operations or making things unnecessarily complex. For both the old and the new case, a simple solution could thus be found that best suits both areas.
Would you like to learn more about our in|sure PSLife software? Then feel free to contact our expert Oliver Schippa, business developer at adesso insurance solutions.