Transforming the insurance sector to an Open API Ecosystem

1. Introduction

"Open" has recently become a new buzzword in the financial services industry, i.e. open data, open APIs, Open Banking, Open Insurance…​, but what does this new buzzword really mean?
"Open" refers to the capability of companies to expose their services to the outside world, so that external partners or even competitors can use these services to bring added value to their customers. This trend is made possible by the technological evolution of open APIs(Application Programming Interfaces), which are the digital portsmaking this communication possible.

Together companies, interconnected through open APIs, form a true API ecosystem, offering best-of-breed customer experience, by combining the digital services offered by multiple companies.

In the technology sector this evolution has been ongoing for multiple years (think about the travelling sector, allowing you to book any hotel online). An excellent example of this trend is the success story of Uber. In just a few years this company has acquired a market capitalisation larger than that of BMW. This while Uber mainly combines multiple API services offered by other companies, i.e.

• Positioning is done by the operating system (iOS, Android)

• Route calculation and maps are provided by MapKit and Google Maps

• Twilio sends real time text messages to the customers

• Payment is handled by Braintree

• The receipt is sent via Mandrill

• The services are hosted in the cloud on Amazon Web Services (AWS)

Combining these best-of-breed API services allows start-ups like Uber to deliver an excellent and innovative user experience in a very short time frame, thus facilitating rapid growth.

Afterwards these start-ups will typically deliver their own APIs, which in their turn are integrated in the offering of other companies. E.g. the API of Uber is also integrated in the application of United Airlines.

These examples show the mutual benefits of such an open API ecosystem, i.e. the customer-facing company can deliver additional services to its customers, while the service-providing company can profit of an increased usage (and monetization) of its APIs (and underlying products/services). This leads for both companies to increased revenues.

The example of Uber is certainly not an isolated case, e.g. UPS has successfully increased its market share by integrating its APIs in online webshops or eBay generates already 60 percent of its revenues via its APIs (e.g. API to submit item for listing on eBay).

The insurance industry, traditionally quite slow in integrating new technologies, will also be more and more impacted. Open Insurance is becoming an emerging trend, pushed by increased and changing customer needs and InsurTech competition.

This article describes the impacts of this trend on the insurance industry.

2. Drivers

While Open Banking has been a hot topic for a while, the trend towards openness has also exponentially increased in the Insurance Industry (i.e. Open Insurance or API insurance). Just as for Open Banking, this is driven by multiple evolutions in the insurance industry:

• Customer needs are increasing and changing: customers are demanding a multi- and cross-channel experience, which is real-time and 24/7 available. Furthermore, the experience should be customer-centric, rather than the product-oriented approach that most insurers currently offer. E.g. customers no longer want to buy a standardized insurance product, but instead want to input the risk for which they want to get insured and receive a tailor-made offer of their insurance company.
  Typical examples of this trend are micro-insurances (i.e. small amount insurances only applying to 1 object and/or for a short time period), peer-to-peer-insurances, usage-based insurances (UBI) and the rise of super-apps (i.e. apps of large tech giants which act as a central platform to initiate any customer journey) and the request of customers demanding a stronger customer engagement with their insurer. While in the past customers only met with their insurer when opening an insurance contract and when filing a claim, insurance companies now realize they should significantly increase the number of contact points with their customers. This will force insurers to evolve to a service-company, offering different tools, typically linked to the prevention of the insured risk (i.e. preventing a claim).

• Regulatory pressure: a continuous flood of new regulations makes that insurer’s IT and operations departments are overloaded with making existing processes compliant with regulations. This makes that very little resource capacity and budget remains to work on innovative services, especially as most insurers also have several digitalization and operational excellence projects to reduce operational costs (vital as revenues are dropping due to increased competition and low interest rates). Insurance companies that wants to innovate need therefore to work out partnerships with other parties.

