Welcome to Understanding Link Analysis. The purpose of my site is to discuss the methods behind leveraging visual analytics to discover answers and patterns buried within data sets.

Visual analytics provides a proactive response to threats and risks by holistically examining information. As opposed to traditional data mining, by visualizing information, patterns of activity that run contrary to normal activity surface within very few occurances.

We can dive into thousands of insurance fraud claims to discover clusters of interrelated parties involved in a staged accident ring.

We can examine months of burglary reports to find a pattern leading back to a suspect.

With the new generation of visualization software our team is developing, we can dive into massive data sets and visually find new trends, patterns and threats that would take hours or days using conventional data mining.

The eye processes information much more rapidly when information is presented as images, this has been true since children started learning to read. As our instinct develops over time so does our ability to process complex concepts through visual identification. This is the power of visual analysis that I focus on in my site.

All information and data used in articles on this site is randomly generated with no relation to actual individuals or companies.

Integrating eCommerce Analysis With Insurance Fraud Analysis

More and more, insurance companies are getting into the eCommerce business. Today you buy policies, file claims, get quotes and pay for everything with a credit card, all online. Many businesses, primarily retail, have been involved in eCommerce and the corresponding fraud analysis that comes with it.

As insurance companies move a great deal of their business online, fraud analysis, prevention and investigation will have to leverage online detail. SIU's are experts at the investigation of claims and in the past all the information from those claims came from contact between the claimant and the claims representative. When a person wanted to take out an insurance policy on a vehicle they went to their agent or at a minimum, talked to a salesperson on the phone, somewhere in the transactions there was personal contact.

With the move of more insurance business moving to the web, there is no personal interaction between the person who is buying a policy from your company to the person filing the injury claims from an accident. It is important to integrate the information captured during these online sessions into the fraud detection, analysis and investigation, yet because this is a fairly new venture for insurance companies, it's time to take a lesson from your retail corporate neighbors on how to integrate eCommerce data into your fraud program.

There are a great deal of similarities between fraud analysis performed for eCommerce and that with insurance fraud. Links between attributes entered by the customer are leveraged to find clusters of suspected fraudulent activity such as addresses, phone numbers, email addresses and the like. The difference between the two industries is that eCommerce analysis places less weight on physical attributes and more weight on internet captured data to determine relationships between entities and purchases.

The reason why more weight is placed on iData then physical or entered data is that in eCommerce fraud analysis, it is assumed that anything entered by the user in a fraud scenario is false. It is still important data, the way people create false data creates important patterns for analysis, but when you are trying to tie multiple fraudulent transactions together, what is behind the information is more important.

In insurance fraud analysis, almost 100% of the weight is placed on physical or entered data and iData is almost non-existent. When I was involved in insurance fraud analysis, the rational for not capturing or integrating iData into fraud analysis and investigation was that at the end of the day, an investigator or claims adjuster will be face to face with the claimant and the information will be verified. The more claims and insurance business is handled online, the more danger SIU's get into. Today, someone can take out a policy and pay with a credit card, file a claim and have the money directly deposited into an account without ever seeing anyone, who is this person?

There is a quick test to determine if eCommerce data needs to be integrated into your fraud analysis:

1. What is your charge back rate for online policies purchased with credit cards.

2. Find the corresponding policy numbers where charge backs have occurred, what is the claim rate for those policies and how much was paid.

3. What claims are paid out without any physical contact with a claims adjuster (broken glass claims, claims under $500)

4. Your company permits the underwriting of new policies online without a vehicle inspection.

If your company has charge back rate above 1% and the rate of claims on the charge back policies exceed 20% of all policies and your company pays certain claims without requiring a meeting with a claims adjuster, you have an insurance eCommerce issue that requires integrating iData into your insurance fraud analysis to combat the following scenarios:

  • A person using stolen credit cards to take out policies and either filing a claim on the policy or requesting a refund for the policy before the cardholder discovers the charge (30 to 60 days depending if the card is a personal or business card)
  • A person acting as an agent, selling individuals policies from your website and charging them more then the policy value without a license to sell insurance

Lets look at an example of leveraging internet data captured during eCommerce in fraud analysis. In this scenario I have a group of PIP claims, all of which are multi-occupant, multi-injury treating at the same medical provider.

