Blockchain in Versicherungen und Insurtech zur Koordination von Schadenfällen und Zahlungen

Versicherung beginnt vor dem Schadenfall. Das Unternehmen identifiziert den Kunden und das versicherte Interesse, schätzt Häufigkeit und Schwere, legt Bedingungen fest, erhebt eine Prämie und stellt Kapital zurück. Tritt ein Ereignis ein, muss es vor der Zahlung Gültigkeit, Deckung, Kausalität, Schaden und möglichen Betrug prüfen. Anschließend holt es Beträge zurück, wenn ein Regressanspruch besteht, und teilt einen Teil des Risikos mit Rückversicherern.

Jede Phase arbeitet mit anderen Registern und anderen Beteiligten. Dazu gehören Vermittler, Sachverständige, Werkstätten, Krankenhäuser, Datenanbieter, Versicherer und Rückversicherer. Ein und derselbe Schaden kann mehrere Policen oder Deckungsschichten betreffen. Die operative Herausforderung besteht darin, Identität, Vertrag, Nachweis und Haftung zu verknüpfen, ohne Informationen zu duplizieren oder eine Schlussfolgerung vorwegzunehmen, die noch eine Beurteilung erfordert.

Blockchain passt, wenn mehrere Unternehmen denselben Vertragszustand beobachten oder dieselbe Exponierung abstimmen müssen. Ihr potenzieller Beitrag ist eine gemeinsame Historie mit ausführbaren Regeln. Die rechtliche Verpflichtung entsteht weiterhin aus der Police und den Vorschriften. Code kann eine Deckung nicht erweitern, eine mehrdeutige Klausel nicht auslegen und nicht allein entscheiden, ob eine Angabe betrügerisch war.

Im Versicherungswesen fungiert die Blockchain als Zustands- und Ausführungsschicht, nicht als vollständige Police. Der Versicherungsvertrag definiert Rechte und Ausschlüsse; der Smart Contract bildet nur die Bedingungen ab, die sich deterministisch ausdrücken lassen. Erhält er ausreichende Daten, kann er das Ereignis erfassen, einen Betrag berechnen und die Zahlung gemäß den festgelegten Kontrollen anweisen oder ausführen.

Um Informationen aus der Außenwelt zu erhalten, braucht er ein Oracle, also eine Quelle oder eine Gruppe von Quellen, die Daten zu Niederschlag, Flug, Index, Standort oder jedem anderen Parameter liefert. Die Automatisierung ist nur so zuverlässig wie die Definition des Index, die Qualität dieser Quellen und das Verfahren zur Klärung eines fehlerhaften Messwerts. Bei nicht parametrischen Produkten bleiben Untersuchung und Schadenbewertung unverzichtbar.

Das belastbarste Modell kombiniert Code und Prozess. Das Netzwerk bewahrt Versionen und gemeinsame Nachweise; der Versicherer behält seine Kontrollen zu Sanktionen, Betrug, Solvenz und Kundenservice; und ein Ausnahmeweg erlaubt die Überprüfung des Ergebnisses. Ziel ist, das Eindeutige zu automatisieren und das Strittige nachvollziehbar zu machen, nicht so zu tun, als sei jeder Schadenfall eine binäre Bedingung.

Eine parametrische Versicherung ersetzt nicht zwangsläufig den beobachteten Schaden. Sie zahlt den vereinbarten Betrag, wenn ein Index einen Schwellenwert überschreitet, etwa Niederschlag an einer Station, Intensität eines Zyklons, regionaler Ertrag oder eine bescheinigte Verspätung. Diese Objektivität reduziert die Schadenbegutachtung und ermöglicht eine frühe Auszahlung, was wertvoll ist, wenn der Versicherte sofort Liquidität braucht.

