Life.Net^®

Life.Net^® is the frame for development of solutions to life insurance companies and pension funds. Generally seen, Life.Net^® is characterised by the following:

• Establishes fundamental concepts such as customer, policy, business event and policy version.
  
  
• Rests on a stringent and consistent model of policy data and forward calculation.
  
  
• Is flexible. Data models at all concept levels can be fully adapted to company-specific circumstances.
  
  
• Supports fast development time. The company-specific data model is specified in a domain-specific language, which forms the basis of automated code generation of significant parts of a final solution. Code generation also ensures a more robust solution with fewer errors and easier test and maintenance.
  
  
• Supports full possibility of roll-back and forward calculation. Also without having to re-register existing business events.
  
  
• Handles offers so that events in an offer are calculated in the same way as final events. Likewise, accepting an offer is simply an activation of registered events under the offer.
  
  
• Supports alternative forecast calculation. It is often requested that forecast calculation be carried out with larger steps and alternative parameter setup than the standard forward calculation.
  
  
• Supports reserve account for carry-forward of retrospective reserve based on a company-specific chart of accounts and a company- specific detailing level.
  
  
• Integrates with MVS easily – without the use of MVS thus being a requirement. Companies which want to use an alternative calculation may very well still use Life.Net^®.
  
  
• Integrates with Unitlink.Net^® easily. In general, integration is supported with arbitrary outside aspects to the policy as long as such aspects understands such concepts as roll-back and forward calculation.
  
  

The above features (and many more) are described in details below in this description.

Customers and policies

A system based on Life.Net^® will administer a collection of policies, where each policy represents a contract between a customer/a member and the life insurance company/pension fund. Each policy is related to one or more customers, where the different customers to which a policy is related can have different roles such as insured, insurance holder, etch. in relation to the policy. Life.Net^® allows the use of multiple policy types (data models and appurtenant mathematics for business events and forward calculation), customer types and relation types in a solution, giving great freedom to model the portfolio and its relations to the customers.

A policy can be divided into several aspects, where each aspect is a unit which can be calculated forward individually. Life.Net^® distinguishes between two types of aspects: Versioned aspects and external aspects. The versioned aspects are the basis of Life.Net^®'s handling of the insurance side of a policy, while the external aspects make it possible to integrate other types of data into the policy - as e.g. a unit linked system. A policy type defines which aspects can or must be in included in a policy of that type.

Versions

The policy (or more correctly: A versioned aspect under the policy) stores data about the insurance side of a policy as a number of policy version. Each policy version is a snapshot of the state of the policy at a certain value time and place in the row of calculations which the forward calculation of a policy consists of. During forward calculation of a policy, a number of policy versions will be created. Life.Net^® offers close control with the service life of these versions, making it possible to balance space consumption in the database.

Life.Net^® supports the possibility of registering changes to data back in value time in relation to the calculations already done. The policy versions which in terms of value time are after the change will be cancelled upon the roll-back which takes place in connection with such a change, and a re-calculation will then create new policy versions that reflect the changes made.

Structure and content of a policy version is solution-specific and reflects company-specific business logic. Life.Net^® does not dictate any specific structure and therefore allows solutions based on Life.Net^® to support administration of very different portfolios. Code generation is also here the key to why this extreme flexibility entails less development time than is the case with standard solutions, in which company- specific data models must be pushed into a standard data model.

Events

A solution based on Life.Net^® will define a number of event types, as e.g. new business, annuity premium, old age retirement, and death. A full company-specific solution typically requires between 10 and 25 event types. A versioned aspect stores a number of events which describe what has happened to the policy over time. Each event is associated to a specific value time and will affect the state of the policy when the policy is calculated forward past this value time. The framework system does not require a value time for an event or a policy version, for that matter, to follow a certain pattern, as e.g. take place on the first day of a month, but such requirements can be added to the specific solution.

Life.Net^® operates with two classes of events:

• Exogenous events: Events which are created by the users of the system (case administrators) or on the basis of calls from external systems (e.g. web portal). At registration of an exogenous event there usually has to be delivered a number of parameter values to the event. For each event type there is an event registrator which is responsible for validation of event parameters and which gives the user feedback by interactive event registration.
  An exogenous event can be edited or deleted. Life.Net^® preserves previous versions of the parameters of an event when calculation results for them are preserved. Life.Net^®'s concept of degree of maturity of a version of the parameters of an event can be used to structure a process, in which required information for completion of an event takes place in multiple steps, e.g. receipt of information about heirs.
  
  
