Open Insurance: What to scoop and what to drop from Open Banking

Open Insurance aims to create tech-driven collaborations among insurance firms and tech companies to foster innovation, provide fertile ground for digital ecosystems and new business models to emerge, and in the end provide better experiences for customers. The tech-driven collaborations enabled by open insurance are based on sharing customer data via APIs with customer consent. Both the storyline and the technology for realizing Open Insurance are quite well-known, albeit in a different industry.

Open Insurance has the advantage of having an older brother, Open Banking, which has ventured out before with similar aspirations and goals. There is a rich set of experiences from various Open Banking initiatives and especially from implementing banks around the world. So what can Open Insurance learn from Open Banking and more concretely: what best practices from Open Banking should insurance companies adopt to have the best possible chances of success in Open Insurance?

Timing: When will Open Insurance break through?

In our global economy, regulatory actions in one jurisdiction often have indirect ripple effects into other  jurisdictions. The Open Banking regulation in the UK and EU (PSD2) has been a pacemaker and moved Open Banking forward. More interestingly, it had ripple effects outside its jurisdiction, spreading to many areas in the world (see openbankingmap.com).

Based on this experience in Open Banking, a good indicator for a breakthrough in Open Insurance is a looming regulation - anywhere in the world. The ripple effect might influence other markets as well, compels other markets to act, react or preempt, whether with a market-driven approach or a regulation of their own.
And in fact, on the regulatory front for Open Insurance, we can already see relevant movements: the EU regulator European Insurance and Occupational Pension Authority (EIOPA) has closed its public consultation on Open Insurance earlier in 2021. The EU might take the lead with Open Insurance too, after having led with regulatory approaches on Open Banking (PSD2) and Data Privacy (GDPR) before.

Prepare for Growth

A learning from Open Banking is not to treat APIs as a compliance project that is implemented to satisfy known requirements - 1,2,3, and done. There is a large chance to miss the biggest opportunities, which might be related to APIs in the vicinity of the regulation, using the same tech stack and infrastructure, but serving different use cases.

So don't think of Open Insurance APIs as being fixed in scope by regulation or industry standards, instead think of your APIs as a growing catalog of products, containing standardized and regulatory Open Insurance APIs as the nucleus but also many differentiating APIs around this nucleus. Set up your Open Insurance API initiative not as a project team, but as a product team that designs, develops, but also maintains, supports, evolves, and grows your Open Insurance APIs from now on out.

Standardization vs. Differentiation

Know when to standardize APIs and when to differentiate by APIs! Standardized APIs are great for data where there is little differentiation among competitors. Such data represents the smallest common denominator among the industry and should be standardized to ease access to it. 

It is advantageous if standardization is driven by industry and not by a regulator. Organize as an industry, and take initiative in designing the Open Insurance standard. You know the market better than any regulator can. 
But take care to create only one standard for Open Insurance! This is where Open Banking in the PSD2 world has gone wrong: Too many standards (e.g. Berlin Group and STET) and variants of standards (slight implementation deviations by various banks) partially defeat the purpose of a standard.

In addition to standardized APIs, each company will have specific areas of differentiation with its existing features, products, and services. For those, it does not make sense to create standardized APIs. Differentiated products should be reflected by differentiated APIs. For example, if a bank is a leading foreign exchange (FX) market maker, it would make a lot of sense to offer a foreign exchange API, even though the API is not standardized and the bank is the only one offering it in a certain market.

Establish API users as customers

APIs are not used by your typical end-users. Bank clients don't use the Open Banking APIs directly. The same will be true for Open Insurance APIs: they won’t be directly used by the insurance policyholders directly. API customers are a new customer segment for insurers - just as they were for banks. It is important to establish the API customers as a new customer group within the organization.
Remember that the API customer group receives value from your organization, so it should be possible to receive compensation in this value transaction - whether it is in the form of money or in some other form. Get to know this new customer group, segment API customers, and describe those segments in the form of personas or customer profiles.

Create customer-centric Open Insurance APIs

Develop APIs in a close feedback loop with potential API customers. It is well-known that following a customer-centric design approach yields superior products. But typically this approach is only practiced for end-user-directed products with a UI, such as a mobile app or website. 

For technical products, such as APIs, customer-centric approaches are typically not well established yet at incumbent organizations, whether it is banks or insurances. In addition, APIs are abstract products, that are hard to grasp and describe. Eliciting feedback and getting a feedback loop going is a tough challenge. A mindset shift needs to be driven, with APIs being seen as products and API users seen as customers.
A lesson learned from Open Banking initiatives teaches us that the best feedback can be received for prototypes and mocks of the APIs. They make the abstract API concrete and tactile, something that can be tested and touched, that already feels like the finished product.

It is more than the API

An Open Insurance ecosystem -- just like an Open Banking ecosystem -- needs to take many aspects into account. Open Insurance can use many of the fundamental "rules of the game” of Open Banking,  covering such topics as: who can participate in the ecosystem, under which conditions, what the responsibilities of the various players are, and in the end how trust is created and maintained in the ecosystem. It is important to set the right stakeholder incentives and establish some form of reciprocity. Bancassurance and insurance optimization based on Open Banking transaction data are initial use cases where customer journeys will need to cross borders between the Open Insurance and the Open Banking ecosystems.

By learning from Open Banking, insurers can flatten their learning curve and realize efficiency gains. But aligning on the fundamental rules of the game for building ecosystems in banking and insurance is even more important, as it will be an enabler for cross-industry collaboration of banks and insurers.  

Photo by Erol Ahmed on Unsplash