EP0935208A2

EP0935208A2 - Integrated insurance system and system method

Info

Publication number: EP0935208A2
Application number: EP98305539A
Authority: EP
Inventors: Peter S. Cahall; James M. Campisi; Larry Resnick; Jr. Lowell H. Greene; Charles R. Mcgrew; John D. Branscomb; Timothy S. Millwood; Steven A. Eisenberg
Original assignee: Individual
Current assignee: Individual
Priority date: 1997-07-11
Filing date: 1998-07-10
Publication date: 1999-08-11
Also published as: EP0935208A3

Abstract

A computerised integrated insurance financing system. Specifically, the computerised insurance system is capable of handling an insurance transaction from the development of an appropriate insurance contract with the client through the management of the client's insurance information during the life of the contract. Initially, census data is received from a potential client in the form of computer records representing a plurality of individuals to be insured. After being reviewed and standardised, the census data is used to perform a pecuniary loss analysis The data from the pecuniary loss analysis is used to generate insurance illustrations and a financial analysis for the client. Once an appropriate insurance contract is finalised, the system generates the insurance contract, and related documentation, and the census data is used to manage the client's insurance information during the life of the contract.

Description

The invention relates to a computer network and to a computerised integrated insurance financing system. More particularly, the computerised insurance system is capable of handling an insurance transaction from the development of an appropriate insurance contract with a client through the management of the client's insurance information during the life of the contract.
As used herein "client" includes an offshore captive corporation or trust which is a purchaser or potential purchaser of life insurance for the purpose of funding or financing benefit liabilities in favour of its parent corporation or grantor. Initially, census data is received from a client in the form of computer records representing a plurality of individuals to be insured. After being reviewed and standardised by the computer system, the census data is used to perform a pecuniary loss analysis. Asset requirements are measured based upon insurance liabilities and/or employee benefit liabilities. The data from the pecuniary loss analysis and the asset measurements are then analyzed by the computer system in order to generate life insurance coverage amounts consistent with applicable insurable interest laws, insurance liabilities and/or employee benefit liabilities. Insurance illustrations and a detailed financial analysis are provided for the client. Once an appropriate life insurance contract is finalised, the system generates the life insurance contract and related documentation. All of the data previously generated is used to automatically manage by the computer system the client's insurance information during the life of the contract.
The present invention is also directed to the computerised design, sale and management of life insurance plans for offshore captive insurance companies located outside of the United States and offshore trusts located outside of the United States except Voluntary Employee Beneficiary Associations (VEBA's) in which the client or trust insures a large number of individuals, such as employees, under a single group contract or several individual contracts. Such an insurance contract might be used to finance insurance liabilities, employee death benefits, worker's compensation benefits, health insurance benefits, disability income benefits and non-qualified retirement benefits. Such an insurance plan can provide tax benefits to a client if the contract qualifies as insurance under applicable laws.
Two possible uses for such a computerised integrated insurance system are 1) the automated design, sale and management of offshore captive insurance programs and 2) the automated design, sale and management of offshore trusteed insurance programs. A captive insurance company or a company sponsored trust, can accept contributions from a parent company to insure employees of related entities for the purpose of financing various insurance liabilities and employee benefit liabilities.
With use by a captive, the captive insurance company pays premiums to an offshore life insurance company. The computer system determines the amount of available insurance coverage under applicable insurable interest laws, measures captive insurance company assets needed to satisfy insurance liabilities and determines the amount of assets which may be efficiently deployed in insurance contracts to improve after-tax investment yields, minimise investment risk, satisfy future liquidity requirements and shift insurance risk from the captive insurance company to an offshore insurance company.
With use by a client sponsored offshore trust (except a VEBA) the trust pays premiums to an offshore life insurance company. The computer system determines the amount of insurance coverage available under applicable insurable interest laws, determines the amount of employee benefit liabilities and measures the amount of assets required to finance those liabilities. The computer system then illustrates information on how to efficiently deploy those assets in life insurance contracts to improve after-tax investment yields, minimise investment risk, satisfy future liquidity requirements and shift insurance risk from the trust to an offshore insurance company.
Known computerised insurance systems are unable to handle an insurance transaction from the complete development of an appropriate insurance plan through the management of the client's insurance information during the life of the contract. This is particularly true with respect to companies which have complex insurance liabilities and/or complex employee benefit liabilities and insure a large number of individuals in a single transaction. In general, known insurance systems are quite limited in that they do not encompass most or all functions required to perform a complete computerised integrated process which encompasses development, analysis, production and management of an insurance contract. Thus, known insurance systems are fragmented and utilise separate pecuniary loss analyzers, illustrators, insurance liability measurement systems, benefit liability estimation systems, asset measurement systems and client insurance information management programs.
Because presently known insurance systems handle an insurance transaction in a fragmented manner, they lack the cohesiveness, flexibility and economies of scale that a computerised integrated insurance system would provide If the insurance transaction were integrated and streamlined, the reduced cost could be passed along to the client. Increased profits on the sale of such insurance are also possible.
Moreover, since data generated by one known insurance system must be transferred from system to system during the transaction, many of which are not compatible, it takes significantly longer to complete than if the entire process were integrated in a single computer system. Given the length of time required to perform pecuniary loss analysis, financial analyses, measure insurance and liabilities employee benefit liabilities, determine asset requirements, and generate financial computer-based illustrations, only a small number of scenarios are generally created for a company whether by a computer or manually. Further, the ease with which interdependent computer calculations can be made is lacking. An integrated computerised insurance transaction, on the other hand, enables a large number of different insurance scenarios to be easily generated for a prospective client based on that client's individual needs in a timely and cost efficient manner. The financial implications of the various plans can also be quickly shown to the client on a cost efficient basis. Moreover, the plans can be rapidly modified based on feedback from the client. This greater flexibility allows optimum cost efficient insurance plans to be generated for the client.
It is thus apparent from the above that there exists a significant need in the art for a computer based integrated insurance system.
It is therefore an aim of preferred embodiments of this invention to provide an integrated computerised insurance system capable of handling transactions in which a plurality of individuals will be insured under a single group contract or several individual contracts.
It is another aim of preferred embodiments of this invention to provide an integrated computerised insurance system capable of handling an insurance transaction more quickly and efficiently, resulting in more precise measurements, than non-integrated insurance systems.
It is another aim of preferred embodiments of this invention to provide a computerised insurance system capable of inputting client census data, performing pecuniary loss analysis, measuring insurance liabilities, measuring employee benefit liabilities, determining asset requirements, performing a comprehensive financial analysis, generating the final insurance contract and managing the client's insurance information during the life of the contract.
Briefly described, the present invention provides a computer system which smoothly integrates these functions in an integrated computer architecture which is capable of designing and managing an insurance contract.
The present invention also provides a computerised method for implementing an integrated insurance system, comprising the steps of: (1) inputting client census data for a plurality of individuals in the form of computer records; (2) automatically performing a pecuniary loss analysis on the census data to classify individuals into cells and determine appropriate insurance coverage amounts under applicable laws; (3) automatically determining asset requirements based upon insurance liabilities and employee benefit liabilities; (4) performing a computerised financial analysis based upon captive insurance company asset requirements and/or trust asset requirements; (5) preparing computer-generated insurance illustrations based on the results of the pecuniary loss analysis, the measurements of assets and underlying insurance liabilities and employee benefit liabilities; (6) creating a final insurance contract and related documentation; and (7) managing through such computer system the client's insurance information and assets utilised to offset insurance and employee benefit liabilities during the life of the contract.
The present invention also provides an apparatus for implementing an integrated insurance system, comprising: (1) an inputting census data unit for a plurality of individuals in the form of computer records; (2) a pecuniary loss analyzer for the census data to classify individuals into cells and determine appropriate insurance coverage amounts under applicable laws; (3) an asset requirements unit to determine asset requirements based upon insurance liabilities and employee benefit liabilities; (4) a financial analysis unit to perform a financial analysis based upon captive insurance company asset requirements and/or trust asset requirements; (5) an illustrator for preparing insurance illustrations based on the results of the pecuniary loss analysis, the measurement of assets and underlying insurance liabilities and employee benefit liabilities; (6) a document generator for creating a final insurance contract and related documentation; and (7) a managing unit to manage the client's insurance information and assets utilised to offset insurance and employee benefit liabilities during the life of the contract.
The present invention provides the features set out in the appended claims.
Figure 1 is a block diagram of the hardware arrangement used in a preferred embodiment of the present invention.
Figure 2 is a block diagram of the functional components of a preferred embodiment of the present invention.
Figure 3 is a block data flow overview diagram according to a preferred embodiment of the present invention.
Figures 4A to 4C are block flow diagrams showing the integrated insurance system according to a preferred embodiment of the present invention.
Figures 5A to 5H are block flow diagrams showing the census data analysis process according to a preferred embodiment of the present invention.
Figure 5I is a sample menu displayed during the census data analysis according to a preferred embodiment of the present invention.
Figures 6A to 6J are block flow diagrams showing the pecuniary loss analysis process according to a preferred embodiment of the present invention.
Figures 7A to 7D are block flow diagrams showing the insurance illustration process according to a preferred embodiment of the present invention.
Figures 8A and 8B are block flow diagrams showing the financial analysis process according to a preferred embodiment of the present invention.
Figures 9A to 9E are block flow diagrams showing the client information management process according to a preferred embodiment of the present invention.
Referring now in detail to the drawings wherein like parts are designated by like reference numerals throughout, there is illustrated in Figure 1 a diagram of the hardware arrangement used in a preferred embodiment of the present invention. An Ethernet backbone 10 connects a number of workstations 20, servers 30, 40, 50 and printer 70. The workstations 20 can be IBM PC compatible machines, running Microsoft MS-DOS and Windows 3.1.1, or Microsoft Windows NT, versions 3.51 and higher. The workstations 20 require the following hardware components: 16MB of RAM, a 500MB hard drive, and a colour VGA video display. It should be noted, however, that other components can be used.
The database server 30, the file server 40 and the backup server 50 can be Intel Pentium based IBM PCs running Novell Netware versions 3.11 or higher, or Microsoft Windows NT Server version 3.51 or higher. Each server 30, 40, 50 requires the following minimums: 64MB RAM and a hard drive.
The database server 30 accepts queries from workstations 20 and returns data sets from a centralised database. The database server 30 also provides data warehousing, backup and data fault tolerance.
The file server 40 performs file and print sharing services and authenticates internal login requests. The file server 40 can also handle external data flow via modems 60.
The backup server 50 provides fault tolerance through continuous on-line backup to tape, and can double as the file server 40 or the database server 30 in the event either server fails.
It will be understood by those skilled in the art that this hardware embodiment is only one of many ways that can be used to implement the integrated insurance system. Although multiple server and workstation processors are shown, their functions could be handled by a single computer if multi-user access is not required. Alternately, instead of the Ethernet backbone 10 the various processors could be connected through other local area network (LAN) topologies such as Token-Ring, wide area networks (WAN), switched telephone networks, such as a public or packet switched network environment such as the Internet. Internet connectivity enhances the system to provide World Wide Web access to databases, and the transmission and reception of e-mail Messaging to automate client reporting, and claim notification from remote sites. For example, census data or claim information could be received from a remote site through the Internet.
Figure 2 is an overview diagram of the functional components of a preferred embodiment of the present invention. The census analyzer 500 receives raw census data from the client. As explained in detail with respect to Figures 5A to 5I, the census analyzer can (1) review input census data representing a plurality of people to be insured; (2) provide a subset of data to a third party for validation; (3) compare present census data with past census data from the same client; and (4) convert the census data into a standardized format.
After the census data has been standardized by the census analyzer 500, the pecuniary loss analyzer 600 processes the data based on input control parameters. As explained in detail with respect of Figures 6A to 6J, the pecuniary loss analyzer 600 calculates the insurable interest that a potential client has in each individual in the census. The pecuniary loss analyzer 600 categorises each individual to be insured and places them in a representative "cell".
These cells of data are used by the illustrator 700. As explained in detail with respect of Figures 7A to 7D, the illustrator 700 adjusts the data in the cells and generates insurance ledgers for presentation to a potential client. The financial analyzer 800 also generates reports regarding the potential client, as explained in detail with respect to Figures 8A and 8B. Next, the final contract generator 100 creates the final contract and related documentation. Finally, the insurance plan is administered by the client insurance information manager 900 as explained in detail with respect to Figures 9A to 9E.
Figure 3 is a data flow overview diagram of a preferred embodiment of the present invention. Data is received from a potential client by the census analyzer 500 in the form of input census data 90. The census analyser 500 can also access prior census data 91 from the same client. The input census data 90 and prior census data 91 can be compared to generate census comparison reports. The census analyzer also converts the input census data 90 into a standardised format, as represented by standardised census data 92.
The standardised census data 92 is used by the pecuniary loss analyzer 600, along with operator input control parameters, to classify individuals into representative cells 80. The cells 80 are adjusted by the illustrator 700 and are used by the financial analyzer 800 to create reports based on operator input control parameters. When an appropriate contract is approved, the final census data 95 is created. The final census data 95 is used by the client insurance information manager 900 to administer the insurance plan. The administration of the plan includes the generation of death benefit paper work, claim status results and financial reports to client.

