Unabhängig – aber im richtigen Modell

Bestandsmigration, Produkteinführung, laufende Qualitätssicherung: Aktuarielle Software wird dort geprüft, wo sie sich ändert. Für den größten dieser Anlässe – die Migration eines Lebensversicherungsbestands – hat die DAV das Controlling zuletzt in einem eigenen Ergebnisbericht beschrieben; sein erklärtes Ziel: die dauerhafte Korrektheit der migrierten Verträge, sein Instrument: die Abweichungsanalyse mit Toleranzgrenzen – dort als Abgleich des Quell- gegen das Zielsystem [1]. Dieselbe Grundfigur – zwei Systeme, eine Differenz je Vertrag – trägt die schärfste Form der Prüfung: die Gegenrechnung durch einen unabhängigen Referenzrechner, dessen Werte Vertrag für Vertrag gegen das Bestandsführungssystem gehalten werden. Wie belastbar diese Prüfung ist, wird dabei meist an einem Kriterium festgemacht: an der Unabhängigkeit der Referenz. Getrenntes Team, getrennte Codebasis, keine geteilte Rechenlogik – dann, so die Überzeugung, trägt der Abgleich.

Unabhängigkeit ist notwendig. Aber sie ist nur die halbe Voraussetzung. Die andere, chronisch unterschätzte, ist Modell-Kongruenz: Referenz und Prüfling müssen im selben Rechenmodell rechnen – Kommutationskalkül gegen Kommutationskalkül, Zustandsmodell gegen Zustandsmodell. Die Gegen-Konstellation ist kein Lehrbuch-Konstrukt: Sie entsteht, wo eine für Projektionszwecke gebaute Modellplattform zur Referenz für einen Kommutationskern erklärt wird, wo nach einer Migration die Werkzeuglandschaft vereinheitlicht wird – oder wo ein zustandsbasiert rechnendes Standardwerkzeug die Referenz für einen kommutationsbasiert rechnenden Bestand liefern soll. Dann wird jede beobachtete Abweichung ein Gemisch aus Implementierungsfehler und Modelldifferenz, das sich nicht mehr sauber trennen lässt. Der Modellbruch ist dabei nur der größte Fall einer allgemeinen Klasse: Dieselbe Mechanik greift, sobald irgendeine rechnungsrelevante Konvention zwischen Referenz und Prüfling abweicht – Diskretisierung der Zeitachse, Rundungsweg, Altersdefinition, die Verknüpfung der Ausscheideordnungen. Was sich ändert, ist allein die Größe der Modelldifferenz, nicht ihre Natur. Der folgende Text begründet das in vier Thesen und rechnet an einem Beispiel vor, was ein Modellbruch die Prüfschärfe kostet.

1 · Das Produkt eines Referenzrechners ist die deutbare Abweichung

Der Wert eines Referenzrechners liegt nicht in der zweiten Zahl, die er liefert, sondern in der Differenz zwischen dieser Zahl und dem Produktivwert – und diese Differenz ist nur so viel wert, wie sie sich deuten lässt.

Die Rolle im Kontrollrahmen. Die Frage, die der aktuarielle Test beantwortet, hat im deutschen Aufsichtsrecht einen benannten Verantwortlichen: Der Verantwortliche Aktuar hat zu gewährleisten, dass bei der Berechnung der Prämien und Deckungsrückstellungen die einschlägigen Grundsätze eingehalten werden [2] – und wer das verantwortet, braucht ein Prüfmittel, dessen Befunde er vertreten kann. International firmiert dasselbe Prinzip als „Effective Challenge”: kritische Prüfung durch fachkundige Instanzen mit ausreichender Unabhängigkeit; der Vergleich mit anderen Modellen – Benchmarking – ist eines der anerkannten Prüfmittel [3].

