IT in der Assekuranz: Bestandssysteme, Migrationen, Altsysteme

Wer die Stellenausschreibungen dieser Branche über einige Monate verfolgt, sieht ein Muster: Nach dem Vertrieb ist die IT der Bereich mit den meisten offenen Stellen, und ein erheblicher Teil davon klingt nach Vergangenheit statt nach Zukunft. Gesucht werden Anwendungsentwickler für Bestandssysteme, Anwendungsbetreuer, Migrationsspezialisten, Testmanager, Business Analysten für Verträge, die vor der Jahrtausendwende geschlossen wurden.

Das ist kein Rückstand, den man aufholen könnte. Es ist die Folge des Produkts. Dieser Text erklärt, was ein Bestandssystem ist, warum diese Systeme so alt sind, was eine Migration so schwierig macht und welche Rollen daraus entstehen.

Was ein Bestandssystem ist

Das Bestandsführungssystem ist die Maschine, in der die Verträge liegen. Es verwaltet nicht Datensätze, sondern Rechtsverhältnisse: Es weiß, welcher Vertrag zu welchem Tarif und mit welchen Rechnungsgrundlagen abgeschlossen wurde, es berechnet Beiträge, schreibt Rechnungen, verbucht Zahlungen, mahnt, stellt beitragsfrei, kündigt, berechnet Rückkaufswerte und Überschussbeteiligung, meldet an das Rechnungswesen und liefert die Zahlen, aus denen später die versicherungstechnischen Rückstellungen entstehen.

Es ist damit gleichzeitig Vertragsarchiv, Rechenwerk und Buchhaltungsvorsystem. Ein Fehler darin ist kein Anzeigefehler, sondern ein falscher Betrag auf einem Konto und im schlimmsten Fall ein falscher Posten in der Bilanz. Das erklärt, warum in dieser Branche so ausgiebig getestet wird und warum Testmanagement eine eigene Rolle mit eigener Ausschreibung ist.

Drei Sorten von Systemen finden sich im Markt. Die hostbasierte Eigenentwicklung, gewachsen seit den 1970er und 1980er Jahren, häufig in Lebens- und Krankenversicherung. Das eingekaufte Standardsystem eines Softwareanbieters, angepasst an das eigene Haus – und in der Anpassung oft so weit von der Standardauslieferung entfernt, dass jedes Release ein Projekt wird. Und die Neuentwicklung auf heutigen Plattformen, die meist mit dem Neugeschäft anfängt und den Altbestand vorerst dort lässt, wo er ist.

Warum die Systeme alt sind

Eine Risikolebensversicherung läuft dreißig Jahre. Eine Rentenversicherung läuft bis zum Tod des Versicherten, also unter Umständen siebzig Jahre nach Vertragsschluss. Solange ein Vertrag lebt, muss ihn ein System bedienen können – und zwar nach den Regeln, die bei Abschluss galten, nicht nach den heutigen.

Daraus folgt das zentrale Problem der Versicherungs-IT: die Tarifgenerationen. Jede Änderung der Rechnungsgrundlagen erzeugt eine neue. Der Höchstrechnungszins ist seit den 1990er Jahren mehrfach herabgesetzt worden; jede Absenkung hat eine neue Tarifgeneration hervorgebracht, während alle vorhergehenden weiterlaufen. Dazu kommen neue Sterbetafeln, geänderte Steuerregeln, das Ende der Unisex-Unterscheidung, jede Reform der Altersvorsorge, jedes neue Bedingungswerk.

Ein Bestandssystem eines mittelgroßen Lebensversicherers enthält deshalb nicht ein Rechenwerk, sondern Dutzende, die parallel gelten und einzeln gepflegt werden müssen. Nichts davon darf abgeschaltet werden, solange ein einziger Vertrag dieser Generation noch läuft.

Der zweite Grund ist banaler und ebenso wirksam: Ein System, das rechnet, wird nicht ersetzt, weil es alt ist. Es wird ersetzt, wenn niemand es mehr bedienen kann oder wenn die Kosten für den Betrieb die Kosten eines Wechsels übersteigen. Genau dieser Punkt ist inzwischen bei vielen Häusern erreicht – und daher kommen die Stellen.

Was in den Altsystemen steckt