Process Overview

Figures 4A to 4C are block flow diagrams showing an overview of the process of the integrated insurance system according to a preferred embodiment of the invention.
As shown in Figure 4A, census data is received from a potential client (step 400) and reviewed (step 402). This process is described in greater detail with respect of Figures 5A to 5I. The data is then input to the pecuniary loss module (step 404).
A pecuniary loss analysis is conducted on an aggregate and an individual basis (step 405). This process is described in greater detail with respect to Figures 6A to 6J. The results of the pecuniary loss analysis are reviewed and analyzed by the client (step 406). If the results are not satisfactory, the assumptions used during the pecuniary loss analysis can be revised and the pecuniary loss analysis can be repeated (steps 408 and 410).
If the results of the pecuniary loss analysis are satisfactory, life insurance projections, or illustration ledgers, are produced (step 412) and a financial analysis is performed as shown in Figure b (step 414). These processes are described in greater detail with respect to Figures 7A to 7D and 8A and 8B. The results of the insurance illustration and financial analysis can then be reviewed (step 416). If the results are not satisfactory, the assumptions used during the insurance illustration and financial analysis can be revised and these functions can be repeated (steps 418 and 420).
When the result of all of the above steps is optimized, the client decides whether or not insurance will be purchased. If insurance is not purchased, that is the end of the transaction (steps 422 and 424). If insurance is purchased, the case is underwritten and issued and the system generates the final insurance contract and related documentation (step 428).
Once the contract is in effect, the system can administer the insurance plan. This process is described in greater detail with respect to Figures 9A to 9E. The plan's administration includes processing death benefit claims as shown in Figure 4C (step 430). The system can also update monthly asset values and monitor the value of funds in the plan (step 432). Financial reports for the insurance company are generated and all relevant data is stored (steps 436 and 438). Finally, the system can prepare an annual plan review, showing historical financial performance and re-projecting future performance based on updated assumptions, to be presented to client (steps 440 and 442).

