Von Bernhard Uitz 

Seit 18 Jahren arbeite ich bei DPS in Projekten unserer Kunden rund um Host- bzw. Mainframe-Systeme – insbesondere im Umfeld von Wertpapierabwicklung. Aus dieser Erfahrung heraus ist für mich klar: T+1 ist kein gewöhnliches Regulierungsprojekt. Es ist ein Stresstest für gewachsene Kernsysteme. 

Im vierten Teil unserer T+1-Serie geht es deshalb um die technische Basis der Umstellung. Nach Scoping, Abhängigkeiten und Umsetzungsfragen rückt nun die Legacy IT in den Fokus. Die High-Level Roadmap des EU T+1 Industry Committee definiert ein klares Zielbild: weitgehende Automatisierung, hohe STP-Quoten, komprimierte Post-Trade-Zeitfenster und klar getaktete Settlement-Cutoffs. Genau hier entscheidet sich, ob bestehende Host-Systeme mithalten können. 

T+1 verkürzt nicht nur Settlement-Zyklen. Es verdichtet die gesamte Post-Trade-Kette – vom End-of-Day-Netting über Matching & Confirmation bis zur finalen depotseitigen Verbuchung. In der Praxis heißt das: Handelszeiten verlängern sich, Verarbeitungszeiten verkürzen sich. 

Tagesendeverarbeitung als kritischer Pfad 

Entscheidend sind die Abwicklungs- und Batchzeiten in der Tagesendeverarbeitung. Orders müssen nach Handelsschluss abgerechnet, bestätigt, intern weitergegeben und depotseitig gebucht werden. Parallel laufen Kapitalmaßnahmenverarbeitung und Stammdatenläufe. 

Diese Massendatenverarbeitung findet überwiegend auf dem Mainframe statt – häufig in COBOL- oder Assembler-Programmen mit IMS- oder DB2-Datenbanken. Das Zeitfenster zwischen Handelsende und Systemhochlauf wird durch T+1 enger. Gleichzeitig steigen Volumen und Komplexität. 

Das Problem ist dabei weniger die durchschnittliche Auslastung als die Verdichtung von Lastspitzen in den Batch-Fenstern. Historisch gewachsene Jobketten mit sequenziellen Abhängigkeiten werden unter T+1 zum kritischen Pfad. Wenn Settlement-Instruktionen rechtzeitig in Richtung Clearing und CSD verarbeitet sein müssen, darf die interne Verbuchung nicht zum Engpass werden.

Realistische Optimierung statt Architektur-Revolution 

In der Diskussion wird häufig eine vollständige Realtime-Transformation ins Spiel gebracht – Event-Driven-Architekturen, Near-Real-Time-Processing oder die Abkehr vom Mainframe. Mit Blick auf 2027 ist das für viele Institute nicht realistisch. 

Stattdessen geht es um belastbare Optimierung im Bestand. 

1. Ein zentraler Hebel ist die Reduktion von Job-Laufzeiten. Dazu gehören Code-Optimierungen, effizientere Datenbankzugriffe, Analyse von I/O-Last sowie das Eliminieren redundanter Verarbeitungsschritte. Gerade in IMS-Umgebungen lassen sich durch Anpassung von Zugriffspfaden oder Commit-Strategien signifikante Effekte erzielen. 
2. Ein zweiter Ansatz ist zusätzliche Rechenkapazität – etwa durch den Zukauf von MIPS zur Abfederung von Peak-Last. Das ist möglich, aber kostenintensiv und keine nachhaltige Lösung. 
3. Der entscheidende Hebel liegt häufig in der Batch-Orchestrierung. Nicht jede Verarbeitung muss strikt sequenziell laufen. Durch Parallelisierung, Priorisierung und gezielte Ressourcensteuerung lassen sich Lastspitzen glätten. Moderne Workload-Management-Konzepte ermöglichen es, unkritische Jobs dynamisch zu verschieben und den settlement-relevanten Pfad zu stabilisieren. 

Hybridarchitekturen im Blick behalten 

Hinzu kommt die zunehmende Hybridisierung der Anwendungslandschaft. Mainframe-Systeme interagieren mit Middleware, dezentralen Anwendungen oder Cloud-Komponenten. Unter komprimierten Settlement-Fenstern werden Latenzen zwischen diesen Systemen spürbarer. 

T+1 verlangt daher nicht nur schnellere Batchläufe, sondern ein sauberes End-to-End-Verständnis der gesamten Post-Trade-Prozesskette – von STP-Quoten im Trade Matching bis zur konsistenten Bestandsführung im Kernsystem. 

Auch das Thema Know-how ist ein begrenzter Faktor. Performance-Optimierung in z/OS-Umgebungen oder in Assembler-nahen Komponenten erfordert spezialisiertes Plattformwissen. Dieses Know-how ist nicht beliebig skalierbar. Wer Optimierungsbedarf zu spät erkennt, gerät unter erheblichen Zeitdruck. 

Mein klares Fazit: T+1 ist kein Architektur-Neustart. Es ist ein Belastungstest für bestehende Kernsysteme. Entscheidend ist, ob Institute ihre Tagesende- und Batch-Verarbeitung so steuern können, dass Settlement-Cutoffs eingehalten, Clearing-Prozesse unterstützt und Bestände konsistent geführt werden.

Die gewachsene IT-Architektur von Wertpapierinstituten ist daher kein Auslaufmodell, sondern kann weiterhin als operatives Rückgrat des Securities Settlement fungieren. Und während T+0 möglicherweise eine echte Realtime-Transformation erfordert, entscheidet sich T+1 an einer deutlich pragmatischeren Frage: Wie robust ist Ihre Batch-Orchestrierung?