Re-Imagining an insurance company - do you really need a policy management system?

I have a fair amount of background in the insurance industry, I even am a fellow of the FLMI (brag brag) but I have always been puzzled by why insurance companies needed policy admin systems’... True, my knowledge of technology is more modern, so I probably can’t appreciate the marvels these systems did, but to me, the technology exists today to do things much simpler, cheaper, and much more flexibly.

Before I had the guts to write this blog (nobody wants to look totally stupid), I chatted with a few friends, a solutions architect who has experience in the insurance industry, a friend whose company sells banking systems, and a couple of actuaries with experience across the industry including in product development. But of course any errors/omissions are mine.

To me, insurance policy admins deal mainly with workflows. There is a specific flow for every activity in the insurance industry, let’s take a policy issuance for example. The flow might be something like:

There are 5 actors in this workflow, the customer, the producer, and 3 actors internal to the insurance company, the team that does the admin side of policies, the underwriting team, and management of the underwriting team for exception handling.

The producer and customer/prospect meet, data captured and application made. If the data is complete the application reaches the underwriting team, else it goes back for completion. If it is the case is insurable it proceeds, else it is rejected.

The underwriting team decides whether it is a standard case, or a non standard case within limits. In both these cases a notice of quotation is sent to the customer followed by a formal quote. If the case is non-standard but not within limits, it is escalated to underwriting management for approval or rejection in which case the notice of quote and quote follow, or the rejection letter.

Upon receipt of the quote, the customer can decide to accept and the policy is issued.

You may be wondering why I have colour coded my flow chart in white on dark blue, dark blue on white, and turquoise on white. Basically, while humans are involved at all stages in the flow chart, the white background show steps that are ready to be performed either by automation, or the use of "Data Science"/Analytics/ML/AI.

In this workflow above, I have added one actor “Analytics/ML/AI”, and instead of admin, we now have an automated process.

In this case, the rejection rates of application and delays to issue policies due to incomplete information disappear since the check of details (and verification for existing customers ensuring consistency) is done on the spot using smart forms. 

Once the forms are received electronically (note in the earlier workflow I skipped the scanning of paper forms which would just have made the comparison even more drastic), it is evaluated by the model/algorithms, firstly for insurability, and whether the case is standard. The non insurable and standard cases are dealt with instantly.

The underwriting team only has to focus on non-standard cases, and underwriting management with non standard cases beyond limits.

This process eliminates individual bias in the process since all policies are treated identically, considerably shortens the time it takes to evaluate the straight forward cases and shortens turn-around-time, while alleviating the burden from the underwriting team, allowing them to focus in fewer cases and be able to again turn around faster.

Of course analytics and automation can also play a role in the other hugely time and resource consuming area in insurance, claims.

Let’s take motor insurance claims for example, start with a very simplified process flow:

When a motor accident occurs, the customer sends pictures and makes a report (with help of producer or company employees) and a case is created. At a later stage, if necessary a police report and claim document are submitted and added to the case file. An estimate of involved cost will be provided by a 3^rd party, usually an adjudicator. Then the claim, based on these submissions, is processed.

The assumption is that below a certain dollar value, an insurer does not stringently verify the claim, however above that value, two sorts of checks are carried out, one on the claimant, checking the probability of fraud, and the second on whether the documents support the damage. Anything that is not in line will warrant an investigation. These increase the cost of the claim to the insurance company. Then based on whether the all clear is obtained, the claim is approved and paid, or rejected.

What analytics can do is perform the fraud checks and evaluate claims automatically.

Using Analytics/ML/AI firstly allows the insurer to verify all claims if need be since the cost of checks is much lower and is the same for all cases. Hence, it is not possible for wannabe fraudsters to game the system by claiming just below the threshold amount they think the insurer uses.

3 different techniques are likely to be used, and combined.

For the customer check, graph databases are extremely efficient. For example, a classic case of fraud is the whiplash injury fraud where a group of people take on some roles: driver, passenger, victim, witness... and simulate an accident where the victim claims whiplash injury. Then they change roles and go again. Graph databases detect such circles very easily.

For the damage estimation, this is done via AI/ML; there are quite a few providers nowadays who offer this service even as an API. Hence being able to estimate the damage and the cost of repair is done via computer vision, being fed the photos of the current damaged vehicle.

To extract information from the accident reports, existing NLP or text mining algorithms including Name Entity Recognition algorithms can be used. This can be used for simple hygiene, extracting the weather, road conditions, speed... Then based on this information, models can be built to estimate the damage. The results of this and the damage estimation can be combined and validated.