• InsurTech competition: new - so called InsurTech - entrants, which can deliver innovative customer services faster and cheaper, are disrupting the market (in 2018 7.6 billion U.S. dollars was invested in the InsurTech sector). Following the example of the banks, insurance companies have learned it’s far better to partner up with a few well-chosen InsurTech companies to deliver attractive services to their customers, than to compete head-on with them. This approach enforces insurers to setup an open API architecture, which facilitates the rapid integration (plug-and-play) of the insurer’s and InsurTech’s service offerings.

• Hungry for data: Insurance companies are hungry for data. The more data an insurance companies has about the customer and the object to be insured, the more accurate the insurer can fine-tune its actuary risk models and consequently its insurance pricing (dynamic pricing model). Insurance companies should therefore integrate a maximum with external providers to get the most accurate view on the insurance risk. Especially with the rise of Big Data and AI, insurance companies are now in the capacity to process and analyse this inflow of data and transform it into actionable results.

• Rise of digital brokerage: until recently most insurances were sold via brick and mortar insurance brokers. Today more and more insurances are being sold over the internet, via digital insurance broker platforms (i.e. online aggregators, providing a comparison of different insurances) and via e-commerce platforms, which forces insurance companies to integrate in a very cost-efficient way with these different distribution platforms.

• New technologies: the rapid technological evolutions in the industry (IoT, big data analysis, real-time customer analytics, AI, block chain…​) make it almost impossible for an insurance company to invest (and be at the top) in every new technology. Partnering with specialist companies (integrated through an open API architecture) is therefore almost a necessity to stay ahead of all those technological evolutions.

• New architectural design principles: historically the application architecture in the insurance industry is composed of several large, very closed, monolithic legacy systems. This traditional architecture is reaching its limits in the current digital and fast-moving world. Insurers are therefore taking their first steps in the migration to a microservices based architecture. Since microservices communicate with each other through well-defined APIs, this architecture can be exposed to the outside world much cheaper and quicker than a traditional architecture.

3. Impacts on the Insurance industry

The insurance landscape is undergoing its most fundamental transformation in decades, driven by the fast digitalisation in the sector. Just like the entertainment, media and retail industry, the internet has changed the way of doing business completely. Insurers should not only open their services, but also build their own digital ecosystems and participate in external ecosystems. Insurers therefore need to transform themselves to an "Open Insurer", offering "Insurance as a Service (IaaS)" (i.e. white label insurance products).

Ultimately insurers should shift from building full end-to-end insurance solutions to assembling best-of-breed insurance services tailored to meet the customer needs. This means that the traditional product-centric distribution should be transformed to services providing deep financial insights and integrating services of other sectors. This can only be achieved by creating an open API ecosystem, which is beneficial for all involved parties.

In practice, this API ecosystem digital platform would resemble an "App store" with services offered by the different parties involved in the ecosystem. The customer would be in the driving seat to choose the functionality/service and user interface that suits him best. Once having made this choice, the customer would give a consent to the party to use specific data present in the ecosystem. Since the customer can easily switch from one service to another, this will boost innovation considerably and result in new service offerings which are superior in terms of cost, performance and convenience.

Open Insurance will also have a substantial impact on the insurer’s organisation where bridges between business and IT departments will be alleviated, as decisions will need to be made quicker due to the faster evolving technologies and customer expectations. Thanks to Open Insurance, business and technology needs will become further aligned urging business analysis and software assembly and implementation to run in coexistence.

4. Opportunities and Threats for the Insurance industry

The creation of open API ecosystems offers several opportunities, but also significant threats, to the insurance industry.

Insurance companies not opening their architecture and not participating in these API ecosystems are expected to lose the most. Interesting to quote the BBVA bank here: "A company without an API is like a computer without internet".

Even when insurance companies build out more engaging services, it is unlikely that customers will choose the app of an insurance company as a central access point to other services and products.

Insurance companies will therefore profit most of the API ecosystem by:

• Utilising more data from a broader external ecosystem

• Sharing their own data and algorithms with the rest of the world

• Sharing their product stack with the rest of the world

