Automation in insurance underwriting processes

Abstract

Underwriting is one of the important processes in insurance operations. The applicant’s information, including various kinds of medical information, must be evaluated before the insurance company can decide to accept the application. These activities are usually supported by process automation facility. However, the support of exception handling mechanism and the monitoring of turnaround time in those process automation solutions are usually inadequate. This results in a low efficiency of the underwriting operations or even loss of business opportunities. To address the problem, this paper presents an Alert-enhanced Underwriting System (AUS), which handles the exception events and monitors the turnaround time with the concept of alerts. We further illustrate how Web services facilitate workflow integration and process communications.

1. Introduction

Life insurance provides protection against the economic loss caused by the death of the person whose life is insured [1]. Because of its popularity, it is a business where many insurance companies allocate many resources in order to gain more market share. A life insurance policy defines the terms and conditions for the prospective client, particularly the situations under which the insurance company promises to pay a benefit upon death [2]. Since life insurance products can provide a stable “cash inflow” for an insurance company, there is a trend that insurance companies market various life products, such as investment-linked life products, savings life products and critical illness protection, in order to attract more customers with different needs.

Although life insurance business can generate financial benefits to the insurance company, the company still needs to bear financial responsibility to pay the insured under some agreed conditions, e.g., the insured dies during a specified period. The insurance will face the consequence of financial loss if the company accepts prospective clients, who present extremely high risks and when some of these insured persons die soon after policy issuance. High quality processes are necessary to assess the degree of risks associated with each application of life insurance. Underwriting (which is also known as “new business”) is a process of assessing and classifying the degree of risk represented by a prospective client and making a decision to accept or decline the insured.

Get Help With Your Essay

If you need assistance with writing your essay, our professional essay writing service is here to help!
Find out more about our Essay Writing Service

The world of electronic collaboration is developing rapidly, introducing new technology and new ways of collaboration. The success of collaboration often depends on the ability of a corporation not only to make sure that their applications are dynamic, but also to maintain a high degree of interoperability with collaboration partners.

In this paper, we present an Alert-enhanced Underwriting System (AUS) as a collaboration platform for streamlining the workflow of insurance underwriting processes. AUS makes use of an Event-Condition-Action (ECA) collaboration model [13] to manage event handling, process integration, and alert/exception management for the process flow of the underwriting operations.

The rest of the paper is organized as follows. Section 2 discusses some related work and background requirements. Section 3 describes system design and implementation for our AUS. Section 4 concludes our paper with our continue research work that look forwards to possible enhancements.

2. Background and Related Work

Electronic Data Interchange (EDI) essentially defined the technology of electronic collaboration in the past. However, EDI is an expensive solution, due to its high cost of network infrastructure and system integration. In addition, security issues of EDI also limited corporations from directly accessing the computing resources of its trading partners, which used “firewall-unfriendly” protocols. Therefore, developers start to find other technologies which have a low cost, flexible software solution that allows corporations to build new applications in response to changing business needs while adhering to a defined electronic business standard [10].

Recently, numerous vendors have offered solutions to support both XML (eXtensible Markup Language) and EDI formats for collaboration. One of the solutions is the transformation of information between companies: XML-to-EDI. Transformation is critical to an “edge” integration strategy that brings together B2B collaboration and enterprise application at the boundary of an enterprise in order to enable the back-end connectivity and workflow required to support a complete business process [11].

In the XML world, e-Business XML (ebXML) [12] is a modular suite of specifications which are initiatively designed for electronic interoperability. The strength of the ebXML architecture is that it provides a framework for electronic business collaboration. The architecture enables businesses to work together to specify business process, discover one another, negotiate collaboration agreements, and execute business processes. However, although ebXML implementations are already being announced, the rate of deployment of ebXML is not quickly accelerated. Many companies are taking a “wait-and-see” approach until ebXML becomes a mainstream in the market.

2.1. Key Processes and Integration

Figure 1 illustrates a typical underwriting process, which usually consists of the following four key activities:

1. Performing field underwriting,
2. Reviewing the application for insurance,
3. Gathering additional information to make a sound decision, and
4. Making an underwriting decision on the case [3]

However, before a new case is sent to an underwriter for processing, there are other activities involved:

1. Packing application forms and other documents from the agent
2. Initial premium payment through the cashier entry system
3. Data entry of new application in a branch or zone office
4. Scanning documents into images for workflow processing
5. Quality Check (QC) and Indexing on the scanned documents
6. Release of the validated and scanned documents images into workflow engine for further processing