Die Kehrseite ist das Basisrisiko. Der Kunde kann einen Verlust erleiden, ohne dass der Index die Zahlung auslöst, oder sie ohne entsprechenden Verlust erhalten. Die Qualität des Produkts hängt davon ab, dass der Parameter gut mit dem Risiko korreliert, dass Gebiet und Zeitraum passend sind und dass die Vertriebskommunikation parametrische Zahlung nicht mit Ersatz des tatsächlichen Schadens verwechselt.

Blockchain automatisiert die Ausführung und macht überprüfbar, welche Daten und welche Version der Regel verwendet wurden. Den Index verbessert die Technologie für sich genommen nicht. Es muss eine Richtlinie für fehlende Quellen, amtliche Korrekturen, Abweichungen zwischen Oracles und Extremereignisse außerhalb des Modells geben. Je unumkehrbarer die Zahlung, desto robuster muss die Daten-Governance sein.

Das Teilen von Policen, Rechnungen oder Ereignissen kann doppelte Ansprüche und nachträgliche Änderungen erschweren. Es erlaubt auch nachzuweisen, welche Informationen bei einer Entscheidung vorlagen. Ein Großteil des Betrugs findet jedoch statt, bevor die Daten das Register erreichen, durch synthetische Identitäten, vorsätzlich herbeigeführte Schäden, gefälschte Dokumente oder Absprachen zwischen Dienstleistern.

Signiert eine gefälschte Quelle ein Ereignis, bewahrt Blockchain die Fälschung mit hervorragender Rückverfolgbarkeit. Prävention erfordert weiterhin Identitätsprüfung, Analyse, Ermittlung und Zusammenarbeit innerhalb der Grenzen von Datenschutz und Wettbewerbsrecht. Das Netzwerk kann Nachweise liefern und verhindern, dass jedes Unternehmen dieselbe Akte neu aufbaut; es darf nicht als automatischer Absichtsdetektor dargestellt werden.

Blockchain schafft einen gemeinsamen Zustand, wenn Versicherer, Vertriebspartner, Dienstleister, Kunden und Rückversicherer dieselbe Police oder dasselbe Ereignis prüfen müssen. Regeln können Deckung, Nachweise, Reserven und Zahlung koordinieren, während jedes Unternehmen seine eigenen Systeme behält. Der Nutzen steigt, wenn die Bedingung objektiv ist, und sinkt, wenn Kausalität, Schaden oder Verhalten eine fachliche Beurteilung erfordern.

In der traditionellen Versicherung durchlaufen Police, Nachweise, Entscheidung, Zahlung und Regress unterschiedliche Systeme und Organisationen. Ein Blockchain-Netzwerk kann gemeinsame Zustände halten und vereinbarte Regeln ausführen. Es ersetzt weder Ermittlung noch Kundenservice, reduziert aber die Abstimmung in wiederholbaren Prozessen und hinterlässt eine überprüfbare Historie, wer jeden Schritt gemeldet, validiert oder freigegeben hat.

Die Meldung eröffnet eine Akte, bestimmt aber nicht die Zahlung. Der Versicherer prüft Gültigkeit, Identität, Deckung, Ausschlüsse und Unterlagen; bildet eine geschätzte Rückstellung; ermittelt, wo angebracht; berechnet die Leistung; zahlt; und kann Regress bei Dritten nehmen. In der Kranken-, Kfz- oder Haftpflichtversicherung liefern mehrere Dienstleister Nachweise, und die Kausalität ist selten ein einfacher Datenpunkt.

DLT kann einen gemeinsamen Zustand halten, wiederholte Anfragen vermeiden und festhalten, wer welches Dokument beigesteuert hat. Smart Contracts können deterministische Schritte ausführen, etwa Fristen prüfen, Dubletten erkennen, Mittel reservieren oder einen bereits genehmigten Betrag verteilen. Bei der Entscheidung, die den Kunden betrifft, müssen Begründung, Verantwortlicher und Beschwerderecht erhalten bleiben.