In the next chapters, we will present a few examples of how these 3 approaches can benefit insurance companies.

4.1. Utilising more data from a broader external ecosystem

As mentioned above, the business of insurances is a data-intensive business. Collecting large amounts of data and transforming them into actionable results is a core business of an insurance company. Thanks to the digital revolution insurance companies have now access to an almost unlimited supply of data, so choosing the right data sources and setting up in a cost-effective way, the data pipelines to capture, transform and process this data will be a key challenge for each insurer.

Some examples of data sources which could result in valuable insights for insurers:

• Open Banking data: Thanks to the EU PSD2 initiative and the Open Banking directive in the UK, customer’s account data is now available to be accessed by TPPs (Third-Party Providers). This will allow insurance companies to get information about the financial situation of its customers, but also to get valuable insights in the type of income and expense transaction the customer executes.

• IoT data: the rise of "Internet of Things" (IoT) can revolutionize the insurance industry, as it facilitates usage-based insurance (UBI), dynamic risk modelling and dynamic insurance pricing. Typical examples of insurances linked to IoT are:

  • Car insurance: via a continuous monitoring of the driver’s behaviour and driving habits, car insurances can be dynamically adapted. This monitoring can be done via an onboard diagnostics (OBD) device installed in the driver’s vehicle or via the driver’s smartphone. Based on this data collection several services and enhancements can be offered:

    • Flexible pricing: reward safer driving through lower premiums.

    • Improved fraud detection: identify on which spots the car is parked (during the day and at night), if a personal vehicle is not used for professional services (like driving a delivery route), how many kilometres is actually driven with the car and if no claim insurance fraud is committed by comparing the car data with the data entered in the claim report (e.g. check if car was actually present and had a strong break at the report crash location).

    • Inform customers of risky situations for the car, e.g. notify customer about bad weather expectations in the neighborhoud of the car (e.g. hail), notify customer when he parks car in a neighborhood with a high amount of reported thefts…​

    • Provide customer (a game-like) overview of his driving statistics, like speed, kilometres…​, with support tools like simulating future gasoline cost

    • Support the customer in case of car breakdown, accident or theft. E.g. insurance company can pro-actively contact the client and arrange emergency support (in case of injuries) when it detects an accident, automatic pre-filling of a digital claim (based on the collected data) in case of an accident, support in arranging car assistance (e.g. Touring assistance) when car breakdown is identified, identify theft of a car when unexpected (deviating) driving behavior is recognized…​

    • Allow parents to monitor (track) their teenagers when they use the family car

    • Support short-term car insurances, allowing policyholders to insure themselves on a friend’s vehicle for a short period or allow drivers to buy a short period covering on their own vehicle

  • Home insurance: Improve the protection of insured houses against threats (fire, leak, flood and theft), thus reducing the risk for insurance claims.

    • Typical IoT devices would be:

      • Smart meters of water, electricity and gaz consumption can automatically detect leaks.

      • Smart smoke detectors can detect fire

      • Advanced alarm systems can detect burglary

    • This would allow more personalized services like:

      • A policyholder could be contacted by his insurance company if an issue is detected and an emergency response team from the insurer/public authority could be dispatched automatically.

      • Provide more personalized insurance pricing. E.g. insurance premium will increase, if customer regularly forgets to lock his doors or turn off his oven.

      • Provide the customer a monitoring view on his house statistics (e.g. online follow-up of his utilities consumption)

      • Propose to the customer potential improvements to the house, which can reduce the customer’s insurance premium

  • Life insurance: wearable sensors (e.g. Fitbit) can be used to monitor health activities and communicate the results back to the company for lower life insurance premiums. Different biometric readings can be collected, like heart rate, body temperature, blood pressure, movement, calorie burn-rate, alcohol consumption…​., which can be used to gamify healthy habits into a point system. Furthermore, insurance companies can provide services for elderly (assisted living) for safety and care (e.g. check if customer is properly taking his required medication).

