News & Insights

1. Open insurance seems to be in no rush to evolve (apart from some notable exceptions)

Top of the class in this edition of the OIM is United Healthcare, having achieved a significant move over the developer experience axis. The health insurer has put significant effort into professionalising the overall look and feel of its developer portal. Besides that, the portal better addresses the information needs of healthcare practitioners by improving the display of use cases and offering comparison guides on available digital solutions. These guides help health practitioners to compare the benefits of direct API integrations against other available options such as self-service portals, based on their own needs. The ‘getting started’ journey is enriched with a beginner’s guide to APIs and extensive video tutorials for API usage. Other improvements of developer usability include app management functionality and two-factor authentication. 

This OIM edition also welcomes a few new entrants, such as insurer Zego who provides API services for live activation of driver insurance based on the driver’s digital timesheet. Insurtechs Kasko, Bsurance and Tigerlab offer APIs that primarily aim to support insurers with the sales and distribution of their products. In the case of Tigerlab, these API services are part of its larger insurance platform that also includes services for underwriting and policy administration. OP Financial Group has added claim services from Finnish life insurer Pohjohla to its ‘Banking as a Service’ (BaaS) offering. KBC Bank has also expanded its BaaS catalogue with a quotation service for home insurance. The API catalogue of the Great American Insurance Group consists of APIs for sales and distribution, underwriting and policy servicing. Chubb has launched a developer portal containing quotation and policy issuing services for various product lines. Qover has re-entered the OIM after a brief absence, now with a select set of APIs focusing on claim services. This insurtech was previously excluded after its developer portal and API documentation were made unavailable.

Comparing the most recent findings from the OIM with the results from May 2021, overall it becomes apparent that open insurance is progressing slowly. Insurers continue to have the richest functional scope (as seen predominantly at AXA and Nationwide), but have yet to invest in improving the developer experience. Meanwhile, banks still have the upper hand in developer experience but lack a rich portfolio of API-enabled insurance services (as illustrated by the cluster of banks in the lower right corner). There are even open insurance players that seem to limit their openness, such as Humana which has now made its developer portal available to registered partners only, and Wakam which has removed its claim and quotation services from its portal without further explanation.

2. Closing the doors: some insurers prefer to serve a select group of partners

Apart from the insurers included in the OIM, there are various insurers that have live developer portals but restrict access to select partners only. Examples include Munich Re, Zurich Insurance, Insurance Australia Group and Markel Corp.

Many of those players that do provide public access to their developer portal lack a solid developer experience to appeal to and attract new partners to their API services. For example, the API documentation on such developer portals is often technical, incomplete and cryptic. This means it can only really be used by readers with technical knowledge who also have a direct support line with the respective insurer offering the APIs. Moreover, knowledge of internal systems and processes is often required to fully understand the APIs. Lastly, absence of the high-level business context and inspiring use cases, as well as limited efforts for community-building, show that these insurers are still at the early stages of positioning themselves as digital ecosystem enablers.

3. Insurers are not yet ready for embedded insurance propositions…

One important driver of open insurance strategies is allowing third parties to seamlessly integrate insurance services and products into other kinds of customer activities – typically on non-financial digital platforms – to serve their customers at the point of need. This form of partnership is also referred to as ‘embedded insurance’. As with many other types of products, driving embedded insurance requires that the underlying open insurance APIs are clear and easy to use.

The findings from the Open Insurance Monitor indicate that many insurers are still primarily focused on supporting intermediaries with APIs (and often administrative ones) instead of directly enabling a better experience for users and end-customers of digital platforms. For example, this is reflected by functionalities such as retrieval of sales guides, underwriting questionnaires, class codes and policy histories, as well as functionality for management of agent/customer accounts. Although these API services can be of value for specific types of partners, they are less suitable for embedded insurance propositions.  

4. …and are not focusing on the uniformity and standardisation necessary for scalability

Looking at how insurers approach principles for API design and architecture, there is still limited uniformity and standardisation. Insurers’ APIs are often exposed from a workflow point of view. Endpoints revolve around specific steps within operational flows and/or aim to retrieve or change very specific data objects. When adding the variety and complexity of different insurance products to the mix, API catalogues rapidly grow into complex take-out menus instead of one-stop shops with plug-and-play solutions for third parties.  

In this context, insurtech companies differ from insurers in that their API offerings are more focused around key digital use cases such as ‘sales and distribution’ or ‘claims management’. Consequently, their API catalogues consist of concise and clear sets of product-agnostic APIs for third parties to embed in their digital platforms. Examples include the policy-issuing APIs from Covergenius and Boost, and claims APIs from Qover.

As the legal landscape formalises in the EU, insurers need to start making open insurance a priority

The current pace of open insurance evolution has allowed insurers to take it slowly. However, the rules of the game have now officially changed with publication of the recent Open Finance Framework. Just as what happened in banking with PSD2, EU-based insurers but also other parties in the insurance value chain like intermediaries (specifically in non-life with exception of health- and medical insurance) are mandated to make their insurance data available to third parties. Those who already have a strategy in place with supporting API architecture will have a head start in capitalising on the new opportunities that will emerge.

Accelerate your open insurance journey

If you would like to explore how to kick-start or accelerate your open insurance journey, don’t hesitate to reach out to Mounaim Cortet or Maarten Bakker.

The INNOPAY Open Insurance Monitor is in continuous development. If you think your organisation should be included in it, please contact Marnix de Kroon.