Smart Contracts in Versicherungen: welche Policen automatisch auszahlen können

Eine parametrische Versicherung wird in umgekehrter Reihenfolge zu einer Schadenversicherung konzipiert. Statt nach dem Schadenfall den Schaden jedes Versicherten zu bewerten, wählt man zuerst einen externen Datenpunkt, der die Zahlung auslöst, etwa die Verspätung eines Flugs in Minuten oder die an einer Messstation registrierte Niederschlagsmenge in Litern, und prüft danach, ob dieser Wert den Verlust gut abbildet, den der Kunde absichern will. Gerade bei dieser Art von Produkt kann einSmart Contractmehr als nur aufzeichnen: Kommt der Datenpunkt über einen verlässlichen Weg, prüft der Smart Contract die Police, berechnet den vereinbarten Betrag und veranlasst die Zahlung, ohne dass jemand eine Schadenmeldung bearbeitet.

Darin liegt auch seine Grenze. Ein Programm kann nur die Deckungen ohne Eingriff auszahlen, deren Schadenfall durch einen überprüfbaren Datenpunkt definiert ist, und dort spart es Begutachtung, Abgleich und Wartezeit. Alles andere bleibt, wo es war: das Risiko, dass der Index nicht mit dem Verlust übereinstimmt, die Abhängigkeit vom Anbieter des Datenpunkts und die Zulassung als Versicherer. Der in der Branche meistzitierte Fall, fizzy von AXA, fügt eine Lehre hinzu, die nicht technischer Natur ist: Der Smart Contract funktionierte, und dennoch wurde das Produkt eingestellt, weil es nicht genug Nachfrage fand.

Welchen Teil einer Police ein Smart Contract ohne Eingriff ausführen kann

Ein Smart Contract prüft Bedingungen, die er lesen kann: ob eine Police zu einem Datum gültig war, ob bereits gezahlt wurde, ob ein Wert einen Schwellenwert überschreitet, ob derjenige, der eine Transaktion signiert, dazu berechtigt ist. Mit diesen Prüfungen kann er einen Betrag nach einer Formel berechnen und eine Zahlung veranlassen. Was er nicht kann, ist wissen, was außerhalb des Netzwerks geschehen ist: Die Verspätung eines Flugs oder die gefallene Regenmenge müssen über einOracle, einen Dienst, der den Datenpunkt veröffentlicht und signiert, eingespeist werden. Die Police bleibt das Dokument, das Deckung, Ausschlüsse und Pflichten festlegt; der Code führt den Teil dieser Bedingungen aus, der sich ohne Auslegung ausdrücken lässt.

Daraus ergibt sich das Kriterium dafür, was programmiert wird. Eine bescheinigte Flugverspätung, ein Niederschlagsschwellenwert oder die von einer Behörde gemessene Stärke eines Erdbebens sind Tatsachen, die alle Parteien im Voraus als Quelle akzeptieren können. Ein Fahrzeugschaden, eine Verletzung oder ein Haftpflichtfall erfordern, Ursache, Schaden und Umstände in Beziehung zu setzen, und eine solche Entscheidung lässt sich nicht auf eine Bedingung reduzieren, die der Code auswerten kann. Bei einer Schadenversicherung kann der Smart Contract höchstens die Police erfassen, die Zahlung eines bereits genehmigten Betrags veranlassen oder jeden Schritt dokumentieren; die Seite zuBlockchain im Versicherungswesengeht diese Einsatzbereiche in Underwriting, Schadenbearbeitung und Rückversicherung durch.

Fizzy von AXA: Der Smart Contract funktionierte, das Produkt wurde 2019 eingestellt

AXA führte fizzy 2017 als ihrerstes parametrisches Produkt auf Blockchain-Basisein, eine Versicherung gegen Flugverspätungen. Die Police wurde im öffentlichen Ethereum-Netzwerk erfasst, und lautLedger Insightslöste eine Verspätung von zwei Stunden oder mehr den Schadenfall aus, und eine vorab festgelegte Entschädigung ging auf das Bankkonto des Kunden, ohne dass er sie beantragen musste. Es war der Anwendungsfall, der am besten zum Mechanismus passt: eine objektive Tatsache, eine Quelle für Flugdaten und ein fester Betrag.

