Mehr Korrektheit ist ein Anti-Feature

Im Abgleich eines neu aufgebauten Rechenwerks gegen ein gewachsenes Bestandssystem gibt es einen wiederkehrenden Moment: Die neue Rechnung ist mathematisch sauberer als die alte. Die Referenz führt das Deckungskapital ungerundet fort; das Altsystem schneidet den gespeicherten Vertragsstand seit Host-Zeiten nach jedem Jahr auf ganze Cent ab. Der Reflex liegt nahe, die sauberere Zahl als Fortschritt zu verbuchen – und die alte als Korrekturkandidaten. Für ein Prüfwerkzeug ist dieser Fortschritt ein Defekt. Ein nachrechnendes System bemisst sich nicht an der schönsten Zahl, sondern an der Deutbarkeit seiner Abweichungen – für die Modellwahl wurde das in dieser Reihe bereits begründet (Modell-Kongruenz). Dieser Text führt das Argument eine Ebene tiefer: in die Implementierungskonventionen, die in keinem Tarifwerk stehen und trotzdem seit Jahrzehnten die Werte des Bestands prägen. Die These: Wo die Prüffrage „reproduziert das neue System das bestehende?” lautet – in der Bestandsmigration, bei der Ablösung eines gewachsenen Referenz-Tools, im Abgleich gegen das Quellsystem –, ist mehr Korrektheit als stiller Default ein Anti-Feature: eine Eigenschaft, die wie ein Vorzug aussieht und den Zweck des Werkzeugs beschädigt. Der folgende Text begründet das in vier Thesen und rechnet an einer einzigen Abschneide-Konvention vor, was sie im Abgleich anrichtet.

1 · Nach dreißig Jahren ist das Verhalten der Vertrag

Ein Tarifwerk legt Rechnungsgrundlagen und Formeln fest. Es legt nicht fest, in welchem Format ein Bestandsführungssystem seine Zwischenstände speichert, an welcher Stelle des Rechenwegs gerundet wird, ob abgeschnitten oder kaufmännisch gerundet wird, in welcher Reihenfolge Teilbeträge verarbeitet werden. Diese Lücken füllt die Implementierung – irgendwann in den Achtzigern oder Neunzigern, selten dokumentiert, im geführten Bestand aber folgenreich. Denn der Bestand macht die Füllung verbindlich: Auf dem gespeicherten Deckungskapital stehen Standmitteilungen und Überschusszuteilungen; der Rückkaufswert hängt am berechneten Deckungskapital – für Neuverträge im Grundsatz über § 169 Abs. 3 VVG, der ihn als das mit den Rechnungsgrundlagen der Prämienkalkulation berechnete Deckungskapital definiert [1], für die Bestände der Host-Ära über den genehmigten Geschäftsplan. Ausgezahlt wurde er, vertragsindividuell und centgenau, auf Basis dessen, was das System tatsächlich gerechnet hat.

Die Softwaretechnik hat dafür einen Namen. Hyrum’s Law fasst die Erfahrung großer Codebasen zusammen: Bei genügend Nutzern einer Schnittstelle ist es gleichgültig, was der Vertrag zusichert – jedes beobachtbare Verhalten wird zur Abhängigkeit [2]. Der Lebensversicherungsbestand braucht dafür nicht einmal adaptive Nutzer: Hier bindet die Zahlungs- und Bilanzhistorie das beobachtete Verhalten – Jahr für Jahr, Vertrag für Vertrag, über Jahrzehnte. Eine Rundungskonvention, die nie im Geschäftsplan stand, ist nach dreißig Jahren Bestandsführung Teil des gelebten Solls – nicht weil sie richtig wäre, sondern weil auf ihr gezahlt, deklariert und bilanziert wurde.

