News & Insights

1. Die Entwicklung von Open Insurance scheint eher langsam vonstattenzugehen (abgesehen von einigen bemerkenswerten Ausnahmen)

United Healthcare hat einen großen Schritt auf der Developer-Experience-Achse gemacht und schneidet in dieser Ausgabe des OIM am besten ab. Der Krankenversicherer hat erheblichen Aufwand in die Professionalisierung des allgemeinen Look-and-feels seines Entwicklerportals gesteckt. Daneben geht das Portal durch die optimierte Anzeige von Anwendungsfällen und die Möglichkeit, Anleitungen zum Vergleich von verfügbaren digitalen Lösungen zu erhalten, besser auf die Informationsbedürfnisse von medizinischem Fachpersonal ein. Diese Anleitungen helfen medizinischem Fachpersonal, die Vorteile direkter API-Integrationen gegenüber anderen verfügbaren Alternativen wie Self-Service-Portalen auf der Grundlage ihrer eigenen Bedürfnisse zu vergleichen. Die ersten Schritte auf dem Portal werden mit einer Einsteigeranleitung zu APIs und umfangreichen Videotutorials zur API-Verwendung ergänzt. Weitere Verbesserungen der Usability für Entwickler sind unter anderem die App-Management-Funktion und die Zwei-Faktor-Authentifizierung. 

In dieser Ausgabe des OIM werden auch ein paar Neueinsteiger begrüßt, wie etwa der Versicherer Zego. Zego stellt API-Dienste zur Live-Aktivierung von Fahrerversicherungen auf der Grundlage von Arbeitszeitnachweisen bereit. Die InsurTech-Unternehmen Kasko, Bsurance und Tigerlab bieten APIs an, die primär darauf abzielen, Versicherer beim Verkauf und Vertrieb ihrer Produkte zu unterstützen. Im Fall von Tigerlab sind diese API-Dienste Teil einer größeren Versicherungsplattform, die auch Dienste zum Underwriting und der Policy Administration umfasst. Die OP Financial Group hat ihrem „Banking as a Service“(BaaS)-Angebot Schadenregulierungsdienste des finnischen Lebensversicherers Pohjohla hinzugefügt. Die KBC Bank hat ihren BaaS-Katalog mit einem Service zur Angebotserstellung erweitert. Der API-Katalog der Great American Insurance Group besteht aus APIs für Verkauf und Vertrieb, Underwriting sowie Policy Servicing. Chubb hat ein Entwicklerportal eingerichtet, das Dienste zur Angebotserstellung und zum Policy Issuing für verschiedene Produktlinien enthält. Nach kurzer Abwesenheit ist Qover nun wieder mit einem ausgewählten Satz an APIs mit dem Schwerpunkt auf Schadenregulierungsdienste im OIM vertreten. Dieses InsurTech wurde bei der vorherigen Bewertung nicht berücksichtigt, nachdem sein Entwicklerportal und die API-Dokumentation nicht mehr verfügbar waren. 

Beim Vergleich der neusten Erkenntnisse aus dem OIM mit den Ergebnissen aus Mai 2021 wird insgesamt deutlich, dass Open Insurance nur langsam voranschreitet. Versicherer haben weiterhin den größten funktionalen Umfang (so wie hauptsächlich bei AXA und Nationwide zu beobachten), müssen aber noch in die Verbesserung der Developer Experience investieren. Währenddessen behalten Banken bei der Developer Experience weiterhin die Oberhand. Ihnen fehlt jedoch ein breites Portfolio an API-unterstützten Versicherungsdienstleistungen (siehe Bankencluster unten rechts). Es gibt sogar Akteure im Bereich Open Insurance, die den Umfang ihrer Offenheit scheinbar wieder einschränken. In diesem Zusammenhang zu nennen sind beispielsweise Humana, das den Zugriff auf sein Entwicklerportal auf registrierte Partner beschränkt hat, und Wakam, welches seine Schadenregulierungs- und Angebotserstellungsdienste ohne weiteren Kommentar aus seinem Portal entfernt hat. 

2. Hinter verschlossenen Türen: manche Versicherer ziehen es vor, nur eine ausgewählte Gruppe an Partnern zu bedienen

Abgesehen von den Versicherern, die Teil des OIM sind, gibt es verschiedene Versicherer, die Live-Entwicklerportale haben, aber den Zugriff auf ausgewählte Partner beschränken. Dies trifft unter anderem auf Munich Re, Zurich Insurance, Insurance Australia Group und Markel Corp zu. 

Vielen Akteuren, die ihre Entwicklerportale öffentlich zugänglich machen, fehlt es an solider Entwicklungserfahrung, um ihre API-Dienste für neue Partner interessant zu machen und diese für sich zu gewinnen. Die API-Dokumentation auf solchen Entwicklerportalen ist oft technisch, unvollständig und kryptisch. Das bedeutet, dass sie tatsächlich nur von Personen mit technischem Hintergrundwissen genutzt werden kann, die außerdem einen direkten Zugang zum Support des jeweiligen Versicherers haben, der die APIs anbietet. Darüber hinaus sind für ein volles Verständnis der APIs Kenntnisse von internen Systemen und Prozessen notwendig. Schließlich zeigt sich durch das Fehlen von übergeordnetem geschäftlichen Kontext und inspirierenden Anwendungsfällen sowie durch begrenzte Bemühungen für den Aufbau von Communitys, dass diese Versicherer bei der Positionierung als Wegbereiter von digitalen Ökosystemen immer noch am Anfang stehen. 

