Finanzsektor und Legacy-Core: Warum Banken auf 50 Jahre alten Systemen laufen
Sie tippen im Online-Banking eine Überweisung ein. Die Oberfläche sieht modern aus. Ein paar Millisekunden später landet Ihr Auftrag in einem Programm, das älter ist als die meisten Mitarbeiter der Bank. Geschrieben in COBOL, gestartet auf einem Großrechner, gepflegt seit Jahrzehnten.
Banking Legacy Software ist im Finanzsektor der Normalfall. Kernbanksysteme, in der Branche "Core Banking" genannt, führen Konten, buchen Zinsen und verarbeiten den Zahlungsverkehr. Viele davon stammen aus den 1970er und 1980er Jahren. Sie laufen noch, weil sie funktionieren. Und weil ihr Austausch zu den riskantesten IT-Projekten gehört, die es gibt.
Dieser Artikel erklärt, warum diese Systeme so alt werden konnten. Er zeigt, was passiert, wenn niemand handelt. Und er nennt die Wege, die in der Praxis aus der Abhängigkeit führen.
Was ein Kernbanksystem eigentlich tut
Das Kernbanksystem ist das Hauptbuch der Bank. Jede Kontobewegung endet dort. Es berechnet Zinsen, bucht Gebühren und erstellt den Tagesabschluss. Alles andere hängt daran: das Online-Banking, die Geldautomaten, die Kreditvergabe, das Meldewesen an die Aufsicht.
Viele dieser Systeme sind in COBOL geschrieben. COBOL ist eine Programmiersprache aus dem Jahr 1959, entworfen für kaufmännische Anwendungen. Sie rechnet mit Dezimalzahlen exakt, ohne Rundungsfehler. Bei Geldbeträgen ist das die Grundvoraussetzung. Ein Teil der Systeme nutzt PL/I, eine ähnlich alte Sprache von IBM.
Diese Programme laufen auf Mainframes, also Großrechnern, die auf Verfügbarkeit und Durchsatz ausgelegt sind. Eine große Bank verarbeitet damit Millionen Buchungen pro Nacht. Ausfälle sind extrem selten. Genau das ist der Grund, warum niemand leichtfertig daran rührt.
Warum diese Systeme noch laufen
Von außen wirkt es fahrlässig. Von innen ist es eine nüchterne Rechnung.
Das System macht keine Fehler, die man kennt
Ein Kernbanksystem, das 40 Jahre lang jeden Tagesabschluss korrekt geliefert hat, ist getestet wie kaum eine andere Software. Jede Sonderregel für Schaltjahre, Feiertage, Fremdwährungen und Stornos steckt drin. Oft ist sie nirgends dokumentiert. Sie ist nur im Code.
Wer das System ersetzt, muss all diese Regeln neu finden und neu bauen. Jede übersehene Regel ist ein Fehler in Kontoständen. Und Fehler in Kontoständen bemerken Kunden sofort.
Ein Austausch ist ein Projekt ohne Übungsmodus
Die britische Bank TSB hat 2018 ihr Kernsystem auf eine neue Plattform migriert. Nach der Umstellung konnten Kunden tagelang nicht auf ihre Konten zugreifen. Manche sahen fremde Kontodaten. Die Behebung dauerte Monate. Die Aufsicht verhängte später eine Strafe von knapp 49 Millionen Pfund. Die Gesamtkosten lagen deutlich höher.
Solche Fälle sind in jedem Vorstand bekannt. Sie prägen die Entscheidung. Wer die Migration verantwortet, trägt das Risiko, die Bank für Tage lahmzulegen. Wer sie verschiebt, trägt nur steigende Wartungskosten. Die Anreize sprechen für das Verschieben.
Regulierung macht jede Änderung teuer
Banken müssen jede Änderung an buchhaltungsrelevanten Systemen dokumentieren, testen und nachweisen können. Die BaFin prüft das in Deutschland über die "Bankaufsichtlichen Anforderungen an die IT", kurz BAIT. Seit 2025 gilt zusätzlich die EU-Verordnung DORA für die digitale Betriebsstabilität.
Ein Systemwechsel bedeutet unter diesen Regeln Jahre an Abstimmung mit der Aufsicht. Das Alte weiterzubetreiben ist regulatorisch einfacher. Zumindest kurzfristig.
Die Kosten fallen leise an
Ein Mainframe-Vertrag kostet Millionen pro Jahr. Ein COBOL-Entwickler mit Bankerfahrung kostet mehr als ein Java-Entwickler, und es gibt weniger davon. Diese Kosten stehen im Budget, jedes Jahr, ohne Überraschung. Ein Migrationsprojekt steht dort nicht. Es muss neu beantragt werden, mit einer Zahl, die niemand seriös nennen kann.
Was passiert, wenn niemand handelt
Die Systeme laufen weiter. Das Problem liegt woanders. Es liegt in dem, was um sie herum passiert.
Die Entwickler, die den Code verstehen, gehen in Rente. Warum COBOL und ähnliche Sprachen trotzdem nicht verschwinden, haben wir in einem eigenen Artikel beschrieben. Kurz: Die Nachfrage bleibt, der Nachwuchs fehlt. Ab einem bestimmten Punkt gibt es für ein Kernsystem keine zwei Personen mehr, die es vollständig verstehen. Dann steht jede Änderung unter dem Vorbehalt, dass diese eine Person verfügbar ist.
Neue Anforderungen kommen trotzdem. Echtzeitüberweisungen, offene Schnittstellen nach PSD2, neue Meldepflichten. Jede davon wird als Umgehung um das alte System herum gebaut. Nach zehn Jahren umgibt das Kernsystem ein Geflecht aus Adaptern, Batch-Jobs und Zwischendatenbanken. Das ist die Form von technischen Schulden, die Banken am meisten kostet: Jede neue Funktion dauert länger als bei der Konkurrenz.
Fintechs und Neobanken tragen keine Banking Legacy Software mit sich herum. Sie starten auf Systemen, die zehn Jahre alt sind statt fünfzig. Sie liefern Funktionen in Wochen, für die eine etablierte Bank Quartale braucht. Der Abstand wächst mit jedem Jahr des Wartens.
Welche Wege aus der Abhängigkeit führen
Es gibt keinen Weg ohne Risiko. Es gibt aber Wege mit kalkulierbarem Risiko. Vier davon haben sich in der Praxis bewährt.
Schrittweise ablösen statt Big Bang
Das Strangler-Fig-Pattern setzt eine neue Schicht vor das alte System. Einzelne Funktionen wandern nach und nach in neue Dienste. Das Kernsystem bleibt so lange in Betrieb, bis die letzte Funktion umgezogen ist. Wie das Muster im Detail funktioniert, erklären wir in einem eigenen Beitrag.
Für Banken ist das der gängigste Weg. Zuerst wandern Randfunktionen wie Kundenstammdaten oder Benachrichtigungen. Das eigentliche Hauptbuch kommt zuletzt, wenn das Team Erfahrung mit der Migration hat.
Das Alte kapseln und mit Schnittstellen versehen
Nicht jedes System braucht sofort einen Ersatz. Wer das Kernsystem sauber hinter Schnittstellen verbirgt, kann drumherum modern entwickeln. Online-Banking, App und Kunden-Onboarding laufen dann auf aktueller Technik. Mit dem Hauptbuch sprechen sie über eine definierte Schnittstelle.
Der Vorteil: Die Bank wird sichtbar schneller, ohne das riskanteste Stück anzufassen. Der Nachteil: Die Abhängigkeit vom alten Kern bleibt. Dieser Weg kauft Zeit, er löst das Problem nicht.
Code automatisiert übersetzen
Werkzeuge übersetzen COBOL in Java oder C#. Das Ergebnis ist lauffähig, aber selten schön. Der übersetzte Code sieht aus wie COBOL mit Java-Syntax. Er ist nicht besser wartbar als vorher, nur auf einer anderen Plattform.
Sinnvoll ist das, wenn der Mainframe-Vertrag ausläuft und die Bank die Plattformkosten senken will. Als Modernisierung im eigentlichen Sinn taugt es nicht. Was System-Modernisierung wirklich bedeutet und wie sie sich von einer reinen Übersetzung unterscheidet, haben wir an anderer Stelle beschrieben.
Wissen sichern, bevor es geht
Der günstigste Schritt wird am häufigsten übersprungen. Solange die Entwickler noch da sind, die das System kennen, gehört ihr Wissen in Dokumentation. Welche Batch-Jobs laufen in welcher Reihenfolge? Welche Sonderfälle stecken im Zinsmodul? Warum gibt es diese eine Tabelle mit dem seltsamen Namen?
Diese Fragen kosten heute ein paar Wochen Gespräche. In fünf Jahren kosten sie Monate an Reverse Engineering. Jede spätere Migration wird mit dieser Dokumentation schneller und sicherer.
Was das für kleinere Häuser bedeutet
Dieses Thema betrifft auch kleinere Häuser. Regionalbanken, Bausparkassen, Leasinggesellschaften und Versicherer betreiben ebenfalls Kernsysteme aus den 1980ern und 1990ern. Oft nicht in COBOL, sondern in Delphi, Visual Basic, altem Java oder PHP. Das Muster ist dasselbe: Das System läuft, der Entwickler ist weg, jede Änderung ist ein Wagnis.
Was Legacy Software genau ausmacht, hängt nicht vom Alter ab. Es hängt davon ab, ob noch jemand das System sicher verändern kann. Nach diesem Maßstab betreiben viele Finanzdienstleister Banking Legacy Software, ohne es so zu nennen.
Für diese Häuser sind die Optionen dieselben wie für Großbanken, nur in kleinerem Maßstab. Kapseln, dokumentieren, schrittweise ablösen. Das lässt sich mit einem kleinen Team über zwei bis drei Jahre planen. Ohne Big Bang und ohne Wochenende mit Notfallplan.
Fazit: Das Risiko ist das fehlende Wissen
Ein 50 Jahre altes Kernbanksystem verdient Respekt. Es hat Jahrzehnte fehlerfrei gebucht. Das Risiko entsteht, weil immer weniger Menschen wissen, wie es funktioniert.
Wer heute anfängt, hat Zeit für einen ruhigen Weg: erst Wissen sichern, dann kapseln, dann Schritt für Schritt ablösen. Wer wartet, bis der letzte Entwickler geht, hat diese Wahl nicht mehr.
Wir übernehmen die Analyse und Betreuung von Altsystemen im Finanzumfeld. Vom ersten Blick in den Code bis zur geplanten Modernisierung. Sprechen Sie uns an. Das Erstgespräch ist kostenlos.