• Location data from mobile phone: sending location data from the mobile phone to the insurer, can not only allow insurers to get a better idea of the risks a specific customer is taking, but also allows to provide extra services and cross-selling opportunities to the customer. Some examples:

  • When customer is driving to the airport or is located abroad, but does not have a travel insurance opened yet, the insurer could propose him to open a travel insurance.

  • When customer is driving to the hospital, the insurance company could inform the customer about the modalities of his hospital insurance.

  • Based on the combination of climate data and customer geolocation data, the insurer can offer hurricane alerts

  • When customer is abroad and from other data, it can be derived that customer is abroad for holiday, this info could be used to send customer a "Happy holiday" card and to make sure the customer is not contacted at that moment.

• Social media: insurers can obtain valuable data about their customers from social media like Facebook, Twitter, LinkedIn…​

• Customer referential data: when insurers can be informed about changes in customer data well upfront (by integrating with postal service, social media or governmental services), this provides a lot of opportunities to insurance companies:

  • A change in address can be an interesting sign to contact a customer to sell new or revise existing policy(ies). Not only for a home insurance, but also for other policies like a car insurance (change in address can result in different transportation habits, if e.g. less access to public transports) opportunities exist. It can even be a sign of a relationship break-up or a child leaving the parental house, in which case a full revision of the insurance portfolio is required.

  • The birth of a child is also a moment for revision, typically for family liability insurances or hospital insurance. Same applies for a change in civil status.

• Valuation services: in order to properly assess insurance risk, a correct valuation of the insured object is also required. Most insurance companies have good models for this, but external services can also be used to provide an accurate initial valuation, but also to review regularly the current valorization. Some examples:

  • Car insurance: call external services to determine value of a car to determine the insurance premium, but also valorization of damage in case of a claim. Examples of such services are "cars.com", "vinaudit.com", Edmunds, Informex…​

  • Real estate: allow to valuate a real estate property, e.g. Rets.ly, SimplyRETS, Rets Rabbit, Property API, Zillow…​

  • Art: valuation of art objects, e.g. "artnet.com", "artprice.com", "valuemystuff.com"…​

4.2. Sharing their own data and algorithms with the rest of the world

Insurance companies that collect (some of the) above data from external sources and combine it also with the rich internal data sets (customer referential data, policy details, claims data) and process it an efficient way, hold valuable insights which can also be commercialized to other (commercial) parties. This chapter provides a few examples how insurance companies can share their data and algorithms with other parties:

• Insurers have worked out sophisticated models for fraud detection, customer risk assessment and valorization of insured objects, which can be exposed (and monetized) to 3rd parties.

• Competitors taking over a car insurance, will be very interested in obtaining the claim history of the customer

• In order to properly insure a car, insurance companies could request customers to provide the name of the driver for any drive (especially for company leasing cars, rental cars and car sharing services). This information could be useful for the police and parking companies, to send fines and bills directly to the right person.

• Instead of the traditional Green Card, insurance companies can provide a digital Proof of Insurance via an API. This would allow the police, ANPR cameras and technical inspection companies to directly check all details of a car insurance policy and its holder.

• Aggregated views of customers assets, liabilities and off-balance positions, like PFM tools, financial or pension planning tools, account aggregators…​, aim to provide a holistic view of the customer’s wealth. Those tools are very interested in obtaining (after customer’s consent) a view on the customer’s policies and outstanding balance for life insurances.

• Insurance planning and aggregation tools, which allow customers to assess risks and open automatically insurance policies to protect against (e.g. UnderCover from Ensur)

• When insurance companies collect driving data about customers, this data could also be shared with other interested parties, like for road pricing (road tolls, distance or time-based fees, congestion charges…​), car sharing and rental services, fleet managers…​

4.3. Sharing their product stack with the rest of the world

Of course, the most interesting of the 3 categories is where an insurance company opens its product stack to the outside world, as this can directly generate revenues for the insurance company. We identify 2 categories here: integrations for origination of new insurance policies and integrations for servicing existing insurance policies. Some examples:

• Origination of new insurance policies: by providing APIs to other industry apps, an insurance company can obtain new customers who were not even thinking about the related insurance aspects:

  • Car dealer apps: sell car insurances

  • Luxury good dealer apps: sell policies to insure specific object or allow to review home insurance

  • Real estate apps: sell home insurances

  • IT protection websites like firewalls, virus-scanners: sell cyber-security insurances

  • Travel apps: sell vacation/travel insurances

  • e-Commerce apps: sell insurances for delayed or no delivery (insure the company selling product or customer receiving the product)

  • Apps that sell (perceived) risky activities, like extreme sports, parachute jumping, flying, travel to dangerous area: sell short-period life insurances (e.g. Sure provides micro-duration life insurance coverage during air travel)

  • Insurance comparison tools, e.g. BusinessComparison, Moneysupermarket, Confused, Compare the Market, MoneySavingExpert…​

• Servicing existing insurance policies: provide different APIs to act upon existing insurance policies:

  • Apps for "safe driving courses", "stop smoking therapy", "sport/fitness clubs"…​ could provide a service to directly review insurance premium pricing (of car, hospital, life…​ insurance)

  • Automatic filing of a claim, e.g. when travel is cancelled, when a package ordered on the internet can not be delivered, when a plane is delayed…​

  • Block (and unblock) an investment insurance policy as collateral for a credit sold by a bank (cfr. LABL product of Capilever). This could allow a customer to open a cheaper consumer credit, as it is backed by the money of an insurance policy. This could also be used for mortgage credits, backed by a group insurance acting as debt balance insurance.

  • Pay-out a life insurance: bank or notary receiving info of a decease could provide automatic instruction to pay-out life insurance.

  • Adapt details of an insurance policy, e.g. fleet managers or car rental/sharing services automatically adapting the driver linked to an insurance or social secretariats, which can automatically add extra employees to group insurances or add/remove partner or children of an employee to/from a hospital insurance…​

5. Success Stories

Even though the insurance sector is only in the beginning of its transformation to an Open Insurance API ecosystem, several examples of successful API ecosystems can already be identified today:

• In 2008, PolicyBazaar was founded in India, as an online platform that aggregates insurance plans and serves as a marketplace for policies.

• In 2013, Ping An, Tencent and Alibaba joined forces to launch Zhong An, which is an online-only property insurance company, selling high volumes of low cost micro-insurances (e.g. cracked screen insurances, flight delay insurances, shipping return insurances…​), via China' biggest tech companies. With over 630 million insurance policies and 150 million clients serviced in its first year of operation, this is definitely a success story.

• In 2014, Ping An (largest insurance company in the world) created Ping An Good Doctor, which is a healthcare ecosystem for the Chinese market. With 265 million registered users, it is the largest mobile medical application in China.

• In 2016, AXA partnered with Silicon Valley InsurTech Trōv to attract the British millennials. Trōv allows customers to buy flexible, short-term insurances for single items via their smartphones. For example, a customer can open a temporary insurance for an expensive camera, when he wants to use it.

• In 2016, American InsurTech company Lemonade launched its online-only insurance app for renters and home insurance policies. Currently valued at more than $2bn, the company disrupted the American insurance industry, via fully digital and cheap insurance policies.

• In 2016, Allianz entered a cooperation with the German InsurTech Simplesurance, allowing Allianz to distribute its insurance products in 28 countries via customer portals and online shops.

• In 2016, the Belgian start-up Qover started with offering new innovative insurance products via Open APIs or as white labelled. Qover has e.g. a partnership with Deliveroo to offer a specific insurance for Deliveroo riders.

• In 2018, Muang Thai developed Baowan BetterCare, a health insurance product for diabetics, with dynamic pricing, which rewards customers who improve their health behaviour with premium discounts.

• In 2019 InsurTech Setoo partnered with travel aggregator Omio to provide insurance products that pay out automatically, when transport is delayed or cancelled.