• Endogenous events: Are events which are created by the system during forward calculation as a consequence of encoded business rules. This may e.g. be automatic old age retirement when the age exceeds a threshold, or automatic conversion to paid-up policy following a grace period. An endogenous event thus primarily acts as a message from the system to the users saying that the business logic has caused a significant change to the policy. As the existence of an endogenous event as well as its parameters are the result of business rules, a user can neither create, edit or delete endogenous events. If e.g. one wants to postpone automatic conversion to paid-up policy, one can thus not delete the automatically inserted event. A case administrator will instead register an exogenous event for postponement of conversion to paid-up policy. After this, Life.Net^® will automatically remove the endogenous event for conversion to paid-up policy on the original date and insert a new automatic conversion to paid-up policy upon expiration of the postponed period.
  
  

Life.Net^® does not define any event types and does not require the existence of specific eventy types in a solution. Because of code generation great flexibility is achieved without being counterbalanced by a long development time.

History and logging

When Life.Net^® saves data in the database, it is given a marking stating which user performed the action and when it happened. The marking also makes it possible to find everything that was hidden as a consequence of the same action. The marking is done in the form of a generation number, which is a serial number which is counted out when one saves, while joint information about a generation - user, time, any run name - is stored in a generation log. The generation number gives great relief in detailing balancings between parts of the system without cutting off the use of real time stamps for that purpose.

Once data is saved in the database it is, as a rule, never physically deleted from the database, but instead given a deletion marking which also includes information about user and time. Together the markings create a solid history in the database which partly is an audit trail showing who did what when, and which partly gives Life.Net^® the possibility of displaying data as it looked at an earlier point in time.

As a consequence of this there is not need for an actual status run (or annual run) which finishes a year. One can always reconstruct the status of a policy as per a given date (e.g. 1 January 2009) and where one disregards all changes made after another given date (e.g. 5 January at 1:43 pm) - whether or not these changes have effect back in 2008 or earlier.

In addition to the history mentioned above, there is also kept a log for each policy. Among other things, this log shows who fetched the policy so that the system also holds information about actions that do not change data. The individual solution determines the use of the log.

Forward calculation

When Life.Net^® is to forward calcualte a policy to a given value time, the basis is the most recent valid policy version. In order to calculate the new policy versions which belong to the interval from the basis and to the value time to which the forward calculation is requested, Life.Net^® performs a sequence of operations. The operations in this sequence are solution-specific and thus not delivered by Life.Net^®. The sequence is created (via code generation) on the basis of information from the specification of the system. Events with value time in the interval to be calculated contribute to the calculation by delivering operations to the sequence. This way, it is possible that different events insert the same type of operation in different places of the calculation sequence, e.g. the new business event and the selection event may both want to insert an operation which changes the clauses of the policy. The calculation can solution-specifically split the interval into more parts, e.g. so that policy versions are always calculated at any turns of the month or year along the way.

Calculations of insurance values, as e.g. provisions at basic level, will typically be included in the forward calculation. MVS is typically used for this purpose, but other calculation cores can also be applied if desired. By using MVS, all common products are supported, both at average premium and natural premium.

During a calculation errors or warnings which may block further calculation may occur. These errors and warnings can be seen in the client program. It is also through the client program that a user can choose to accept a blocking warning so that the calculation may continue.

Alternative calculation

At specification of a solution based on Life.Net^® it is possible to describe alternative sequences for the use of calculation which are to be done differently - e.g. forecast calculations. This makes it easy to implement forecast calculation which e.g. calculates forward to expiration in larger steps or with simpler mathematics than the actual forward calculation.

Dependent aspects

If a policy consists of more than one aspect, in connection with forward calculation of the policy there may be a need for communication between the aspects. This need arises if the calculation of an aspect depends on information calculated by another aspect. In order to avoid too tight a link between the aspects, Life.Net^® provides a construction - shared histories - to formalise communication.

Once again, code generation is the key to speedy implementation of a robust and strongly typed formalisation of exactly what information the individual aspects can see about each other. The use of shared history is also the key to ensuring against the implementation of different aspects becoming so tight that maintenance is impeded.

Offer

An offer in Life.Net^® consists of a named amount of events which one can choose to include on a sidetrack to the real forward calculation. Solution-specifically an offer can contain parameters, e.g. assumptions about changed contribution level. This makes it possible to study the consequence of the events without influencing the normal calculations and data of the system while the same encoded business rules are being applied during offer calcuation. An offer can be saved and processed - e.g. as a part of a dialogue with the customer/member who has the policy. When the result is as desired the offer can be accepted, after which the events act as standard events. Life.Net^® supports multiple concurrent offers on a policy, which makes it easy to compare alternative scenarios.

