blogposts

ExcecInsurtech 2018 – In a Nutshell

It was a pity that I couldn’t attend longer the brillant organized and inspiring ExecInsurtech 2018. But even with only the few bits I took with me I predict 2019 will be the year of PSD2 Insurance. I saw a lot of interesting solutions and ideas. On a high level these could be sorted into one of these three categories:

1. PSD2-Aggregation – Creating Multi-Insurance- and Account-Views with the help of PSD2
2. PSD2-Contract- and Account–Management – Comparing and offering Insurance alternatives  with the help of PSD2 and KI
3. PSD2-Advisor – Full-fledged full-automated Robo Insurance Advisor with the help of customer account- and transaction-information and KI

I am very curious, if these new technical and business capabilities will be accepted by the market and the customers.  And if and how these will then influence traditional  carrier relationships finally. Besides I also discussed Open Insurance compared to and in the context of PSD2. With the help of Friendsurance’s Sebastian we got a first  insight into and  impressions of how PSD2 insurance can work.

Masterclass PSD2 and OpenInsurance

Together with our classroom participants we discussed, if PSD2 derived Open APIs could also be a trend for insurance.  After the exchange of some  controversial views we answered the following polls: These polls and our classroom results are far from being representative. But with the solutions I saw at ExecInsurtech, the feedback I received and  the discussions I led I believe I see a trend. And an interesting question remained in the room: How should/could the existing and traditional world handle and react to it?  

The first OpenCologne meeting at AXA in Cologne was a success.  At least if one considers the No-Show-Rate of zero and the demand for participation in advance. But also from other perspectives I believe this initial meeting was a valuable one. More than 25 individuals, different  insurers, Fintechs and experts synchronized on their views on Open APIs and created interested and constructively one common understanding and definition for OpenCologne: OpenCologne is a Self-Service and standardized, freely available B2C Insurance API controlled by the customer with Strong Customer Authentication and Consent Management provided, implemented and powered by the insurer. My impression of these first three hours:  It’s time for an Open API movement beyond banking. (Sketchnoting OpenCologne Results – Credits to Alexander Huth – Talanx) As one outcome this understanding now has to be communicated and synchronized internally by every participant.  Everybody clearly needs to understand: OpenCologne is an important business strategy (decision) and not just integration technology. A smaller working group of five insurers (Alte Leipziger, AXA, Generali, Gothaer, Talanx and Uniqa) and two Fintechs (Friendsurance, Kasko) has been formed and will meet end of November again at Insurlab Germany. Every member,  as a homework, has now to reflect which Business APIs from their perspective could/should be included into a technical and secured B2C OpenCologne container accompanied by corresponding and proving use cases. In the following two days in November or December we will find out if the group can identity one common set of Business APIs and  can define a ‘compromise of appetite’ for API openness and API standardization. Besides a first governance and operating model should be identified. Based on the  given results,  detailed in a decision template, every incumbent has then to decide if there’s a base to continue and to implement OpenCologne. Hopefully end of the year we’ll know if we’ll continue to transforming insurance from ‘Insurance to Go‘ to ‘Insurance to Stay‘. We’ll keep you posted. Your OpenCologne Group.

Kommenden Dienstag treffen sich für ein sehr aktuelles Thema namhafte Vertreter der Versicherungswelt, bunt gemischt aus traditionellen Versicherungsunternehmen und Startups, erstmalig in Köln bei AXA. Der Name OpenCologne ist hierbei bewusst Programm – Köln erster Austragungsort und Open das Leitthema der Veranstaltung. Mit an Bord sind Vertreter der Zurich, Generali, Talanx, DEVK, Gothaer, Uniqa, Alte Leipziger und AXA, aber auch Startups wie Friendsurance, Schutzklick,  Kasko, Element und eine Reihe weiterer Experten. Zielsetzung des ersten Aufeinandertreffen ist die offene, aber durchaus gewollte und zielgerichtete Diskussion offener Standards für vom Kunden kontrollierte, regulierte und grenzenlos einsetzbare B2C APIs:

1. Glauben die Teilnehmer daran, dass die Reduktion der Informations-Asymmetrie durch Öffnung ihnen und allen Teilnehmern einen Mehrwert bietet?
2. Ist ein gemeinsamer Standard in Summe wertvoller, als proprietäre Offene APIs vom  jeweiligen Teilnehmer?
3. Finden die teilnehmenden Protagonisten einen gemeinsamen Nenner und ein Verständnis für eine erste Implementierung, für eine API, wie es diese im Bereich von Banken in Deutschland schon lange gibt und ab Ende 2019 auch Europaweit geben wird (PSD2)?

