Lords of COBOL: unser Bankensystem ist 1959 steckengeblieben

Ihr entsperrt eure Banking-App mit Face-ID, alles smooth und fintech. Aber hinter dieser hübschen Oberfläche läuft Code, der geschrieben wurde, als Leute noch dachten, dass Zigaretten gesund sind und Mond-Besucher im Staub versinken würden.

Dieser Code heißt COBOL.
Und ein absurder Teil des globalen Finanzsystems hängt immer noch daran: Schätzungen reden von rund 220 Milliarden Zeilen COBOL-Code, die noch produktiv im Einsatz sind; ungefähr 40–45 % der Bankensysteme und der Großteil der ATM-Swipes laufen noch immer über diese Altlast.

Kurz: Die Weltwirtschaft läuft auf einer Programmiersprache, die älter ist als die Beatles.

Wie wir bei COBOL gelandet sind: Geldliturgie seit 1959

COBOL wurde Ende der 1950er für Business-Anwendungen entworfen, stark beeinflusst von (Admiral) Grace Hoppers FLOW-MATIC, mit englisch klingenden Befehlen wie MOVE A TO B, damit auch Manager so tun können, als würden sie den Code verstehen. COBOL ist so alt wie die B-52.

Warum hat sich das Zeug in Banken festgefressen?

• Dezimalarithmetik
  COBOL rechnet nahezu perfekt mit großen Geldbeträgen und festen Dezimalstellen. Kein Gleitkomma-Chaos, keine Cent-Differenzen, die kumuliert irgendwann Milliarden werden.
• Mainframe-Maschinenraum
  Auf IBM-z/OS-Mainframes laufen COBOL-Programme zusammen mit CICS, IMS & Co (was auch immer das ist). Diese Dinger sind dafür gebaut, Millionen Transaktionen pro Tag durchzuballern, mit Uptime, die eure Cloud-Cluster „Ay, Caramba!“ schreien lassen.

Das Ergebnis ist ein Tech-Hybrid:
Oben: euer trendy React-Frontend für iOS mit Dark Mode.
Unten: ein COBOL-Tempel, der Transaktionen so zuverlässig bucht, dass ganze Volkswirtschaften lieber die Finger von ihm lassen.

Wenn ihr sehen wollt, wie realistische Hacking-Logik aussieht, wenn sie auf solche Systeme trifft, gibt’s den passenden Reality-Check im Serienformat: „Was ich über Hacking bei MR. ROBOT gelernt habe“.

Reale Katastrophen: Wenn die alten Götter stolpern

Nordea / Logica: Der Gibson ohne Neon

Erinnert euch an die legendäre „Gibson“-Nummer der 90er-Hacker-Szene: ein riesiger, zentraler Rechner, auf dem ALLES liegt. Im echten Leben gab’s das sehr ähnlich mit Logica und Nordea:

• Ein schwedischer IT-Dienstleister (Logica) betrieb u. a. Systeme für die Steuerbehörde.
• Die Nordea-Bank hing mit ihrem Großrechner-Backend dran.
• Ein Angreifer verschaffte sich Zugriff auf IBM-Mainframes, nutzte Schwachstellen in z/OS-Umgebungen und konnte unautorisierte Transaktionen anstoßen. Keine Steuern mehr, und die Nordea-Bank vermisst auch keine Kohle..

Die Ermittler ordneten die Attacken dem Umfeld von Pirate-Bay-Mitgründer Gottfrid Svartholm Warg zu. Es ging nicht um „lulz“, sondern um direkten Zugriff auf Steuer- und Bankdaten – plus reales Geld.

(Wer das ganze „Gibson“-Mythos-Paket mit Razzien, Raids und 90er-Hysterie einmal sauber durchdekliniert haben will, bekommt die Vollbedienung im Hintergrundtext „Die echte Welt hinter ‚Hackers‘ (1995): Raids, Razzien & Ruhm“. Das hier ist genau dieselbe Architektur, nur ohne Rollerblades und ohne Trance-Bass im Hintergrund.)

RBS / NatWest: Ein kaputter Job, Millionen hängen fest

2012 hat die Royal Bank of Scotland gezeigt, wie wenig es braucht, um so ein Legacy-System frontal in die Wand zu fahren:

• Ein Update am Batch-Scheduler CA-7 ging schief.
• Ergebnis: Zahlungen, Gehälter, ATM-Nutzung – für Millionen Kunden waren Tage lang chaotisch.
• Die Bank bezifferte den Schaden später auf rund 175 Millionen Pfund, inkl. Entschädigungen.

Kein Hacker, kein „Zero-Day“. Nur ein Fehler im Betrieb eines Systems, das mittlerweile so komplex ist, dass ein versehentlich verbogener Scheduler-Job den Alltag ganzer Länder zerlegt.

Wenn Politik plötzlich „COBOL-Dev gesucht“ ruft

2020 steht der Gouverneur von New Jersey vor Kameras und sagt im Prinzip:
„Äh, kann bitte jemand COBOL? Unser Arbeitslosensystem bricht unter der Pandemie-Last zusammen.“

• Das Arbeitslosengeld-System lief auf jahrzehntealten Mainframe-Anwendungen.
• Mit der Corona-Welle explodierte die Last, Updates waren nötig, aber das Personal und das Know-how fehlten.

Das war der Moment, in dem vielen klar wurde:
Die kritische Infrastruktur hängt nicht an „Innovation“, sondern an Leuten kurz vor Rente, die noch wissen, was eine JCL ist und warum dieser eine COBOL-Block niemals angefasst werden darf…

DOGE vs. Sozialversicherung: AI-Speedrun auf 60 Millionen Zeilen