Wer eine Ausschreibung liest, in der COBOL steht, sollte wissen, worauf er sich einlässt. Der typische Altsystemstapel besteht aus einem Großrechner unter z/OS, Programmen in COBOL, PL/I und gelegentlich Assembler, einer Transaktionsverarbeitung mit CICS, einer relationalen Datenbank – meist DB2 – oder einer älteren Datenhaltung, und aus Stapelverarbeitung, die nachts läuft und in der die eigentliche Arbeit steckt: Beitragsläufe, Mahnläufe, Provisionsabrechnung, Jahreswechselverarbeitung.

Zwei Eigenschaften dieser Systeme werden von außen unterschätzt. Sie sind erstens außerordentlich zuverlässig; Häuser wechseln nicht, weil der Host ausfällt, denn das tut er nicht. Und sie sind zweitens unvollständig dokumentiert. Die Fachlogik steckt im Code, nicht in einer Spezifikation, und wer sie kennt, kennt sie aus dreißig Jahren Arbeit an demselben Programm. Diese Leute gehen jetzt in Rente. Das ist der eigentliche Treiber des Arbeitsmarkts in der IT dieser Branche.

Die Migration

Eine Bestandsmigration bedeutet, Millionen Vertragsverhältnisse aus einem System in ein anderes zu überführen, ohne dass sich für einen einzigen Kunden ein Betrag ändert. Das ist der Grund, aus dem solche Projekte Jahre laufen und in der Branche als Königsdisziplin gelten.

Die Schwierigkeiten liegen dabei fast nie in der Technik:

• Nachrechenbarkeit. Der neue Rechenkern muss für jeden Altvertrag denselben Betrag ausgeben wie der alte – auf den Cent. Wo er das nicht tut, muss geklärt werden, welche der beiden Zahlen richtig ist. Erstaunlich oft ist es die neue, und dann fängt eine andere Diskussion an.
• Datenqualität. Verträge aus vierzig Jahren enthalten Felder, die zwischenzeitlich umgedeutet wurden, Kennzeichen mit Bedeutungen, die niemand mehr kennt, und Sonderfälle, die einmal von Hand eingetragen wurden. Ein erheblicher Teil der Projektzeit geht in Bereinigung.
• Fachliche Ausnahmen. Jeder Bestand hat Verträge, die nirgends hineinpassen: Sonderabsprachen, Kollektive, Verträge in einer Währung, die es nicht mehr gibt. Sie sind wenige und kosten überproportional viel Zeit.
• Parallelbetrieb. Meist läuft das Altsystem noch, während der neue Bestand schon geführt wird. Zwei Systeme mit einer Wahrheit – das verdoppelt Schnittstellen, Tests und Betriebsaufwand für die Dauer des Übergangs.

Nicht jeder Bestand wird migriert. Manche Häuser schließen einen Teilbestand für das Neugeschäft und führen ihn aus – der Run-off –, andere übertragen ihn auf einen Abwicklungsspezialisten. Eine solche Bestandsübertragung ist nach § 13 VAG genehmigungspflichtig: Die Aufsicht sieht sich an, ob die Belange der Versicherten gewahrt bleiben. Für die IT ist ein Run-off übrigens keine Entlastung, sondern eine eigene Aufgabe – der Bestand muss weiter korrekt rechnen, nur ohne dass jemand in Neuerungen investiert.

Was die Aufsicht verlangt

IT ist in dieser Branche kein Werkzeug, sondern ein aufsichtsrechtlich geregelter Teil der Geschäftsorganisation. Die Grundpflicht steht in § 23 VAG: Jedes Unternehmen braucht eine wirksame Geschäftsorganisation mit einem angemessenen Risikomanagement. Wird ein Teil davon an einen Dienstleister gegeben, greifen die Regeln über die Ausgliederung nach § 32 VAG – wichtige Funktionen dürfen nicht so ausgegliedert werden, dass Steuerung und Kontrolle verloren gehen.

Ausgeformt hat die BaFin diese Pflichten jahrelang in den Versicherungsaufsichtlichen Anforderungen an die IT, kurz VAIT. Seit Januar 2025 ist dieser Rahmen europäisch: Die Verordnung über die digitale operationale Resilienz des Finanzsektors – DORA – gilt unmittelbar und regelt IT-Risikomanagement, Meldung schwerer Vorfälle, Test der Widerstandsfähigkeit und das Verhältnis zu IT-Dienstleistern. Wie weit die nationalen Rundschreiben daneben noch gelten, sagt die Aufsicht selbst; prüfen Sie den Stand, wenn Sie sich auf eine Stelle mit Regulierungsbezug bewerben.