Die dokumentierte Migrationspraxis zieht daraus die Konsequenz. Der DAV-Ergebnisbericht zur Bestandsmigration nennt als eine wesentliche Forderung an die Übernahme in ein Zielsystem, dass sich Leistungen, Beiträge und Deckungskapitale des Kunden nicht unangemessen ändern; das Ziel des aktuariellen Migrationscontrollings ist die dauerhafte Korrektheit der migrierten Verträge, geprüft über Toleranzgrenzen, deren obere und untere Äste separat betrachtet werden – zum Beispiel dürfen Beiträge nicht steigen und Leistungen nicht sinken [3]. Der Maßstab ist durchgängig die Kontinuität des geführten Bestands, nicht die Nähe zu einer idealisierten Neurechnung. „Richtiger als das gelebte System” ist in dieser Prüffrage kein erreichbares Prädikat; erreichbar ist nur „anders, als der Bestand geführt wurde” – und anders heißt hier: erklärungsbedürftig.

Eine Grenze gehört an den Anfang, nicht in die Fußnote: Verbindlich wird nur die Konvention, die das dokumentierte Soll offen lässt. Wo das Verhalten des Altsystems dem Geschäftsplan widerspricht, ist es kein Gewohnheitsrecht, sondern ein Befund – wie damit umzugehen ist, klärt These 3.

2 · Die richtigere Rechnung erzeugt Differenz ohne Befund

Was eine nicht nachgebildete Konvention kostet, lässt sich beziffern. Die beobachtete Abweichung je Vertrag sei wie im Kongruenz-Argument zerlegt:

Implementierungsfehler plus Konventions-Differenz (die Referenz selbst sei fehlerfrei; ihr eigener Fehleranteil wäre ein dritter Term). Eine Referenz, die „richtiger” rechnet als das gewachsene System, setzt $\delta_{\mathrm{konv}}$ bewusst ungleich null. Sie tut das nicht aus Nachlässigkeit, sondern aus Überzeugung – und genau deshalb systematisch, auf jedem Vertrag.

Der Abgleich hat jetzt nur zwei schlechte Optionen. Exakt vergleichen – dann weicht ab mittlerer Laufzeit praktisch jeder Vertrag ab, und das Fehlersignal ertrinkt in Alarmen, die alle dieselbe Nicht-Ursache haben. Oder ein Toleranzband spannen, das die Konventions-Differenz schluckt – ex ante und über alle Laufzeiten heißt das: an der hergeleiteten Schranke ansetzen, hier gut 0,50 € – und damit die Blindzone öffnen, die in dieser Reihe bereits vermessen wurde: Unentdeckt bleibt jeder Fehler, solange $|\delta_{\mathrm{impl}} + \delta_{\mathrm{konv}}|$ innerhalb der Toleranz liegt. Der Ergebnisbericht benennt diese Falle selbst: Zu großzügig festgelegte Toleranzgrenzen drohen systematische Fehler der Tarifabbildung oder des Mappings zu verdecken [3]. Der Unterschied zum Modellbruch ist dabei der entscheidende: Diese Blindzone ist vollständig selbst gewählt – sie lässt sich durch Nachbildung der Konvention auf null bringen, ohne das Rechenmodell anzutasten. Ein Band gegen selbst erzeugtes Rauschen ist keine Prüfschärfe; es ist der laufende Preis dafür, eine Zahl zu verteidigen, die niemand bestellt hat.

Die dritte Option liegt jenseits des Abgleichs: die alte Rechnung „korrigieren”. Sie betrifft nicht mehr das Prüfwerkzeug, sondern das System, das den Bestand künftig führt – und sie ist die teuerste: Ein Zielsystem, das den Bestand mit der saubereren Konvention fortführt, ändert reale Vertragswerte – und steht damit vor der Korrekturmechanik der Migrationspraxis: Beitrags- oder Deckungskapitalkorrektur, nur in geringem Umfang akzeptabel, das Absenken des Deckungskapitals besonders begrenzt, weil an ihm Rückkaufswerte und Überschusszuteilungen hängen [3]. Eine Rundungsbereinigung ist möglich – aber sie ist eine bewusste Änderung der Tarifabbildung mit Gremienbeschluss und Ausweis, keine Nebenwirkung einer eleganteren Implementierung. Wer sie als Nebenwirkung einführt, hat nicht besser gerechnet, sondern ungefragt den Bestand verändert.

3 · Emulation ist Konfiguration, nicht Kopie

