InsurTech: Event-driven Insurance Policy Processing Approach

Traditional monolithic policy processing systems are often burdened with complexity and inefficiency, leading to slow response times, errors, and customer dissatisfaction. However, the emergence of InsurTech has paved the way for innovative solutions that can revolutionize insurance policy processing.

In this blog, you’ll learn how to build a modern, scalable insurance policy administration system on Amazon Web Services (AWS). Specifically, we’ll create an event-driven architecture using services like Amazon EventBridge, AWS Step Functions, and AWS Lambda to loosely couple components for efficient policy processing and underwriting.

The event-driven serverless setup allows scaling to handle spikes in policy requests. The application will leverage a microservices-oriented structure with different components handling core functions like data ingestion, business and eligibility rule processing, risk analysis and pricing calculations. Customer data will be persisted in Amazon DynamoDB enabling low latency data access.

This blog post provides a solution that will assist customers in implementing a skeleton or template for an event-driven architecture framework. This can accelerate the process of developing an event broker engine for the high-level business process workflow in policy management to:

Onboard new customers
Underwrite and rate policies
Integrate with external partners
Complete end-to-end policy lifecycle handling
Minimize overhead costs

General Processing of an Insurance Policy

The workflow for processing an insurance policy typically begins when a customer submits an application with their details and requested coverage to an insurance company. The insurer reviews the application, assesses overall risk, and formulates a policy quote with coverage specifics and premiums for the applicant to approve. To bind the policy, the applicant approves the quote and policy generation occurs as part of the issuance workflow, resulting in the insurer sending final policy documents to the insured customer. This issuance completes the policy processing and initiates active coverage, which is subject to renewal on a recurring basis, where the insurer reevaluates risk and pricing in order to continue the policy.

Traditionally, insurance companies utilize dedicated, coordinated departments like sales, underwriting, rating, policy processing, claims, and compliance to execute the end-to-end workflow. It begins with sales facilitating applications and assessing needs, then flowing to underwriting for evaluating risk, and pricing to generate quotes. Next, policy processing would input data to ultimately issue policy documents and manage renewals, all while compliance ensures adherence to insurance regulations throughout the process. Processing bottlenecks in this system can lead to significant time and money costs, potentially resulting in the loss of customers.

Challenges with Traditional Insurance Policy Processing

Many insurance carriers rely on aging, legacy policy administration systems that pose increasing burdens. These systems often consist of tightly coupled, interdependent components that communicate in complex ways. This tangled architecture means that even a small change to one element can create major failures across other components.

As a result, essential processes like underwriting, rating, and policy management depend on outdated technology that strains to meet the scaling demands of growth. Adding new product lines or integrating with modern channels may be impossible without major workarounds. There is constant risk that performance could degrade severely or even fail entirely when usage spikes occur.

Ultimately, aging policy administration platforms have become a source of organizational fragility and mounting technology debt. The lack of flexibility impedes bringing innovative products and experiences to market—hampering a carriers’ competitiveness. The interdependencies between the aging policy administration platforms and integrating systems are complex, which can potentially create system outage risks that violate compliancy mandates or completely prevent customer service.

Why Model an Event-driven Architecture

An event-driven architecture (EDA) decouples application components by using events for communication between them. This pattern is well-suited for modern microservice-based applications since it enables loose coupling between the microservices. The independence of the loosely coupled microservices provides increased resilience and scalability to the application—services can scale or fail without affecting others.

EDA facilitates rapid development and release of microservice features; as teams only need to worry about their own service behavior, not those of other services. Additionally, new capabilities can be built on top of existing event workflows without invasive changes, allowing developer teams to innovate quickly. Basically, EDA leverages events to allow the microservices in modern applications to be developed, scaled, and enhanced independently.

Event-driven Lifecycle of an Insurance Policy Processing

To process an insurance policy several steps are typically involved. Figure 1 outlines the general lifecycle of an insurance policy processing workflow which is implemented in the application as an event-driven module. The application architecture will include services that are orchestrated through a central event broker. The event broker facilitates the coordination and integration between the different services and events.

Figure 1 – Lifecycle of an Insurance Policy Workflow

The policy processing business workflow includes:

Renewal Processing: The insurance company may offer policy renewal as expiration nears, reevaluating coverage, risks, and premiums to align the renewed policy with any changes in the policyholder’s situation.
Reserve Submission: The submission service team is responsible for the full process of reviewing, processing, and approving insurance submissions to reach the point of issuing quotes and policies to customers. This involves creating and reviewing submissions, verifying information, checking for compliance, requesting more details if needed, and transferring submissions between agents and underwriters. The submission service uses various methods like shell creation, viewing and updating submissions, regulating blocks, and finally issuing quotes, binding/booking, and issuing policies.
Create Quote: The insurance company reviews the application and assesses the risk associated with providing coverage to the applicant. This evaluation includes factors such as the applicant’s age, health, occupation, driving record (if applicable), and other relevant criteria.
Policy Pricing: If the application is approved, the insurance company creates a policy document outlining the terms and conditions of the coverage. This document specifies the coverage limits, premium amounts, deductibles, and any additional policy features or endorsements.
Policy Issuance: If the policyholder is approved for insurance, the insurance company will issue the policy. The policy will include the terms and conditions of the insurance coverage, such as the premium, deductible, and coverage limits.
Policy Notification: Official notice of communication regarding policy details such as policy terms and conditions, renewal timelines and premium payments.