Für Bewerber ist daran vor allem eines interessant: Diese Vorschriften erzeugen dauerhaft Stellen, die es in anderen Branchen nicht gibt. Informationssicherheitsbeauftragte, IT-Auslagerungsmanagement, IT-Revision, Notfall- und Wiederanlaufplanung – Funktionen, die hier besetzt werden müssen und nicht besetzt werden können, wenn gerade Geld fehlt.

Die Schnittstellen

Ein Versicherer ist kein geschlossenes System. Er tauscht Daten mit Vermittlern, mit Rückversicherern, mit Banken, mit dem Kraftfahrt-Bundesamt, mit den Kassen, mit anderen Versicherern.

Zwei Standards prägen den Alltag. Der GDV-Datensatz, seit Jahrzehnten das Format für den Datenaustausch zwischen Versicherern und Vermittlern, ist satzorientiert, alt und weit verbreitet. Die BiPRO-Normen der Brancheninitiative sind die jüngere Antwort darauf: dienstorientiert, für Tarifierung, Antrag, Bestandsabruf und Dokumentenzustellung. Wer bei einem Makler oder Vermittlerbetrieb in der IT arbeitet, arbeitet an diesen Schnittstellen, denn dort läuft alles zusammen, was aus zwanzig Häusern kommt.

Dazu kommt das Meldewesen: Solvency II verlangt regelmäßige, formatgebundene Meldungen an die Aufsicht. Die Zahlen dafür kommen aus dem Bestandssystem, laufen über das Aktuariat und das Rechnungswesen und müssen fristgerecht in einem vorgeschriebenen Format abgeliefert werden. Das ist eine IT-Aufgabe mit fachlichem Kern und einer der Gründe, aus denen Business Analysten hier besonders gesucht sind.

Welche Rollen ausgeschrieben werden

Grob sortiert nach Häufigkeit:

• Anwendungsentwicklung Bestand. Host oder Java, oft beides. Der größte Posten.
• Anwendungsbetreuung. Zwischen Fachbereich und Entwicklung: Störungen analysieren, Anforderungen aufnehmen, Releases begleiten. Der übliche Einstieg für Fachleute aus dem Betrieb, die in die IT wechseln.
• Business Analyse und Requirements Engineering. Die Rolle, die Fachlichkeit in Spezifikation übersetzt. Wer die Sparte kennt, ist hier mehr wert als jemand mit besserem technischen Werkzeugkasten.
• Test und Testmanagement. Eigenständige Laufbahn, siehe oben zur Fehlerwirkung.
• Migration und Datenqualität. Projektgetrieben, gut bezahlt, endlich.
• Betrieb, Datenbanken, Plattform, Cloud. Der Übergang vom Rechenzentrum in die Cloud läuft in dieser Branche langsam und unter Auslagerungsregeln.
• Informationssicherheit und Regulatorik. Siehe oben. Wachsend.

Was das für Bewerber heißt

Vier Beobachtungen, die sich aus dem Vorstehenden ergeben.

Domänenwissen schlägt Technologiemode. Wer versteht, was eine Deckungsrückstellung ist und warum ein beitragsfreigestellter Vertrag anders rechnet, ist in dieser Branche schwerer zu ersetzen als jemand, der ein aktuelles Framework beherrscht. Die Fachlichkeit ist der Teil, der Jahre braucht.

Alte Technik ist ein Angebot und kein Makel. COBOL lässt sich in Wochen lernen; das Fehlen von Leuten, die es können, ist ein Verhandlungsargument. Prüfen Sie allerdings, ob das Haus einen Plan für die nächsten zehn Jahre hat – "wir migrieren demnächst" ist seit fünfzehn Jahren eine verbreitete Antwort.

Fragen Sie im Gespräch nach dem System. Welches Bestandssystem läuft, wie viele Tarifgenerationen sind darin, gibt es ein Migrationsprojekt und in welchem Jahr des Projekts befindet es sich? Die Antworten sagen mehr über die nächsten drei Jahre Ihrer Arbeit als jede Stellenbeschreibung.

Der Quereinstieg funktioniert in beide Richtungen. Fachleute aus der Sachbearbeitung gehen in die Anwendungsbetreuung, Entwickler aus anderen Branchen kommen in die Bestandsentwicklung. Die Wege dorthin stehen in Quereinstieg in die Versicherungswirtschaft; wer in die rechnende Richtung will, findet den längsten Weg in Der Weg zum Aktuar DAV. Welche Häuser gerade suchen, zeigen die offenen Stellenangebote.