Der Ausweg ist, die Konvention nachzubilden – aber kontrolliert, und an diesem Wort hängt die gesamte Beweislast. Denn dieselbe Reihe, die hier Emulation empfiehlt, hat als Regel aufgestellt: Konventionen kommen aus dem dokumentierten Soll, nicht aus dem Code des Prüflings – eine Referenz, die Rechenwege zurückliest, baut Fehler per Konstruktion nach. Beide Sätze bestehen nebeneinander, weil zwischen Kopie und Emulation ein Dokument liegt. Und dieser Text präzisiert den vorigen: Die dort geforderte exakte Vergleichbarkeit – auf die definierten Stellen runden, dann $\varepsilon = 0$ – ist gegen ein gewachsenes System erst erreichbar, nachdem dessen ungeschriebene Konventionen erhoben und ins Soll überführt sind. Kongruenz endet nicht beim Rechenmodell; sie reicht bis in die letzte Implementierungskonvention.

Kontrolliert heißt: erhoben, benannt, abgenommen. Die Softwaretechnik liefert das Verfahren für den ersten Schritt: Characterization Tests – Tests, die das tatsächliche Verhalten eines bestehenden Systems fixieren, nicht das gewünschte [4]. Ins Aktuariat übersetzt: Je Tarifgeneration werden Testfälle am Altsystem durchgerechnet, bis die Konvention isoliert ist – abgeschnitten oder gerundet, an welcher Stelle des Rechenwegs, auf wie viele Stellen. Das Ergebnis ist kein Code-Import, sondern ein Satz benannter Eigenheiten mit Fundstelle und Zahlenbeleg. „Begründet” heißt dabei dreierlei, und keines davon ist der Gremienstempel: Die Eigenheit wirkt konsistent über den Teilbestand (sie ist reproduzierbar charakterisierbar), sie ist fachlich deutbar (als Konvention ihrer Plattform und Ära erkennbar – Festkomma-Abschneiden ist eine Signatur, kein Rätsel), und sie ist in den geführten Werten tatsächlich gelebt (die Wertehistorie trägt sie). Was eines der drei verfehlt, ist keine Konvention, sondern ein Befund. Die Erhebung selbst durchläuft dann dieselbe Disziplin wie jede andere Soll-Änderung – der Ergebnisbericht sieht Genehmigungs- und Dokumentationsprozesse gegebenenfalls schon dann ausgelöst, wenn sich nur technische Bestandsführung und Rundungsvorschriften ändern; die Akzeptanz legen entscheidungsbefugte Gremien fest, in der Regel unter Beteiligung des Verantwortlichen Aktuars [3]. Was diese Prüfung passiert hat, ist Teil des dokumentierten Solls geworden – so prüfbar, so versioniert und so revidierbar wie das Tarifwerk selbst.

Implementiert wird die Eigenheit als Schalter, nicht als Sitte. Der Unterschied zwischen einer zurückgelesenen und einer emulierten Konvention liegt im Artefakt: Die zurückgelesene steckt unsichtbar im Rechenweg, niemand kann später sagen, was alles übernommen wurde. Die emulierte ist ein expliziter Konfigurationspunkt – je Tarif und je Rechenschritt: Rundungsmodus, Stellenzahl, Rundungszeitpunkt –, sichtbar im Rechen-Nachweis, dokumentiert mit ihrer Begründung, abschaltbar für den Norm-Modus. Ein Emulations-Schalter, den niemand begründet hat, ist ein kopierter Fehler. Ein begründeter ist eine dokumentierte Soll-Konvention, die zufällig im Altsystem zuerst stand.

Der Preis, auch hier beim Namen genannt. Jede emulierte Eigenheit ist eine Stelle, an der der Abgleich das Altsystem nicht mehr widerlegen kann – die Referenz rechnet dort per Konstruktion gleich. Die Prüflast wandert in die Erhebung, und deren Testfall-Abdeckung ist endlich. Deshalb sind zwei Disziplinen nicht verhandelbar: Der Schalter wird eng geschnitten – je Konvention und Tarifgeneration, nie als pauschaler „Kompatibilitätsmodus” –, und das Delta zwischen Emulations- und Normrechnung läuft als Kennzahl mit. Wächst es anders als charakterisiert, ist die Erhebung überholt – die emulierte Stelle bleibt so unter Beobachtung, statt hinter dem Schalter zu verschwinden.