In the traditional way of performing the activities 1 to 5 without any automation processes, it incurs high cost in human resource, storage cost, and paper work, together with a high turnaround time. That means it causes the underwriter to spend a long time to handle a new application. This affects the insurance company’s reputation and may further induces financial losses or even legal penalties.

With the advent of information technology, most of the above activities are linked together to streamline the workflow for processing a new business, starting from receiving documents from an agent, ending at the underwriter getting the case from workflow system and issuing new policy if approved.

Some benefits accrued to the business for automating the entire underwriting processes:

• Improvement of the service quality (such as turnaround time)
• Reduce of the risk of losing submitted documents during delivery
• Transfer of applications to the next step of the process immediately
• Better control of risk management such that some cases (i.e., excess of coverage limit) can only be approved by senior underwriters

The key integration of the processes between the agents and the underwriters are as follows.

Images and Data Transfer Process – This activity is an automated process and does not involve any manual operation unless the sub-system is down or errors / inconsistency occurred during the transfer. The purpose of this process is to transfer the scanned images and indexed data from a branch or zone office to the central office for importing into the workflow system. If the network linkage between a branch or zone office and the central office is a private connection (i.e., leased line), the operation is just a simple transfer of document images into the file server in the central office with an XML file including all the indexed data. If the network connection between both sides is public (i.e., the Internet) and it is not a Virtual Private Network (VPN) connection, then the interactions require other security measures as described in later sections.

Import Robot and Workflow Engine – They are located at the central office of an insurance company. The engine waits for the image files and XML data to be uploaded from the branch or zone office and verify the XML data integrity with the appropriate XML Schema. The imported document images and indexed data are installed into the existing workflow routing engine for case assignment to appropriate underwriters for further case approval.

2.2. Requirements Overview of Stakeholders

In automated underwriting processes architecture, a workflow engine (e.g., eistream [9]) is deployed at the central office. This engine can efficiently route job assignments to appropriate underwriters. The processing performed with the workflow engine is usually referred to as post-processing of the workflow. There are many pre-processing activities, which must be completed before those new insurance applications can be imported into the workflow engine for further underwriting. Figure 2 depicts a use case diagram of the underwriting process. The key stakeholders involved are discussed as follows.

Agent – He/she is an authorized representative to sell insurance products on behalf of an insurance company. The agents have the responsibilities to perform a simple check first by gathering initial information about prospective clients and screening applications who have requested coverage [4]. They have to gather required documents (such as health certificate) from the prospective client in order to speed up the underwriting process. Email access or Internet portal are the prompt means for agents to communicate with an insurance company.

Cashier Entry – For a new application of life insurance, the prospect client is required to pay the initial premium in the form of cash or check. The amount of premium is also dependent on the payment mode of the proposed policy. The agent has to submit the initial premium with the application. The cashier entry will collect the initial premium and put a premium receipt record in a “Premium Collection System.” The Cashier Entry also files the application forms and documents for data entry.

Data Entry – A user in branch/zone office enters the information recorded on the application form, such as the policy owner information, proposed insured information or medical information, etc., into the underwriting front-end input system.

Scanning Officer – When a scanning officer receives the documents, including application form, from an agent, he/she will try to sort and classify the documents into different document types (such as health certificates, identity proofs), and then scan them into images for auditable backup as well as indexing and quality check (QC). The application form is scanned just for auditable backup because the data has already been entered.

Index and QC Officer – After the submitted documents have been scanned into images, the index and QC officers (it may involve two individuals) will try to index the fields on several regions of a scanned image and save the indexed data into the database, so that the indexed data can be adhered with the corresponding images and imported into the workflow system. If the index officer discovers that the image quality of scanned document is not good, the document must be rescanned until the image quality of the document is acceptable for indexing.

Underwriter – An underwriter is assigned with a case (new or pending case) by the workflow engine. The underwriter carries out an assessment process by considering the submitted documentations, medical information, other personal factors like age, driving history, tobacco use, career nature, and financial factors of the potential client, etc. Then, the underwriter will determine whether the application is approved, pended for additional proofs or documentation, counter-offered to the applicant, or rejected.

2.3. Alert and Exception Handling

Although most of the activities starting from submitting documents in branch or zone office to the back-end underwriting processes are automated, there are still many events, both business-oriented and technology-oriented, must be handled in order to streamline and speed up the entire underwriting process.