Census Data Analysis

The insurance transaction begins when raw census data is received from the client. The census data contains a plurality of computer records representing the individuals to be insured. Such a computer record might contain the individual's name, social security number, sex, date of birth and salary. The received census data is reviewed for completeness and standardized. Newly received census data can be compared to census data previously received from the same client to determine which individuals have been added or deleted. The system also generates a computer file that can by used by a third party to verify that the social security numbers are valid. Figures 5A to 5H are block flow diagrams showing this census data analysis process.
As shown in Figure 5A, the user is first presented with a menu listing the census data analysis choices (step 510). Such a menu is shown in Figure 5I. The menu includes an option to return to the higher level menu (step 512), select a help screen (step 514), save the parameters currently entered (step 516) or load a set of parameters that were previously stored (step 518).
The user can also select to perform a census data analysis (step 520). First, parameters are converted to usable alpha or numeric formats (step 521). These values are then verified to determine, for example, that the date of birth is valid, (step 522) and tested for overlap of specified fields on output files (step 523). Next, the disk files are opened (step 524) and the system is ready to perform the process shown in Figure 5B.
The processes shown in Figures 5B to 5G compare the input client census data, or the Update File, with previously received client census data, or the Master File. The Update File represents the input census data 90 and the Master File represents the prior census data 91 shown in Figure 3. The comparison generates three output files: (1) a list of individuals in both the input and the previously received census data called the Match File; (2) a list of individuals added to the census called the Unmatched date File; and (3) a list of individuals deleted from the census called the Unmatched Master File. It is important to note that both the Master and Update Files are sorted by their social security number or any other unique identifier "Key" to simplify the comparison.
As shown in Figure 5B if both the end of the Master File (End=Y) and the end of the Update File (End=Y) have been reached,the comparison is finished and the process shown in Figure 5H is executed (step 525). If End=Y, End=N and the end of the Update File has been reached, SEPTATE is set to infinite and the process shown in Figure 5C is executed (steps 527 and 528). If End=N and the end of the Update File has been reached, the process shown in Figure 5C is executed. If both End and End are not Y, and it is not the end of the Update File (step 526), an update record is read and the update count is increased (steps 529 and 555).
The number of update records that have been read is displayed (step 556) and the social security number, or "key," is extracted and verified (step 557). The system checks for duplicate update records (step 558) and the process shown in c is executed.
As shown in Figure 5C, if both End=Y and End=Y, the comparison is finished and the process shown in Figure 5H is executed (step 548). If End=Y, End=N and the end of the Master File has been reached, SSMast is set to infinite and the process shown in Figure 5D is executed (steps 552 and 554). If End=N and the end of the Master File has been reached, the process shown in Figure 5D is executed. If both End and End are not Y, and the end of the Master File has not been reached (step 550), a master record is read and the master count is increased (step 559 and 560).
The number of master records that have been read is displayed (step 561) and the key is extracted and verified (step 562). The system then checks for duplicate master records (step 563) and the process shown in Figure 5D is executed.
As shown in Figure 5D, a social security number in the Master File is compared to a social security number in the Update File. If the social security number in the Master File, or SSMast, is less than the social security number in the Update File, or SEPTATE, a terminated employee has been detected and the process shown in Figure 5E is executed (step 564). If SSMast is greater then SEPTATE, a new participant is detected and the process shown in Figure 5F is executed (step 565).
If SSMast is equal to SEPTATE, (step 570) a match has been found. The matched count is therefore increased by one and a matched record is built from the Master and Update Files (steps 570 and 572). The matched record is written to the match file (step 574). If the end of the Master File has been reached, End is set to Y, SSMast is set to infinite ( steps 576, 578 and 582). If the end of the Master File has not been reached and the End of the Update File has been reached, End is set to Y and SEPTATE is set to infinite ( steps 580, 581 and 583). In any event, the process shown in Figure 5E is executed.
The process executed when a terminated participant has been discovered, that is a record has been found in the Master File that is not present in the Update File, is shown in Figure 5E. If End equals N, the unmatched master count is increased by one and, if desired, an unreported master record is built and written to the unreported master file ( steps 584, 530, 531, 532 and 533).
If the end of the Master File is not detected, the process shown in Figure 5C is executed (step 534). If the end of the Master File is detected, End is set to Y, SSMast is set to infinite and the process shown in Figure 5F is executed (steps 535 and 536).
The process executed when a newly added participant has been discovered, that is a record has been found in the Update File that is not present in the Master File, is shown in Figure 5F. If End equals N, the unmatched master count is increased by one and, if desired, an unreported master record is built and written to the unreported Master File ( steps 537, 538, 539, 540 and 541).
If the end of the Update File is not detected, the process shown in Figure 5G is executed (step 542). If the end of the Update Pile is detected, End is set to Y, SSUpdate is set to infinite, and the process shown in Figure 5G is executed (steps 543 and 544).
As shown in Figure 5G, if both the end of the Master File (End=Y) and the end of the Update File (End=Y) have been reached, the comparison is finished and the process shown in Figure 5H is executed (step 545). If End or End are N and the end of the Update File has been reached, the process shown in Figure 5D is executed (step 564). If End or End are N and the end of the Update File has not been reached, the next update record is read and the update count is increased by 1 (steps 547 and 585). The number of update records is displayed and the social security number or "key", is extracted and verified (steps 586 and 55). The system then checks for duplicate update records (step 551) and the process shown in Figure 5D is executed.
As shown in Figure 5H, at the end of the comparison, the data files are closed (step 587). A report is printed (step 588) listing the results in the form of (1) individuals in both the input and the previously received census data; (2) individuals added to the census called the Unmatched Update File; and (3) individuals deleted from the census called the Unmatched Master File.
Thus, as shown in Figures 5A to 5H, the census data analysis ("CDA") module can compare two distinct sequential ASCII files, each comprised of fixed records of employee information. The fields in each record of one file can differ in form and substance from the fields in each record of the other file in all but one respect. Records in both files must each contain one "key" field, the value of which is unique within the file, and which is used as an identifier for that particular record. In the preferred embodiment, the social security number is used for this purpose. Both files are first sorted in order of the key and the program scans through both files simultaneously looking for records from both files with matching keys. Matching records contain a combination of data which relate to a single employee. The program take selected fields from each record to create a composite output record.
One input file is designated as the Master file while the other is referred to as the Update fife. The program allows the user to specify the disk location of each input file and to specify the location of the fields in each record of that file. The user then describes the desired layout of as many as three separate output files created as a result of the matching process. The first of a file of matched records where fields from both Master and Update records are merged together and selected to create combined and updated output records. The next option is to create a file of unmatched Master records. The records on this file can be redesigned by the user from any of the fields on the Master File. Similarly, a file of unmatched Update records can be created.
Consider a Master File of policy issue information for all of the originally insured participants of a particular client. Several years after plan inception a current employee census is prepared. This Update file contains such items as current salary and state of residence. From the matched records, the CDA module is able to create a file of all current employees who were previously insured. This single file could contain both policy data as well as current salary and state of residence information for each insured active employee.
A file of records created or copied from the unmatched Master records could also be created. These would be records for people who were originally insured, but are not currently employed and are thus either terminated, retired or deceased. Finally, a file of information for potential new entrants to the plan could be created from the unmatched Update records of current employees.
The program allows the flexibility to simply reformat the layout of existing files and create output files with any combination of either matched or unmatched Master or Update records. It is also useful for simply tabulating the total numbers of matched or unmatched records without ever having to create any output files.