6. Successful API Strategy

Critical to a successful API strategy, is the understanding that an open API is also a commercial business product and not just a technical interface. Therefore, converting the insurer’s services to open APIs should not just be a technical IT project, but instead be driven by business. This means insurers should hire API product managers on the business side.

A successful open API should allow to:

• Create new revenue streams, i.e. monetization of APIs. Different monetization models are possible:

  • End-users paying transaction fees to use the solution

  • Partners and/or developers paying for service/data usage

  • Partners and insurers entering into a revenue-sharing agreement, such as pay-per-click advertising (i.e. step out of the traditional product/service license fee agreements)

• Improve customer service and satisfaction, i.e. APIs should be designed for customers, i.e. exposing a service valuable to a customer, not just exposing products and raw data (e.g. transaction history from an account).
  This can be achieved by enriching the raw data (e.g. adding a categorization to the transaction history of an account) or by adding value-added services on the raw data (e.g. provide a saving or investment offer based on the raw data of the transaction history).

• Gain more data: capturing more customer data, allowing to obtain better customer insights, which in their turn can be used to improve revenues (e.g. through cross-selling and up-selling) and customer service and satisfaction.

At the same time, such an API should:

• Be carefully monitored, so that usage can be monitored continuously, and rapid action can be taken upon these metrics.

• Be quickly changed upon need. Important however is that even if an API evolves, the API format (i.e. the request and reply interface used by the external parties) should be changed as little as possible or in any case support previous versions of the format. This to avoid that all partners should adapt their software, when a new API version is delivered.

• Be well marketed, not to traditional end-customers, but to innovative companies, who could partner in the ecosystem. In this context, it is important to create a real developer community, which is typically done through events, like innovation days, hackathons, online marketplace…​, where ideas for new insurer services are matched with developers.

• Be well supported by development portals, allowing to make the developer experience as seamless as possible. Such a portal should provide

  • Easy and quick onboarding (i.e. ideally through a self-service access) without much support of the insurance company

  • Detailed documentation of the APIs (e.g. through Swagger), i.e. API should be self-explanatory

  • A sandbox to try out APIs, including a good description of the test data available in the sandbox

  • Cross-platform SDKs and other tools (e.g. sample applications, sample source code…​) to reduce time and effort of third-party developers to consume the APIs.

A successful API strategy should furthermore not only focus on the outbound APIs, i.e. the APIs exposed by the financial service company. Financial service companies should also have a strategy of using APIs from other companies (like tech companies). This allows rapid creation of new services, by building further on functionality exposed by partner companies.

7. Standardisation

A major issue for InsurTechs and companies from other sectors wanting to use the APIs is the lack of standardisation in the APIs. Developers do not want to integrate a completely different API for each insurer or InsurTech they want to connect with.

Unfortunately, like any standardisation process, creating this "lingua franca" is very challenging. Many initiatives try to define a standard, but an agreement on a global (or even national) standard is not expected for the very near future.

Some interesting initiatives are:

• Open Insurance Initiative (OPIN): https://openinsurance.io/

• Open Insurance: https://open-insurance.org/

• ACORD Data Standards: https://www.acord.org

• CGI Insurance Information Services: https://iis.cgi.com

• NAIC registry: https://content.naic.org/

8. Implementing APIs

As mentioned before, APIs are standardised sets of requirements that govern how one software application can talk to another (e.g. Google Maps API, which allows to integrate map information in any application). An API can be seen as a user-interface, with different users in mind, i.e. computer applications and their programmers.

To facilitate using this interface, the service provider publishes a precise API specification, which typically provides following details:

• What functionality is available

• A description of the flow (like e.g. next possible/best action)

• The details of the communication, i.e.

  • Data Transmission: the way the data is transmitted. This is almost always HTTP/HTTPS.

  • Data Exchange: the format of the exchanged data. Most common formats are XML and JSON.

• The API design, i.e. the way the API is designed. Most common standardized design principles are REST (Representational State Transfer) and SOAP (Simple Object Access Protocol).

