Versicherungsprodukte als Regelwerke

Ein Versicherungsprodukt ist ein Regelwerk, welche die mögliche Kombinationen von Deckungszusagen beschreibt: den sog. Deckungs- oder Produktbaum. Welche Deckungsbausteine stehen zur Verfügung, welche Attribute mit welchen Wertebereichen haben diese, wie lassen sie sich kombinieren.

Die Regeln für das Produkt definieren die zulässigen Konfigurationen des Produkts. Der Deckungsbaum bildet gewissermaßen das einheitliche Rückgrat für eine Reihe verwandter Objekte:

  • Produktkonfiguration

  • Berechnung

  • Offert

  • Antrag

  • Vertrag

Die jeweils aktiven Regeln können dabei zusätzlich von der Art des Objekts und von seinem Status abhängen. Geschäftsobjekte im engeren Sinn sind Offert, Antrag und Vertrag.

Die Produktkonfiguration soll dabei das abstrakte zugrundeliegende Modell beschreiben.

Diese Objekte bestehen wiederum aus Objektnetzen, in deren Zentrum der hierarchische Baum der Deckungen steht, die aber viele weitere Unterobjekte und Bezüge zu Objekten haben:

  • Versicherungsprämien bzw. Beiträge

  • Risikoobjekte

  • Antrags- bzw. Vertagsrollen

  • Personen

  • Adressen

  • Zahlungsdetails

  • Hinweise, Warnungen, Fehlermeldungen

  • Dokumente (als Beilagen)

Regelwerk der Interaktion

Während naturgemäß über fachliche Regeln insbesondere Produktregeln in Versicherungsunternehmen viel nachgedacht wird, läuft die Interaktion zur Manipulation der Geschäftsobjekte über eine oder mehrere Medien. Für das jeweilige Medium der Kommunikation gelten eigene Regelwerke.

In heutigen webbasierten Schnittstellen werden die obigen Objekte über Http-Requests und Responses manipuliert. Die Objekte werden dabei in einem wählbaren Mediatype wiedergegeben oder repräsentiert. So kann die Repräsentation eines Antrags oder Vertrags beispielsweise über XML, Json oder als PDF Dokument erfolgen.

Beide Regelwerke, das für das Produkt im engeren Sinne und das für die Interaktion sollten idealerweise mit der gleichen Technologie abgebildet werden.

Die Produktdefinition als Regelwerk

Die Produktdefinition legt vorab – a priori, unabhängig vom einzelnen Kunden – fest, welche Produktinstanzen (Antrags- oder Vertragskonfigurationen) möglich sind.

Die Regeln für das Produkt sind ein weitere Regelwerke eingebettet: Regulierung für Versicherungsverträge wie das VersVG, Regeln gegen Geldwäsche und bezüglich Steuer, Regeln für Geschäftsabläufe insbesondere für die Antragseinreichung bei einer bestimmten Versicherung. Auch diese Regelwerke werden für eine Antragsstrecke als gegeben und a priori beschreibbar angesehen.

Wie veränderlich sind diese Regelwerke: Sehr unterschiedlich. So ist die Regel, dass die Prämie zu Beginn des versicherten Zeitraums fällig ist, sehr alt. Das deutsche VVG geht auf das Jahr 1908 zurück. Das österreichische VersVG wurde auf dieser Basis am 1. Jänner 1959 novelliert. Die Regeln für konkrete Versicherungsprodukte ändern sich oftmals jährlich. Die Prämien können sich noch häufiger ändern und insgesamt möchte man die Produkte in Zukunft möglichst schnell an Marktbedingungen anpassen können.