The Event Broker (Amazon EventBridge) orchestrates the policy processing workflow. The details of some of the AWS services and components are explained in the event-driven architecture section.

The service layer consists of reusable, modular components that enable orchestration of policy processing using event-driven architectures. Key services include:

Third-party Data Integration: Enables seamless data exchange with external systems to enhance capabilities.
Policy Endorsement: Modifies existing policies by adding, deleting, or changing coverages to meet policyholder needs.
Policy Issuance: Handles processes of preparing, reviewing, and delivering policy documents after underwriting approval.
Policy Management: Manages policies throughout their active lifetimes including making changes or amendments to an existing insurance policy (such as adding or removing coverage, changing limits or deductibles), adding drivers or vehicles, and such without having to cancel and rewrite the entire policy.
Document Processing: Supports workflow and insights extraction from historical, third party and other policy related documents to facilitate decision making. It leverages AWS Intelligent Document Processing to unlock insights from policy documents—reducing time to value for decision making.

Event-driven Solution for Reserve Submission

The Reserve Submission is one of the key sub-processes within the life cycle of an insurance policy (shown in Figure 1). We’ll now outline the Reserve Submission process as an example and describe how event-driven architecture can be applied. The same approach can be extended to other sub-processes explained in the overall workflow.

A submission refers to the set of information that is sent to a commercial insurance underwriter for the quoting and underwriting process and then used to book an insurance policy. The Submission includes details like:

Type of business
Years in operation
Location
Claims history
Desired coverage
Assessment of the risk
Pricing of the policy

The Submission allows the underwriter to evaluate the risk profile of the business and determine appropriate terms, conditions, and pricing for the policy. To reserve a Submission, several steps are typically involved.

Figure 2 – Reserve Submission Workflow

Figure 2 outlines the overall submission workflow which include creating and managing submissions (Get, Add/Update) and accessing existing policy information. It also includes transferring (Assign) submissions between parties (like the business owner, agent, and underwriter), and ultimately providing a quote (Create Quote) for the new or renewal policy.

Figure 3 – Reference Architecture Diagram

When transitioning from a monolithic to a microservices architecture, we must determine how the different AWS services will communicate. Event-driven architectures can decouple and decentralize application components through synchronous or asynchronous messaging. Figure 3 provides an overview of key AWS services for developing event-driven architectures. This includes using events to integrate distributed services, enabling them to communicate asynchronously and building a modern application strategy.

This architecture style helps customers build loosely coupled, scalable applications that support rapid new feature development. Event-driven architectures have a strong affinity with serverless services that are invoked by events. The EDA architecture in insurance policy management minimizes service inter-dependency, improves scalability and flexibility, near real-time visibility and monitoring, as well as near real-time processing.

Some AWS services considered in this solution uses are:

Amazon API Gateway – a fully managed service that makes it straightforward for developers to create, publish, maintain, monitor, and secure APIs at any scale. API Gateway removes complexity around API creation, maximizes efficiency and scalability, and provides governance across policy admin APIs. These are key capabilities for insurance digital transformation.
Amazon EventBridge – a serverless event bus service that connects applications using data from a variety of sources. Amazon EventBridge removes bottlenecks, enables automation, and provides visibility as policies flow through your insurance systems. With appropriate rules and integrations, it can optimize and streamline policy processing workflows.
AWS Step Functions – a serverless orchestration service that lets you combine AWS services into serverless workflows. The service helps model complicated policy processing workflows through a visual interface, streamlines management and reduces errors.
AWS Lambda – a serverless, event-driven and efficiently scalable compute layer with native integration across AWS services. Lambda functions can integrate policy admin systems with other services like payment gateways, Know Your Customer (KYC) providers, and fraud check APIs. It enables insurers to modularize logic for reusability, maintenance and scalability.
Amazon DynamoDB – a serverless, NoSQL, fully managed database with single-digit millisecond performance at any scale and can be used as the data store for policy storage details like customer data, coverages, limits, premiums and more.

Figure 4 – Event-driven Architecture Sample Submission Data Flow

Figure 4 explains the high-level data flow involved in event-driven architecture systems focusing on the submission workflow.

The Read API allows the retrieval of a Submission snapshot. This is implemented as a read-only API that consumers access through a GET request to the API Gateway. The API Gateway then invokes an AWS Lambda function to perform the read operation against the backend database and retrieves the Submission snapshot data. The AWS Lambda function can also orchestrate and aggregate any additional information as needed. If a more complex state or task management is required, AWS Step Functions could be considered as an alternative implementation option along with AWS Lambda.

The Write API allows users to perform write operations by sending POST or PUT requests to the API Gateway. These requests then invoke AWS Lambda functions, which post messages to Amazon EventBridge. This event-driven approach enables a distributed architecture where coarse-grained service APIs can be triggered by events to update a database or send out notifications. External parties can also subscribe to these events for further downstream data processing.

The architecture pattern described can serve as a high-level blueprint for implementing event-driven architectures. The same approach of having loosely coupled services that communicate by using events can be applied when designing APIs for other services.

This sample GitHub repo application showcases how to set up an event-driven architecture, which can be referenced for insurance policy processing.

Conclusion

In this blog we explained the insurance policy process, the benefits of designing the application with an event-driven architecture, and described the flow of the application.

In examining insurance policy processing systems, we found that distributed architectures not only coordinate events between business units but orchestrate workflows within them. Coordinating events across business units and organizing workflows within business units is most effective when these approaches work hand-in-hand.

Contact an AWS Representative to know how we can help accelerate your business.

AWS for Industries