Und der echte Altfehler? Die Erhebung fördert neben den Konventionen, die das Soll offen ließ, auch Verhalten zutage, das dem Soll widerspricht. Für Letzteres ist die Emulation nicht zuständig; es wandert als Befund in denselben Gremienprozess, mit zwei sauberen Ausgängen: bewusste Korrektur über die dafür vorgesehene Mechanik – oder bewusst beibehaltene Abweichung mit Ausweis [3]. Der eine Ausgang, den es nicht geben darf, ist der stillschweigende: weder das stille Fortschreiben des Fehlers durch Kopie noch sein stilles Wegkorrigieren durch eine Referenz, die es besser weiß.

4 · Das Toleranzprofil ist die Restgröße – und die Norm-Differenz eine Kennzahl

Emulation macht Toleranz nicht überflüssig; sie weist ihr den richtigen, kleinen Platz zu. Nach der Nachbildung der erhobenen Eigenheiten bleibt ein Rest von zweierlei Art: Verhalten, das sich nicht als Regel fassen lässt, weil es über Code-Zweige und Wartungsstände inkonsistent gewachsen ist – dort wird nicht geschaltet, sondern je Teilbestand neu charakterisiert oder eben toleriert –, und Differenzen, die an der konkreten Auswertungsreihenfolge hängen, etwa die Fließkomma-Zwischenergebnisse eines gewachsenen Tabellen-Rechenwerks. Erst für diesen Rest ist das Toleranzprofil das richtige Instrument. Seine Form beschreibt der Ergebnisbericht präzise: je Wert beziehungsweise Wertetyp festgelegt, absolut und relativ kombiniert, obere und untere Grenzen separat [3]. Seine Herleitung ist die Konsequenz dieses Textes: aus der quantifizierten Resteigenheit, nicht als globale Einstellung – das Profil dokumentiert, was die Prüfung bewusst nicht sieht; ein Band, dessen Breite niemand herleiten kann, dokumentiert nur, dass niemand nachgesehen hat.

Der Bericht kennt sogar die feinste Stufe dieser Idee. Als ein mögliches Vorgehen zur Vorbereitung der produktiven Freigabe beschreibt er, erklärte, akzeptierte Abweichungen pro Vertrag, Prüfwert und Zeitpunkt zu speichern; beim nächsten Controllinglauf wird die bekannte Abweichung berücksichtigt und nicht erneut als Toleranzverletzung ausgewiesen [3]. Das ist Emulation auf Datenebene: Die bekannte Differenz wird beziffert abgezogen statt pauschal toleriert – das Band bleibt eng, das Signal bleibt scharf.

Was aus der Norm-Rechnung wird. Sie fliegt nicht heraus – sie wechselt die Rolle: von der stillschweigenden Voreinstellung zum ausgewiesenen Vergleichsmodus. Ein Rechenwerk, das dieselbe Größe emuliert und normkonform rechnen kann, macht die Konventions-Differenz je Vertrag zur Kennzahl – im Rechenbeispiel: +0,23 € auf dreißig Jahre, deterministisch, tarif- und laufzeitaufgelöst. Genau diese Quantifizierung verfahrensbedingter Unterschiede – etwa maximale und durchschnittliche Abweichung, geeignet dokumentiert – führt der Ergebnisbericht ohnehin als Aufgabe der fachlichen Konzeption [3]; und sie ist die Entscheidungsgrundlage, auf der ein Gremium eine Eigenheit mitnehmen oder bereinigen kann, bevor sie im Abgleich als Rauschen auftaucht. Damit schließt sich der Bogen zum Titel: Mehr Korrektheit als stiller Default zerstört das Prüfsignal – mehr Korrektheit als bezifferte, ausgewiesene Differenz ist genau die Kennzahl, die ein nachrechnendes System liefern soll. Emulieren, exakt vergleichen, die Norm-Differenz beziffern: In dieser Reihenfolge wird aus der schöneren Zahl ein Werkzeug statt eines Störsenders.

Was dieser Text Emulation nennt, ist in unserer Projektpraxis seit 2013 wiederkehrende Arbeit: gewachsene Rechenwerke ablösen, ihre Eigenheiten erheben, die Differenz ausweisen. Wie wir das in Migrationsprojekten aufsetzen, steht auf der Seite Bestandsmigration.