Pecuniary loss Analysis

The reviewed and standardized census data is then used to perform a pecuniary loss analysis. Figures 6A to 6J are block flow diagrams showing the pecuniary loss analysis process according to a preferred embodiment of the present invention. The analysis is based on a set of parameters controlled by the operator. For example, the operator might select projected rates of inflation over the life of the contract, the average amount of life insurance provided to employees based on their salary, the normal retirement age for employees, the maximum and minimum premiums the client wishes to pay per individual, and which state's (or country's) laws and regulations will be used in the analysis. As a result of the pecuniary loss analysis, each individual in the census is classified, or placed in a "cell", based on the insurable interest the client has in the individual. If the results of the pecuniary loss analysis are not acceptable to the client, the parameters can be modified and other pecuniary loss analysis can be performed.
As shown in Figures 6A, the user is first presented with a menu listing the pecuniary loss analysis choices (step 610). The menu includes an option to return to the higher level menu (step 612), select a help screen (step 614), to save the parameters currently entered (step 616) or to load parameters previously stored (step 618).
When the appropriate control parameters have been entered or loaded, the user can also select to perform the pecuniary loss analysis. Initially, parameters are converted to usable alpha or numeric formats (step 620).
A vector or stream of annual health cost trend rates is created (step 622). This process is described in detail in Figure 6G. The health cost trend rate is taken for each year and used to calculate a health cost ( steps 670, 671 and 674.). The process is repeated until either the ultimate rate or the individual's retirement age has been reached (steps 672 and 673).
Referring back to Figure 6A, a vector of premium bands is created (step 623). This process is described in detail in Figure 6H. A maximum and minimum annual premium for each individual is selected for the client. For example, the client might wish to pay between $400 and $1,000 for each individual to be insured. A number of premium bands is also selected for the client. For example the client may wish to categorise individuals into three groups, or bands. The premium band size is then computed (steps 680 and 682). Using the above examples, three bands would be created: $400 to $600; $600 to $800 and $800 to $1,000. The bands are displayed (steps 681 and 683) are computed until the maximum premium is reached (step 684).
Returning to Figure 6A, the client's premium rates are loaded (step 624) and state workers' compensation benefit rates are computed as shown in Figure 6B (step 625).
As shown in Figure 6B, four brackets are set between the client's minimum and maximum premium values. The parameters for the states are verified and the standardized census data file is opened so that the data can be accessed (steps 627 and 628). A record representing an individual to be insured is read and the data is parsed into the appropriate fields (step 629). The individual's applicable state, such as New York or Virginia, and date of birth are then verified (steps 630 and. 631). If the date of birth is not valid, it is set to an unrealistic number, which forces the individual to be excluded form the insurance calculations.
As shown in Figure 6C, the field representing the sex of the individual is verified. If the value of this field is not valid, it is to set to "M" for male, as a default. The system then sets a flag if the applicable state for the individual is an "active health" state (step 633). That is, the flag is set if the state considers the health costs for the individual to be recoverable. The age is calculated based on the individual's date of birth (step 634). The age is considered invalid if the individual is under 20 or over 65 years of age.
If either (1) the age of the individual or (2) the state are not valid, nothing more can be done and the record for the next individual is read (step 635).
If the age and state are valid, the normal retirement age (NRA) for the individual is calculated, which determines when health premium payments will no longer represent an insurable interest (steps 636 and 637). After the normal retirement age is calculated, a determination is made: based upon user input, as to whether or not a non-qualified retirement income benefit liability (NQRIB) is present. If NQRIB is yes, then the NQRIB flag is set to "Y". The system then branches to the NQRIB module as shown in Figure 6J. Various parameters, some calculated, issue age, retirement age, some input, retirement payout period interest rates, plan type, are loaded (step 690). The system determines whether the NQRIB is a defined benefit (DB) or defined contribution (DC) plan (step 691).
In the case of a DB NQRIB, the benefit liability may be entered as flat amount or defined by formula ( steps 692 , 694 and 697). If defined by formula, the expression evaluator will parse and load the benefit formula.
In the case of a DC NQRIB, the deferral amount may be entered as a vector of deferral amounts or defined by formula ( steps 693, 696 and 697). If defined by formula, the expression evaluator will parse and load the deferral vector.
Once the benefit/deferral amounts are loaded, the retirement income liability (RIL) payout is calculated (step 698). The RIL is stored for later comparison to the CalcSumBen result as well as for use by the insurance illustration system, for targeting cash value and death benefit purposes.
Returning to Figure 6C, after calculating the age to stop health premium payments (step 637) the process shown in Figure 6D is executed. As shown in Figure 6D, the health care premium cost per year for the individual's state is calculated step 640). This is done for all the specified states until the final year of the insurance contract, or the final year that health insurance will be provided for the individual, is reached (step 642). The workers' compensation survivor's benefit is calculated based on the individual's salary (step 644). When the maximum benefits for all of the years have been determined, the sum of the individual's death benefit, health cost and workers' compensation is stored (step 645). When the sum of all the benefits is calculated, the system checks to see if the NQRIB flag is set to "Y". When the flag is yes the system will reset the sum of all benefits to the lesser of RIL or the current sum of all benefits.
This number represents the insurable interest the client has in the individual, not including life insurance. The process shown in Figure 6E is then executed.
Returning now to Figure 6E, the individual's premium bracket is increased (step 654) or decreased (656) based on the new benefit value and the face insurance value ( steps 651, 652 and 653). The amount of life insurance based on the new premium bracket is re-calculated. These steps are repeated until an appropriate premium bracket is selected. When the appropriate premium bracket is selected, a final benefit value is calculated using the appropriate recovery amount and the value previously computed and stored in step 645 (step 657). The process shown in Figure 6F is then executed.
As shown in Figure 6F, if the total value of benefits is greater than the face amount (step 660), a valid record is established (step 661) and, after the appropriate counters are updated and the record is packed (step 662), the output record is written. If the total value of benefits is not greater than the face amount, the user can select whether or not the record should be saved (step 664). In either case, if the end of the standardized census file has not been reached, the record for the next individual is processed (step 665). If the end of the standardized census file has been reached, the pricing and state analysis file is saved and pecuniary analysis reports are printed (steps 666 and 667).
Thus, the pecuniary loss analysis combines information regarding several types of benefits, provided to each member of a group of individuals in the census, with the individual's data. This is used to determine the total of the client's insurable interest in each of the chosen individuals on a pecuniary loss basis. This pecuniary loss analysis may be subjected to situs constraints of the transaction and or the residence of the insured. As this is done, the module determines an amount of life insurance for each employee that would reimburse the employer for its insurable interest at the employee's death at a level no higher than the pecuniary loss. Generally, the amount of coverage is chosen as the amount provided by one of several fixed levels of premium, very similar to a defined contribution type approach. The program uses an iterative process to solve for the appropriate premium level. As an alternative, the system may be given an aggregate employer benefit liability and would then calculate the insurance levels and premiums per insured, a defined benefit approach.
Normally, the employer's estimated pecuniary loss is comprised of four components. First, the amount of the employer provided pre-retirement death benefit is determined. This is generally based upon a pay related formula including the application of a salary scale to anticipate future increases in the actual benefit. Next, the state of residence of each employee may be used to determine the specific workers' compensation survivor's benefit payable in that state. Assumptions are made as to each employee's dependent status at death. For employees residing in states (under the insured residence approach) with modern insurable interest statutes, a total of the trended employer provided health care cost is also included. Finally, an amount which represents the accumulated value of the actual life insurance premium payments (time value adjusted) made by the employer is added to the other items.
The module contains a great deal of flexibility in its ability to deal with specified groupings of employees and special benefits unique to individual clients. It also generates various reports and data files which are used to communicate the results of its analysis and to provide input to other software for specific pricing and plan performance analysis.