Der entscheidende Unterschied. Benchmarking im Sinne der Modellvalidierung vergleicht zwei Schätzungen: Liegen zwei Modelle nahe beieinander, stützt das die Plausibilität beider. Der aktuarielle Test stellt eine härtere Frage – nicht „sind die Werte plausibel?”, sondern „setzt der produktive Kern das Tarifwerk exakt um?”. Ein Tarifwerk ist kein Schätzgegenstand: Prämie und Deckungskapital sind auf definierte Stellen bestimmt, jede Abweichung hat eine Ursache. Deshalb genügt es nicht, dass die Referenz „auch eine Zahl” liefert. Eine Differenz von null bestätigt; jede andere Differenz erzeugt eine Bringschuld – sie muss einer Ursache zugeführt werden: Implementierung, Stand der Rechnungsgrundlagen, Testfall-Konstruktion. Was offen bleibt, ist kein Ergebnis, sondern Restrisiko plus Klärungsaufwand.

Die Messlatte für einen Referenzrechner ist damit nicht, wie viel er rechnet, sondern wie eindeutig seine Abweichungen sprechen. Genau an dieser Messlatte entscheidet sich die Modellfrage.

2 · Der Referenzrechner ist kein Voter

Die Unabhängigkeits-Doktrin hat eine empirische Geschichte, und die ist unbequemer, als ihr Ruf vermuten lässt.

Der klassische Befund. Die Idee, Verlässlichkeit durch unabhängige Mehrfach-Implementierung zu erzeugen, wurde in der Softwaretechnik als N-Version-Programming systematisch untersucht. Das maßgebliche Experiment: 27 Versionen desselben Programms, unabhängig entwickelt an zwei Universitäten, eine Million Testfälle. Die Versionen waren einzeln ausgesprochen zuverlässig – aber gemeinsame Ausfälle traten weit häufiger auf, als unter Unabhängigkeit zu erwarten wäre; die Unabhängigkeitsannahme wurde auf dem 99-%-Niveau verworfen [4]. Die Autoren beschränken diesen Befund ausdrücklich auf ihr Experiment – die Erklärung, die er nahelegt, ist gleichwohl unbequem: An denselben schweren Stellen entstehen dieselben Fehler, auch bei getrennter Entwicklung.

Der Übertrag ins Aktuariat. Zwei Teams, die dasselbe missverständlich formulierte Tarifwerk lesen, implementieren dieselbe Fehldeutung zweimal – etwa eine mehrdeutige Rundungsvorschrift oder eine unklare Altersdefinition. Die Differenz der beiden Systeme ist dann null, und der Abgleich bestätigt einen Fehler. Unabhängigkeit reduziert die zufälligen, voneinander unabhängigen Fehler – gegen die gemeinsam gedachten ist sie machtlos. Auch die Aufsichtsleitlinie führt die Abhängigkeit mehrerer Modelle von gemeinsamen Annahmen, Daten und Methoden als eigenes Aggregatrisiko [3].

Der naheliegende Fehlschluss. Wer diesen Befund ernst nimmt, könnte folgern: dann eben maximale Diversität – anderes Team, andere Sprache, und gleich auch ein anderes Rechenmodell. Für N-Version-Systeme wäre das konsequent, denn dort entscheidet ein Voter per Mehrheit über den Ausgabewert; jede Quelle zusätzlicher Diversität senkt das Risiko gleichgerichteter Ausfälle. Der Referenzrechner aber hat keinen Voter. Er überstimmt niemanden, er produziert Differenzen, die einzeln fachlich eingeordnet werden müssen. Diversität in der Implementierung ist deshalb sein Mittel – Diversität im Rechenmodell dagegen zerstört das Signal, das er messen soll.

Der Preis, beim Namen genannt. Wer Modell-Kongruenz fordert, verzichtet darauf, gemeinsame Blindstellen beider Systeme über Modell-Diversität aufzudecken. Dieser Tausch ist im aktuariellen Test richtig, denn er prüft die Umsetzung eines definierten Solls – nicht dessen Angemessenheit. Gegen die gemeinsam gelesene Fehldeutung des Tarifwerks hilft kein Modellbruch, sondern Disziplin an anderer Stelle: Testfälle, die aus dem Text der Vorschrift konstruiert werden statt aus dem Code, und Stichproben, die gegen den Geschäftsplan statt gegen das System gelesen werden. Und ob die Rechnungsgrundlagen selbst angemessen sind, ist eine eigene Prüfung mit eigenen Instrumenten – sie dem Nachrechnungs-Abgleich unterzuschieben, verwischt beide.