Runs

Insurance.Net^® contains a solid and efficient management of runs, which Life.Net^® applies for providing a framework for portfolio runs for developers. In addition, Life.Net^® supplies two important standard runs:

• Forward calculation run: Forward calculates the policy portfolio (or parts of it) to a date. Life.Net^® supplies the run, but the actual forward calculation is solution-specific as described above.
  
  
• Recalculation test: Performs a roll-back and recalculates. After this, a comparison can be made to the original version and the new version can be saved. This can e.g. be used to investigate the effect of a new delivery of the system - partly if errors have been corrected and partly if changes haft had unwanted consequences.
  
  

The system architecture of Insurance.Net^® makes it easy to execute runs across large portfolios without problems and to scale the operational hardware for the system to the desired performance by using cheap standard servers.

Reporting to authorities

In order to ease the work of extracting and supplying the information which life insurance companies/pension funds in Denmark must report to authorities, Life.Net^® has a framework system for reports. The framework system defines a pattern for how the numerical basis for the reports is extracted, processed and sent in a way which ensures that reports are made correctly.

Life.Net^® itself uses the framework system for handling the following types of reports:

• Pension yield taxation (PAL).
  
  
• Pension contribution system (CPS).
  
  
• Pension rights/early retirement allowance (PERE).
  
  
• Reporting on interests (IRTE).
  
  

The individual solution can easily add and implement own types of reports according to the same pattern. Additionally, Edlund's support of reporting via eIncome is used for:

• Reporting of group life premiums by means of eIncome (section 56, subsection 5).

The common denominator of these five types of reports is that in a solution only functionality to calculate the values that must be reported has to be developed.

Client

The Insurance.Net^® client is a modern GUI application which, in connection with Life.Net^®, makes it fast and easy for users to work with the system. The user interface is constructed so that solution-specific elements can expand or replace the displays of policy data etc. which already exists. The client is based on Windows Presentation Foundation (WPF) which provides a very free framework for development of graphically rich presentation of data.

The client can, without any kind of customer-specific adjustment, display customers, policies, events, policy versions, etc. - including the customer-specific parts which are automatically generated on the basis of the specification of data structures.

Registration of events often requires entry and validation of event data. Life.Net^® provides an automatically generated wizard/guide for each event type. This wizard can be adjusted in case customers have requests for any special functionality in it.

Life.Net^® supplies browsers for search of customers and policies, and filters for extracting parts of the portfolio on the basis of special criteria can be specified. Runs can be initiated on the subset of the portfolio which is extracted via a filter.

Development of customer solutions

Life.Net^® was developed focusing on the process of specifying, developing, testing, and maintaining a solution which must be efficient and result in a high quality product. Some of the initiatives which support this desire are described below.

Code generation

Code generation is a central concept in Life.Net^®. It is an automatic process in which a specification in a domain-specific language is converted into source text. Large parts of a solution can be created on the basis of specifications which describe the solution at a higher level than standard source text, which radically reduces time consumption for development of these parts of a solution. It is particularly important that the connections between the overall parts of the system are specified early and in business terms at this leve in order to, among others, to avoid the circular dependencies arise during detail specification. Maintenance is similarly facilitated and the quality raised as the source text generated has been tested in advance. In Life.Net^® the following parts are generated on the basis of a specification:

• Policy
  
  
• Versioned aspect
  
  
• Policy version
  
  
• Events
  
  
• Event registrators
  
  
• Operations
  
  
• Deduction of operation sequence
  
  
• Shared histories
  
  
• Accounts
  
  
• Registers
  
  
• Address module
  
  
• Filters
  
  
• Reporting types
  
  

A lot of things are generated that would otherwise have had to be developed/maintained 'by hand':

• Database schema
  
  
• Data types of the server side
  
  
• Persistence and serialisation of data
  
  
• Data types of the client side
  
  
• User interface
  
  

The generated parts can be adjusted and replaced by components developed traditionally in case what was generated does not meet specific requirements for e.g. display in the user interface, but in many cases the specification language and code generation are sufficiently flexible.

Consistent abstractions

The different parts of Life.Net^® uase the same abstractions as far as possible. This makes specification of the individual solution easier and reduces the task a developer has making himself/herself acquainted with the framework system. Forecast calculation, for example, typically uses assumptions about future payments, bonus parameters, etc., while such assumptions cannot be allowed in real forward calculation. Life.Net^® accommodates this by formalising and implementing access to the surroundings which is different according to calculation mode. This keeps the business logic intact.

