Den Rechenkern komponiert man

Ein Vertrag besteht aus einem Hauptvertragsteil und einer späteren Erhöhung. Für die Beitragsfreistellung liegen die Rückkaufswerte beider Vertragsteile vor; beide Einzelrechnungen sind geprüft. Trotzdem kann die beitragsfreie Rente falsch sein: wenn der nächste Rechenschritt die Werte zusammenfasst und dabei die Zuordnung zu den jeweils anzuwendenden Rechnungsgrundlagen verliert. Der Fehler steckt dann weder in den Rückkaufswerten noch in der Umwandlung für sich genommen. Er steckt in ihrer Verbindung.

Der DAV-Ergebnisbericht zur Bestandsmigration benennt ein verwandtes Problem: Selbst gleichnamige Geschäftsvorfälle können in Quell- und Zielsystem fachlich verschieden sein [1]. Ein Name bezeichnet eine Bearbeitung, noch keinen eindeutigen Rechenweg. Für einen Referenzrechner folgt daraus eine Architekturaufgabe: Er muss die Übergaben zwischen den Rechenschritten ebenso ausdrücklich beschreiben wie die Formeln. Dieser Text entwickelt dafür eine Konstruktion aus vier Teilen: benannte Zwischenergebnisse, gekapselte Rechenmodule, geprüfte Verkettungen und einen Vergleich, der Änderungen sichtbar macht. Die festgelegte Folge der Rechenschritte eines Geschäftsvorfalls heißt dabei, wie in der Softwaretechnik üblich, Pipeline.

1 · Zwischen zwei Formeln wird mehr übergeben als ein Betrag

Eine Formel kann richtig angewendet werden und trotzdem den falschen Wert liefern, wenn ihre Eingabe eine andere Bedeutung hat als vorgesehen. „Deckungskapital“ allein beschreibt eine Übergabe nicht ausreichend. Es fehlen mindestens der Vertragsteil, der Stichtag, die verwendeten Rechnungsgrundlagen und der Bearbeitungsstand. Ein Wert vor der Fortschreibung und ein Wert danach können denselben Feldnamen und dieselbe Einheit tragen.

Die Erhöhung macht diese Lücke greifbar. Betrachtet sei eine klassische Rentenversicherung, deren Hauptvertragsteil und spätere Erhöhung als getrennte Vertragsteile mit unterschiedlichen Rechnungsgrundlagen geführt werden. Für das folgende Beispiel sei tariflich festgelegt, dass bei einer Beitragsfreistellung jeder Vertragsteil für sich in eine beitragsfreie Rente umgewandelt wird. Wie der Rückkaufswert je Vertragsteil zu bilden ist, welche Abzüge gelten und welche Garantien bestehen, regeln die Vorschriften dieses Tarifs. Die Überschussbeteiligung bleibt im Beispiel außer Betracht. Es behauptet keine allgemeine Beitragsfreistellungsformel.

Unter dieser Voraussetzung muss die Rechnung die Vertragsteile bis zur Rente getrennt halten. Sie bildet je Vertragsteil den Rückkaufswert, wandelt ihn mit den Rechnungsgrundlagen dieses Vertragsteils in eine beitragsfreie Rente um und fasst erst danach zusammen. Bei gleichem Rentenbeginn, gleichem Zahlungsrhythmus und gleichem Leistungsumfang, etwa bei Rentengarantiezeit und Todesfallleistung, lassen sich die Renten addieren. Erst an dieser Summe prüft der vorausgesetzte Tarif Regeln des Gesamtvertrags, etwa eine Mindestleistung: Wird sie unterschritten, entsteht keine beitragsfreie Rente, ausgezahlt wird der Rückkaufswert. Andernfalls ist die Summe die ausgewiesene Gesamtrente. Werden dagegen schon die Rückkaufswerte summiert, reichen der Gesamtbetrag und die Rechnungsgrundlagen nur eines Vertragsteils nicht mehr aus: Die Information, welcher Teil des Betrags mit welchen Grundlagen umzuwandeln ist, ist verloren. Eine gemeinsame Umwandlung wäre nur dann gleichwertig, wenn sie diese Zuordnung auf andere Weise erhält oder ihre Entbehrlichkeit fachlich nachgewiesen ist. Auch nach der Summenbildung bleiben die Vertragsteile im Vertragsstand erhalten, weil im vorausgesetzten Tarif spätere Geschäftsvorfälle sie wieder einzeln brauchen.

