Building a modern, event-driven application for insurance claims processing – Part 1

In this series, you’ll learn to build a modern insurance claims processing application on AWS. You’ll see an application that uses an event-driven architecture to loosely couple the applications’ components. This application is built with Amazon EventBridge, AWS Step Functions, AWS Lambda, Amazon DynamoDB, and more. You’ll also learn why an event-driven architecture and serverless services are well-suited for the insurance claims processing use case. Although this series focuses on an insurance industry use case, the concept of an event-driven architecture for loosely coupled systems is broadly applicable to industries that process customer requests, such as e-commerce, automotive, customer service, aviation, banking, loan processing, manufacturing, and more.

Processing an insurance claim

In the insurance industry, a common workflow is processing customer claims. The end-to-end process involves several steps for both the customer and insurer. For example, imagine that a customer has purchased a car insurance policy. When their car is damaged, they must file a claim to request payment from the insurance company for repairs. The customer takes photos, describes the incident, and submits a claim to the insurance company. The insurance company receives the claim, validates the claim information, confirms it’s covered by the policy, and determines the proper payment amount. Finally, the insurance company then distributes the payment to the appropriate parties.

Today, many companies execute these workflows using a combination of manual checks and legacy applications. Automation of manual processes can save thousands of hours, as in the case of Broadridge’s document processing solution. Legacy applications require ongoing maintenance to operate and scale. These applications may be tightly coupled, meaning that a change or failure in one component can impact the rest. Tightly coupled applications can be difficult to scale and risky to make changes to.

Why choose an event-driven architecture

An event-driven architecture uses asynchronous events to coordinate communication between different components. This creates loose coupling, which allows individual components to scale and fail as needed and development teams to build independently and release changes rapidly. Visit this post to get started with event-driven architectures.

Processing an insurance claim is inherently event-driven and asynchronous. The customer submits a claim, but they don’t expect an immediate or synchronous response from the insurance provider. Similarly, when the insurance provider requests details from the customer, such as their driver’s license and photos of the damage, there will be delay on the customer side when getting the information submitted. Furthermore, the insurance provider isn’t concerned with getting this information in a particular order, as long as it’s all submitted eventually. Given the asynchronous nature and lack of strict ordering, insurance claims processing is well-suited for an event-driven architecture.

Insurance claims processing flow

The following diagram shows the insurance claim processing flow in detail. Each of these steps will be implemented in the application as an event.

1. First Notice of Loss (FNOL):
   1. The customer informs the insurance provider about the damage/incident.
   2. The claims adjuster verifies the policy details.
   3. The customer provides FNOL information.
   4. Claim ID is generated as a reference.
   5. The customer uploads documents against the Claim ID.
   6. Documents are parsed and matched against the existing policy.
   7. Fraud is determined simultaneously.
   8. Claims gets accepted or rejected based on the validation and fraud determination.
2. Appraisal:
   1. Upon claim acceptance, the adjuster calls the accessor for appraisal and damage assessment.
   2. The assessor service provides compensation details to the adjuster service, which adjusts with the customer’s deductibles.
3. Settlement:
   1. The adjuster service provides the customer and a repair vendor with their assessment details and finalizes on a settlement
   2. The repair vendor contacts the customer to repair damages.

To achieve this flow, we must build an application that includes these nine services communicating via a central event broker.

Part 2 provides a walkthrough of the implementation of this application, including example code repository, AWS services used, and event-driven architecture best practices such as observability and monitoring.

Conclusion

This is Part 1 of a series on building a modern insurance claims processing workflow with AWS services. This post explains the insurance claims process, the benefits of designing the application with an event-driven architecture, and describes the flow of the application. Part 2 walks through the application architecture using AWS services, including EventBridge, Step Functions, Lambda, DynamoDB, and more.

See these resources to learn more:

• Event-Driven Architecture on Serverless Land
• AWS Skill Builder Serverless Learning Plan
• AWS Step Functions workshop
• Amazon EventBridge tutorials