After importing the claims and policy information into my visualization I do not detect a link between the multiple claimants or the related entities to the claimants such as address or phone.

I discover that all of the policies were incepted in the last 60 days and all were applied online at the company web site. I discover the IP address for each session when the policy applications were completed online and the corresponding device ID's and import that data into my visualization.

I find that out that all 12 claims were on policies that originated from three separate computers tied to one IP address. All eCommerce transactions capture the IP, device ID, operating system and browser type in order to present the information needed for the transaction to the end user. Device ID's are normally hashes from an algorithm established by your IT department based on information captured during the transaction. The level of information captured from the device differs from company to company but regardless of the level of detail, the device hash creates your unique identifier for the computer transacting claims and policies on your system.

Now that I know all the policies originated from the same IP address, I can run a "whois" query on the IP address to determine the ISP or host for the IP address. In this case I discover that the IP address linked to my 12 claims is assigned to the medical provider where all the claimants are treating!

Sounds unrealistic, while the personal information has been changed for this chart, this was an actual case investigated by SIU in Florida. Taking the analysis to the next step it was discovered that the payment instrument used to pay for these policies online was an Corporate Amex belonging to the medical director of the company.

This moves us along to the next necessity in visualizing iData for insurance fraud analysis. Just as in eCommerce fraud, there is a point of friction in each online transaction. If the goal is obtain stolen merchandise online, the point of friction is the shipping address, in the case of insurance eCommerce fraud the point of friction, just as in all insurance fraud claim, is where the money comes in and goes out.

Capturing the payment instrument hash for analysis will take your insurance fraud analysis to the next level as well. I can visualize instances where 10 or more policies were paid for with the same payment instrument and the corresponding claims to discover fraud.

I can visualize where multiple claims all with different claimants had their settlements deposited into the same ACH (direct deposit) account and discover the reason why.

To summarize, the integration of eCommerce or iData has been essential in the detection and analysis of online fraudulent transactions in the retail space for years. As insurance companies transition more business online, the importance in integrating iData into claims and policy fraud increases. Information such as:

  • Session IP and cookie data

  • device ID

  • payment method hash

can expand your ability to proactively detect insurance fraud from eCommerce transactions.

Fraud Modeling Insurance eCommerce Transactions

Using fraud modeling methodology has been used and refined in retail eCommerce transactions but has been absent in insurance eCommerce.

Once again, the more business that insurance companies transition to the internet, the more important fraud modeling based on eCommerce transactions becomes important. There is important data captured on online sessions that can be critical to policy and claims fraud identification.

One example would be based on a scenario we discussed earlier in visualizing payment hashes used in policy inception. In that example we discussed how to identify multiple policies incepted by the same payment method and hash to identify potentially fraudulent claims.

There would be no legitimate reason for multiple policies belonging to different people to be incepted with the same payment instrument. More likely reasons would be someone incepting policies to commit claims fraud or someone acting as an unlicensed agent to sell policies utilizing the companies web site.

By leveraging in-line fraud modeling, a velocity check could be placed on the payment instrument hash preventing these transactions from occurring at the point of origin. A basic velocity rule would preclude more one or two policies with two different policy holders names from being incepted with the same payment instrument hash.

Another modeling point would velocities and "black listing" of suspect IP addresses. If multiple online transactions from the same IP addresses result in charge back or identified as fraudulent from investigations, a velocity and black list in-line check would prevent future policies from being established from that IP address.

Other velocities which could be incorporated into an insurance in-line risk model could include attributes from previously discovered fraud activity such as:

1. Fictitious drivers license numbers or those belonging to staged accident participants
2. Addresses of medical providers or drop boxes being utilized to establish insurance policies
3. SSN's or Name DOB combinations of past insurance fraud participants
4. IP location data in relation to where the claim occured or the policy was incepted. For example the IP address is in New York, NY and the policy indicated the vehicle and the policy owner is in Florida.

There has always been fraud check rules in place at the adjuster level for insurance fraud discovery. By moving some of these rules in-line and integrating eCommerce data, scoring of potentially fraudulent policies and claims can be accomplished real time for more timely intervention by the SIU.