Das ist eine Frage nach der Bedeutung der übergebenen Werte, nicht nach dem Werkzeug. Auch ein Programm kann beide Vertragsteile zu früh zusammenfassen; auch eine Excel-Datei kann sie sauber getrennt halten. Schwierig wird die Prüfung, wenn die Bedeutung nur aus Zellpositionen, globalen Variablen oder dem Wissen des ursprünglichen Autors hervorgeht. Dann muss der Prüfer die gesamte Rechnung rekonstruieren, um eine einzelne Übergabe zu verstehen. Der Architekturvorschlag lautet deshalb: Zwischen zwei Rechenschritten steht ein benanntes Zwischenergebnis, das alle Angaben trägt, die der Folgeschritt benötigt.

Wie fein die Vertragsteile zu trennen sind, ist selbst eine fachliche Entscheidung. Der DAV-Bericht verlangt im Zusammenhang mit übertragenen Garantiewerten die Klärung, auf welcher Vertragsebene sie bereitgestellt und bei späteren Geschäftsvorfällen berücksichtigt werden [1]. Daraus folgt keine allgemeingültige Gliederung. Für den Referenzrechner folgt die Pflicht, seine gewählte Gliederung offenzulegen: Was gehört zum Gesamtvertrag, was zur Haupt- oder Zusatzversicherung, was zur Erhöhung? Eine technisch bequeme Zusammenfassung ist noch keine fachlich zulässige.

2 · Die Pipeline ist explizit, die Rechenmodule sind gekapselt

Eine Pipeline trennt zwei Entscheidungen, die in einem langen Makro ineinanderliegen: was ein Rechenschritt tut und in welcher Verbindung er für einen bestimmten Geschäftsvorfall verwendet wird. Die erste Entscheidung gehört in ein geprüftes Rechenmodul. Die zweite lässt sich als eigene, versionierte Pipeline-Definition beschreiben. Für die Beitragsfreistellung aus These 1 könnte sie so aussehen:

pipeline: beitragsfreistellung
version: 3
schritte:
  - name: rueckkaufswert
    modul: rueckkaufswert@2.1
    je: vertragsteil
  - name: grundlagen
    modul: rechnungsgrundlagen@1.0
    je: vertragsteil
  - name: beitragsfreie_rente
    modul: umwandlung_beitragsfrei@2.0
    je: vertragsteil
    eingabe: [rueckkaufswert, grundlagen]
  - name: summe_renten
    modul: summe_renten@1.0
    eingabe: beitragsfreie_rente
  - name: ergebnis
    modul: mindestleistung@2.0
    eingabe: [summe_renten, rueckkaufswert]

Die Definition enthält keine Formel. Sie legt fest, welche Rechenmodule in welcher Version vorkommen, welche Ergebnisse ein Schritt als Eingabe erhält und auf welcher Ebene er arbeitet. je: vertragsteil heißt: Der Schritt läuft für jeden Vertragsteil einzeln. Die Umwandlung erhält also den Rückkaufswert und die Rechnungsgrundlagen desselben Vertragsteils; erst summe_renten fasst zusammen. Der letzte Schritt prüft die Mindestleistung und braucht dafür neben der Summe auch die Rückkaufswerte, weil er bei Unterschreiten diese auszahlt. Ein Programm liest die Definition, ruft die Module in dieser Reihenfolge auf und reicht die benannten Ergebnisse weiter. Die Frage aus These 1, ob vor oder nach der Umwandlung summiert wird, steht damit in der Reihenfolge und den Eingaben der Schritte. Ein Aktuar kann sie lesen, ohne den Programmcode der Module zu kennen.