Die beste Automatisierung beseitigt nicht alle Prüfungen. Sie leitet einfache Fälle über einen schnellen Weg und eskaliert Unstimmigkeiten. Das Design umfasst buchhalterische Stornierung, Korrektur von Quellen, Betrug nach der Zahlung und Kontinuität bei Nichtverfügbarkeit des Netzwerks. Eine schnelle Zahlung, die sich weder erklären noch anfechten lässt, verlagert operative Kosten in Verhaltensrisiko.

In der Rückversicherung tauschen Zedent, Makler und Rückversicherer Verträge, Bordereaux, Prämien, Schäden und Erstattungen aus. Die Informationen treffen zu unterschiedlichen Zeitpunkten und in unterschiedlichen Formaten ein und können eine monatelange Abstimmung erfordern. Ein gemeinsames Register kann jede Bewegung mit der anwendbaren Vertragsversion verknüpfen und zeigen, welcher Teil akzeptiert oder strittig ist.

Die Schwierigkeit ist nicht nur technischer Natur. Die Verträge enthalten Limits, Aggregate, Wiederauffüllungen, Währungen und Klauseln, die Auslegung erfordern. Zudem enthalten die Portfolios geschäftliche und personenbezogene Informationen, die nicht unter Wettbewerbern verbreitet werden dürfen. Die Architektur ist in der Regel permissioned, mit selektiver Sichtbarkeit und detaillierten Dokumenten off-chain.

Die Automatisierung eignet sich für akzeptierte Berechnungen und Bewegungen, während Streitfälle und Änderungen von Schätzungen weiterhin menschliches Eingreifen erfordern. Der Nutzen bemisst sich in schnellerem Abschluss, weniger Differenzen, besserem Überblick über Kumule und weniger gebundenem Kapital, nicht im Ersatz des Rückversicherers durch Code.

Betrug kostet allein in den USA rund 308,6 Milliarden US-Dollar pro Jahr, so die Coalition Against Insurance Fraud im Jahr 2022. Die Zahl erklärt das Interesse daran, Nachweise zu teilen und Doppelmeldungen zu erkennen. Sie belegt nicht, dass jede Automatisierung Betrug reduziert, denn Identität, Kausalität und Kollusion können versagen, bevor ein Ereignis überhaupt ins Register gelangt.

Etherisc und ACRE Africa dokumentierten den Einsatz von Smart Contracts für indexbasierte Agrarversicherungen in Kenia. Die Ethereum Foundation beschrieb 2021, wie das Projekt die Registrierung der Landwirte, Wetterdaten und Zahlungen verknüpfte. Es handelt sich um eine Implementierung in einem spezifischen Kontext. Wer ihre Übertragbarkeit auf einen anderen Markt bewerten will, muss Vertrieb, Qualität des Index, Kosten und den tatsächlichen Zugang zum Geld prüfen, ohne universelle Einsparquoten zu unterstellen.

Die institutionelle Einführung befindet sich jedoch weiterhin in einer frühen Phase, verglichen mit Technologien wie Analytik, KI oder IoT. EIOPA weist darauf hin, dass viele europäische Entwicklungen nach wie vor Proofs of Concept oder Implementierungen in kleinem Maßstab sind. Die verfügbaren Belege zeigen die Machbarkeit in konkreten Prozessen, nicht einen generellen Ersatz der Bestands- und Schadensysteme.

Nicht alle Versicherungen verhalten sich gleich. Eine Flugverspätung oder ein Wetterindex lassen sich über eine vereinbarte Quelle verifizieren. Ein Kfz-Schaden erfordert die Verknüpfung von Unfall, Ersatzteilen, Reparatur und möglicher Haftung. Eine Krankenversicherung umfasst medizinische Notwendigkeit und besonders geschützte Daten. Lebens- und Haftpflichtversicherungen können von Dokumentation und langwierigen juristischen Entscheidungen abhängen.

Die Programmierung muss an der richtigen Stelle ansetzen. In einem parametrischen Produkt kann sie die gesamte Leistung berechnen; in einer Schadenversicherung validiert sie vielleicht nur die Police, sammelt Nachweise und verteilt eine bereits genehmigte Zahlung. In der Rückversicherung kann sie akzeptierte Anteile berechnen, ohne über eine strittige Deckung zu entscheiden. Wer all diese Prozesse als automatische Zahlung darstellt, verdeckt den Unterschied zwischen Ereignis, Schaden und Verpflichtung.

