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)?
Go where the customer is with your Insurance Data and ProcessesI’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:
Finance Planning Journey
Buy Car Journey
Sell Car Journey
Compare Insurance Journey
Make Appointment Journey
Platforms are about Existing Business – Platforms are about keeping the customerTraditionally 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 BusinessAnd 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 OpennessFrom 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 OpenCologneThe 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 approachMany 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 SharingThe 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?
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)