Automated Life Underwriting

Large numbers of insurers have realized that use of an automated underwriting system has become a must for jet issuance of policies. The industry is struggling to grow trying multiple channels of distribution but the growth is hindered by complex underwriting processes which are either too complex or time consuming thus making the new business acquisition an expensive and protracted affair.

Life Insurers have not really changed the way the policies are underwritten from last few decades. Processes are still people dependent, their experiences, referring to rule documents and other raw pieces of information from different sources. Manual processes may result in inconsistencies in terms of high error rates and cost of labor.

Even though there are technology advancements to create instant issue environment such as paperless offices i.e. no need to float the physical papers across, Web based underwriting systems integrated with advanced analytics engines to support underwriting decisions but most of the companies are still on the old legacy systems.

An automated underwriting System evaluates all criteria relating to an application and the applicant and then return one of the three recommendations decline, approve or review (gray area) or “caution”. These decisions are arrived by the rules configured in the System. A typical Life Underwriting System can underwrite an application or a proposal on following criterion:

1. Insurable interest: The first step in underwriting a life insurance policy is to verify the policy owner's insurable interest in the insured individual, defined as "having an interest in that person remaining alive, or expect emotional or financial loss from that person's death."

2. Medical and Non-medical: Companies usually investigate the health of the proposed insured. Height & weight (Body Mass Index), blood pressure and other health factors are taken into account.
Based on the Sum Assured, Entry Age of the Life Assured (LA), Sum under Consideration (Sum Assured of all policies and proposal including specific riders of the LA with the insurer), and Plan opted by the applicant etc medical tests to be undertaken by the LA can be derived.

3. Female Lives: based on the occupation, age, insurance on husband (if married) etc.

4. Juvenile Lives: health condition of the child/ minor.

5. Occupation & Avocation: A proposal can also auto loaded / rated up the system for Occupation of the Life Assured and the policy holder. Different occupations can be associated with classes.

6. Medical questions filled by the Life Assured and the results of medical tests: the system can be made interactive with reflexive questionnaire based on user inputs. E.g. If Life Assured is a smoker than next question would be “how many cigarettes in a day?” etc.

7. Family Health history: Any medical history in the family and any post critical illness deaths before the age of 60 etc.

8. Alcohol & smoking history.

9. Financial Underwriting: financial stability of the life assured or the policyholder can be judged by annual income, source of income etc.


Cased Base Reasoning

The underwriting process and the rules can be continuously improved based on the experience collected in these systems. The process of underwriting a new proposal based on the underwriting decisions made of similar past cases is called Cased Based Reasoning (CBR). Case-based reasoning is not only a powerful method for computer reasoning, but also a pervasive behavior in everyday human problem solving; or, more radically, that all reasoning is based on past cases personally experienced.

CBR traces its roots to the work of Roger Schank and his students at Yale University in the early 1980s where the effort was made to introduce another method of artificial intelligence. These principles can be extended to Automated Underwriting (author comments).

CBR for the purpose of automated underwriting can be of a four step process.

1. Retrieve: Given the set of data parameters in the application form, relevant set of cases underwritten earlier can be retrieved and the decisions made. E.g. an underwriter who wishes to underwrite a term policy for a pilot with age 55 years may retrieve all term plan cases underwritten earlier with occupation as pilot.
In the process of retrieval also the claim information of similar cases can be retrieved.

2. Reuse: Map the retrieved data to the target proposal which is in the process of underwriting. E.g. in this case the underwriter must adapt his retrieved solution to include the addition of higher age at entry.

3. Revise: Having mapped the previous solution to the target situation, test the new solution in the real world e.g. the decision can be given on vetting by an experienced underwriter or also looking at the previous claims experience of similar type of cases.

4. Retain: After the solution has been successfully adapted to the target problem, store the resulting experience as a new case in memory. E.g The newly underwritten case becomes an addition for the system thus enriching set of stored experiences.


Conclusion:
Moving towards an automated underwriting system adapting to latest technology insurers can create a real time and intelligent environment which can support an instant and jet issuance environment. Policies can be issued in minutes and companies can open more distribution channels such as online, retail, banks, individual agents etc.

