For InsureTech to Flourish, Carriers Must Ensure Tech

Parker Barrile, Partner, Norwest Venture Partners

Reid Hoffman, the founder of LinkedIn, said that the “Web 3.0” era will be driven by data. I lived through that transition in my past life at LinkedIn, where I was VP of Product Management from 2009 to 2014. Our business model was built on top of the profile data that LinkedIn users submitted, and many external parties wanted access to it. So we built APIs that enabled authorized third parties to submit and extract data from LinkedIn. This allowed us to control the flow of data in and out of LinkedIn’s systems. We could grant or revoke access, limit query volume, and minimize unauthorized traffic on our web frontend. The APIs took time to build, maintain, and program-manage, but they gave LinkedIn full control over how third-parties interacted with its data and services.

After my experience at LinkedIn, I assumed that virtually every company was going through the same transition to provide programmatic access to their systems and data. Boy, was I wrong!

Fast-forward to earlier this year when, on behalf of Norwest, I led an investment in Policygenius, an insurance marketplace that makes buying insurance as easy as booking travel. It’s an exciting company that’s innovating on the parts of the insurance-buying process that matter. Modern consumers want to buy things online with minimal friction. They want to do research to compare their options and they want to know that they're getting a great deal. And that's where Policygenius comes in. They've built a platform that addresses all those consumer needs, just like Amazon in e-commerce or Kayak in travel.

If only the rest of the insurance industry were as innovative and forward-thinking.

"If Web 3.0 is all about data, then allowing data to flow securely should be a top priority for every company"

In one of my first meetings with the Policygenius co-founders, Jennifer Fitzgerald and Francois de Lame, they mentioned that insurance carriers still require applications to be submitted as PDFs via email or FTP. None of the carriers offered application APIs or otherwise supported programmatic submission of an application. In response, the Policygenius engineering team built a proprietary system that maps customer data from their application flow–field-by-field, to over 3,000 PDFs, one per carrier per state–and automates the process of collecting the applicant’s signature via DocuSign. Policygenius also ingests carriers’ rate sheets through nightly batch processes or by crawling pages on the carriers’ websites.

While I applaud Policygenius’ scrappiness, it was a shock to discover that the insurance carriers, many of whom are large, highly-profitable companies, haven’t taken the time to build APIs that allow programmatic submission of applications or retrieval of rate sheets. Most carriers rely on brokers and agents to originate policies, so they have an incentive to streamline the process. What’s more, when applications are submitted as PDFs, the carriers have to parse or transcribe the content into their own system, which requires custom scripts or human effort.

The net effect is the same: data flows from Policygenius’ website to the insurance carrier’s database. But rather than allowing authorized third-parties like Policygenius to submit data directly and programmatically into their database, this convoluted flow functions like a pseudo- API. Instead of HTTPS POST, the application data is transferred via email. Instead of JSON, the data payload resides in a PDF form.

APIs have four key advantages over ad hoc data flows:

Security: APIs require third-parties to authenticate before transacting, ensuring that only authorized partners can interact with key systems. This prevents unauthorized access and helps identify bad actors that are using unauthorized techniques to submit or extract data (e.g. scraping website content).

Data Integrity: Processes that involve transcribing data into forms are inherently error-prone. Data can be mapped to the wrong field, forms can get lost in transit and it can be hard to catch errors. Well-designed APIs use HTTP protocols to alert users about transmission errors, data loss, and incomplete or incompatible values.

Human Effort: Most non-programmatic data flows require some degree of human effort. For example, the processes of uploading, transcribing, or error-checking documents. Well-designed APIs should eliminate the need for human involvement and allow systems to interact directly and programmatically.

Architectural Hygiene: Building APIs forces companies to ensure that data structures make sense and provide clean interfaces for submitting and extracting data. In many cases, this results in better internal systems architecture and faster development going forward.

If Web 3.0 is all about data, then allowing data to flow securely should be a top priority for every company, even those in traditional industries like insurance. Not only is the recent wave of innovation in InsureTech creating exciting new businesses, it’s also nudging incumbents toward an API-driven future that will benefit companies and consumers alike.