Insurance Illustration

The pecuniary loss analysis generates data in the form of representative "cells". These cells are used to create insurance illustrations, or ledgers, for the client. Figures 7A to 7D are block flow diagrams showing the insurance illustration process according to a preferred embodiment of the present invention. The ledgers are created based on another set of parameters controlled by the operator. These parameters might include the client's cash flow requirements and funding objectives. The illustration reviews, and if necessary revises, every cell for each year of the insurance contract. The review includes calculations to determine whether the contract is a modified endowment contract MEC) and comply with § 7702(b) of the Internal Revenue Code of 1986 as Amended ("Code"). As before, the input parameters can be modified, and another illustration can be created, if the results of the illustration are not acceptable.
As shown in Figure 7A, census data is created and verified (steps 710 and 712). A menu is used to set up input parameters from the census data (step 714) and a compensation level, or profit level, is set for the sale of the insurance plan (step 716). Product loads, such as break points, state premium taxes and deferred acquisition cost ("DAC") tax considerations are calculated (step 718) as are product cost of insurance ("COI") charges (step 720). Finally, a probability table representing mortality assumptions is either read from a pre-stored file or generated (step 722) and the cash value and/or asset deployment allocation is read or calculated.
As shown in Figure 7B, cash flow parameters, such as the size of assets to be invested and the dates that assets are to be deposited to, or removed from, the plan, are defined (step 724). The client's funding objectives are also defined at this point (step 726). For example, the client may wish to build the cash value of the plan to a predetermined value by a specific date.
A death benefit level is calculated based on the census data and the premium levels committed to by the client (step 728). Each cell is then analyzed and adjusted on a per year basis. The death benefit is increased based on the plan's qualification as a modified endowment contract ("MEC") (steps 730 and 732). This is because distributions from a MEC are taxed to the extent of any income in the contract and there can be an additional tax on the amount of any taxable income distributed from a MEC. Also, loans from a MEC are treated and taxed as distributions.
The death benefit is also increased based on compliance with Section 7702(f) (7) (b) of the Code steps 740 and 742). This is because section 7702 sets out certain requirements that a policy must satisfy in order to be considered "life insurance" for tax purposes. The process then determines how to handle distributions in excess of the basis (step 750). For example, it must be decided if loans on the plan will be allowed. Finally, the process shown in Figure 7C is executed.
As shown in Figure 7C, current values and values that will be guaranteed based on certain assumptions are calculated (steps 752 and 754). These values are often required by the Securities and Exchange Commission (SEC) or state insurance regulators. If the last year of the contract has not been reached, the next year is then analyzed (step 756). Optionally, the process can also determine whether the calculated values are within present target ranges (steps 758 and 760). The target ranges may also be loaded from the values stored as retirement income liability from the pecuniary loss analysis. If not, the target amounts can be updated and the analysis can be repeated (steps 764 and 766). If such targeting has not been selected, or if the values fall within the target ranges, the process of Figure 7D is executed (step 762).

