How to Achieve Seamless Insurance Connectivity with APIs

In the world of insurance, a lot has been written about the path to a faster world of data, insights, and interface-agnostic workflows with less friction. Or in fancier words, data interoperability.

Interestingly, several other highly regulated financial industries have successfully achieved similar transformations, and many areas can be applied to the world of insurance, without necessarily introducing any crazy or risky unproven ideas. Sometimes “move fast and break things” may not be the best approach, so let’s look at what has already worked in other financial verticals for peace of mind. And yes, what that might or might not mean for AI.

What worked for other highly regulated financial industries?

Let’s start in the world of credit cards, where Stripe as the dominant connectivity company made life much easier for merchants, credit card companies, and consumers alike. With Stripe connecting multiple parties’ data together, any credit card company could take payments from any merchant, and consumers could submit payment via any software application builder, in any interface they like. All they had to do was call Stripe’s API, and it didn’t matter that different parties were on different systems built in different languages – Stripe tied them together seamlessly. You could now learn everything about your payments data at the tip of your finger, or the tip of your API, regardless of where they came from and whether it was with one company or another.

In the world of consumer banking, Plaid is now the easiest way for banks, consumers, distributors, and financial apps to interact with each other in the form of requesting data or moving funds. A famous example is the app Venmo, which uses Plaid’s API that allows users to send money to each other seamlessly between different banks. For banks themselves to each build a different Venmo internally would be slow, full of friction, and prohibitively expensive.

The common theme is that stakeholders in both of these industries have benefited tremendously from the adoption of well-engineered and neutral connectivity layers that they didn’t have to re-write and re-build themselves, which allowed them to focus on their core business advantages, and leverage the existing connectivity to build amazing new use cases, software, and operational efficiencies on top of it. All of these are learnings we can take note of and apply back to our world of insurance.

What’s ahead for the insurance transformation journey in Life & Annuities?

Now, let’s look at our own world of life & annuities (L&A), where we largely live in a world absent of comparable connectivity for insurance organizations (via middleware) that other financial industries enjoy. 

For example, in credit cards, it’s unthinkable for a merchant/consumer to need 3 different apps/processes to process 3 credit cards from Visa, Mastercard, and American Express. You call one API (Stripe) for all payments (products), regardless of differing providers or underlying systems, and you are done with all 3 without redundancy.

In life insurance, however, you often do need to learn 3 different processes and use 3 different sets of software to access 3 different insurance products, even from within the same carrier, because different products often are powered by different core systems.

Interestingly, these problems haven’t been for the lack of other technical innovations. On the contrary, many carriers have adopted new core systems, and gone partially or fully into the cloud, along with other modernization efforts. The key missing piece was simply how huge a role connectivity layers play in reaping maximum benefits from other modernization efforts that they’ve already invested in.

In the absence of well-engineered insurance connectivity, it becomes expensive and difficult to connect different systems and data, across different product lines, for different parties.  This means everyone must rebuild the same thing separately many times, individually to different specs, whenever they seek to grow or launch a product, incurring lots of costs.

This problem is further exemplified when a carrier needs to connect with multiple distributors, and when each distributor needs to connect with multiple carriers. What the industry then ends up with is a web of complex and largely non-reusable, and sometimes hard-coded manual connections between systems that are expensive to maintain and full of friction.

To illustrate, this is the insurance world without a neutral connectivity layer:

And this is what a good connectivity layer for insurance organizations achieves similar to other industries:

The same can be said for what’s commonly referred to as the “spaghetti ball” within a carrier:

And what could benefit everyone, including the carrier itself:

As evident from the graphic illustrations, the key is for all parties to have one common place for data, rules, and workflow. This is extremely important because maintaining many things in many different places becomes very expensive and time-consuming. When everything can be configured and executed in one place, it can then be considered a Infras API layer, a layer that allows for seamless interaction between different parties and systems in one common place.

Why a world without Infras API’s is slow, expensive, and full of friction

With a Infras API layer, companies can connect data and workflows from any selection of systems, and have a universal output exposed to outside parties, such as distributors, reinsurers, data insight platforms, or AI models, that require interaction, and manage all this in one place without redundancies.

On the contrary, it might be helpful to also imagine why not having a Infras API layer is bad for everyone:

• It’s bad for carriers because they must each build and maintain bespoke integrations to multiple distributor/AI platforms redundantly, which is expensive due to its non-reusable nature.
  
• It’s bad for distributors because each bespoke interface and integration for each different product requires different sets of training and processes for its staff, leading to operational inefficiencies, confusion, and slow turnaround, also due to the non-reusable nature of separate and bespoke internal solutions.
  
• It’s bad for consumers because they must navigate many fragmented interfaces and processes across different distributors and products, to accomplish even simple requests as such submitting new applications or requesting in-force data.
  
• Again, this means everyone must rebuild the same thing separately many times, individually to different specs, whenever they seek to grow or launch a product, and everyone incurs the cost of fragmentation and re-training.

This is the same reason why banks don’t each build their own version of Venmo, and credit card companies don’t each build their own Stripe.

What are sample use cases of Infras APIs that we wouldn’t otherwise have?

1. Do business anywhere -  In the past, the functionality of systems is often expressed as a user interface (UI). You can configure, transact, and submit/request information as the software’s UI will allow. However, with a Infras API in place across multiple systems, users are no longer captive to the UI of any one given system. Rather, because users are now empowered with data and logic from multiple systems, they can do business anywhere. This is an engineering concept called a “headless infrastructure”, or in simpler terms, do business in any UI. Sometimes, the best interface is the ability to support any interface.
   
2. Universal data feed - In the past, you needed to have multiple integrations to get data from multiple systems, and sometimes even navigate multiple different UI’s. With the right architecture, both internal and external parties now have one easy place to request and get approved for data.

That’s great, how about AI?

AI use cases are generally a function of feeding quality data models to generate an output. As such, AI use cases can actually be considered an extension of #2 above, a universal data feed, given that the quality of AI output is a function of how much quality data is readily accessible. 

When data is spread everywhere and in many different formats, AI efficiency will struggle. When data is standardized in common places, the carrier is much more AI-ready, which is a key requirement to transform AI models into practical applications.

Where do we go from here?

The insurance industry sits at the perfect timing and crossroads of AI explosion and abundance of data both within and across enterprises. Consolidation in distribution also means increasing demand for freedom on where distributors want to do business and access their data, and whoever meets them where needed can win on ease of use.

Like other financial industries in the past, it is a transformative moment for our industry in its own journey of creating better infrastructure for the future for everyone’s benefit, and we may just look back a few years from now and wonder how we managed to survive.

‍