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 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.
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
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.
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.
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.
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.