Financial Analysis

Figures 8A and 8B are block flow diagrams showing the financial analysis process according to a preferred embodiment of the present invention. The purpose of the financial analysis process and financial analyzer device is to analyze the insurance purchase and its financial impact on the client. The financial analysis can be conducted with respect to offshore captive asset deployment, as well as a company sponsored trust that funds employee benefit liabilities. The analysis measures insurance cash value (assets), it's allocation among various investment strategies (short, intermediate & long term), pre-tax and net after tax financial impact at various discount rates and the underlying cost structure of the insurance contract. Additionally, the analysis allows for matching of current and future liquidity requirements with cash flows that the insurance contracts generate, in terms of death benefits, cash value withdrawals and loans. The analysis clearly demonstrates the advantage to deploying assets offshore, through a captive insurance company, or a company sponsored trust. The financial analysis calculates the amount of assets that may be effectively deployed in insurance to maximise investment yields, minimise investment risk, shift insurance risk and satisfy future liquidity requirements.
The system calculates approximately 150 different tabulated variables that include the areas of: insurance analysis, income statement, balance sheet, cash flow analysis, earnings analysis, insurance product loads and expenses, alternative use of funds analysis, net present value analysis, earnings per share, return on investment, internal rates of return and the ability to customise additional variables, on an ad-hoc basis, as the client may request. These variables are tabulated and may be selectively chosen to generate standard, as well as customised, reports to meet the client's needs.
Referring now to Figure 8A, the user is first presented with a menu listing the financial analysis choices (step 810). The menu includes an option to return to the higher level menu (step 812), select a help screen (step 814), to save the parameters currently entered (step 816) or to load parameters previously stored (step 818).
When the appropriate control parameters have been entered or loaded, the user can also select to perform the financial analysis (step 820). Initially, a 100 by 150 matrix is set up (step 822) and insurance illustration data is loaded (step 824). Corporate tax rates, discount rates and use of money rates can also be loaded ( steps 826, 828, 830).
As shown in Figure 8B, a calculation methodology is selected and all of the financial analysis calculations are completed ( steps 840, 850 and 860). After the calculations are complete, the report parameters can be loaded and the reports are generated ( steps 870, 880, 890).