Das ist keine Aufforderung, jede Formel zum eigenen Modul zu machen. Parnas hat den Einwand gegen eine bloße Zerlegung nach Verarbeitungsschritten bereits 1972 formuliert: Sinnvolle Modulgrenzen kapseln Entwurfsentscheidungen, statt lediglich die Kästen eines Flussdiagramms nachzubauen [2]. Eine Pipeline, deren Schritte alle dieselbe veränderliche Datentabelle kennen müssen, gewinnt durch die neue Darstellung wenig. Die Abhängigkeiten bleiben bestehen; sie haben nur Namen erhalten.

Auf den Rechenkern übertragen heißt das: Ein Rechenmodul kann beispielsweise die Beschaffung und Interpolation einer biometrischen Tafel kapseln. Sein Aufrufer muss wissen, welche Wahrscheinlichkeiten mit welcher Altersdefinition er erhält; er muss nicht wissen, in welchen Dateien sie liegen. Ein anderes Modul kann einen Rentenbarwert nach einem bestimmten Rechenmodell bestimmen; umwandlung_beitragsfrei nutzt es intern. Dessen Schnittstelle muss Zahlungsrhythmus, Bewertungszeitpunkt und Voraussetzungen offenlegen, ohne seine internen Hilfsgrößen allen übrigen Schritten aufzuzwingen. Ob der Rentenbarwert intern aus Kommutationswerten entsteht, entscheidet das Modul. Ob die Umwandlung vor oder nach der Summenbildung läuft, entscheidet die Pipeline – und diese Entscheidung muss der Aktuar sehen können. Ein einziger Schritt „Beitragsfreistellung berechnen“, der den gesamten bisherigen Programmtext aufruft, macht gerade diese Frage wieder unsichtbar.

Der Gewinn hat eine Grenze: Neue Mathematik bleibt Entwicklungsarbeit. Fehlt ein benötigtes Rechenmodul, muss es implementiert, dokumentiert und geprüft werden. Konfiguration erspart diese Arbeit nicht. Sie verhindert im günstigen Fall, dass für jede neue Verbindung vorhandener Module ein weiterer, fast gleicher Programmzweig entsteht. Dafür muss die Definitionssprache eng bleiben: benannte Schritte, Modulversionen, Eingaben und die Ebene, auf der ein Schritt arbeitet. Eine Konfiguration mit beliebigen Schleifen, verdeckten Seiteneffekten und frei ausführbarem Code ist wieder ein Programm – mit denselben Prüfaufgaben.

3 · Ein geprüfter Rechenschritt macht seine Verkettung nicht richtig

Zwei gültige Rechenschritte können eine ungültige Folge bilden. Der zweite kann einen Wert nach der Fortschreibung voraussetzen, während der erste einen Wert davor liefert. Er kann einen einzelnen Vertragsteil erwarten und eine Summe über den Vertrag bekommen. Oder er erwartet einen ungerundeten Zwischenwert und erhält einen bereits für die Ausgabe gerundeten. Eine Schnittstelle, die lediglich „Betrag in Euro“ verlangt, erkennt keinen dieser Fehler.

Die Verkettung braucht deshalb prüfbare Vor- und Nachbedingungen. Jedes Rechenmodul deklariert, welche Zwischenergebnisse es annimmt, welche es erzeugt und welche Angaben dabei erhalten bleiben. Für die Umwandlung aus These 1 könnte das in Version 2.0 des Moduls so aussehen:

@dataclass(frozen=True)
class Rueckkaufswert:
    vertragsteil: str      # z. B. "Erhöhung 2019"
    tarif: str             # Tarifgeneration
    stichtag: date
    nach_fortschreibung: bool
    betrag: Decimal        # ungerundet

@dataclass(frozen=True)
class BeitragsfreieRente:
    vertragsteil: str
    rentenbeginn: date
    zahlungsrhythmus: str
    leistungsumfang: str   # z. B. "Garantiezeit 10 J."
    betrag: Decimal

def umwandlung_beitragsfrei(
    rkw: Rueckkaufswert, rg: Rechnungsgrundlagen
) -> BeitragsfreieRente:
    if rg.tarif != rkw.tarif:
        raise Unzulaessig("Grundlagen eines anderen Tarifs")
    ...