Ende 2019 stellte AXA den Vertrieb ein. Auf die Einstellung angesprochen, erklärte das Unternehmen gegenüberArtificial Lawyer, das Produkt habe seine kommerziellen Ziele nicht erreicht, vor allem weil das Interesse des Marktes noch nicht ausreichte, es habe keine wirksamen Vertriebskanäle gefunden, und man habe es nach dem Test-and-Learn-Prinzip entwickelt. Die Automatisierung löste die Zahlung, doch die Zahlung war nur ein kleiner Teil des kommerziellen Problems: Eine Flugverspätungsversicherung muss dort verfügbar sein, wo der Reisende seine Reise plant, und ohne Kanal an dieser Stelle erreichte der technische Vorteil den Kunden nicht.

Das Basisrisiko beseitigt kein Oracle

Die Weltbank definiert das Basisrisiko als dasRisiko, dass die Auszahlung der Police nicht mit den tatsächlichen Verlusten übereinstimmt, ein bekanntes Problem jedes parametrischen Risikotransfers. Es kann in beide Richtungen auftreten: Der Versicherte erleidet einen Verlust, und der Index erreicht den Schwellenwert nicht, oder der Index wird ausgelöst, und die Zahlung übersteigt den Schaden. Ihrer Analyse der parametrischen Katastrophenversicherungen auf den Philippinen zufolge führten Auszahlungen, die den Schaden in einer Provinz überstiegen, ebenfalls zu Verzögerungen.

Das Oracle spielt bei dieser Abweichung keine Rolle. Es kann den Wert einer Wetterstation, die zehn Kilometer vom Ort des Regens entfernt liegt, exakt übermitteln, und der Smart Contract zahlt oder zahlt nicht auf Grundlage dieses Werts. Die Qualität des Produkts hängt davon ab, Index, Messort und Zeitraum richtig zu wählen und dem Kunden zu erklären, dass er bei Eintritt eines Ereignisses einen vereinbarten Betrag erhält und keine Entschädigung für seinen Verlust. Vom Oracle hängt etwas anderes ab: was geschieht, wenn die Quelle nichts veröffentlicht, den Wert nachträglich korrigiert oder zwei Quellen nicht übereinstimmen, und wer berechtigt ist, das zu klären.

Regen bei einem Festival: Wie eine parametrische Deckung konzipiert wird

Die Zahlen dieses hypothetischen Falls dienen der Veranschaulichung. Ein Assekuradeur will gemeinsam mit einem zugelassenen Versicherer, der das Risiko trägt, eine Deckung für Veranstalter von Open-Air-Events anbieten: Sie zahlt 20.000 €, wenn eine offizielle Wetterstation in der Nähe des Geländes am Veranstaltungstag zwischen 16:00 und 23:00 Uhr mehr als 10 Liter pro Quadratmeter registriert. Bevor eine Zeile Code geschrieben wird, entscheidet das Produktteam, welche Station verwendet wird, was geschieht, wenn sie keine Daten mehr sendet, wie mit einem von der Behörde korrigierten Wert umgegangen wird und ab wann ein Wert als endgültig gilt.

Sind diese Entscheidungen getroffen, ist der Ablauf kurz. Die Police wird bei Abschluss mit ihren Parametern erfasst. Nach dem Event veröffentlicht das Oracle den kumulierten Wert der Station für das vereinbarte Zeitfenster im Netzwerk; der Smart Contract prüft, ob die Police gültig war, ob noch nicht gezahlt wurde und ob der Schwellenwert überschritten wurde, und veranlasst die Zahlung. Kommt der Wert nicht an, erhält die Police den Status „Daten ausstehend“, der sich von „keine Deckung“ unterscheidet, und geht in ein Prüfverfahren mit einer benannten verantwortlichen Person über. Der Veranstalter kann im Netzwerk nachprüfen, welcher Wert und welche Regel angewendet wurden.

Das Basisrisiko kommt im Verkaufsgespräch zur Sprache. Geht ein heftiges Gewitter über dem Gelände nieder und registriert die mehrere Kilometer entfernte Station 8 Liter, verliert der Veranstalter seine Einnahmen und erhält keine Zahlung. Der Assekuradeur mindert dieses Risiko, indem er eine nahe gelegene Station wählt, mehrere Auszahlungsstufen je nach Niederschlagsmenge anbietet oder zwei Stationen kombiniert, und erklärt es vor dem Verkauf schriftlich. Kein noch so gut programmierter Smart Contract ändert dieses Gespräch, und genau dieses Gespräch entscheidet, ob das Produkt verkauft und verlängert wird.