Exceptions are events that can drive not only reactions performed by business parties [6], but also information exchanged within an organization, across physical boundaries (e.g., departments located in different geographical areas) or within (e.g., underwriting department and printing service department located in the same building) individual organizational boundary. In order to handle the exceptions and monitor the exception handling process, (especially those important and / or with urgency requirements), Chiu et al. [6] proposed the use of alerts to model and implement this. The key differences between alerts and exceptions are that alerts represents messages sent to a target, usually with time and urgency constraints, and that alerts are monitored and tracked. That means, to handle an exception, an Alert Management System (AMS) sends an alert message to a handler (human or system) and keeps track of the process until the handling job is finished.

In this application, the main objective of applying alerts is the concern about the turnaround time in the insurance application process. Some key exceptions and alerts generated by the main stakeholders are listed as follows.

Agent – Cancellation of an insurance application can trigger an alert to the central office so that the workflow system can change the application status (if it has been imported into workflow engine) into pending status and no more human resource will be wasted on this application. The application will ultimately be cancelled after the cancellation form is scanned and imported into the workflow system. The AMS can therefore make sure that the case is closed within a reasonable time limit.

Cashier Entry – An alert can be generated when the agent submits an initial premium payment for the new applicant but only part of initial premium has been settled. The alert can notify the central office underwriter to solve the application case if the case has been pended for the reason of insufficient premium.

Scanning Officer – Exceptions can be generated if the agent submits unknown type of documents or forms. If the workflow automation system does not know how to handle the unknown type documents or forms, then “unknown document” alert can notify the corresponding agent about this issue and urge him/her to fix this within a certain period.

Index and QC Officer – A “Document Rescan” alert can be generated to the scanning officer if the index officer finds the document image quality is too poor to be indexed. A QC officer can also generate a “Reindex” alert if he/she found that an index officer did not correctly index the fields on document images. QC officer can also trigger “Document Rescan” alert if he/she found the quality of document image is unacceptable even the index officer has accepted the quality of document image.

Underwriter – An “Insufficient Initial Premium” alert can be generated so that the agent can be notified that the initial premium must be settled before the policy can be issued even all the underwriting checks are passed for the case. This situation may occur when the client paid the initial premium with check but the check could not be cleared.

On the other hand, exceptions and alerts can be generated by automated processes, such as the following:

Images and Data Transfer Process – A “Transfer” exception can be triggered if the transfer process of images and XML data to the central office file server is not completed or failed/aborted at some points (because of the stability of network connection). An alert can then notify the MIS staff in the branch or zone office to investigate the root cause of transfer failure and resume the transfer process as soon as possible. An alert can be triggered after the transfer process of the branch or zone office is completed successfully, so that the import robot resided on the workflow engine can start the data verification process and import the images and data into workflow system. This helps to shorten the total time for processing of new applications and monitor pending cases.

Import Robot and Workflow Engine – A “Data Inconsistency” alert is sent to the agent if the import robot checks that the XML data uploaded from the branch or zone office contains inconsistency after validating with XML schema. This alert urges the agent to repeat or fix the images and data upload process.

Workflow Engine – An “Application Pending” alert is triggered to the agent who submitted an application for his/her client when the underwriter changes the new application status to “pending” because additional documentation is required. This alert urges the agent to contact its customer for the relevant documents before he receives an official “document request” letter from the insurance company, as applicants may need time to present documents, like health certificates or financial statements issued by banks.

2.4. Relationship management requirements

Alerts and exceptions are not only dedicated to handling abnormal or unexpected events. These can be used to enhance the relationship between insurance company and potential customers (B2C). For example:

Applicants can be notified by email with the progress of its life insurance application. On the other hand, the agent can contact his applicants promptly after he receives an acknowledgement email. Reminder alerts can be sent to the agent in the form of SMS to remind him/her to contact his/her applicant to collect required additional documents to process a “pending” application. This helps reduce the risk of insurance application being cancelled after an application has been pending for some time. This is because the customer may not know that insurance company requests more additional documents from him in case the agent does not contact him. This also reduces the chance of giving a negative image to the potential customers of poor services.

3. System Design and Implementation

In this section, we present the system design and implementation for our AUS, which includes the system architecture, various system components, Web services security, and an example scenario.

3.1. System Architecture

Figure 3 shows the overall system architecture for our AUS. We add on top of the existing enterprise information systems four main components in the backend AUS: Web Services Agent, Message Server, Alert Management System (AMS), and Event-Condition-Action (ECA) rules database that defines the actions to be triggered under some predefined conditions. We discuss the functionalities of these components in the following subsections.

