ExcecInsurtech 2018 – In a Nutshell
It was a pity that I couldn’t attend longer the brillant organized and inspiring ExecInsurtech
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:
- PSD2-Aggregation – Creating Multi-Insurance- and Account-Views with the help of PSD2
- PSD2-Contract- and Account–Management – Comparing and offering Insurance alternatives with the help of PSD2 and KI
- 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:
- Glauben die Teilnehmer daran, dass die Reduktion der Informations-Asymmetrie durch Öffnung ihnen und allen Teilnehmern einen Mehrwert bietet?
- Ist ein gemeinsamer Standard in Summe wertvoller, als proprietäre Offene APIs vom jeweiligen Teilnehmer?
- 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
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:
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.
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’
‘ 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
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’).
perspective is open as well. There are no limits connecting the demand and the supply side technically and from a platform perspective.
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.
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.
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.
What is the difference to other API initiatives (e.g. BIPRO in Germany)
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?
- Open Cologne wants to provide a ”True Open API” (see for Architectures and capabilities)
- Open Cologne wants to provide a “Platform API” in contrast to a “Pipeline API” (see above for architecture and differences)
- Open Cologne is designed for PULL-, Demand- and User- Driven Models
- Open Cologne wants to provide an API controlled and ‘owned’ by the Customer and User (“Consent Driven API”)
- Open Cologne wants to keep the Incumbent and API provider visible by keeping the Incumbent, the Insurer “visible”
- Open Cologne APIs wants to be as frictionless and as self-service as possible and thus as scalable as possible
- Open Cologne wants to keep the Platform’s Core Value and Filters transparent to everybody
- 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