Die Entscheidungstabelle kombiniert Objektivität des Auslösers, Qualität der Quelle, Korrekturmöglichkeit, Auswirkung auf den Kunden und Bedarf an Ermessen. Je größer die Mehrdeutigkeit, desto nützlicher ist Blockchain als gemeinsamer Prüfpfad und desto weniger eignet sie sich als unumkehrbare Ausführungsinstanz. Reife bedeutet nicht, Menschen zu eliminieren, sondern ihr Eingreifen für Ausnahmen vorzubehalten, die tatsächlich Urteilsvermögen erfordern.

Ein Smart Contract kann feststellen, dass eine Verpflichtung besteht, und eine Anweisung an ein konventionelles Zahlungssystem senden. Er kann auch tokenisiertes Geld übertragen, sofern Produkt, Institut und Jurisdiktion dies zulassen. Im ersten Modell stimmen Netzwerk und Bank das Ergebnis ab. Im zweiten trägt der Vermögenswert Emittenten-, Verwahrungs-, Liquiditäts- und Rückzahlungsrisiko.

Prämien und Leistungen unterliegen Vorgaben zu Währung, Steuern, Sanktionen, Geldwäscheprävention und Kundenschutz. Ein Stablecoin macht aus einer internationalen Zahlung nicht automatisch risikofreies Geld und erlaubt dem Versicherer nicht, außerhalb seiner Lizenz tätig zu werden. Der Begünstigte benötigt möglicherweise lokale Währung und einen Beschwerdeweg, auch wenn die Transaktion on-chain final ist.

Die atomare Abwicklung ist vor allem zwischen Instituten relevant, die Positionen und Zahlungsmittel austauschen, etwa in bestimmten Rückversicherungsflüssen. Für Privatkunden wiegen meist Verfügbarkeit, Rückabwicklung bei Fehlern, Kosten und einfacher Zugang schwerer. Die Zahlungsschicht wird nach dem Design des Versicherungsprodukts gewählt, nicht umgekehrt.

Die am besten begründeten Anwendungsfälle haben objektive Regeln, Daten mit klarer Governance und mehrere Beteiligte gemeinsam, die denselben Status prüfen müssen. Parametrische Versicherungen, Rückversicherung, Deckungsbestätigungen, Regress und einfache Schadenmeldungen können profitieren. Komplexe Schadenfälle erfordern weiterhin Ermittlung, Gutachten, Betreuung des Versicherten und einen klaren Weg, Entscheidungen zu korrigieren oder anzufechten.

Eine Architektur für den Produktivbetrieb verbindet Bestandsverwaltung, Schadenbearbeitung, Zahlungen, Identität, Dienstleister und Reporting. Die DLT speichert Zustände oder Nachweise, die mehrere Parteien verifizieren müssen. Dokumente, Gesundheitsdaten, Telematik und vollständige Akten bleiben in der Regel off-chain, mit Berechtigungen, Aufbewahrungsfristen und Berichtigungsmöglichkeit.

Oracles erfordern Redundanz, Änderungskontrolle und Rückverfolgbarkeit. Es muss bekannt sein, wer veröffentlicht, wie häufig, was bei Abweichungen geschieht und ob der Wert nachträglich revidiert werden kann. Ein Smart Contract sollte keine wesentliche Verpflichtung auf Basis einer API ohne Notfallverfahren ausführen. Die Quelle ist Teil des Produkts und seines operationellen Risikos.

Auch Schlüssel und Wallets dürfen keine Rechte blockieren. Der Kunde braucht Wiederherstellung, Vertretung und alternative Kanäle. In Netzwerken zwischen mehreren Unternehmen regelt die Governance die Aufnahme von Nodes, Versionen, Incident Response, Korrekturen und Austritt. Verteilte Validierung beseitigt weder den Verantwortlichen für die Datenverarbeitung noch den gegenüber dem Versicherungsnehmer verpflichteten Versicherer.