3. Versicherer sind noch nicht bereit für Angebote im Bereich eingebettete Versicherungen…

Ein wichtiger Wegbereiter für Open-Insurance-Strategien ist es, Dritten zu ermöglichen, Versicherungsdienstleistungen und -produkte in andere Arten von Kundenaktivitäten zu integrieren – typischerweise auf nicht finanziellen digitalen Plattformen –, um ihre Kunden am Point-of-Need zu bedienen. Diese Art der Partnerschaft wird oft auch als „embedded insurance“ – also eingebettete Versicherung – bezeichnet. So wie bei vielen anderen Produktarten müssen die zugrunde liegenden Open-Insurance-APIs klar und einfach zu verwenden sein, um eingebettete Versicherungen voranzutreiben. 

Die Erkenntnisse aus dem Open Insurance Monitor deuten darauf hin, dass viele Versicherer sich weiterhin primär darauf konzentrieren, Vermittler mit APIs (oftmals zur Versicherungsverwaltung) zu unterstützen, anstatt direkt eine bessere Erfahrung für Nutzende und Endkunden von digitalen Plattformen zu ermöglichen. Dies spiegelt sich beispielsweise in Funktionen wie dem Abruf von Vertriebsanleitungen, Underwriting-Fragebögen, Klassencodes und Vertragsverläufen sowie Funktionen für die Verwaltung von Vertreter-/Kundenkonten wider. Obwohl diese API-Dienste für bestimmte Partner von Wert sein können, eignen sie sich weniger für Angebote von eingebetteten Versicherungen. 

4. ...und konzentrieren sich nicht auf die für Skalierbarkeit notwendige Einheitlichkeit und Standardisierung

Schaut man sich an, wie Versicherer Prinzipien für API-Design und -Architektur verfolgen, zeigt sich weiterhin, dass Einheitlichkeit und Standardisierung nur begrenzt vorherrschen. Die APIs von Versicherern werden oft aus der Workflow-Perspektive zugänglich gemacht. Endpunkte drehen sich um spezifische Schritte innerhalb operativer Abläufe und/oder zielen darauf ab, sehr spezifische Datenobjekte abzurufen oder zu ändern. Wenn dann noch die Unterschiedlichkeit und die Komplexität verschiedener Versicherungsprodukte ins Spiel kommen, werden API-Kataloge schnell komplex und unübersichtlich, anstatt eine zentrale und leicht zu verstehende Anlaufstelle mit Plug-and-play-Lösungen für Dritte zu sein. 

In diesem Zusammenhang unterscheiden sich InsurTech-Unternehmen von Versicherern dahingehend, dass ihre API-Angebote sich mehr auf wichtige digitale Anwendungsfälle wie etwa „Verkauf und Vertrieb“ oder „Schadensmanagement“ konzentrieren. Folglich bestehen ihre API-Kataloge aus präzisen und klaren Zusammenstellungen produktunabhängiger APIs für Dritte zur Einbettung in deren digitale Plattformen. Zu nennen sind hier beispielsweise APIs von Covergenius und Boost für Policy Issuing und Schadens-APIs von Qover. 

Mit der Formalisierung der rechtlichen Landschaft in der EU müssen Versicherer anfangen, Open Insurance zu priorisieren

Die aktuelle Entwicklungsgeschwindigkeit von Open Insurance hat es Versicherern erlaubt, es erst einmal langsam angehen zu lassen. Allerdings haben sich die Regeln mit dem jüngsten Open-Finance-Framework offiziell verändert. So wie es im Banking mit der PSD2-Regelung geschehen ist, werden gleichermaßen in der EU ansässige Versicherer – aber auch andere Akteure in der Versicherungswertschöpfungskette wie Vermittler (insbesondere im Bereich Nichtlebensversicherungen mit Ausnahme von Krankenversicherung) – verpflichtet werden, ihre Versicherungsdaten Dritten zur Verfügung zu stellen. Diejenigen, die bereits eine Strategie mit unterstützender API-Architektur haben, werden einen Vorsprung dabei haben, die neu entstehenden Chancen zu nutzen. 

Beschleunigen Sie Ihre Open-Insurance-Journey

Wenn Sie erfahren möchten, wie Sie Ihre Open-Insurance-Journey anstoßen oder beschleunigen können, zögern Sie nicht, sich an Mounaim Cortet oder Maarten Bakker zu wenden.  

Der INNOPAY Open Insurance Monitor entwickelt sich ständig weiter. Wenn Sie der Meinung sind, dass Ihre Organisation aufgenommen werden sollte, kontaktieren Sie bitte Marnix de Kroon.