Zu lesen ist das so: Jede class beschreibt, welche Angaben ein übergebenes Zwischenergebnis trägt. frozen=True heißt, dass es nach dem Erzeugen nicht mehr verändert werden kann; die Angaben bleiben auf dem Weg durch die Pipeline also erhalten. Die Funktion nimmt einen Rueckkaufswert und Rechnungsgrundlagen an und liefert (->) eine BeitragsfreieRente. raise bricht die Rechnung mit einer benannten Fehlermeldung ab; ... steht für die eigentliche Umwandlung, auf die es hier nicht ankommt. Dass der Betrag ungerundet ist, steht hier nur als Kommentar; ein eigener Datentyp könnte auch das erzwingen. Das Ergebnis behält die Kennung des Vertragsteils und beschreibt die beitragsfreie Rente mit Beginn, Zahlungsrhythmus und Leistungsumfang. Erst das Modul summe_renten darf die Vertragsteile zusammenfassen. Es nimmt eine Liste von BeitragsfreieRente an und bricht ab, wenn Rentenbeginn, Zahlungsrhythmus oder Leistungsumfang voneinander abweichen.

Ein Teil dieser Bedingungen ist vor dem Rechnen prüfbar. Das ausführende Programm kennt die Schnittstellen der Module. Beim Laden der Definition vergleicht es für jeden Schritt, ob jede verlangte Eingabe vorgesehen ist und den verlangten Typ hat. Eine Summe über den Vertrag, etwa vom Typ Betrag, ist kein Rueckkaufswert und wird deshalb vor der ersten Rechnung abgewiesen. Andere Bedingungen lassen sich erst am konkreten Vertrag prüfen: Gehören Rechnungsgrundlagen und Rückkaufswert zum selben Tarif, passt der Stichtag, erfüllt der Vertrag die tariflichen Voraussetzungen für diesen Geschäftsvorfall? Bei einer verletzten Voraussetzung muss die Pipeline mit einer benannten Fehlermeldung abbrechen. Eine fehlende Größe durch null zu ersetzen, würde aus einer erkennbaren Lücke eine scheinbar vollständige Rechnung machen.

Die technischen Prüfungen setzen das fachliche Urteil voraus. Ein System kann feststellen, dass ein Wert als Rueckkaufswert gekennzeichnet ist. Ob das Modul dahinter die richtigen Abzüge und Garantien berücksichtigt, entscheidet diese Kennzeichnung nicht. Das muss gegen Tarifunterlagen und unabhängige Erwartungen geprüft werden. Der DAV-Bericht nennt AVB und mathematische Vorschriften als Ausgangspunkt für die Bestimmung der Geschäftsvorfälle [1]. Sie bleiben auch dann der Maßstab, wenn die Rechnung als Pipeline konfiguriert ist.

Deshalb sind drei verschiedene Prüfgegenstände nötig: die Vorschrift im einzelnen Rechenmodul, ihre Verkettung in der konkreten Pipeline und die Folge von Geschäftsvorfällen über die Vertragslaufzeit. Der letzte Punkt geht über die Pipeline eines einzelnen Geschäftsvorfalls hinaus. Eine korrekte Beitragsfreistellung muss einen Vertragsstand hinterlassen, auf dem etwa der spätere Rentenübergang korrekt aufsetzen kann. Ein Test, der für diesen nachfolgenden Geschäftsvorfall einen unabhängig neu aufgebauten Mustervertrag verwendet, prüft diese Übergabe nicht. Er benötigt den tatsächlich erzeugten Vertragsstand. Der DAV-Bericht stellt an das Controlling einer Bestandsmigration eine verwandte Forderung: Vergleichswerte und -zeitpunkte sind so zu wählen, dass sie auch auf die korrekte Weiterentwicklung im späteren Vertragsverlauf schließen lassen [1].