Ein Pilotprojekt beginnt mit einer objektiven Regel, ausreichenden historischen Daten und einer klar abgegrenzten Gruppe von Versicherten. Es vergleicht Auszahlungsdauer, Bearbeitungskosten, Fehlerquote, Basisrisiko und Beschwerden mit dem aktuellen Prozess. Außerdem simuliert es ausgefallene Quellen, korrigierte Daten, Sanktionen, Betrug und Technologieausfälle.

In der Rückversicherung oder in geteilten Prozessen zählen eliminierte Abstimmungen, Abschlussgeschwindigkeit, Vollständigkeit und die Zeit für das Onboarding von Partnern. Wenn das Netzwerk verlangt, alle Datensätze zu duplizieren, oder Streitigkeiten weiterhin außerhalb gelöst werden, ohne abgebildet zu werden, verliert der On-Chain-Zustand seine operative Verbindlichkeit.

Skalierung erfordert Produkt-Governance, aktuarielles Modell, Vertrieb, Support und Kapital, nicht nur auditierte Smart Contracts. Blockchain verdient ihren Platz, wenn sie eine multilaterale Reibung reduziert oder ein Produkt ermöglicht, das zuvor nicht tragfähig war. Liefert eine signierte API mit einem anerkannten Betreiber dasselbe Ergebnis, ist sie meist die einfachere Option.

Bei einer parametrischen Versicherung muss der Test den Auslöser mit bekannten Schäden vergleichen, um das Basisrisiko zu verstehen. Es kann Schäden ohne Auslösung und Auslösungen ohne entsprechenden Schaden geben. Ziel ist nicht, diese Differenz per Software zu beseitigen, sondern sie vor Vertragsabschluss zu messen und zu erklären. Die Akte muss die Quelle des Index, dessen Version und die Regeln für fehlende oder korrigierte Daten festhalten. Ebenso ist zu testen, was geschieht, wenn der Datenlieferant während der Deckungsperiode nicht mehr antwortet.

Die Ausführung muss bestätigen, dass eine gültige Deckung besteht, dass die Prämie vertragsgemäß behandelt wurde und dass die Zahlung nicht bereits erfolgt ist. Danach verknüpft sie die Berechnung mit verfügbaren Mitteln und einem verifizierten Begünstigten. Eine wiederholte Anweisung darf keine weitere Entschädigung auslösen. Schlägt die Zahlung fehl, behält der Versicherte einen Informations- und Beschwerdeweg, und die offene Verpflichtung bleibt sichtbar. Die Geschwindigkeit wird bis zur Verfügbarkeit des Geldes gemessen, einschließlich Kontrollen und Ausnahmen, nicht nur bis der Smart Contract ein Event auslöst.

Die Deckungslücke (Protection Gap) von Swiss Re ist eine modellierte Schätzung des Deckungsbedarfs und etwas anderes als die Summe der in einem Jahr beobachteten nicht versicherten Schäden. Ebenso umfasst das Automatisierungsszenario von McKinsey Technologien und operative Veränderungen, die weit über Blockchain hinausgehen. Diese Referenzen verorten das versicherungstechnische Problem, doch das Projekt muss seine eigene Verbesserung bei Deckung, Verwaltung und Kosten nachweisen. Der Vergleich muss dieselbe versicherte Population und dieselben Policenbedingungen beibehalten, um interpretierbar zu sein.

MiCA reguliert Kryptowerte, keine Versicherungsprodukte. Ein Versicherer, der Blockchain einsetzt, unterliegt weiterhin dem sektoralen Rahmen einschließlich Solvency II sowie den Pflichten zur digitalen Resilienz nach DORA unter der zuständigen Aufsicht, zusätzlich zu Datenschutz und Wohlverhaltensregeln. MiCA kommt ins Spiel, wenn die Struktur einen regulierten Kryptowert umfasst.