The nice thing is that this process can be run quickly and across all claims; only those that do not clear the process would require human intervention to review for approval.

Hence the time to process claims (and the cost) drops as the Analytics takes care of most cases quickly and consistently, and the cases that do not clear the process are then referred to humans allowing focus and dedication to quickly clear more complex cases.

Ok, so what I am saying is that Analytics/ML/AI can help add consistency to insurance processes (applications, claims...), make the processes run faster and allow humans to really focus on these cases requiring specific attention.

No big deal, at least not enough to warrant the disclaimers and bragging at the beginning...

Actually, I will go further.

As I have shown above with 2 examples, most of the administration of insurance policies can be relatively easily converted to workflows, with some document management thrown in. In fact, I would argue that most insurance policy admin systems are just that, workflow and document management systems, with formulae (for calculating the next premium for example) built in.

The newer insurance systems acknowledge that by highlighting that they come with workflow templates to allow users to quick start including their products. But is that enough?

I would argue that these do not go far enough. 

I am not a technical guy nor am I very familiar with many cloud providers, so I will use GCP (Google Cloud Platform) as an example.

They have this very interesting product called data flow which allows you to create workflows just like the diagrams above, and each box has a specific task to accomplish. Another neat aspect of dataflow is that the boxes can be the running of algorithms, for example a simple decision tree to decide whether a risk is standard or not, or the application of a clustering model to decide the premium to be applied in a particular case. Hence, most non manual processes can be orchestrated with dataflow.

When dataflow is fed by another product pubsub that basically acts as a giant reservoir that holds requests and releases them as and when they are ready to be processed (either by pull or push) it becomes even more powerful.

It could be argued that traditional insurance systems can also be tweaked to make the workflows more automated, but where size comes into the picture, the winner is clear.

Most insurance systems are chunky. They come at a certain price and can manage a certain number of cases. So if you are a new company, you might be getting something too big for you.  On the other hand, once you decide a size, it can be quite hard to quickly scale up and scale back down again.

This is what GCP allows insurance companies to do. Pubsub allows insurance companies to accept huge volumes of applications that arrive in a very quick succession or even simultaneously and make sure none are lost (the order they are attended to may be messed up but no application should be lost). 

Then since it is a no-ops cloud product the size of/number of machines required temporarily to process this huge workload can be put online in minutes, process the applications, and shutdown when they are not needed.

The data, once processed by dataflow, can be pushed to big table (to take advantage of low-latency and be easily updatable) (and say cloud storage for pictures for example).

A simple example will illustrate the point. Let’s say, an insurance company decides to offer accident coverage to participants of the Standard Chart Marathon, all 50,000 of them. The applications come in fast and furious during registration, these need to be processed, approved quickly, and then you won’t need such processing power immediately.

What of the next event you want to cover is the OCBC Mass Cycling event but this time want to insure the bikes...

The other nice thing about dataflow is that creating a new workflow can be done in python, not some arcane language.

Basically insurance companies using a cloud service with something like GCP’s pubsub, dataflow, ML and storage like Big Table (which can include metadata about pictures) and something like Cloud Storage for actual pictures/scans together with APIs (for example to verify payments have been made) can substantially simplify their processes, make them much more responsive to business needs, and allow themselves the flexibility of creating new products and/or new processes that suit them and their customers rather than relying on pre-packaged generic products.

Again, I’d just like to reiterate I am using GCP as an example and I am sure other cloud providers can offer similar advantages.

However the conclusion, to me, is still valid. If the main reason insurance companies are tied to traditional insurance management systems is legacy, new insurers are at an amazing advantage. Technology today allows them to create new, flexible workflows, be able to customise products for micro-insurance/event insurance, and process them in a timely manner by quickly scaling up and down as required, and use very generic skills (python) to do so.

Does that mean that traditional insurers are going to be extinct? No. It’s just that their legacy is a burden, but no one stops them from using new technology to create and manage micro-insurance/event-insurance, new products to serve their customers better, to run in parallel with their current systems as these are sunset and the functions ported over.

The key is to find ways to efficiently serve your customers exactly how they want to be served, customised products, flexible options, true customer centricity. This is the true advantage and the technology is just an enabler.

The insurance industry is ripe for disruption and the appropriate use of technology, sacrificing some sacred cows, and re-thinking and customising products while retaining flexibility is the way forward.