ISAP 1 ordnet Modellvalidierung und Kontrollen nach dem Modellrisiko ein und behandelt ausdrücklich auch Einsatzbedingungen, Änderungen und die Verwendung einzelner Laufergebnisse [3]. Als internationaler Modellstandard ist er nicht unmittelbar für jeden Aktuar bindend; eine bestimmte Softwarearchitektur schreibt er ebenfalls nicht vor. Die Vor- und Nachbedingungen sind hier ein eigener Vorschlag, diese Prüfaufgaben am Rechenweg sichtbar zu machen.

4 · Die Änderung an der Pipeline wird zum eigenen Prüfgegenstand

Der praktische Nutzen zeigt sich beim nächsten Änderungsauftrag. Zwei Fassungen einer Excel-Datei können dieselben Formeln enthalten und trotzdem anders rechnen, weil sich Bezüge oder die Reihenfolge der Bearbeitung geändert haben. Ein Vergleich der Endwerte sagt, welche Testfälle darauf reagieren. Er sagt noch nicht, welche fachliche Entscheidung verändert wurde.

Bei einer versionierten Pipeline-Definition zeigt der Vergleich die Entscheidung selbst. Angenommen, Version 2 hatte die Rückkaufswerte vor der Umwandlung summiert, und das Umwandlungsmodul beschaffte sich die Rechnungsgrundlagen intern. Welche es für eine Summe über zwei Vertragsteile verwendete, war in der Definition nicht zu sehen. Version 3 aus These 2 korrigiert das. Zeilen mit − entfallen, Zeilen mit + kommen hinzu:

 pipeline: beitragsfreistellung
-version: 2
+version: 3
 schritte:
   - name: rueckkaufswert
     modul: rueckkaufswert@2.1
     je: vertragsteil
-  - name: summe_rueckkaufswerte
-    modul: summe_betraege@1.0
-    eingabe: rueckkaufswert
+  - name: grundlagen
+    modul: rechnungsgrundlagen@1.0
+    je: vertragsteil
   - name: beitragsfreie_rente
-    modul: umwandlung_beitragsfrei@1.4
-    eingabe: summe_rueckkaufswerte
+    modul: umwandlung_beitragsfrei@2.0
+    je: vertragsteil
+    eingabe: [rueckkaufswert, grundlagen]
+  - name: summe_renten
+    modul: summe_renten@1.0
+    eingabe: beitragsfreie_rente
   - name: ergebnis
-    modul: mindestleistung@1.2
-    eingabe: [beitragsfreie_rente, summe_rueckkaufswerte]
+    modul: mindestleistung@2.0
+    eingabe: [summe_renten, rueckkaufswert]

Hätte die alte Definition bereits Version 2.0 des Umwandlungsmoduls mit der Schnittstelle aus These 3 verwendet, hätte das ausführende Programm sie schon beim Laden abgewiesen, und zwar doppelt: summe_betraege liefert einen Betrag ohne Vertragsteil statt eines Rueckkaufswert, und die verlangten Rechnungsgrundlagen fehlen als Eingabe. Auch mindestleistung erhält in Version 3 andere Eingaben und trägt deshalb eine neue Modulversion. Der Vergleich zeigt, welche Entscheidung sich geändert hat. Er ersetzt weder die Tarifprüfung noch den Ergebnisvergleich; er benennt, worauf beide ihre Aufmerksamkeit richten müssen.

Eine solche Änderung bestimmt auch die notwendigen Gegenproben. Ein Vertrag mit nur einem Vertragsteil deckt den beschriebenen Fehler nicht auf. Bei zwei Vertragsteilen mit identischer linearer Umwandlungsvorschrift sind beide Rechenwege bis auf Rundung gleich. Auch unterschiedliche Rechnungsgrundlagen genügen nicht, wenn ein Vertragsteil kaum Rückkaufswert trägt, etwa eine junge Erhöhung, oder wenn sich die Grundlagen nur in Elementen unterscheiden, die in die Umwandlung nicht eingehen. Aussagekräftig ist erst ein Fall, in dem beide Vertragsteile nennenswerte Rückkaufswerte tragen und nachweislich verschieden umgewandelt werden. Hinzukommen müssen Fälle an den Stellen, an denen der Tarif nichtlinear wird, je Vertragsteil oder auf Ebene des Gesamtvertrags: Mindestleistung, feste Abzüge, Rundung. Welche Fälle das sind, ergibt sich aus der geänderten Stelle der Pipeline. Ein Bestand, der sie zufällig enthält oder nicht enthält, sagt darüber nichts. Die erwarteten Ergebnisse brauchen eine unabhängig begründete Rechnung. Wer lediglich die Ausgabe der geänderten Pipeline als neuen Sollwert speichert, dokumentiert die Änderung, prüft sie aber nicht.

