September 21, 2020 | Written by: ibmblogs
Categorized: AI | Banking | Cloud | FinTech | IBM RegTech Innovations
Share this post:
149, 542, 782, 974 . . . what do those numbers mean to a claims handler or to an investigator? When analytics programs evaluate claims and/or other insurance objects such as policy holders, body shops, providers, etc., the analytics generate a score to reflect the level of risk of the evaluated objects. That score is presented to the claims handlers who typically work in their claims systems such as Guidewire, DXC Assure, Majesco, and other systems. It also goes to investigators from the SIU who are leveraging a case management application to investigate referred claims. While claims handlers and investigators understand that the higher the score, the higher the risk. The score alone doesn’t arrive with any indication of what contributed to that score. The score doesn’t carry an explanation as to whether there was an anomaly detected, whether the claimant has a history of claims, whether one of the involved parties has a history of financial distress or a criminal history, or other anomalous situations.
What part of the claim is suspicious or needs more evaluation?
For 10 years or more, technical programs have generated scores, or perhaps a red, yellow, or green color bar indicating suspicion — which leads claims handlers to take a closer look at the claim. But the question is: What part of the claim is suspicious or needs more evaluation? Claim handlers are busy people, often handling claims with expectations to evaluate, gather information, and conduct an initial claims investigation – quickly – to speed the claims process to settlement.
During the settlement process, for example, an alert comes to the representative with a score of 850, but that’s it, just a score. Now the claims handler has an indication that something may not be right, but what is the basis for the score? After all, the claim associates handle many claims a day and perhaps nothing that they’ve seen so far in the scored claim seems suspicious to them.
Adjusters need more than just a score
A better practice is to provide some other indicator that there are features of a claim that need more work or review – and show those features to the adjuster so they don’t have to search through the entire file of work, documents, statements, EUO’s and more to find what’s causing the analytics to alert. Adjusters need more than just a score.
Providing “explainability,” with easy-to-read descriptions of what fired in the analytics leads the handler back into the claim, document, or recorded statement to the item that needs more attention, or is suspicious before settlement occurs. Then the claims handler can do their initial review or send the claim to SIU for more investigation.
SIU’s have historically used analysts or even investigators to scour through claims that scored high, for example looking for underlying features that caused the claim alert. Once they reviewed the claim notes and what electronic documents they could find in the logs, they may have discovered something that they thought was the trigger of the alert and score, just to realize that they missed something. Easy to do, they’re human. So when the technology points out that something is out of place and explains what that is, then the person working the claim can verify that event or activity and determine how to proceed with settlement.
Machine learning provides greater dynamics for explainability
Even better is a low- or no-score associated with a claim. This allows claims professionals or claim processing systems the opportunity to settle a claim without suspicions of fraud, quickly and confidently that there is nothing out of place. Machine learning applied to your company data and tuning up your models regularly provides greater dynamics for explainability and keeps you informed about trends that are particular to your company. Does your company have a solution to flag or alert particular claims that need additional investigation? If so, how are the alerts handled? Do they generate a number or other form of alert to the claim handler, analyst or investigator to dig through, slowing the claims settlement process down?
About IBM FCI
IBM Financial Crimes Insight for Claims Fraud (FCI) provides alerts through your claims system. An activity is assigned to a claim’s handler in Guidewire, for example, to work and either close the activity with investigative notes or send the claim to SIU for more investigation. With efficiency, the associate or analyst sees what alerted in the file through explainability provided in the alert. The FCI solution provides explainability so that your associates can settle claims expeditiously, with confidence that suspicions have been investigated or eliminated through the analytics.
In the world of digital claims and speed to settle, are you confident you’re catching suspicious claims before settlement? For more about the latest analytic techniques to combat claims fraud, check out the IBM webinar replays on demand at COVID-19: Responding to the threat of fraudulent claims and How can the Insurance Fraud Industry stay ahead of Insurance Fraud in the new normal?
IBM Financial Crimes Insight for Claims Fraud is part of the IBM RegTech regulatory compliance solutions that are designed to help financial institutions better meet their regulatory monitoring, reporting, compliance and risk management needs. Read more about FCI at https://www.ibm.com/cloud/financial-crimes-insight-claims-fraud
By Wade Wickre, Watson Financial Services – Insurance Financial Crimes Leader for North America, IBM Global Markets – Cloud Sales, and by Neil Leblanc, IBM Cloud and Cognitive Software