3 · Im fremden Modell wird die Abweichung unlesbar

Die deutsche Personenversicherungsmathematik kennt zwei Rechenwege zu denselben Größen: das klassische Kommutationskalkül, das Barwerte über tabellierte Hilfsgrößen aus der Ausscheideordnung bildet, und das Markov-Zustandsmodell, das den Vertrag als Zustandsraum mit Übergangswahrscheinlichkeiten beschreibt. Beide gehören zum Standardrepertoire – das Standardwerk von Milbrodt und Helbig entwickelt die Personenversicherung durchgängig im Rahmen markovscher Sprungprozesse und behandelt die Berechnung mittels Kommutationszahlen als eigene, darauf bezogene Rechentechnik [5]. Auf dem Papier, bei identischen Rechnungsgrundlagen und identischer Diskretisierung, führen beide Wege zum selben Erwartungswert.

Implementiert sind sie nie identisch. Reale Rechenkerne unterscheiden sich dort, wo das Modell Konventionen setzt: in der Rundung tabellierter Zwischengrößen gegenüber rekursiv fortgeschriebenen Zustandswerten, in der Diskretisierung der Zeitachse, in der Behandlung unterjähriger Zahlweise. Das klassische Kalkül nähert unterjährig zahlbare Renten typischerweise aus der jährlichen Rechnung – nach dem bekannten Muster $\ddot{a}^{(m)} \approx \ddot{a} - (m-1)/(2m)$, einer rechnungsmäßigen Annahme über die Verteilung der Zahlungen im Jahr. Ein monatlich rechnendes Zustandsmodell braucht diese Korrektur nicht – es verlagert die Annahme in die Ableitung seiner monatlichen Übergangswahrscheinlichkeiten aus der jährlichen Tafel. Die Konvention verschwindet nie, sie sitzt nur an anderer Stelle. Genau deshalb differieren zwei Systeme verschiedener Modellwelten auch dann, wenn beide fehlerfrei sind: nicht als Fehler, sondern als Eigenschaft – klein, aber tarif-, alters- und laufzeitabhängig.

Was der Abgleich davon sieht. Je Vertrag beobachtet der Abgleich nur eine Zahl: die Abweichung $\Delta$, zerlegbar in den Implementierungsfehler $\delta_{\mathrm{impl}}$ und die Modelldifferenz $\delta_{\mathrm{mod}}$ (die Referenz selbst sei fehlerfrei – ihr eigener Fehleranteil wäre ein dritter Term). Im kongruenten Modell ist $\delta_{\mathrm{mod}}$ strukturell null – $\Delta$ ist ein reines Fehlersignal, und es trägt sogar eine Signatur: Eine je Vertrag konstante Abweichung deutet auf einen systematischen Rechenschritt, eine altersabhängige auf die Tafel-Anbindung, eine laufzeitabhängige auf die Diskontierung. Im inkongruenten Modell liegt unter jedem Vertrag ein Teppich aus Modelldifferenzen. Der Abgleich braucht dann ein Toleranzband. Toleranzgrenzen sind im Migrations-Controlling, dem Abgleich des Quell- gegen das Zielsystem, etablierte und sinnvolle Praxis – je Wertetyp festgelegt, absolut und relativ kombiniert [1]: Dort trennen sie wesentliche von unwesentlichen Abweichungen. Im inkongruenten Modell-Abgleich leistet dasselbe Band etwas anderes – es deckelt das Modellrauschen und wird damit zur Blindzone der Prüfung.