Grid computing & Batch Jobs

“Mike what is the status of renewal premium bills to be generated for this month; we are already late by 2 days to send the letters to customers”

Mike: Boss, the process is running very slowly, 1 million records are getting processed and PDF files are to be generated for all customers. We will be sending the files for printing and also email them to customers. My estimate, it would take another 26 hours for the whole process to get completed.

Jack: But Mike, we invested in a Quad core server with 16 GB RAM last week for this job. I thought there will substantial improvement on this front. Gosh… we spent $16,000 on the machine.

Mike: The process is running in a single thread, all the resources of the machine is not getting utilized. The Memory and CPU are idle by 70%. I guess we can’t do much about it…

Many of us face such similar problems, where we have voluminous deliverables to give to business users but are also constrained by the way systems are built. “Single Thread processing problem” as Mike was facing is common to most of the batch job runs in a typical Insurance company. This may also be applicable to organizations with similar nature of jobs. E.g. a credit card company generates monthly statements and sends them to Emails of customers, summary of statement is sent as an SMS and consolidated data is sent for physical printing. A bank may be doing the same for monthly bank statement etc. In-house programmers in these companies made efforts in improving the performance by tweaking the queries which were extracting the data from the Databases or legacy systems, and the process of creating final output was parallelized by using “Multithreading”.

Mike: Boss, I can modify the program for fetching the data and do the process of making PDF by multithreading.

Jack: That seems to be a good idea, but how many threads you think, can be run in parallel in our new server.

Mike: It’s a Quad core and there is enough memory; I guess we can runs 4 threads simultaneously and reduce the time of processing by 1/3rd ...hmm…approximately.

Jack: seems to be a good idea… let’s try to implement it.

Mike with lot enthusiasm created the design of new idea.



Jim (the programmer) helped Mike to transform the idea into an actual running program. He did many trials and pilot runs before actually using the program to generate the next month’s premium bills. Results were outstanding; processing time was reduced to almost 1/3rd as actually guessed by Mike.
Bitten by performance improvement bug, Mike started thinking of further improvements in the process.

Mike: Boss, I’d like to scale up the server and would like to add more CPUs. We can create more number of threads for processing the files.

Jack: Mike I’m afraid that we will not able to invest any more in hardware. Budgets are not approved. It’s a difficult situation; you may have to think of some alternative.

“Necessity, who is the mother of invention” – Plato

When no silver bullets are left and necessity arises then as rightly said “constraints create Innovation”.

Jim: How about Grid Computing?

Mike: Wow that seems to be a good idea. But we do not have additional servers to run the grid.

Jim: We have 120 dual core Desktops in our office, we can use them for running our program. Desktops are usually free during the night time.

Mike: Any grid software that you are aware of?

Jim: Heard of many, but I did small Proof of concept with Gridbus during my university project. We may try writing our program on the alchemi framework. It’s an open source framework.

Mike: Jim, can you help me draw the architecture of our new idea? I am kind of excited to get this thing running…



Jim: We have 120 dual core desktops with 2 GB RAM, I think we have an ocean of memory and CPU. The Grid server component we’ll place in our server and all the processing (executors) in identified workstations. I suppose it should work like this

• Server will fetch the Data from the database and keep the data in memory.
• The process of formatting the data and generating of PDF files can be given to each individual executor.
• Collate generated PDFs on the server.
• Since we have to also Email the files to clients, we can dedicate few threads for sending Emails to individual customers.

Jim programmed the complete logic using grid framework and the results were marvelous. Perseverance of Mike and efforts of Jim resulted in a masterpiece.

Mike: Jim lets cross our fingers and run the program on the final data for this month.
Processing…..

Jack: Guys, I am proud of both of you. Your ideas and efforts have solved our everlasting pain.

Many of us face similar problems in day to day operations. Sometimes we are constrained by tighter budgets, ideas and resources but few of us think forward and out of the box to make life easier. I wanted to present this article as a theory on Grid computing but a short story seemed to me as a good idea (!)