Wie auch schon seit Jahren im Bankenumfeld ist dieses Thema stark polarisierend und wird, je nach Perspektive, in die eine oder andere Richtung schon vorab emotional diskutiert. Auch ich, als langjähriger Teilnehmer der vielen Banken-API-Diskussionen, bin mir letztendlich noch unschlüssig, ob eine Öffnung und Standardisierung und wenn ja, welcher Grad genau, einen Mehrwert  für Kunden und Versicherungen bieten wird. Insofern ist das erste Zusammentreffen auch für mich persönlich und meine Sichten eine gewollte Challenge. Ich werde unsere, meine Gedanken vorstellen und bin gespannt auf das Feedback, die anschließende Diskussion und den Verlauf. Wird es am Ende des Tages ein weiteres dieser vielen Austauschmeetings der Versicherungsbranche werden oder doch vielleicht der Startschuss zu einer langen ‘Reise einiger Entwickler, um mit neuen Architekturen und Schnittstellen die Versicherungswelt neu zu vermessen’? Ich kann es nicht sagen. Aber eines weiß ich aber schon jetzt: Unser Meetingraum  wird voller werden, als gedacht und geplant. Es kann durchaus sein, dass einige Mitstreiter im Stehen die Welt verändern müssen  🙂 Infos und Gedanken zu OpenCologne: OpenCologne Customer Journeys OpenCologne Openness OpenCologne Agenda

Go where the customer is with your Insurance Data and Processes

I’ve been often asked what are the advantages of OpenCologne? For simplification and illustration purposes I’ve created some Customer Journeys without claiming any completeness and/or correctness. I’m very happy if one is taking these illustrations to challenging these stories behind OCGN or providing other good examples:

Tax Journey

The customer uses a cloud based service to create his tax declaration. Instead of manually entering insurance data he integrates his insurance account into the tax service with the help of the OCGN button.

eCommerce Journey

The customer decides during checkout to insure items in the basket. An alternative to selecting a new insurer he protects the corresponding item with his existing carrier account and signs the transaction with strong customer authentication (SCA) applying a One Time Password (OTP).

Finance Planning Journey

The customer can create a Multiview-Insurance perspective by integrating his data via OCGN and PSD2. From this Multi-View he does Change Business with his existent carrier.

Buy Car  Journey

The customer buys a new car via a motor web platform and decides to quote the new model via OCGN and his existing carrier. Besides he orders via OCGN an EVB automatically.  The customer can also initiate a bind and sign via OTP.

Sell Car Journey

The customer wants to sell his car via a motor web platform, but instead of entering all car data manually to create the ad and the offer he fetches necessary data via OCGN and his assigned insurer.

Compare Insurance Journey

The customer can, after searched for the best offer via an aggregatator site, also compare via OCGN with his existing insurer’s offer with a one click login.

Make Appointment  Journey

The customer can make an appointment via a doctor’s web appointment platform and can register via OCGN. The necessary insurance data is automatically added to the appointment.

Platforms are about Existing Business – Platforms are about keeping the customer

Traditionally Insurance is focusing New Business. Mainly every monetary incentive priorities the new customer. And so do insurance products, processes and technology. This is different to some other successful business lines and models,  for example the emerging platform business.  Sustainable ecosystem and platform models try to focus the existing customer by serving  him as best as possible. This historic difference explains why it’s today rather difficult to transfer the insurance business and thinking into a platform and ecosystem oriented world with its high customer interactions and cross selling opportunities. Successful platforms, like Amazon, always have focused and preferred the existing customer compared to just attracting new customers. They try to reduce (technology and service) friction for this group as much as possible. Insurance companies in contrast usually reduce friction for the new customer.

Why OpenCologne is important for a Sustainable Platform Business

And this where OpenCologne comes into play.  OCGN is much more a business  than a technology strategy.  It lays the foundation for reducing the today’s digital friction for existing insurance customers. With OCGN the customer receives a lightweight and friction-less possibility to use his Insurance Identity and corresponding data and services with an Open API approach.  He receives a ‘Take-away-API’ and ‘Take-away-Identity‘  for nearly every context and application. The services necessarily don’t need to be provided by the insurance company. These extend the insurances core values with new added values by keeping the binding to the insurer. All the user has to do is to login with his existent insurance credentials, no extra registration or extra KYC processes and governance are usually necessary. No single application, no single portal – go with your insurance data where the value ist. But extra and new values will only be created by external innovation power, if enough known customers can be reached by these.  A customer only wants to become a known one, if the ‘known’ attribute pays off for him  with a broad and rich offer. This is why a sustainable platform strategy has to focus the known, IDENTIFIED customer with extra and non-core services – and the open cooperation with other verticals. Both isn’t typically within the  traditional DNA of an insurer.        

Dimensions of Openness

From the research perspective there are at least four Dimensions of Openness in a platform world. The openness of the Demand-, the Supply-,  the Provider- and the Sponsor perspective. The current thoughts of the OCGN Group concerning this structuring are the following:

Current view of OpenCologne

The Demand side is at no cost open for everybody.  Everybody can develop at no licence fees against the OCGN APIs. Same is valid for the Supply view. Every insurer can build against the API designs at no costs and should also supply a basic sets of implemented APIs for free (comparable to the current PSD2 regulation – ‘at no discrimination’). The Provider perspective is open as well. There are no limits connecting the demand and the supply side technically and from a platform perspective. The Sponsor’s design responsibility and it’s IP is up to the OCGN group and its members. We will work on a shared governance- and operating mode,  but as with the other elements as well, we’ve just started to sort out different opinions and objectives. Interesting and important to know is there are levels of openness. Openness is an important mean to control and manage a two-sided market.  

