Skip to main content

Data Integrity – Avoiding Data ‘Fluff’

I remember more than a few years back attending one of our auto carrier’s annual roadshow. When the presentation reached the topic of ‘discounts & credits,’ the presenter opened the new section with a bit of sarcasm (and truth) in their one-liner. They joked that all of their insureds were ‘executives with PhDs’ and the room responded with reciprocating laughter, or was it snickering because they felt like they’d gotten one over on the system in their guiltless wit?

For those of you reading this who may be new to the industry, insurers have historically given premium credits and/or preferred underwriting to insureds with higher education and white-collar professions. Since carriers are never going to request an insured to mail in a certified copy of their framed and mounted diploma, much less take a picture with it, nor troll their LinkedIn profiles, everyone’s achieving their highest marks and ambitious careers. The irony is, the credit is so de minimis that it usually only amounts to a dollar here or a dollar there.

I’ve often reflected on this one-liner over the years and have retold the anecdote more times than I can recall. Since then it’s evolved into a parable, a perplexing one at that. It’s become a question of who is the more guilty player in the narrative.

Has the agent put their integrity in question by trying to beat a system for their own gain (client acquisition)? Is the carrier to blame for creating ‘franken-underwriting,’ a system of haphazard logic thrown together with laughable restraint? Maybe it’s the market itself, in that the over-commoditization of the product, by unintentional design, has made cheaters of us all?

Then and now, it becomes a question of data integrity and if both agents and carriers have been collecting ‘fluffy’ data: 1) have we come too far to reverse and 2) what damage have we done? What do I mean by ‘fluff’? I’m referring to basic data filler like John Doe, 555-5555, email@email.com, round numbers, generics, etc. just to appease the AMS or rater requirements. I’m also referring to inflated data as mentioned in my opener i.e. c-suite occupations, graduate level degrees, $200K household incomes, etc., aka the nuclear family.

This moral hazard (yes, I said it) is a depreciative creep, a virus in your data. Let’s not kid ourselves here, agents are notoriously lazy when it comes to AMS/CRM management with a policy (pun intended) that ‘if it ain’t downloaded, it ain’t important enough.’ In all irony, I commonly see agencies overlapping in redundancy with several management systems after catching the tech bug, but again, the data they are trading doesn’t seem to improve. Let’s face it, nowadays our data is becoming the new intrinsic value to our agencies, not merely the renewal premium and retention rate.

This being said, and since most of the data points we already have a process to collect are becoming redundant due to the fact that third parties are now sourcing us what has become public domain, I believe we will see a push for more ‘social’ data, not just for underwriting purposes, but used effectively in service and sales models. This information will include such data points as perhaps alumni affiliation, travel destinations, favorite foods, and similar commerce data that search engines and social media are already, and have been, utilizing.

It will be interesting to see, meaning will a Pitt grad who spent a summer backpacking in EUR and loves Italian cuisine, be less of a risk for an insurer as opposed to a Penn Stater who spent a year with the Peace Corps in Central America and has an affinity for Latin cuisine? Furthermore, will a CSR, or even better yet an adjuster, be able to deescalate an already tense situation by simply relating to an insured by relating to a Big 10 Conference win over the weekend? Will a sales agent better convert a boat policy because he knows a prospect prefers wakeboarding to fishing or vice versa?  

So…what can we be doing now? Gathering as much data as possible and as efficiently as possible. Right now, there is no data burden (as in useless & redundant), and data scrubbing is far easier than data acquisition.  When in question, drag, don’t dump. Petition your developer, in this case HawkSoft, to add fields.

Next time we will discuss actually using this new data effectively, but if I can leave you with one thought for now, it would be this: ‘Do today what InsureTech will be doing tomorrow.’

Blog Author:

Michael Tonsetic
President | CEO
Blanchard Insurance, Inc.
Altamonte Springs, Florida

MikeTonsetic_small