Application of Insurance.Net^® components

Insurance.Net^® holds a lot of components which are ready to be used by a solution based on Life.Net^®. Some examples are:

• Registers
  Flexible module for implementation of company-specific versioned registers for management of master data. Here, master data is data which forms the basis of other calculations in Life.Net^® – e.g. cross-cutting contracts, collective agreements, bonus rates, market value rates, cost values and sums/premiums for group life-like products. Just as Life.Net^®, the register module builds on massive use of code generation, so that implementation time for even very complex registers with many fields in many levels (and possibly with inheritance of values) is short.
  
  
• Account module
  Handles entries and extractions in accounts. A solution can have several different types of accounts such as reserve account and cashflow account, where each type has its own chart of accounts and its own data types. Likewise, accounts can be associated to either a specific aspect or the policy across aspects.
  
  
• Address module
  An expandable module which can store contact information and other master data about different interested parties.
  
  
• Payment system
  Handling of reporting and payments. Receipt of data from various sources (PBS and similar solutions). Manual registration of payments which are not received electronically.
  
  
• Disbursement system
  Handles disbursement of benefits and sums, including information about tax rate and deduction card.
  
  
• Document system
  Generates and handles documents in several different formats. Contains a phrase-based mail merge generator which can be used for generating mass-distributed letters as well as individual letters. Also supports implementation of complex policy overviews and cover statements.
  
  
• Workflow/case management
  Modules for supporting business processes which involve manual procedures and long-term processes.
  
  

Integration with external systems

Life.Net^® supports in several ways that a solution can be a part of a system landscape in which integration with other systems must be done. Life.Net^® can exchange data in multiple ways:

• Life.Net^® can act as a host for web services and can also call services in other systems.
  
  
• Life.Net^® can receive and submit data (e.g. reports) via asynchronous queues based on MSMQ, MQ Series, Bizztalk or other technologies. The message format will typically be XML.
  
  
• As Life.Net^® is implemented in Microsoft .Net, which is a strong and general environment, it also supports other common forms of integration (ftp, file exchange, data in joint databases, etc.).
  
  

All Life.Net^®'s data types can be converted into XML which facilitates exchange.

If the external systems do not support roll-back in the same way as Life.Net^®, problems may arise when data which has already been passed on from Life.Net^® to an external system is changed as a consequence of a roll-back. Because of this problem, Life.Net^® has an abstraction ('containers'), which are used as a link between roll-back/forward calculation and communication with an external system. An operation performed during the forward calculation can inform a container about a value which must be passed on to an external system. The container will do this. It will also save the value so that the container remembers the external system's image of what happened. At a subsequent roll-back the container will be asked if roll-back can be allowed and will then perform the required compensating acts against the external system.

Data from a Life.Net^® database can be extracted in several ways:

• Runs which load data by fetching e.g. policies and calling calculation functionality on the policies to find the requested values. Here, it might be advantageous to use the system for creation of reports. Data can then be supplied in the run report, files, database tables, etc.
  
  
• Runs which access the database directly via SQL.
  
  
• Direct SQL enquiries.
  
  
• Dump of the database to data warehouse. The database schema for Life.Net^® is easy to understand and only holds simple types which are all directly readable. Thus no BLOBS (binary large objects) or the like are used to represent business data.
  
  

Documentation

Life.Net^® is documented at the following levels:

• Model documentation: General description of Life.Net^®'s modelling and concepts.
  
  
• Specification guides: A collection of instructions for how a solution based on Life.Net^® is specified.
  
  
• Implementation guides: A collection of instructions and examples for the system developer.
  
  
• API documentation: All public classes and methods in Life.Net^® are accompanied by a brief description intended for the system developer.
  
  

Select screens

The client is fully implemented in Windows Presentation Foundation (WPF), which allows efficient and stylish dialogues. Just as the rest of the clients in our framework systems, the client for Life.Net^® is fully expandable in connection with customer adjustment.

The client for Life.Net^® is also, similar to the clients in our other framework systems, fully localisable.

In the following, you can see select screens from the Life.Net^® client. Click the images to view them in natural size.

Note: The screens were taken from the test implementation of Life.Net^®, which is primarily used for internal testing. This implementation does not focus on the possibility of demonstration of Life.Net^®. Some of the information in the screens is therefore very strange! Shortly, they will be replaced with corresponding screens from our reference implementation.

	Policy where the topmost level of a policy version is displayed.
	Guide for manual event registration.
	Policy with offer activated.