Wie werden diese Regeln insbesondere für den Antrag operationalisiert?

  • Traditioneller Weise wurden diese Regeln in Produkthandbüchern und Verkaufsunterlagen erfasst, verteilt und dann in Systemen implementiert. Je nach Art der Implementierung konnten Regeln schneller geändert werden oder waren fester in den Systemen verankert.

  • Feste unveränderliche Regeln machen ein EDV-System stabiler, und reduzieren Fehler.

  • Die Flexibilisierung und Optimierung auf "Time-to-market" soll sich daher nur auf für den Markterfolg relevante Regeln beziehen. So soll es beispielsweise leicht möglich sein, neue Produktgenerationen zu veröffentlichen und neue Produktbausteine einzuführen. Die Prämie wird weiterhin zu Beginn des Versicherungszeitraums fällig werden, wie es aus guten Gründen seit Jahrhunderten Gebrauch ist.

Die Anforderungen für den Umgang mit Regeln haben sich aber mit dem Aufkommen von Webschnittstellen verändert:

  • Genügte es früher, diese Regeln im zentralen System zu implementieren und die Mitarbeiter einzuschulen, so gilt es heute diese Regeln an im Grunde unbekannte Clientsysteme von Geschäftspartnern zu übermitteln.

  • Konnte der Wechsel von Regeln früher über Releases des zentralen Systems organisiert werden, so ist dies heute kein gewünschtes Vorgehen mehr:

    • Die Absatzverantwortlichen möchten nicht an den Releasezyklus der IT gebunden sein.

    • Die IT möchte nicht auf sehr kurzfristige Markteventualitäten reagieren müssen.

    • Durch eine Vielzahl von angebundenen externen Partnern ist ein Wechsel der Schnittstelle zu einem bestimmten Zeitpunkt nicht mehr möglich. Vielmehr muss eine neue Version parallel angeboten werden.

  • Sind es heute noch überwiegend programmierte Clients, welche die Schnittstellen ansprechen, so ist auch auf Clientseite ein Trend zur Flexibilisierung absehbar:

    • Sog. Smartclients können Regelwerke zur Laufzeit konsumieren, wenn diese maschinenlesbar übermittelt werden.

    • KI-Agenten interagieren nur noch zur Laufzeit. Sie müssen dazu aber ebenfalls die Regelwerke zur Laufzeit verstehen können.

Aus den vorgestellen Gründen werden in Zukunft Regelwerke für die Antragsstrecke und insbesondere für Versicherungsprodukte explizit in formalen Sprachen auszudrücken sein.

Der Paradigmenwechsel: Von Implizit zu Explizit

Früher war es so: Die "unveränderlichen Regeln" (z. B. "Ein Benutzer muss volljährig sein") standen in einer if-Abfrage im Backend. Wenn sich diese Regel änderte, musste man den Code ändern, testen und neu deployen.

Wenn du diese Regeln nun in eine standardisierte, zur Laufzeit interpretierbare Sprache auslagerst, änderst du das System-Design grundlegend:

Die Vorteile einer einheitlichen Regelsprache

  • Single Source of Truth (SSOT): Wenn Client und Server dieselbe Regelsprache sprechen, können Validierungen auf beiden Seiten absolut synchron laufen. Der Client weiß sofort, warum ein Button deaktiviert ist, ohne den Server zu fragen, weil er dieselbe Regel-Engine lokal ausführt.

  • Auditierbarkeit und Compliance: In regulierten Branchen (Finanzen, Medizin) ist es Gold wert, wenn Regeln nicht in Binärdateien versteckt sind, sondern als lesbare "Policies" vorliegen. Man kann beweisen, welche Regeln zu welchem Zeitpunkt aktiv waren.

  • Entkopplung von Release-Zyklen: Du kannst Business-Logik (die "Regeln") unabhängig von der Infrastruktur (dem "API-Gerüst") aktualisieren. Das senkt die operative Entropie, weil Änderungen gezielter und mit weniger Kollateralschäden am System vorgenommen werden können.

  • Symmetrie: Ein Client kann dem Server sogar eigene Regeln vorschlagen ("Verarbeite diesen Batch nur, wenn Bedingung X erfüllt ist"), was extrem mächtige, flexible Schnittstellen ermöglicht.