Springen wir in die Gegenwart – Elon Musks neue US-Behörde Department of Government Efficiency (DOGE) hat eine göttliche Idee: Lasst uns die komplette IT der Sozialversicherung – über 60 Millionen Zeilen COBOL – in wenigen Monaten nach Java portieren. Mit Generative AI.

Laut Berichten plant DOGE, die COBOL-Systeme der Social Security Administration im Eilverfahren durch eine modernere Codebasis zu ersetzen, unterstützt von KI-Tools, die die alten Programme automatisch „übersetzen“.

Selbst verkalkte US-Senatoren warnen inzwischen deutlich:

• Hektische Migration kann dazu führen, dass Renten und Sozialleistungen falsch berechnet oder gar nicht ausgezahlt werden.
• Das System ist „Jenga“, nicht Lego: Ziehst du das falsche COBOL-Stück raus, liegt der Turm.

Das ist das Legacy-Problem in Reinform:
Du weißt, dass du aus dem alten Haus raus musst, aber wenn du zu schnell renovierst, kannst du nirgendwo mehr die Goth Girls stapeln.

Filmrealität: Gibson, E-Corp und der hässliche Unterbau

Hackers-Ära vs. Nordea-Realität

Die ganze „HACKERS“-Saga aus der 90er-Hackerwelt romantisiert genau das, worauf COBOL heute noch läuft:

• Ein riesiger, zentraler Rechner
• Alle wichtigen Daten liegen dort
• Wer reinkommt, hat gottähnliche Macht über Konten, Akten, Existenzen

Im Nordea/Logica-Fall war das exakt die Architektur, nur ohne VR-Tunnel und Techno-Soundtrack. Stattdessen: 3270-Terminals, Logfiles, IBM-Mainframe, Ermittlungsakten.

Elliot und E-Corp: „Mr. Robot“ als Tutorial für Legacy-Hass

Im Universum von E-Corp geht es nie um den coolen Webserver ganz vorne. Es geht um die Core-Systeme, die Schulden, Kredite und Identitäten verwalten.

Jede Operation, die Elliot startet, hat am Ende nur dann wirklich Wucht, wenn sie den Kern trifft: die Systeme, auf denen die Schulden registriert sind, die Transaktionen verbucht werden, die Historien festgeschrieben sind.

Das ist genau der Layer, in dem COBOL lebt:

• Batchjobs, die nachts Konten abgleichen
• Transaktionsmonitore, die jede Karte am ATM prüfen
• Datenbanken, die seit Jahrzehnten wachsen und alles wissen

Wenn jemand da reinkommt – sei es durch einen Logica-Nordea-Style-Hack oder durch einen DOGE-Style-KI-Umbau mit zu wenig Tests – dann brennt nicht „die App“. Dann brennt das System.

Warum das alles ein Legacy-Problem ist

Niemand kennt den ganzen Dungeon

COBOL-Bankensysteme bestehen aus:

• Millionen Zeilen Code
• Jahrzehnten an Patches, Regulatorik-Sonderlocken und „Bugfixes“
• einem Zoo aus Mainframe-Spezialtools und Datenformaten

Niemand hat das gesamte Ding im Kopf. Alle kennen nur Räume im Dungeon. Deswegen ist „wir schreiben das neu“ kein IT-Projekt, sondern eine mehrjährige Operation am offenen Bankherz.

Skill-Problem: Die Gilde stirbt aus

2020 war der Markt plötzlich wieder heiß auf COBOL-Dev, weil Staaten ihre Alt-Systeme unter Last nicht mehr im Griff hatten und panisch Leute suchten, die das noch können. Das ist kein „Vintage-Tech-Hobby“, das ist ein flächendeckendes Risiko: Wenn die letzten Expert*innen aufhören, habt ihr immer noch den Code – aber niemanden, der versteht, was passiert, wenn ihr eine Zeile zu viel ändert.

Risiko: Jeder Eingriff kann RBS 2.0 auslösen

Der RBS-Fail zeigt, was passiert, wenn man in solchen Systemen „nur mal kurz“ den Scheduler anfasst: Millionen Leute ohne Zugriff aufs Geld, zweistellige Millionenbeträge an Schaden, ein wochenlanger PR-Albtraum. Genau deswegen landen so viele Banken bei der Feiglingsstrategie:

„Wir lassen COBOL laufen, kapseln es mit APIs ein und hoffen, dass niemand tief graben muss.“

Lords of COBOL – alte Götter, neue Panik

Unser Bankensystem hängt in 1959, weil COBOL drei Eigenschaften vereint, die in Kombination toxisch sind:

1. Es funktioniert unfassbar gut für Geld.
   Präzise, schnell, massiv skalierend.
2. Es ist archaisch und überkomplex.
   Alles hängt an historischen Workarounds und Mainframe-Sonderlogik.
3. Das Wissen stirbt schneller, als es nachwächst.
   COBOL-Dev ist kein glamouröser Karriereweg, aber ohne ihn kippt der Laden.

Von außen sieht das alles nach „Digital Banking“ aus. Innen drin sitzt ein COBOL-Monolith auf einem Mainframe und entscheidet, ob eure Karte heute Geld ausspuckt oder nicht.

Die Lords of COBOL sind nicht hip, nicht hübsch und definitiv nicht modern. Stifthalter in der Brusttasche, aber Bankkonto voller Yachten. Solange niemand bereit ist, das Risiko eines echten Neuaufbaus zu tragen, regieren sie weiter: Leise, im Keller, mit Lochkarten-DNA und Batchjobs, die unsere Realität in Zahlen gießen.

Und ihr streicht in der App den Hintergrund von Hell- nach Dark-Mode und nennt das dann „Banken-Transformation“.