Auch die Aggregatsicht rettet den Abgleich nicht. Der naheliegende Einwand lautet: Über den Bestand verschiebt ein systematischer Fehler von 0,23 € die Verteilung der $\Delta$, im Histogramm müsste er trotz Toleranzband sichtbar sein. Nur: $\delta_{\mathrm{mod}}$ ist weder mittelwertfrei noch strukturlos – die Modelldifferenzen hängen selbst an Tarif, Alter und Laufzeit und tragen damit genau die Signaturen, an denen man Fehler erkennen wollte. Ein Shift oder ein Cluster in der $\Delta$-Verteilung kann ebenso gut Modelldifferenz sein; die Konfusion verschwindet nicht, sie wandert von der Einzelfall- auf die Verteilungsebene. Im kongruenten Abgleich gilt das Umgekehrte: Dort ist jede Struktur der $\Delta$-Verteilung per Konstruktion ein Fehlersignal.

Das Toleranzband ist damit keine Feinheit der Testkonfiguration, sondern das operative Eingeständnis der Modellinkongruenz: Seine Breite beziffert, was die Prüfung nicht mehr sieht. Und der Anreiz wirkt nur in eine Richtung – fehlerfreie Verträge wie C laufen dauerhaft dicht an der Schwelle, und jeder Beinahe-Alarm spricht fürs Weiten des Bandes, keiner fürs Engen.

4 · Kongruenz ist eine Architektur-Entscheidung

Unabhängigkeit und Kongruenz stehen nicht im Widerspruch – sie gehören nur auf verschiedene Ebenen. Unabhängigkeit gehört in die Implementierung: getrenntes Team, getrennte Codebasis, eigene Testfall-Konstruktion, kein geteilter Rechenweg. Kongruenz gehört ins Rechenmodell: gleiches Kalkül, gleiche Diskretisierung, gleiche Rundungskonventionen – als explizite, dokumentierte Konfiguration statt als impliziter Nebeneffekt. Entscheidend ist dabei die Herkunft dieser Konventionen: Sie kommen aus dem dokumentierten Soll – Geschäftsplan, technische Berechnungsgrundlagen, Tarifwerk –, nicht aus dem Code des Prüflings. Eine Referenz, die Rundungswege aus dem Produktivsystem zurückliest, baut dessen Fehler per Konstruktion nach; eine Referenz, die das dokumentierte Soll im selben Modell eigenständig implementiert, kann sie finden. Erst diese Kombination macht den Abgleich scharf: „auf die definierten Stellen runden, dann exakt vergleichen” ist nur im kongruenten Modell eine sinnvolle Vorschrift.

Daraus folgen drei praktische Regeln.

Erstens: Die Modellwahl der Referenz folgt dem Prüfling – pro Tarifgeneration, nicht pro Werkzeug. Ein Bestand, dessen Kern kommutationsbasiert rechnet, braucht eine kommutationsbasierte Referenz; ein zustandsbasiert rechnender Kern eine zustandsbasierte.

Zweitens: Kongruenz heißt nicht, das Zustandsmodell zu verwerfen. Für Aufgaben, die keine Nachrechnung eines definierten Solls sind – Produktentwicklung, Profit-Testing, Projektionen –, ist es häufig das angemessene Werkzeug. Das ist eine andere Aufgabe mit eigenem Maßstab, keine zweite Meinung im selben Abgleich.

Drittens: Wo Kongruenz vorübergehend nicht herstellbar ist – etwa in Migrationsphasen, in denen eine Referenz gegen den alten und den neuen Kern zugleich rechnet und beide verschiedenen Konventionen folgen –, gehört das Toleranzband je Tarif aus den Modelldifferenzen hergeleitet und dokumentiert, nicht als globale Einstellung gepflegt. Ein pauschales Band ist keine Prüfschärfe, sondern deren Abwesenheit mit Zahlenwert.

Die Unabhängigkeit einer Referenz steht in jeder Anforderungsliste; die Modellfrage wird oft erst gestellt, wenn die ersten Abweichungslisten unerklärt bleiben. Dabei entscheidet erst das Zusammenspiel beider, ob ein Abgleich Fehler findet oder Deutungsarbeit erzeugt. Referenzrechner-Arbeit zieht sich seit 2013 durch unsere Projektpraxis – vom Neuaufbau bis zur punktuellen Validierung; die Haltung dieses Textes ist aus ihr gewachsen. Einen Überblick gibt die Seite Referenzrechner.