One of the main problems in the current process automation is the effectiveness of communication among different stakeholders and systems involved in the entire process of underwriting. Based on the above discussions, we design an AUS based on exceptions and alerts as the unifying communication platform within the entire underwriting processes. On this platform, we choose to use Web Services with SOAP protocol for the communication and Message Server (such as Microsoft MSMQ [8]) for the underlying message (exceptions and alerts) processing. The reasons why we choose Web services with SOAP protocol in our platform are as follows:

• Web services can be invoked over the Internet or intranet, within or outside the firewall. For example, some processes like document scanning or image indexing may be located in the central office or outsourced to other service providers.
• Less development time is required to deploy Web service features from existing application, especially with the tools and libraries provided.
• It supports synchronous (RPC) and asynchronous messaging.
• SOAP has been implemented on many different hardware and software platforms.
• SOAP can be protected under the Web Service security [7] standard.

3.2. Web Services Agent

In our system, Web services technology is chosen to support the communication between the AUS backend systems and other front-end, sub-systems in branches and zone offices, as well as external agents and clients. The Web Services Agent transforms the incoming messages, which are in the form of XML data embedded in SOAP (Simple Object Access Protocol) [14], into native message formats that can be sent into the queues of the central message server. The Web Services Agent also transforms the alerts and exceptions from the form of native message format into the XML/SOAP format and uses HTTP protocol to send the XML message to the branch/zone offices systems through respective Web services.

A sample SOAP messages from a client system is shown in Figure 4. This message describes the indexed data and images to be uploaded to the file server in the insurance headquarter after scanning operations have been performed on the submitted documents in branch and zone offices. Figure 5 shows a response message from the AUS that describes an alert from the Transfer Module in a branch or zone office and notifies the MIS staff to handle the exception.

3.3. Message Server