Status  Update – More than Utopia – Interest is here (to stay)

In the meantime the OpenCologne Initiative has been discussed with several carriers and startups. Five carriers and the same number of startups have articulated interest to discuss further and to identify a suitable operating and governance model. The new group intends to meeting for a first iniital setup in October in Cologne  trying to answering the question above and to defining a first MVP. Our focus is ‘being open’, but starting small and delivering instead of trying to solving everything theoretically and in advance. Attached below the rationale behind OpenCologne and its objectives (for the ones who haven’t yet joined former discussions). Stay  tuned. I know it’s far from easy, but I know it can work reflecting  past activities for HBCI and PSD2/BerlinGroup and other API and community activities I’ve supported the last 30 yeas.

The OpenCologne Agenda in a Nutshell

 

Why it’s important to find the right mix of Platform Openness and Value Sharing

And how to by leveraging the right Open APIs approach

Many Platform- and Ecosystem Strategies are possible. Also different API strategies are applicable. But one, who really wants to benefit from exponentiell  platform-network effects, should follow the ‘True Open API Architecture‘ approach compared to Pipeline Architectures, I guess. Why? By keeping specific API core features within the authority of  Incumbents and Insurers the Insurer can increase or keep the binding to and the interaction with the customer:

Fair mix of Value Sharing

The Insurer keeps the Identity of the customer and can leverage it for further interactions. The user is a known customer and not only a ‘product sale’. The Insurer’s API provides Strong Customer Authentication to enable further transactions, e.g. for cross-selling, with the known customer. The API Provider, the Insurer, provides Login and Registration to keep the user interface to the customer. The API User can benefit from transaction fee sharing, can integrate and can extend the given functionality and can create new services and products. The API User doesn’t have to care for the complex handling of Identity and Security. I assume, it’s a fair and from an Insurer’s perspective also necessary approach in a platform-driven and changing world. Your thoughts?

What is the difference to other API initiatives (e.g. BIPRO in Germany)

While forming the OpenCologne initiative I am often asked:

• Why do we need another, a new API approach?
• What is the difference to other activities like BIPRO et al?
• Why now?
• And why we as Insurer?

Many good questions. And for all of them I hope I can provide an answer and rationale. While I tried to explain in my last blog post, what a ‘True Open API’ is I today would like to illustrate by the graphic below, why we need a ‘True Open API’  for Platform Economic scaling also for Insurance. And why current approaches don’t scale as best as possible and aren’t the most suitable match for platforms from an Insurer’s perspective.

What are the key capabilities of an OpenCologne API or Platform API?

1. Open Cologne wants to provide a ”True Open API” (see for Architectures and capabilities)
2. Open Cologne wants to provide a “Platform API”  in contrast to a “Pipeline API” (see above for architecture and differences)
3. Open Cologne is designed for PULL-, Demand- and User- Driven Models
4. Open Cologne wants to provide an API controlled and ‘owned’ by the Customer and User (“Consent Driven API”)
5. Open Cologne wants to keep the Incumbent and API provider visible by keeping the Incumbent, the Insurer “visible”
6. Open Cologne APIs wants to be as frictionless and as self-service as possible and thus as scalable as possible
7. Open Cologne wants to keep the Platform’s Core Value and Filters transparent to everybody
8. Open Cologne want to use modern developer oriented technologies and methods (Open Source)

Many of the given capabilities aren’t fulfilled by others today and thus the reason for trying something new.  And I’m not alone with this interest – not any longer. Your opinion? What are your thoughts, your approaches?

What is a True Open Insurance API

Another hype topic besides platforms and ecosystems are Open APIs. Open APIs are the DNA for a friction-less scale on the supplier and demand side within an ecosystem. But not every API is in my eyes a True Open API. While  banks, as finance forerunners, especially in Germany in the past and long before PSD2, developed or are currently developing Open APIs I don’t see this trend yet within the Insurance space. Only because an API is technically accessible and can be accessed via Internet standards  it’s not fully open or a True Open API. And if an Insurance API is not a True Open API the API won’t scale on a platform as best as possible.

How to create an Open API?

To become an Open API for Insurance the Customer has to ‘sit in the Driver Seat’ and control the API like he can within banking in 2019 (B2C API). The Insurance API must include everything necessary to be leveraged seamlessly. The partner shouldn’t need to implement Identity management, security or validations etc.  in order to use the API properly and securely. The partner must be able to integrate the API in a Self-Service approach and the developer should be able to work autonomously. At a highest level of True Open Insurance APIs  the partner should be able to use the same API definition not only for one incumbent. Last but not least the API should be governed and regulated (in some form) in order to operate in a stable, transparent, reliable and by all parties broadly accepted environment.