LXA — a single solution which will transform your insurance claims process

LXA is a claims automation engine. In other words, it uses data analytics as a mechanism for driving automation.

It’s industry agnostic, too. And because LXA is not a bespoke platform, it can easily be used for any process where there’s a chain of decisions to be made — handling social security claims, for instance.

But the most enlightening thing about the scalable and visually appealing LXA is that astute insurance firms are using its generic solution to solve specific point problems, such as automation. Conversely, instead of using LXA’s one-stop solution for all issues, less insightful insurers are buying armories of individual tools to combat each and every challenge they come up against.

Luxoft can help you prove a point

Using LXA and doing a proof of concept on a single-point solution gives an entirely reusable proposition. No more taking the traditional approach of building a one-dimensional model and thinking that’s, for example, fraud dealt with, then building another model to deal with recoveries, and then another to deal with subsequent issues like litigation and supply chain management. With the easily extendible LXA, once your first model is built, the platform can be used for injuries, for the supply chain, and many other business sectors. The smart strategy is to simplify and reuse the components across all insurance automation challenges. LXA replaces fraud tools, injury tools, litigation management and supplier databases with a Dataiku layer that looks after all existing information. Using your existing data scientists, and leveraging the knowledge of your claims experts to write the rules in Dataiku, the system will drive decisions and send them back (via an API) to the claims systems (see chart 3).

LXA is not (just) a fraud engine

Although this is a fraud example, LXA is not only a fraud engine. It’s an intuitive automation engine which uses analytics to improve scenarios across any number of issues and industries. The modular, plug-and-play platform is easy to train, test and monitor, and delivers real-time levels of performance and a rapid time to market. Our current use cases feature either existing platforms or manual interventions which look at historic data and take a decision on the claim or underwriting system. Using LXA, machine learning can easily be introduced into that process in order to automate primary experiences.

It’s all about automating processes using machine learning and AI with a proven model. The following chart shows how technology and the insurance business align within the claims model:

1. Delivering a single solution for claims

Business decision-makers are concerned with issues in the outer circle: “How do I automate my claims? How do I do my injury assessment? How do I do my legal cost assessment?” The IT department looks at the bullseye, saying, “Here are some proprietary tools that I can deploy to enable the business to achieve whatever it’s aiming to achieve.”

A businessperson might look at the chart and say, “Great! I could do claims automation” without really understanding what that means. From a technology perspective, an IT manager looks at the chart and thinks, “I’ve got Snowflake too. Wait a minute, you’re telling me that the tool I already have can be used to deliver all of these things for which the business is expecting me to come up with a solution?” It’s two sides of the same coin.

LXA streamlines claims handling

This second chart represents the generic claims process relied on by most insurance companies. You’ll find similar processes for policy administration and other functions, too.

2. The insurance claims ecosystem

Chart 2: Existing claims ecosystem

A policy holder submits a claim (first notification of loss: FNOL). The triage person says, “Was anyone injured?”

The customer replies, “Yes.” “OK I’ll put you through to somebody who’s experienced in handling injury claims.” Then the insurer checks:

• Coverage: Were we insuring the car at the time of the accident? Was the driver covered under the terms of the policy?
• Liability: Did our customer cause the accident? Are they responsible for injuries to the other person?
• Quantum: How much is that accident worth? Did anyone have whiplash? What’s the quantum — the value of the claim?
• Indemnity: Usually, this is just about the payment. But, if it was a household claim, indemnity could involve repairing a house (or just physiotherapy, maybe). How do you deliver the claim resolution?
• Payment: Insurer does the claims resolution and makes a payment
• Recovery: Sometimes, someone else is responsible for the claim and it’s necessary to make a recovery

System of record: Insurance companies have a system of record that sits underneath that process layer. It’s a policy admin system that records all policies sold. It’s also a claims admin system for claims received. And sometimes, that system of record includes workflow management with another workflow management tool around it.

Analytics warehouse and databases: Most of these systems of record feed into an analytics warehouse where tools are used to analyze the data. That can mean anything from supporting pricing through to determining, “Are my claims going up in value? Am I getting more claims? Are the claims getting more complicated? Am I getting more claims for this particular vehicle or in this particular area?” The database products sit alongside in a layer, including:

• Fraud database: Many organizations have a list of people suspected of committing fraud or a set of rules identifying potentially fraudulent claims. For instance, car accidents that happen at 2 a.m. on dark country lanes are often caused by people who’ve spent the night socializing at a pub, bar, restaurant, etc. So, there’s likely to be an element of fraud in the claim because they’re never going to admit to drunk driving.
• Injury database: Most insurers have an injury database listing medical injuries that can occur and how severe those injuries can be. A good example would be if you’re right-handed and break your dominant arm. That’s worth more than if you break your left arm, because it means you can’t do as much as you could previously. Insurers use their injury database to estimate how much the claim is likely to cost them.
• Litigation database: Insurers collect information on lawyers to record which practitioner always takes a low/high offer, which one adds on extra injuries, and so on. This enables them to benchmark lawyers and keep an eye on claims where costs are spiraling out of control.
• Supplier database: Back to indemnity. If you’ve advised a supplier to repair your house, then the supplier might have a database that stipulates the average cost of rebuilding a house, the average cost to replaster a wall, and so on.

Integration layer: Some of those underlying databases are directly connected to the system of record. The fraud database could have a direct link, taking information from the main system and feeding it straight back in. The same with the injury database — some might just be feeding data down.

So, the system of record is sending data down but getting nothing back. You can remedy this with a platform like Dataiku. Currently, insurers are saying things like, “I’ve got my analytics. If the analytics aren’t in the same database, I can either extend the platform over those other databases, so Dataiku can call data in from here and do some assessment in the middle, or I can move my databases into the analytics warehouse.”

Leveraging the Dataiku platform to do more

LXA doesn’t mind what data warehouses are sitting beneath. With a Dataiku platform, its functionality can be leveraged for analytics and machine learning, and this can be used to drive actions back to the system of record.

For instance, take private healthcare, where people submit receipts for GP appointments. Now, you can use Dataiku and your information to ratify a receipt against the amount claimed. And if the claim’s within the bounds of tolerance, it can be paid — automatically validating the claim using information already held.

3. Claims automation using LXA

Chart 3: Using Dataiku

A customer calls to report their claim accident circumstances (FNOL). You’ve got lots of information in your analytics database about how much claims should cost, and you can see the claim is likely to involve fraud, so you want to have a look at it.

Triage is saying smart routing. Again, Dataiku can be used to work out the complexity of the claim and write the rules to say it should go one way or the other. Then you send a message through an API back to your system of record, which routes it into the correct location.

STP stands for straight through processing. If the claim circumstances look right and there have been 1,000 claims that are exactly the same — and were paid immediately — you can feel confident paying this claim straightaway using machine learning. Then it’s possible to start replacing tools that take care of things like fraud separately.

Ahead of the curve, or still playing catch-up?

Several insurers are using Dataiku solely for data reporting. They’re not using the data for automation. And rather than, “I’ve been automating for 3 months, how do I get to the next level?” their big question is, “How do I start automating?” By using analytics to drive automation, adopters will be ahead of the curve.

LXA’s aim is to leverage insurers’ existing investments, with as short a time-to-value as possible. And the first chart (which includes Dataiku, Tableau and Snowflake), flags our point of view. A large number of insurers are already using Dataiku and Snowflake. So, it’s the IP around how you’re using analytics to drive automation that’s the differentiator, not necessarily the underlying tools.

Practical scenarios

As mentioned earlier, LXA is platform agnostic. Consequently, the resulting cross-fertilization of ideas and learnings with other industries while using LXA in different scenarios can only be healthy.

A good example is in online retail. Online retailers are running analytics to determine which customers are returning items, who’s over-ordering, which customer’s packages are always going missing, etc. They’re using machine learning to try and second guess customers — should they provide free postage and packaging, should they charge for returns, or even blacklist certain customers? What they’re doing here can transfer directly into the insurance space.

Again, insurers can adopt some of the analytics and the learnings. If somebody buys a garment online, wears it once and later sends it back, then that’s a clear example of poor moral hazard.

If you’d like to find out about LXA and what the platform could do for your own claims processes, contact Jeremy Owenson. For more information about our industry experience visit luxoft.com/insurance.