Client Information Management

Once an appropriate insurance contract is finalised, the system generates the insurance contract, and related documentation, and the census data is used to manage the client's insurance information during the life of the contract. Figures 9A to 9E are block flow diagrams showing the client information management process according to a preferred embodiment of the present invention. At this point, the census data is frozen and used to manage the client's insurance related information. Death benefit claims can be processed, an individual's insurance data can be edited and financial reports can be generated for the client. Because the insurance system is entirely integrated, all of these functions are automated.
System Administrators have access to insurance information for multiple clients and to housekeeping and databases directly. System Administrators are presented with a menu (step 906) that allows them to return to the main menu (step 909). This menu also lets the user: sweep a database as described with respect to Figure 98; perform data management; and perform finance and accounting functions.
As shown in Figure 9B, when the System Administrator elects to perform a sweep, an output file is created containing the social security number of the insured individuals which is then sent to a third party for validation (step 980). Sweep results are received from the third party, imported into the system and displayed (steps 981 and 982). Next, the data is reviewed and discrepancies are identified and flagged as described with respect of Figure 9C (step 970). Invalid social security numbers are resolved and, if necessary, death benefit claim are generated. The client is notified of any discrepancies (step 983) and an internal report is also generated containing the results of the sweep (step 984). When the sweep is completed, the system returns to the system administration menu (step 906 in Figure 9A).
Figure 9C illustrates the processing required to identify and flag discrepancies as discussed with respect to step 970 in Figure 9B. In particular, if an individual has a different last name, and is not a female having the same date of birth, the record is marked as containing a discrepancy (steps 971 and 972). If an individual has a different last name and is a female having the same date of birth, a marital status change is assumed and the record is not marked as containing a discrepancy (step 973).
Figure 9D shows the main menu displayed for the client information management system process. A portion of the screen will display a list of selected claims related to the insurance plan (step 920). The user is also presented with a menu listing the client information management system choices (step 910). The menu includes options to perform a claim search (step 950), generate reports (step 940), alter the status of an individual from deceased to living (steps 930 and 931), and edit an existing claim or create a new death benefit claims (step 920).
If the user selects the creation of a new death benefit claim, a new claim record is created (step 921) using the individual's census data and the client's insurance policy information (step 922). The remaining steps, shown in Figure 9E, are the same as those performed when the user selects to edit an existing claim from the main menu.
As shown in Figure 9E, financial transaction history information is retrieved (step 923) and the edit claim screen is displayed (step 960). The edit claim screen includes options to view general information about the claim, possibly to interface with other databases (steps 927 and 928), obtain a summary of claim financial transactions (step 926), view overall policy information (step 925). enter or edit insured data (step 924) and create death benefit claim paperwork.
If the user elects to create death benefit claim paperwork, the system will automatically generate a request for a death certificate (step 961). This includes a cover letter to the appropriate governmental records office, and the required fee, based on the zip code where the death occurred. After the death certificate is received (step 962), the information to process the claim is transmitted (step 963). Finally, once the insurance proceeds are received (step 964), the funds are distributed to the appropriate party through a wire transfer (step 965).
Thus, the client information management system ("CIMS") module is designed to automate the process of handling death claims, insured information, client billings, accounting servicing and overall plan administration. This is accomplished by providing a centralized database and interface that provides all necessary reporting and output to complete any of these functions.
The CIMS workstation application is an application which runs on all current versions of Microsoft Windows version 3.1 and higher. The main interface is a "desktop", by which a plan administrator, accountant, financial analyst or supervisor, can view the status of current claims in process, paid claims, policy, plan and insured information. Claims can be edited, inputting data as it is received, until the entire claim is processed. New claims can be identified to the system individually, or in a batch/sweep process, by matching the master insured list against databases of deceased individuals. The system allows a use to process a claim completely in a single sitting, or step by step, as each required step is completed. The system tracks the status of partially completed claims, displaying the status of each claim on the desktop, and if desired, prioritizing claim activity by status, time since notification, or by client. The system allows the user to identify critical steps in the process, such as ordering and receiving documentation, auditing and transferring payments. The CIMS application generates most of the paperwork involved in claims processing, and reporting on policy information. Death certificate orders, notification of pending and paid claims to clients and carriers, and cover letters and fax forms, can be generated to the laser printers on the network.
The CIMS application also handles the financial and accounting computations as well as policy data during the life of a policy. Premium payments, loans, withdrawals, cash values, interest calculations, and all transaction reversals, are all tracked by the system. All of these items are available for display, calculation and reporting at the carrier level, client level, policy level and insured level.
The overall system is built around a PC based Client/Server network architecture, utilising software and operating systems that will run on a variety of operating systems. The database server runs an SQL database engine, and contains all of the data tables required. It receives data requests in the form of queries from workstation clients and returns the necessary information. It also schedules database backups and provides fault protection through transaction processing, and by being supplied by uninterrupted and conditioned power.
The system also contains two other servers. A file server provides file and print sharing services, both for the CIMS application, and other office functions, such as word processing. The file server also handles login authentication to the Local Area Network (LAN). A backup server is in place to backup data on the file server, and archive copies of the SQL database, for disaster recovery. This server also provides fault tolerance by being able to stand in place of one of the other two servers, in the event of a hardware failure.
PC workstations access the CIMS data engine via the LAN, and run a client application of CIMS, which formulates the data queries sent to the SQL server, and provide output and reporting to the end users.
In preferred embodiments the invention comprises a system enabling faster processing within the hardware implementation.
Although preferred embodiments are specifically illustrated and described herein, it will be appreciated that modifications and variations of the present invention are covered by the above teachings and within the purview of the appended claims without departing from the spirit and intended scope of the invention.
The reader's attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference.
All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive.
Each feature disclosed in this specification (including any accompanying claims, abstract and drawings), may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.
The invention is not restricted to the details of the foregoing embodiment(s). The invention extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed.