MiCA kommt nur ins Spiel, wenn die Lösung einen Kryptowert nutzt, etwa einen Stablecoin zur Zahlung von Prämien oder Entschädigungen. Das Versicherungsprodukt vom technologischen Vehikel zu unterscheiden und auf beide jeweils die einschlägigen Vorschriften anzuwenden, ist der Ausgangspunkt jedes Projekts.

Die Automatisierung mindert nicht die Pflichten zu Information, Produkteignung, Beschwerdemanagement oder Überwachung von Dienstleistern. In der Europäischen Union bezieht DORA Versicherer und Rückversicherer in ihren Rahmen für IKT-Risiko und Resilienz ein. Nodes zu betreiben oder von Oracles und Verwahrern abzuhängen, erfordert je nach Fall Inventar, Verträge, Tests, Kontinuität und Incident Reporting.

Ein parametrisches Produkt muss eine korrekt konzipierte und vertriebene Versicherung bleiben. Der Kunde muss Index und Basisrisiko verstehen. Wird zusätzlich eine wirtschaftliche Beteiligung tokenisiert, eine dezentrale Versicherungsgemeinschaft geschaffen oder werden digitale Vermögenswerte eingesetzt, können Vorschriften zu Wertpapieren, Kryptowerten, Zahlungen und Geldwäscheprävention hinzukommen. Die Einordnung erfolgt nach Funktionen und Rechten, nicht danach, ob man den Code Insurtech nennt.

Die meisten Kunden können einen Smart Contract nicht auditieren, und selbst wenn sie es könnten, enthält der Code nicht zwangsläufig die gesamte Police. Bedingungen, Ausschlüsse, Definition des Index, Quellen, Gebühren und Beschwerdeverfahren müssen vor Vertragsabschluss in verständlicher Sprache kommuniziert werden. Eine Oberfläche, die Blockchain verbirgt, kann die Folgen des Produkts nicht verbergen.

Jede automatisierte Entscheidung mit erheblicher Wirkung braucht Rückverfolgbarkeit und Aufsicht gemäß dem geltenden Rahmen. Der Versicherte muss wissen, welcher Wert die Leistung ausgelöst oder verhindert hat, wie er ihn korrigieren lassen kann und wer haftet. Ändert das Oracle eine Beobachtung oder weichen zwei Quellen voneinander ab, muss die Plattform Versionen aufbewahren und die Ausführung gegebenenfalls aussetzen oder überprüfen.

Auch finanzielle Inklusion wird nicht vorausgesetzt. Eine schnelle mobile Zahlung kann in der Landwirtschaft oder bei Katastrophen wertvoll sein, doch das Produkt muss Konnektivität, Kompetenz der Nutzer, Verwahrung, Gebühren und Umtausch in nutzbare Währung berücksichtigen. Effizienz ist nur real, wenn der Kunde eine angemessene Deckung erhält und seine Rechte ausüben kann, ohne Wallets oder Netzwerke beherrschen zu müssen.

Die Technologie kann eine Regel schneller und prüfbarer machen, aber sie macht aus einer schlechten Deckung, einem schwachen Index oder einer ungerechten Entscheidung kein gutes Produkt. Sie bestimmt auch keine Kausalität, bewertet keine komplexen Schäden, verhindert keine gefälschte Identität und garantiert nicht, dass der Wert des Oracles den tatsächlich erlittenen Schaden des Versicherten abbildet.

Diese Begriffe unterscheiden vertragliche Deckung, gemessenes Ereignis, tatsächlichen Schaden, Datenquelle und Zahlungsmechanismus. Sie trennen außerdem Automatisierung von Entscheidung, parametrische von schadenbasierter Versicherung und geteiltes Register von tokenisiertem Geld. Diese Präzision erlaubt es, einen Vorschlag zu bewerten, ohne anzunehmen, dass ein Smart Contract die Police, den Gutachter oder die Versicherungsaufsicht ersetzt.