Der Vergleich muss erfassen, was tatsächlich ausgeführt wird. Unveränderte Schrittnamen reichen nicht aus, wenn hinter einem Namen eine neue Modulversion steht oder sich ein Parameter geändert hat, den die Definition nicht selbst nennt, etwa eine Rundungsregel aus einer gemeinsamen Voreinstellung. Das Prüfobjekt muss deshalb neben der Pipeline-Definition auch die tatsächlich verwendeten Modulversionen, Parameter und Referenzdaten identifizieren, dazu die Version des ausführenden Programms, weil es fehlende Angaben mit Voreinstellungen ergänzt. Andernfalls bleibt gerade die Änderung unsichtbar, die der Vergleich erklären soll. Das ist zunächst eine Anforderung an das Prüfobjekt; die dauerhafte Aufbewahrung dieser Angaben ist eine weitere Aufgabe (Der Nachweis, der sich selbst beschreibt).

Ändert sich statt der Pipeline-Definition ein Rechenmodul selbst, reicht die Korrektur so weit wie seine Verwendungen. Nutzen etwa die Beitragsfreistellung und die Verrentung beim Rentenübergang dasselbe Modul für den Rentenbarwert, gehören beide Pipelines in die Auswirkungsanalyse. Ein Abhängigkeitsverzeichnis kann diese Menge bestimmen, sofern sämtliche Verwendungen darin erfasst sind. Es kann nicht entscheiden, ob die gewählten Testfälle fachlich ausreichen. Wiederverwendung spart Implementierungen und vergrößert zugleich den möglichen Wirkungsbereich eines Fehlers. Die passende Antwort ist ein nachvollziehbarer Regressionsumfang, keine pauschale Zusicherung aus dem Modultest.

Auch der Einwand gegen den Aufwand ist berechtigt. Für einen kleinen, stabilen Tarifumfang kann eine klar gegliederte Implementierung mit guten Tests die bessere Wahl sein. Ein Programm, das Pipelines ausführt, benötigt Versionierung, Fehlerbehandlung und eine verständliche Darstellung. Es lohnt sich dort, wo wiederkehrende fachliche Vorschriften in wechselnden Verbindungen gepflegt werden müssen und die Prüfung dieser Verbindungen sonst immer wieder aus dem Programmtext heraus beginnt. Der Maßstab ist, ob ein fachkundiger Dritter die konkrete Änderung mit ihren Folgen beurteilen kann.

Den Rechenkern komponieren heißt damit: Die Mathematik bleibt in verantworteten Rechenmodulen, ihre Verwendung wird zu einem eigenen Prüfgegenstand – einer versionierten Definition, deren Schritte, Eingaben und Ebenen ein Aktuar lesen und deren Änderungen er vergleichen kann.

Für unsere Arbeit an Referenzrechnern heißt das: Eine Änderung wie die beschriebene gilt erst als abgenommen, wenn sechs Dinge zusammen vorliegen. Beide Fassungen der Definition mit allem, was tatsächlich ausgeführt wurde. Die neuen und geänderten Rechenmodule, geprüft gegen die Tarifunterlagen. Testverträge, deren Vertragsteile nennenswerte Rückkaufswerte tragen und nachweislich verschieden umgewandelt werden. Fälle an den nichtlinearen Stellen des Tarifs. Unabhängig begründete Sollwerte. Und der nachfolgende Geschäftsvorfall, gerechnet auf dem tatsächlich erzeugten Vertragsstand.