Published On: 20. Juli 2022 | Categories: Aktivität, Community, Österreich, RNext |
Historie

Die RNext-Gruppe TAA Kfz in Österreich startete im Sommer 2019 mit ausschließlich österreichischen Mitgliedern. Da es derzeit keine flächendeckende Implementierung der RClassic-TAA-Normen in Österreich gibt, ist RNext eine willkommene Alternative. Nach einem Erstentwurf (Proof of Concept) der API, in dem der Fokus sehr stark auf der Datenmodellierung lag, wurde der erste Code-Freeze bereits Ende 2019 von den Gruppenmitgliedern vorgenommen. Ein Code-Freeze beschreibt das Commitment der RNext-Gruppe, diesen entwickelten Stand der RNext-API auf einem produktionsnahen System zu „verproben“ und somit praxisnah zu belegen, dass die Ideen und die Konzepte funktionieren, wie eine RNext-TAA-Norm aussehen sollte. Durch verschiedene Repriorisierungen in den einzelnen Unternehmen konnte die Erstimplementierung erst Ende 2020 bzw. Anfang 2021 erfolgen. Die Implementierenden, bestehend aus Serviceanbietern (Providern) und Serviceabnehmern (Consumern), trafen sich dann im Herbst 2021 erneut, um über die weitere Roadmap zu entscheiden und sich über die „Lessons Learned“ aus der Erstimplementierung auszutauschen. Weitere Mitglieder, sowohl auf Seite der Provider wie auch auf der Seite der Consumer wurden auf dieses Vorhaben aufmerksam und schlossen sich der RNext-Gruppe an, um ihre Ideen ebenfalls in die weitere Entwicklung einzubringen und die Schnittstelle mit ihren Partnern zu implementieren. Der Scope der zweiten Iteration der Schnittstellenentwicklung wurde festgelegt. Dabei sind vor allem Prozesse in den Vordergrund gerückt. Während man sich zu Anfang noch sehr stark an den TAA-Prozessen in RClassic orientiert hatte, entdeckte man nun schnell, dass die neue Architektur auf Basis von JSON/REST, OpenAPI sowie Microservices auch die Abbildung weitaus interessanterer Use Cases ermöglicht.

Doch was hat das mit Embedded Insurance zu tun?

Ende Juni 2022 wurde die zweite Iteration abgeschlossen. Das Ergebnis war ein weiterer Code-Freeze, der von der RNext-Gruppe gemeinschaftlich beschlossen wurde und derzeitig von den Gruppenmitgliedern implementiert wird. Ziel der RNext-Gruppe ist es, bereits etablierte Prozesse, die es im TAA-Bereich zwischen Maklern und Versicherern gibt, mit der neuen Schnittstelle abzubilden. Ebenfalls soll die Schnittstelle für die Kommunikation zwischen eigenen, hausinternen Portalen und dem „Backend“ verwendet werden, um Kosteneinsparungen zu fördern und Mehrfachentwicklungen zu vermeiden. Zusätzlich soll auch neuen Marktteilnehmern, die z. B. außerhalb der Versicherungsbranche tätig sind, eine Möglichkeit gegeben werden, in den TAA-Prozess einzusteigen. Dieses hochgesteckte Ziel wurde relativ einfach mit einem Use Case beschrieben: „Stupid Client“.

Die anfangs despektierlich klingende Beschreibung meint einen „Client“, also einen Serviceabnehmer, der nicht die tiefe Kenntnis über Kfz-Versicherungsprodukte hat und ebenfalls keine impliziten Regeln kennt. Aber warum sollte so ein Client eine Versicherung abschließen wollen und was hat es denn nun wirklich mit Embedded Insurance zu tun?

Die Teilnehmer der RNext-Gruppe stellen sich dabei ein selbstfahrendes Auto vor, am besten noch ein „shared car“, mit dem jeden Tag eine andere Person fährt. Der Anspruch ist es, dass dieses Auto sich über die neue RNext-TAA-Kfz-Schnittstelle selbst versichern könne. Viele Marktteilnehmer werden jetzt sagen, das sei doch gar nicht so einfach. Woher soll das Auto denn wissen, welchen Selbstbehalt es bei der Banania in der Haftpflicht gibt und welchen bei der Insassenversicherung? Und wie soll das funktionieren mit providerspezifischen Erweiterungen und Antragsfragen, wenn das Auto ebenfalls einen Vergleich macht, um eine möglichst günstige Versicherung für die Insassen zu finden? Natürlich sind diese Fragen gar nicht so einfach zu beantworten. Es werden aber in der RNext-Gruppe TAA Mechanismen aufgezeigt, wie so etwas mit z. B. einem Listenservice für Selbstbehalte funktioniert und ob der Client vor der Tarifierung automatisiert abfragt, welche Werte gesetzt werden dürfen. Ebenfalls wird ein Szenario durchgespielt, bei dem man die Antragsfrage „Hatten Sie schon mal einen Unfall?“ mit „Ja“ beantwortet und das dann zu einer Folgefrage führt: „Wann war der Unfall?“.

Abgerundet wird die Schnittstelle durch einen Mechanismus für providerspezifische Erweiterungen, den es in TAA wohl noch eine ganze Weile geben wird, weil sich verschiedene Produktanbieter voneinander unterscheiden wollen. Da wo es angebracht ist, lassen sich Bausteine der Schnittstelle gezielt „customizen“. Eine automatisierte Codegenerierung der Schnittstelle für Provider ist dabei weiterhin möglich. Gleichzeitig kann der Consumer ebenfalls einen „Stack“ für seinen Client generieren, auch wenn er mit unterschiedlichen Produktanbietern zusammenarbeitet und diese sich in der providerspezifischen Erweiterung unterscheiden. In anderen Worten wurde der Schnittstelle durch die Modularität und Feingranularität die Möglichkeit gegeben, zukünftig völlig neuartige Produkt anzubieten. Tarifwechsel (auch tägliche(!)) sind nun auch kein Thema mehr, da es dafür keine Schnittstellenanpassung mehr auf Consumerseite geben muss. Durch diese Dreifaltigkeit der Schnittstelle in Bezug auf die Verwendung durch Makler, das eigene Portal sowie auch branchenfremde Clients wurde eine Embedded Insurance einfach mitgedacht. Die Teilnehmer der RNext-Gruppe konzentrieren sich derzeit primär darauf, die Schnittstelle den jeweiligen Vertriebspartnern anzubieten oder auch auf firmeninterne Anwendungen auszuweiten. Aber die Teilnehmer sind froh, für die Zukunft gewappnet zu sein, auch wenn dies eigentlich nur ein Nebenprodukt war und nicht im Fokus stand.

Wer bei Embedded Insurance oder Open Insurance ausschließlich an die Datenherausgabe durch die Versicherer denkt, der betrachtet dies nur eindimensional. Open Insurance bedeutet im wesentlichen Sinne, Branchenfremde möglichst einfach in das Versicherungsökosystem zu integrieren. Somit müssen die Einstiegshürden möglichst niedrig gehalten werden, so dass Branchenfremde durchaus eigenständig eine solche API bedienen können – ohne breites Vorwissen. Dies ist der RNext-Gruppe TAA Kfz sehr gut gelungen, und dieses Verfahren könnte durchaus eine Blaupause für TAA-Vorhaben in RNext in Deutschland werden. Wer mehr darüber erfahren möchte, der kann direkt auf die Gruppe zugehen: RNext-Gruppe TAA Kfz (Österreich).

Leave A Comment

Kategorien

Monatsarchive

Neueste Beiträge