Claims

A computerised integrated insurance system method, comprising the steps of:

inputting census data for a plurality of individuals in the form of computer records;

performing a pecuniary loss analysis based on pecuniary loss parameters and said computer records to classify said individuals into representative cells;

preparing insurance illustrations based on said representative cells;

performing a financial analysis based on financial parameters and said representative cells;

creating a final insurance contract and related documentation based on said representative cells; and

managing insurance information during the life of said contract based on said computer records.
A computerised integrated insurance system method, comprising the steps of:

inputting census data for a plurality of individuals in the form of computer records;

analysing said computer records; and

managing insurance information during the life of said contract based on said computer records.
A computerised integrated insurance system method according to claim 1 or claim 2, wherein said step of inputting census data further comprises the step of comparing said computer records to prior census data.
A computerised integrated insurance system method according to claim 2, wherein said step of analysing said computer records further comprises the step of performing a pecuniary loss analysis based on pecuniary loss parameters and said computer records to classify said individuals into representative cells.
A computerised integrated insurance system method according to claim 1 or claim 4, wherein said step of performing a pecuniary loss analysis can be repeated using modified pecuniary loss parameters.
A computerised integrated insurance system method according to any one of claims 1, 4 or 5, wherein said step of performing a pecuniary loss analysis calculates an insurable interest for each of said individuals in said input census data.
A computerised integrated insurance system method according to claim 4, wherein said step of analysing said computer records further comprises the step of preparing insurance illustrations based on said representative cells.
A computerised integrated insurance system method according to claim 7, wherein said step of preparing insurance illustrations includes adjusting said representative cells based on compliance with insurance laws and regulations.
A computerised integrated insurance system method according to claim 7 or claim 8, wherein said step of analysing said computer records further comprises the step of performing a financial analysis based on financial parameters and said representative cells.
A computerised integrated insurance system method according to claim 9, wherein said step of performing a financial analysis can be repeated using modified financial parameters.
A computerised integrated insurance system method according to claim 9 or claim 10, further comprising the step of creating a final insurance contract and related documentation based on said representative cells.
A computerised integrated insurance system, comprising:

a census analyzer (500) to input census data for a plurality of individuals in the form of computer records;

a pecuniary loss analyzer (600) to perform a pecuniary loss analysis based on pecuniary loss parameters and said computer records and classify said individuals into representative cells;

an illustrator (700) to prepare insurance illustrations based on said representative cells;

a financial analyzer (800) to perform a financial analysis based on financial parameters and said representative cells;

a final contract generator (100) to create a final insurance contract and related documentation based on said representative cells; and

an insurance information manager (900) to manage insurance information during the life of said contract based on said computer records.
A computerised integrated insurance system, comprising:

a census analyser (500) to input census data for a plurality of individuals in the form of computer records;

an analyzer (600) to analyze said computer records; and an insurance information manager (900) to manage insurance information during the life of said contract based on said computer records.
A computerised integrated insurance system according to claim 12 or claim 13, wherein said census analyzer (500) compares said computer records to prior census data.
A computerised integrated insurance system according to claim 13, wherein said analyzer (600) further comprises a pecuniary loss analyzer (600) to perform a pecuniary loss analysis based on pecuniary loss parameters and said computer records and classify said individuals into representative cells.
A computerised integrated insurance system according to claim 12 or claim 15, wherein the pecuniary loss. analyzer (600) can perform more than one pecuniary loss analysis based on modified pecuniary loss parameters.
A computerised integrated insurance system according to claim 12 or claim 15 wherein said pecuniary loss analyzer (600) calculates an insurable interest for each of said individuals in said input census data.
A computerised integrated insurance system according to claim 15, wherein said analyzer further comprises an illustrator (700) to prepare insurance illustrations based on said representative cells.
A computerised integrated insurance system according to claim 15 or claim 18, wherein said illustrator (700) adjusts said representative cells based on compliance with insurance laws and regulations.
A computerised integrated insurance system according to claim 18 or claim 19, wherein said analyzer further comprises a financial analyzer (800) to perform a financial analysis based on financial parameters and said representative cells.
A computerised integrated insurance system according to claim 15 or claim 20, wherein said financial analyser (800) can perform more than one financial analysis based on modified financial parameters.
A computerised integrated insurance system according to any one of claims 15, 20 or 21 further comprising a final contract generator (100) to create a final insurance contract and related documentation based on said representative cells.
A method for implementing an integrated insurance system using a computer system, said method comprising the steps of:

receiving census data for a plurality of individuals into the computer system;

performing a pecuniary loss analysis based on pecuniary loss parameters and said census data to classify said individuals into representative cells;

preparing insurance illustrations based on said representative cells;

performing a financial analysis based on financial parameters and said representative cells;

creating a final insurance contract and related documentation based on said representative cells; and

managing insurance information with the computer system using information generated with said census data.
A computer network comprising a plurality of electronic numerical computers networked together, which network is adapted and configured to operate according to any preceding claim.