Das Risiko: Die "Meta-Entropie"

Obwohl dieser Ansatz die Ordnung auf der funktionalen Ebene erhöht, birgt er eine Gefahr auf der architektonischen Ebene:

Komplexitäts-Verschiebung: Du hast weniger Entropie im Business-Code, aber dafür eine extrem hohe Entropie in deiner "Rule-Engine". Wenn die Sprache zu mächtig ist (z. B. Turing-vollständig), baust du im Grunde eine Programmiersprache in einer Programmiersprache. Das ist schwer zu debuggen.

Performance: Das Interpretieren von Regeln zur Laufzeit ist immer langsamer als nativer Code.

Arten von Regeln

Die Anforderungen an Objekte können:

  • In Request und Response gleich sein, z.B. die Daten eines Kfz in der Sparte Kraftfahrt

  • Für den Request gelten: Informationen, welche der Server für die Berechnung benötigt

  • Nur für den Response gelten: z.B. erwartet der Client Angaben zur Prämienhöhe als Ergebnis einer Berechnung, sonst ist es keine erfolgreiche Berechnung.

Anwendung

Gefragt ist daher ein Konzept, welches die Regeln explizit und zur Laufzeit zur Verfügung stellen kann:

  • die Regeln für das Versicherungsprodukt im engeren Sinn (Risikobeschreibung und Konfiguration des Versicherungsumfangs für die Berechnung der Prämie)

  • die Regeln für die Antragseinreichung (auch Regulatorik und Geschäftsprozesse ändern sich heute schneller als früher und die KI kann zur Laufzeit darauf reagieren)

  • die Regeln für Vertragsänderungen wie z.B. Fahrzeugwechsel oder Ausschluss einer Kaskoversicherung.

  • die Regeln für Konvertierung von einem Vertrag in einen neuen Vertrag eines Nachfolgeprodukts.

Vorab festgelegte Regeln

Diese Regeln existieren für den einzelnen Vorgang vorab (a priori) und können mit geeigneten Sprachen auch vorab ausgedrückt werden.

  • KI Systeme verstehen besonders gut Vokabulare welche auf Knowledge-Graphen basieren. Diese ermöglichen es auch Begriffe über einzelne Unternehmen und Konsumenten hinweg festzulegen. Mit Json-LD steht eine moderne Syntax zur Verfügung.

  • Mit der Shapes Constraint Language SHACL steht eine W3C Norm zur Verfügung um einerseits Abhängigkeiten in Versicherungsprodukten zu übertragen, andererseits um Anforderungen von Server und Client an die Kommunikation zu formulieren.

Adhoc

Daneben können mögliche Änderungen an bestimmten Instanzen aber auch ad hoc übermittelt werden. Wenn ich beispielsweise einen rudimentären Kfz-Antrag konfiguriert habe, kann mir die Schnittstelle den Einschluss eines weiteren Fahrzeugs als Wechselkennzeichen anbieten. Wenn ich einen bereits polizzierten Kfz-Vertrag beauskunfte, kann mir die Schnittstelle die Stornierung der Kaskoversicherung anbieten.

Solche Ablaufsteuerungen in Abhängigkeit vom aktuellen Status werden als Hypermedia-Controls bezeichnet und das Konzept hierzu wird als HATEOAS abgekürzt.

Dies sind z.B. die

  • Explizit durch Objektbeschreibungen und Regeln, z.B. RDFS Definitionen und SHACL Constraints

  • Implizit durch die Implementierung von Webservices und Dokumentationen.

Regeln für den Antrag können vom Status abhängen. Ein unvollständiger Antrag kann beispielsweise nicht eingereicht werden.

Regeln für Vertragsänderungen können vom Vertragsstatus abhängen, z.B. können für einen im Prämienverzug befindlichen Vertrag andere Regeln gelten.