What SIUs Want: An Easier Way to Take Aim at Soft Fraud

From the special investigative unit perspective, soft fraud is like a cancer: It’s a silent but deadly disease that’s not easy to detect.

When it comes to insurance fraud, “hard fraud” is what we most often see in the headlines: A professional con artist stages a catastrophic slip-and-fall accident and wages a six-figure lawsuit against a restaurant. An organized crime syndicate works with several players in concert. Any hard-working American will say insurers should do everything possible to stop hard fraud in its tracks.

Of course, those well-meaning people don’t realize that they themselves might be guilty of fraud. Surely, they aren’t hard-core con artists who intend to rip off insurance companies. They tell little white lies to earn themselves a little extra money. These small deceits, exaggerations, and omissions are known as soft (or opportunity) fraud, which includes things like:

  • Exaggerating about the extent or origin of damage when filing a claim
  • Overestimating the value of lost contents, especially electronics and jewelry
  • Underestimating annual mileage driven
  • Failing to mention the household’s teenage drivers

Interestingly, a 2013 Insurance Research Council study found that 24% of respondents thought it was acceptable to increase the amount of a claim to make up for a deductible, and 10% of respondents said that insurance fraud “doesn’t hurt anyone.”

Though most people have a moral objection to hard fraud, they seem to be generally OK with soft fraud. Perhaps that’s because they don’t realize how much fraud costs them. According to the Coalition Against Insurance Fraud, insurance fraud costs the economy $80 billion every year. That’s enough to pay the salaries of 2.2 million American workers for a year.

How can insurers protect their policyholders from the cost of soft fraud?
Based on industry data, insurers should consider that 10-20% of insurance claims could be fraudulent. However, from the perspective of the special investigative unit (SIU), soft fraud is like a cancer. It’s a silent but deadly disease that’s not easy to detect. Detection tactics tend to be invasive, and nobody wants to risk offending a loyal or seemingly “good” customer with a probing investigation.

Case in point: Imagine that someone breaks into your vehicle. You submit a claim for losses in the amount of $1,961. You’ve had no other claims for the past five years, and you’ve been paying good money to insure two vehicles and a home with your insurance company for 10 years. In other words, you’re a loyal customer. Now imagine that your insurer aggressively scrutinizes everything about your claim. How do you feel? Probably like calling the low-price insurer you saw on TV last night.

As you can see, the SIU must walk a fine line. It must detect opportunistic fraud without making claimants feel interrogated or under suspicion. That’s where fraud technology comes into play. Data analysis won’t catch every opportunistic claimant, but it can detect a reasonable percentage of soft fraud. And when the public learns that insurers are taking a harder stance on these issues, some otherwise opportunistic claimants may be deterred.

What types of data analysis may be helpful?

Establishing patterns of activity by claim type or claimant demographic and flagging anomalies

Setting up business rules and thresholds to flag claims for closer review — based on either claim characteristics (exceeding a certain dollar limit) or insured behavior (change in the coverage limit up to 60 days before a claim)

Developing profiles or norms for common claims and flagging those that defy the norms

Comparing in-house and third-party data to identify unusual behavior

Comparing average retail store values with claim values to identify anomalies

Eliminating data silos so investigators can merge data from different sources within the company

Is it worth the effort?
An analytical investigative approach may seem complex, but it achieves several goals. It’s a cost-effective way of getting investigators involved in claims with the highest likelihood of fraud. If successful, it detects and deters the “cancer” known as soft fraud. And it achieves the ultimate goal of driving down premium costs for all policyholders.

— Originally published to Insruance & Technology December 1, 2014 and can be viewed here.

Error updating Mysql2 Gem on Windows 7 with Rails 3.1 and Ruby 1.9.2p290

When trying to upgrade to Rails 3.1 on my development system I ran into an error updating the MySQL2 gem.  After a bit of searching this turned out to be a known issue with win23 and the MySQL2 gem.   The error I received was:

c:\>gem install mysql2
Temporarily enhancing PATH to include DevKit...
Building native extensions.  This could take a while...
ERROR:  Error installing mysql2:
        ERROR: Failed to build gem native extension.

        C:/ruby/bin/ruby.exe extconf.rb
checking for rb_thread_blocking_region()... yes
checking for main() in -llibmysql... no
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers.  Check the mkmf.log file for more
details.  You may need configuration options.

Provided configuration options:
        --with-opt-dir
        --without-opt-dir
        --with-opt-include
        --without-opt-include=${opt-dir}/include
        --with-opt-lib
        --without-opt-lib=${opt-dir}/lib
        --with-make-prog
        --without-make-prog
        --srcdir=.
        --curdir
        --ruby=C:/ruby/bin/ruby
        --with-mysql-dir
        --without-mysql-dir
        --with-mysql-include
        --without-mysql-include=${mysql-dir}/include
        --with-mysql-lib
        --without-mysql-lib=${mysql-dir}/lib
        --with-libmysqllib
        --without-libmysqllib


Gem files will remain installed in C:/ruby/lib/ruby/gems/1.9.1/gems/mysql2-0.3.7
 for inspection.
Results logged to C:/ruby/lib/ruby/gems/1.9.1/gems/mysql2-0.3.7/ext/mysql2/gem_m
ake.out

c:\>

FIRST – Be sure to install DevKit from RailsInstaller.org.  It is a set of .bat and .dll files you will need to place in your the bin directory of your ruby installation.  In my case my Ruby was installed at ‘c:\ruby’ so I dropped the files from DevKit in the ‘c:\ruby\bin’ directory.

Once you have DevKit installed go ahead and install an older version of the MySQL gem.  I am currently using version 0.2.6 which is working just nicely with Rails 3.1.

At the command prompt run the following command:

c:\>gem install mysql2 -v 0.2.6

The MySQL2 gem should install without a problem.

c:\>gem install mysql2 -v 0.2.6
Successfully installed mysql2-0.2.6-x86-mingw32
1 gem installed
Installing ri documentation for mysql2-0.2.6-x86-mingw32...
Enclosing class/module 'mMysql2' for class Client not known
Installing RDoc documentation for mysql2-0.2.6-x86-mingw32...
Enclosing class/module 'mMysql2' for class Client not known

c:\>

Now you should be all sent using Rails 3.1 and the MySQL2 gem.  Just an older version.  Once win32 is fully supported this work-around will no longer be necessary.

Note: There is another way to do this by specifying the library and includes.  That method did not work for me however if it works for you it may be worth a shot.