• Conditions for using the service, i.e. the data access determining who gets access to which data and how this is achieved. Most common standards here are SAML (Security Assertion Markup Language) and OAuth 2.0 (Open Authorisation).

An API can be open or closed/private. An open API can be accessed (under specific conditions) by third parties, while a closed API can only be accessed within the boundaries of the organisation.

A good API should additionally meet several non-functional requirements:

• Secure: given that open APIs are exposed publicly, a good security design is essential, so that confidential data is not exposed to the wrong party and that DoS attacks (on the APIs) don’t affect other (critical) systems of the company.

• Flexible to adapt: APIs should be flexible to modify. E.g. bugs in an API should be fixed very quickly, since such bugs will not only have internal impacts, but also give impacts for external partner companies.

• Easy deployable: given that an API should be flexible to adapt, it should also be easy to deploy. This deployment should happen without downtime and running multiple versions of the same API concurrently should be supported.

• Highly available: given that the usage of APIs is hard to predict and can be very flexible, windows of unavailability become very hard to manage. Therefore, APIs should be 24/7 available and guarantee also high availability in case of unforeseen incidents.

• Elastic Scalability: since APIs will be used by other companies, which are often start-ups, the usage can grow very rapidly. APIs should therefore support elastic scalability, i.e. automatically adjust (without down-time) the available resources based on the load.

Both at design and run-time APIs are typically supported by an API Gateway, which provides following functionalities:

• API routing: route requests based on message content, headers, identity and other factors. The API routing should also support prioritisation of requests, based on SLAs agreed with the API callers.

• Data Transformation & Validation: the request should be validated against a schema and transformation of the data should be supported.

• Tool comes with several standard connectors, allowing the API to connect directly to mail servers, databases, document management systems…​

• Security Management: this is probably the most important functionality of an API gateway. The tool should

  • Manage the API visibility and restrict access. Typically, this consists of supporting authorisation standards like SAML and OAuth 2.0. It also includes the management of authorisation keys (e.g. creation and validation of keys) for external parties to access the APIs.

  • Authenticate and encrypt all messages sent over the network

  • Secure tagging to easily manage sensitive and non-sensitive data in the API calls

  • Enforce rate limiting and throttling dynamically based on usage quotas and bandwidth quotas

  • Detect and prevent SQL, JavaScript or XPath/XQuery injection attacks

  • …​

• API Repository/Registry: repository to manage and store all available APIs. This repository allows to search APIs, view API details, manage APIs (like activate/deactivate, deployment, access management), send notifications when new API (version) is published…​

• API Portal: provide a secure online portal to onboard partner third parties and create a community. This portal should contain:

  • Self-registration to subscribe to APIs (sandbox / production)

  • API documentation (i.e. functionality, API format, request/reply examples, code examples of how to use API…​)

  • Forum discussions

  • Description of the sandbox (i.e. connection details, test data description…​)

• Tools to easily design, build, document, test and deploy APIs (new APIs or changes to existing APIs)

• API Monitoring and Analytics: different types of monitoring on the APIs:

  • Technical monitoring: track API usage, successes versus errors, latency, …​

  • Define SLA rules and monitor if APIs meet these SLAs

  • Business Activity Monitoring

  • API Analytics: identify key trends and behaviors in usage of APIs, deeper understanding in API traffic…​

  • Alerting: receive notifications when SLAs are not met, when change is published on tracked API…​

• API Monetization: configure payment schemes to monetize API usage and integrate with billing systems for automatic billing.

9. Conclusion

Insurers should move now in adapting their internal architecture, to expose well-defined and well-documented services to the outside world. Instead of only doing the bare minimum to integrate with the most popular distribution platforms, insurance companies should already start opening their full data insights and product catalogue. This strategy of exposing products and services as APIs, will not only allow the business of an insurer to explore new opportunities, but will also push IT organisations to restructure, allowing them to evolve to a more agile, customer-centric organisation.