How to Accelerate Innovation in Insuretech

The insurance industry is going through a vast innovation cycle that will alter how products are sold and managed. These changes will also simplify how carriers, brokers, MGAs and insureds interact with each other. This blog covers how technology can simplify and accelerate this groundbreaking process.

The main drivers for these innovations are:

1. Improved customer experience.
2. Accelerate underwriting by increasing access to more data.
3. Reduce operational cost.
4. Increase automation in claims processing.
5. Faster, wider, and deeper access to business data from internal and external sources.
6. Ability to support flexible rules for backend processes.
7. Ability to interoperate with the existing internal ecosystem.

Business Challenges

The insurance domain experts often conceive of a new insurance product idea. That is when the challenge starts:

• How to prototype the idea and get customer validation.
• How to iterate over the idea, and incorporate customer feedback.
• Setup infrastructure, hire SI, build an in-house team of technical experts.
• Last but not least, perhaps the greatest challenge, how to do this essential digital transformation within a reasonable budget, i.e. without committing several hundreds of thousands or millions of dollars.

Real-life Experience

Before we get into the solution of the problems, I would like to discuss a real-life use-case our team was involved with recently. This application supported the following functionality:

• Direct sell to customers through an online website.
• Customer self-service portal for policy viewing, document downloading, billing, claims submission and tracking.

The system didn’t have that many well-defined use-cases. Yet, its technical implementation turned out to be a very long project. While the domain experts did a fabulous job of defining the use-cases, and the technology team also did a great job during the implementation, we learned several lessons that we like to cover in this blog.

Application Requirements

The application had the following requirements:

• The website should deliver the best possible user experience on all types of devices, i.e. phones, tablets, and laptops.
• The new application should be cloud-native to avoid the acquisition of new hardware.
• The application should have standard security capabilities.
• It should integrate with legacy products for rating, policy document generation, billing/accounting functions.
• The application should be able to use new generations of cloud services to make the product offering robust and fast. For example, the underwriting of policies should be automated using the information available from other services and government agencies.
• The application should be able to use an external payment gateway for online payment through credit card and checking accounts.

Application Architecture At 10,000 Feet

The domain experts provided an excellent design of the user interface and process definition. The technical team got to work and came up with the following architecture.

• Microservices architecture with a focus on reusability vs pure microservices.
• An API gateway for secure access to all APIs.
• Integration with an industrial strength authentication service.
• Secure integration with legacy products using custom connectors.
• Secure integration with external cloud services using their API’s.
• Replicated and encryption-enabled managed database.
• Microservice deployment architecture using containers and a cluster manager.
• Deployment on a popular public cloud.
• Use one of the latest frameworks for UI development.

Where The Time Was Spent

The application was delivered successfully and, as of this writing, has been functioning smoothly for several months. But looking back, we realized that most of the time was spent on the activities that had little to do with the domain of insurance.

• CI/CD setup — took months to stabilize.
• CI/CD use by developers — This is a critical point. One aspect of CI/CD is to set it up for cloud deployment. The often overlooked part of CI/CD where most of the time is lost, i.e. its use by the development team. Whenever a developer made a small change, they had to run the CI/CD for testing their change in the cloud environment. Often, the developers spent an inordinate amount of time on using CI/CD pipeline.
• DevOps — Designing cloud architecture, setting up a cloud network, setting up gateways, etc.
• Slow UI Iterations — We had an excellent UI team. However, this is an area that will require industry-wide attention to improve. In order to build the best user experience, it is a necessary requirement that actual users provide feedback to the UI as it is being developed.

What We Missed

We missed out a few pieces in our architecture. As we know more about these now, a future Insurtech architecture could address these. It will help accelerate the delivery of future similar applications at a rapid pace and at a much lower cost.

• Dynamic configuration — Although we used metadata at some places, we did not use it in several important components such as data model, API mapping, service integration (using OpenAPI).
• Serverless Development — In this context, we will use serverless in a broader sense than Cloud Functions or AWS Lambda. The serverless for the application developer means a) scripting, 2) rule-based application logic and, 3) graphical design of the process.
• Eliminate CI/CD For Developers — This ties into the previous point of rule-based development and scripting. The developers writing the application logic should provide a framework where they can merely script the logic than build a process and deploy.
• Ways to Enable Quick UI Iterations — This can be achieved in 2–3 steps such as being able to load UI from a local server, interface with the cloud services using an access token, and build metadata-driven components. In an ideal world, all or most of the UI components would be available from a single source and they will metadata-driven. The framework should provide a metadata-driven scenario builder. This will minimize the UI code and enable rapid iterations.

A Futuristic Architecture For Insurtech

Based on the above considerations, we recommend that future Insurtech applications follow these architectural principles:

• Dynamic integration of business logic — The architecture should support rules, business process definition, and scripting. The author of the application should be able to change these without having to build the entire code-base. They should also be able to test it in their own sandbox.
• Dynamic Data Model — The application author should be able to specify the data model dynamically, i.e. the data model can be changed at any time without the need to redeploy the application.
• OpenAPI for Service Integration — The application author should be able to input authentication configuration and OpenAPI documents of the services. The platform should transparently provide integration with these services.
• Sandboxing — The platform should enable a testing ground for the dynamic changes described above. Each application author should be able to verify the changes without impacting other team members and the environment.
• Eliminate CI/CD — If the platform supports the above requirements, the application author can be completely free from CI/CD.
• Eliminate Repeated DevOps / Security — A platform supporting the above characteristics can be deployed once on the cloud with all the correct configuration and security settings. Another instance of the platform can be created by following the same process. It means there is no need to deal with any DevOps issues after the initial deployment time.
• Dynamic UI — UI components and UI scenarios should be created using metadata with the least amount of coding.
• Balance of Legacy and New Services — The legacy applications provide domain intelligence captured over several years. At the same time, they are usually not very flexible. In order to achieve the most flexibility, a mix of new rules & scripts coupled with legacy services should be used. For example, there may be cases when a custom rating engine can provide more flexibility and control. Or, in another case, the generic API available on the cloud can be used for PDF document generation.
• Use Machine Learning for Analytics — Make decisions based on the intelligent analysis of demographic and audio/visual data.
• Use AI for Underwriting and Claims — Use AI/ML whenever there are gaps (unavailability) in data, process, product and customer interactions.
• AI Driven Development — Create applications in-house in a highly intuitive manner using Natural Language Processing on a platform that provides agility, reuse, and open architecture (no vendor lock).