The message server comprises of application queues and system queues and the server manages the received data (i.e., incoming XML/SOAP messages, internal MSMQ messages from other enterprise systems, and alert messages from the AMS and routes the messages to the target (subscribed) parties. For example, when the Transfer Module sends a Web service message to the AUS, the message is put into two waiting queues: one for the Import Robot and another for the AMS (so that the AMS can monitor the progress of the Import Robot). When the Import Robot has verified the integrity of uploaded data and images, it sends a message to inform the AMS of job completion, or a “Data Inconsistency” alert in case of data inconsistency. These messages triggers events so that the AMS issues new alert/exception messages upon on the conditions in the event repository database to related parties for further actions (as discussed in Section 2.3) based on the ECA rules defined by the administrators.

The reasons why we choose the Message Server as a core component in managing data communication are as follows:

• Most of the message servers support Web service functionality.
• Message servers support guaranteed message delivery.
• Asynchronous message communication as well as publish-and-subscribe can be supported.

3.4. Alert Management System (AMS)

The main role of the AMS is to manage the alerts. It also captures the events and exceptions (i.e., MSMQ native message format) submitted by other parties. Alerts are generated based on the ECA rules specified in database to the appropriate parties. It further transforms the alerts into a MSMQ message and put it on the waiting queue for Web Services Agent for the delivery. Further details of the mechanism of the AMS, including descriptions of the ECA rules, can be found in our earlier paper [6]. We apply the same AMS module except that we include a message server component to further increase the messaging reliability.

3.5. Example Scenario

In this subsection, we use a scenario to illustrate the system flow in our AUS. Figure 6 depicts the process flow for this scenario. First, a Scan Station prepares a XML data file which contains the policy number and other indexed data for the scanned documents. When the XML file is ready, the Transfer Module uploads the XML file and document image files into the central file server. Upon completion, the Transfer Module generates a SOAP message, which details the uploaded data to Web Services Agent in order to notify the Import Robot to verify the integrity of uploaded data and images.

After the verification, the Import Robot generates the verification result event and the AMS captures the “data uploaded” event from the Transfer Module together with the event generated by the Import Robot, and returns the appropriate events back to the Scan Station and Scan Officer based on ECA rules processing.

3.6. Web Service Security

Web services integrate applications inside and outside the organization. However, distributed computing always has a challenging set of security issues. Identities and messages are two of the greatest security challenges brought on by Web services. Web services transport potential unknown entities into your organization and messages are transported from one place to another place through an unsecured channel, the Internet. Therefore, actions must be taken to safeguard the information exchanged among the authenticated parties. XML Encryption and XML Signature are used to address the protection of sensitive data and the identification of identity of data sender respectively [15]. Figure 7 shows an unprotected SOAP message that contains payment information for an insurance policy. Figure 8 shows how encrypted messages and signature are put in a SOAP envelop.

The element block contains the encrypted form of payment information. The element contains the XML signature for payment data. In general, a shared key must be provided so that receiver of the messages can decrypt the protected data. However, it is a bad idea to include the key in the SOAP message (i.e., the element block) because unauthorized parties could just get the key and decrypt the protected data. AgreementMethod is a protocol for safely communicating a secret key. This key agreement protocol, like the SSL secret key agreement protocol, is used to generate the encryption key along with the key material necessary to repeat the encryption key generation on the recipient’s side [15].

4. Discussion and Summary

Process automation by integrating existing enterprise information systems with workflow software has proved to increase the staff productivity, thus turns out to generate more business values in terms of more revenue and less expenditure. However, if the process flow within a business workflow from one step to next step is not smoothly executed (e.g., failure of transferring complete XML data to workflow engine and servers but no further “resend” action is done), then the next step may not be able to proceed until the problem is detected and fixed. This kind of situations significantly wastes human resource and time and should are not expected to occur in automated processes. Therefore, by integrating the AUS with the existing workflow infra-structures can bring the workflow automation into full play because the errors or unexpected events can be detected and relevant parties or processes are notified with alerts to rectify the problems. The following tangible benefits can be achieved with the AUS, mainly through the enhanced monitoring and tracking through the AMS with a service-oriented architecture.

For example, the turnaround time taken to rescan documents, which have been identified as poorly scanned, is shortened. If the scanning officer is not notified properly, the poorly scanned document will probably be rescanned after the scanning officer triggers to print out a report on listing those document rescan requests, thus resulting in longer processing time in some cases. This benefit is also applicable to the process of “Document Reindex” for the index officers.

Moreover, the AUS helps maintain data integrity in uploading data into the centralized file server. If the XML data is inconsistent and the import robot still proceeds to import the inconsistent data into workflow engine, it will result in unexpected or serious consequences. The consequences may be a delay in processing applications or even a wrongly underwritten insurance application that could put financial risk to insurance company.

On the other hand, more attributes can be added to measure staff performance. Since the alerts generated to officers and agents are monitored by the AMS, the time spent on handling the exceptions and alerts can be calculated based on the time recorded in database. For example, if a scanning officer receives a “document rescan” alert, then he must rescan the requested documents and relevant records within the “document update time.” The performance is logged into database and reports for staff can include this kind of attributes to measure the staff performance. So, the workload on investigating problems related to the entire operation flow can be reduced as detailed information about the problems can be found from the exceptions and alerts well managed by the AMS of the AUS.

In addition, the following intangible benefit can be achieved with the AUS. Customer satisfaction can be improved. The document processing and flow are smoothly controlled and executed. This can shorten the entire processing time for new case applications and thus result in issuing and sending policy to policy owner within a shorter period of time. This can enhance the insurance company’s professional image as well because the short processing time of new insurance application can impress its customers and improve the customers’ confidence in insurance company. This might led to more business opportunities in the future.

This paper has presented an overview of underwriting process in an insurance company and the automated facilities incorporated into the underwriting process to drive the entire underwriting. A Web-service based alert-enhanced underwriting system has been presented in this paper to overcome most of the existing problems of the underwriting process workflow implementation. We expect this approach is suitable to other business processes that involve human approval together with the need for maintaining documents for auditing and legal purposes, such as loan and credit card approval.

After finishing the AUS platform prototype, we shall then proceed to study the benefits of adopting the platform in existing workflow infra-structures in the insurance company’s perspective through questionnaires to collect user feedback. Although the proposed platform obviously facilitates the handling of most problems or events in the process flow of underwriting, there are still some unexpected events that are hardly to be detected or tracked. Further studies should be carried out on this topic. Future works include the extension of AUS platform to support artificial intelligence in handling the exception events as well as agent-based assistance to internal staff and external users. We are also interested in empirical measurements of the improvement of staff performance and customer satisfaction.

References

1. Miriam Orsina, Gene Stone, “Insurance Company Operations” (2nd Ed), pp.3, LOMA, 1999
2. Harriett E. Jones, Dani L. Long, “Principles of Insurance: Life, Health and Annuities” (2nd Ed), pp. 8, LOMA, 1999
3. Jane Lightcap Brown, Kristen L. Falk, “Insurance Administration”, (2nd Ed), pp. 22, LOMA, 2002
4. Jane Lightcap Brown, Kristen L. Falk, “Insurance Administration”, (2nd Ed), pp. 67, LOMA, 2002
5. Miriam Orsina, Gene Stone, “Insurance Company Operations” (2nd Ed), pp.243
   

    

   Share this: Facebook Twitter Reddit LinkedIn WhatsApp