Mittel und Lizenz bleiben außerhalb des Codes

Dass ein Smart Contract eine Zahlung veranlasst, heißt nicht, dass er über das Geld verfügt. Wird die Leistung in Euro auf ein Bankkonto gezahlt, erteilt der Smart Contract eine Anweisung, die der Versicherer in seinem Zahlungssystem ausführt und mit seiner Buchhaltung abgleicht. Wird mit tokenisiertem Geld direkt aus dem Smart Contract gezahlt, muss jemand diese Mittel hinterlegen, und das im Netzwerk sichtbare Guthaben belegt nicht die Solvenz des Versicherers, die an seinen Rückstellungen und seinem Kapital gemessen wird. In beiden Fällen ist es ratsam, dass die Berechtigungen zum Pausieren und Aktualisieren des Smart Contracts oder zur Korrektur einer Zahlung bei einem Konto mitMulti-Signaturund benannten Verantwortlichen liegen, denn sie sind der Weg, einen Fehler zu korrigieren, und zugleich eine Konzentration von Befugnissen.

Auch die Lizenz ändert sich nicht. In der Europäischen Union bedarf die Aufnahme der Versicherungs- oder Rückversicherungstätigkeit nach derSolvabilität-II-Richtlinieeiner vorherigen Zulassung, und die Automatisierung der Zahlung ändert nichts daran, wer das Risiko trägt und wer gegenüber dem Versicherten haftet. Die EIOPA, die europäische Versicherungsaufsicht,beschrieb 2021die möglichen Vorteile von Blockchain und Smart Contracts, etwa weniger doppelte Prozesse und mehr Automatisierung, zusammen mit Herausforderungen bei Komplexität, Datenschutz und Cyberrisiko. Eine Agentur oder ein Insurtech, das das Produkt einführen will, tut dies gemeinsam mit einem zugelassenen Unternehmen, und der Code ist ein weiterer Baustein in dessen Kontrollsystem.

Was ein Smart Contract bei Versicherungen automatisiert, ist die parametrische Auszahlung, nicht die Nachfrage nach dem Produkt

Der Nutzen ist real, in einem klar abgegrenzten Bereich. Wenn der Schadenfall durch einen überprüfbaren Datenpunkt definiert ist, entfällt mit dem Smart Contract die Bearbeitung der Schadenmeldung, er zahlt, sobald der Datenpunkt verfügbar ist, und hinterlässt einen Nachweis, den der Versicherte prüfen kann: welcher Wert verwendet, welche Regel angewendet und wann gezahlt wurde. Bei Deckungen mit niedrigem Betrag und hoher Frequenz wie Flugverspätungen oder bei Deckungen, bei denen die schnelle Auszahlung das Wertversprechen ist, etwa bei Naturkatastrophen, kann dieser Unterschied die Entwicklung rechtfertigen.

Außerhalb dieses Bereichs liefert der Code Rückverfolgbarkeit und wenig mehr. Er verbessert keinen schlecht gewählten Index, ersetzt nicht die Begutachtung eines Schadens in der Schadenversicherung und verleiht keine Lizenz zum Versichern. Fizzy hat zudem gezeigt, dass eine korrekte automatische Auszahlung nicht genügt, wenn das Produkt weder Kunden noch Vertriebskanal findet. Ein aussagekräftiger Pilot misst die Zeit von der Verfügbarkeit des Datenpunkts bis zur Zahlung, die Fälle, die eine manuelle Prüfung erfordern, die Beschwerden wegen Basisrisiko und die Verlängerungsquote, jeweils im Vergleich zum selben Produkt ohne Blockchain.

Bei Metlabs entwickeln wir dieSmart Contractsund die Oracle-Anbindung parametrischer Produkte und beginnen mit der Definition des Index und der Ausnahmefälle. Wenn der Smart Contract in Produktion geht, dasSmart-Contract-Auditsprüft, ob der Code genau das umsetzt, was in der Police steht.