Katalog / Prognose- und Vorhersage-Anwendungsfälle / PRED-035

Prognose von Wertpapier-Abwicklungsfehlern und Management von Post-Trade-Ausnahmen

Vorhersage, welche Wertpapiergeschäfte am vorgesehenen Abwicklungstag nicht abgewickelt werden, und Priorisierung der Post-Trade-Ausnahmen, damit Abwicklungsteams sie vor dem Annahmeschluss beheben können.

Jedes Wertpapiergeschäft, das nicht am vorgesehenen Tag abgewickelt wird, bindet Liquidität und Bestände, verursacht Strafzahlungen und Finanzierungskosten und beansprucht Arbeitszeit der Abwicklungsteams. Die Prognose von Abwicklungsfehlern bewertet jede offene Instruktion Stunden oder Tage vor der Abwicklung anhand von Merkmalen zu Gegenpartei, Instrument, Bestand, SSI und Matching-Status und ordnet dann die Ausnahmewarteschlange, sodass knappe Abwicklungskapazität auf die Geschäfte entfällt, die tatsächlich scheitern werden, und Korrekturen (SSI-Korrektur, Leihe, Teilabwicklung) vor dem Annahmeschluss erfolgen. Da die EU den Wechsel zu einem eintägigen Abwicklungszyklus (T+1, Zieldatum 11. Oktober 2027) plant, schrumpft das Zeitfenster für manuelle Korrekturen stark; die Priorisierung wird damit zu einer zentralen betrieblichen Fähigkeit.

Problem & Nutzen

  • Heute: Die Abwicklungsteams bei Banken, Brokern, Vermögensverwaltern und Verwahrstellen arbeiten statische tägliche Klärfalllisten ab: nicht gematchte oder nicht bestätigte Instruktionen, fehlende Wertpapiere, fehlende Liquidität, SSI-Abweichungen. Priorisiert wird nach Geschäftsgröße oder Alter, nicht nach der Wahrscheinlichkeit des Scheiterns.
  • Kosten eines Abwicklungsfehlers: Im EU-Regime der Abwicklungsdisziplin nach CSDR (Verordnung (EU) 909/2014) ziehen verspätetes Matching und Abwicklungsfehler tägliche Geldstrafen nach sich, die der Zentralverwahrer erhebt, zusätzlich zu Finanzierungs- und Betriebskosten. Das verpflichtende Buy-in-Element wurde durch spätere Reformen faktisch abgeschafft (prüfen Sie den aktuellen Stand, bevor Sie sich darauf verlassen).
  • KI-Nutzen: Eine kalibrierte Wahrscheinlichkeit je Instruktion erlaubt es den Teams, (1) die riskantesten Fälle zuerst zu bearbeiten, (2) automatische vorbeugende Maßnahmen auszulösen, (3) das Strafzahlungsrisiko zu prognostizieren und (4) strukturelle Ursachen zu erkennen (eine Verwahrkette, eine Instrumentenklasse, der Annahmeschluss eines Marktes), die Prozessänderungen rechtfertigen.
  • Warum jetzt: Kürzere Abwicklungszyklen nehmen die nächtliche Korrekturzeit weg, die T+2 erlaubte. Die Auswirkungsanalysen von Branche und Aufsicht zu T+1 nennen immer wieder Affirmation, Allokation, SSI-Qualität, Bestands-/Devisenfinanzierung und Automatisierung als Erfolgsfaktoren; genau das sind die Merkmale des Modells. Hier wird kein quantifizierter Nutzen behauptet; messen Sie ihn an Ihrer eigenen Historie (siehe Kennzahlen).

Varianten

  • Broker/Händler oder Investmentbank: prognostiziert Fehler auf Kunden- und Marktseite; Anbindung an den Bereich Wertpapierleihe und Repo-Finanzierung.
  • Verwahrstelle / globale Verwahrstelle: prognostiziert Fehler je Unterverwahrer-Markt und Kunde; nutzt Statusnachrichten auf Instruktionsebene von vielen Zentralverwahrern.
  • Vermögensverwalter: konzentriert sich auf die Rechtzeitigkeit von Allokation/Affirmation und das Ranking der Qualität von Gegenparteien/Brokern, besonders bei T+1 über Zeitzonen hinweg (US-/Asien-Fonds, die EU-Wertpapiere handeln).
  • Zentralverwahrer / Marktinfrastruktur: systemweite Analysen der Abwicklungseffizienz und Teilnehmer-Dashboards (aggregiert, keine Empfehlungen auf Instruktionsebene an Teilnehmer).
  • Kein Anwendungsfall für Privatpersonen; Privatanleger sehen das Ergebnis nur als abgewickelte Order.
  • Abgedeckte Varianten: prädiktive Empfehlung „Teilabwicklung oder Leihe“ und LLM-gestützte Ausnahmeklassifizierung (Lesen von E-Mails/Chats der Gegenpartei zur Ursachenbestimmung), beide als Module derselben Pipeline.

So funktioniert es

  1. trade capture / OMS / allocations
  2. status ingestion (matching, affirmation, SSI, hold/release, partial, cash/credit) via ISO 20022 / SWIFT / CSD APIs
  3. feature store (counterparty history, instrument liquidity & lendability, time-to-cut-off, SSI age & change flags, market calendar)
  4. fail model (gradient boosting; probability + SHAP drivers; re-scored on every status event)
  5. exception prioritiser (expected penalty + funding cost × probability, within SLA window)
  6. action engine (rules + optional LLM agent: correct SSI, request borrow, chase counterparty, allow partial settlement)
  7. human review for high-value / non-standard cases
  8. feedback of outcome labels into training
  • Kernmodell: überwachte Klassifikation auf Tabellendaten; Label = Instruktion wurde am vorgesehenen Abwicklungstag nicht abgewickelt (oder um n Tage verspätet). Zeitbewusste Validierung ist unerlässlich (auf früheren Zeiträumen trainieren, auf späteren testen).
  • Kalibrierung: Die Abwicklung braucht Wahrscheinlichkeiten, keine Scores; wenden Sie isotone oder Platt-Kalibrierung an und überwachen Sie die Drift.
  • LLM-Schicht (optional): klassifiziert freitextliche Ausnahmegründe aus E-Mails/Chats und entwirft Nachfass-Nachrichten an die Gegenpartei. Sie ändert nie Instruktionen; Änderungen laufen über den bestehenden Workflow mit Vier-Augen-Freigabe.
  • Mensch-in-der-Schleife (Human-in-the-Loop): Die Abwicklungsmitarbeitenden verantworten alle Abwicklungsinstruktionen und Stornierungen; das System gibt Empfehlungen.

Datenaufbereitung

Benötigt werden Handels- und Allokationsdaten, Abwicklungsinstruktionen und Statusnachrichten (ISO 20022 sese / SWIFT MT54x), Standard-Abwicklungsinstruktionen, Bestands- und Liquiditätspositionen sowie historische Fehler mit Strafzahlungen. Sie liegen typischerweise im Abwicklungssystem des Back-Office, im Order-Management-System, in den Portalen von Verwahrstellen und Zentralverwahrern und teilweise in E-Mails und Excel-Ausnahmelisten.

Typische Lücken: Fehlerursachen nur als Freitext erfasst, uneinheitliche Kennungen der Gegenparteien (LEI, BIC, interne IDs), Stammdatenänderungen ohne Historie, Statusnachrichten je Zentralverwahrer in unterschiedlichen Formaten, E-Mail-Nachfassaktionen ohne Verknüpfung zur Instruktion sowie Zugriffsrechte zwischen Front- und Back-Office.

Konkrete Schritte: eine einheitliche Instruktionstabelle durch Verknüpfen von Nachrichten und Geschäften aufbauen (PREP-005); Kennungen der Gegenparteien und Fehlerursachen-Codes vereinheitlichen (PREP-019); Labels (fehlgeschlagen oder abgewickelt, Ursache) aus historischen Datensätzen gewinnen (PREP-020); Kennzahlen wie Fehlerquote und Strafzahlungsrisiko definieren (PREP-012); Nachfass-E-Mails mit einem LLM auswerten (DOC-014); einen zeitbasierten Hold-out-Datensatz bereithalten (PREP-018). Werkzeuge: SQL oder ein Data Warehouse, Python, Nachrichten-Parser. Rechnen Sie mit etwa 30-40 % des Aufwands. Siehe GUIDE-003.

Umsetzungswege

Welcher Weg für wen

  • enterprise: B - das Modell muss in eigene Abwicklungs-, Stammdaten- und Messaging-Systeme integriert werden, und kein Produkt deckt die Gegenparteien und den Zentralverwahrer-Mix jedes Hauses ab; Cloud-KI-Dienste für den Sprachteil und eigene Tabellenmodelle halten den Aufwand moderat.
  • developer: C - Tabellenmodelle und Open-Source-Werkzeuge für Streaming und Orchestrierung laufen auf HW1 und halten die Handelsdaten in der eigenen Umgebung.

Weg A — Kaufen (Standardsoftware)

  • Post-Trade- und Abstimmungsplattformen mit ML-/Analytik-Modulen: SmartStream, Broadridge, SS&C, Nasdaq Adenza (Calypso), Murex, Torstone und ähnliche Anbieter bieten Abwicklungs-Dashboards und prädiktive Ausnahmemodule; Marktinfrastruktur-Analysen von Euroclear, Clearstream (Deutsche Börse) und DTCC sind für die EU bzw. global relevant. Funktionsumfang und Produktnamen ändern sich schnell, prüfen Sie daher je Anbieter.
  • Wählen Sie A, wenn: Sie bereits eine dieser Plattformen betreiben und ein prädiktives Modul ein Upgrade darstellt; Anbietermodelle lernen über Kunden hinweg, Sie müssen aber die Bedingungen zur Datenweitergabe und das EU-Hosting prüfen.

Weg B — Auf Cloud-KI-Diensten aufbauen (für die meisten Häuser mit Datenteam empfohlen)

  • Datenplattform: Lakehouse in einer EU-Region (Azure, AWS Frankfurt, Google Cloud europe-west3 oder souveräne EU-Angebote) mit Streaming-Erfassung der Statusnachrichten.
  • Modellierung: verwaltetes AutoML oder Notebooks mit XGBoost/LightGBM; MLflow zur Nachverfolgung.
  • LLM-Schicht: Frontier- oder EU-LLM-Schnittstellen (z. B. Mistral, Claude, GPT über EU-Regionen) mit strukturierter Ausgabe zur Klassifizierung der Ausnahmeursache.
  • Integration: Vorhersagen in das bestehende Klärfall- oder Workflow-Werkzeug einspielen.

Weg C — Selbst betreiben (Open Source)

  • Stack: XGBoost (Apache-2.0), LightGBM (MIT), scikit-learn (BSD-3), SHAP (MIT), MLflow (Apache-2.0), Kafka/Flink oder Ähnliches für Ereignisse, PostgreSQL/ClickHouse als Feature Store.
  • Hardware: Das Tabellenmodell läuft auf CPU-Servern (HW1); ein kleines Open-Weight-LLM (HW2) wird nur für die optionale Freitext-Klassifizierung benötigt. Viele Banken betreiben dies On-Premises, weil Instruktionsdaten geschäftlich sensibel sind.
  • Betriebsaufwand: ein kleines MLOps-Team; in Banken gilt das Modellrisikomanagement (SR 11-7-artig oder internes MRM).

Weg D — Eigenes Training

Dies ist der klassische Weg: Die Modelle werden auf der eigenen Instruktionshistorie des Hauses trainiert, weil Fehlermuster hausspezifisch sind (Gegenparteimix, Märkte, Workflows). Nützliche Ergänzungen: Überlebenszeit- bzw. Time-to-Settle-Modelle, Graph-Merkmale über die Kette aus Gegenpartei/Verwahrstelle und kostensensitives Lernen, das große und strafzahlungsintensive Fehler stärker gewichtet. Benötigt wird typischerweise eine Historie von 1–3 Jahren auf Instruktionsebene mit Fehler-Labels; das Ungleichgewicht seltener Ereignisse ist das Hauptproblem der Modellierung.

Stand der Technik (2026)

  • Gradient-Boosting-Bäume bleiben das Arbeitspferd für strukturierte Post-Trade-Daten; tiefe Modelle und Foundation-Modelle bringen wenig, es sei denn, Text oder Sequenzen sind wichtig.
  • Ereignisgesteuerte Neubewertung bei jeder Statusänderung (gematcht, bestätigt, SSI geändert, Leihe bestätigt) schlägt einen einzelnen nächtlichen Score.
  • Erklärbarkeit (SHAP) wird genutzt, um einen Score in eine betriebliche Maßnahme zu übersetzen: „SSI vor 2 Tagen geändert“, „Affirmation der Gegenpartei meist verspätet“, „Instrument schwer zu leihen“.
  • LLM-Agenten werden für Ausnahmeklassifizierung und Kommunikation mit Gegenparteien pilotiert; zuverlässig nur mit eng begrenzten Werkzeugen und menschlicher Freigabe.
  • T+1-Kontext: Die USA wechselten im Mai 2024 zu T+1; die EU und das Vereinigte Königreich bereiten einen koordinierten Wechsel vor (EU-Zieldatum 11. Oktober 2027 laut Gesetzesänderung der CSDR; bestätigen Sie den endgültigen Rechtstext). Marktinfrastrukturen veröffentlichen Analysen zur Abwicklungseffizienz, und Branchenverbände veröffentlichen Leitfäden zur T+1-Bereitschaft, die nützliche Quellen für Merkmale und Vergleichswerte sind.
  • Grenzen: Fehler sind seltene Ereignisse mit starkem Klassenungleichgewicht; externe Ursachen (Marktstress, Ausfälle von Zentralverwahrern, Kapitalmaßnahmen) sind schwer vorherzusagen; Modelldrift nach Änderungen der Marktstruktur (der T+1-Wechsel selbst) erfordert Nachtraining mit Daten nach dem Wechsel; Merkmale, die auf dem Verhalten von Gegenparteien beruhen, können manipuliert werden oder veralten. Öffentlich bewertete Vergleichsdatensätze gibt es nicht; Herstellerangaben sind nicht unabhängig vergleichbar.
  • Recherchelücke in dieser Datei: Das Kontingent der Websuche war beim Schreiben erschöpft, daher wurden anbieterspezifische Messergebnisse, ML-Veröffentlichungen von DTCC/Euroclear und ESMA-Statistiken nicht erneut verifiziert. Behandeln Sie sie als Hinweise zum Nachprüfen, nicht als Tatsachen.

Gemeinsame Bausteine & Kombinationen

  • Gleicher Stack aus tabular-ml + time-series: PRED-009 (Kredit-/Ausfall-Scoring), PRED-016 (Cashflow- und Liquiditätsprognose, die prognostizierte Fehler nutzt, um Finanzierungsbedarf vorherzusagen), PRED-021 (Zahlungsverhalten).
  • Angrenzende Post-Trade-/Finanz-Anwendungsfälle: AGENT-006 (Abstimmungs- und Abschluss-Agent), ANOM-012 (Marktmissbrauch und Handelsüberwachung; getrennte Verantwortung beibehalten), ANOM-006 (Buchungsanomalien), AGENT-002 (Workflow-Automatisierung im Back-Office).
  • Gemeinsame Bausteine: Event-Streaming (Kafka), Feature Store, MLflow-Modellregister, Workflow-Engine (n8n/Camunda oder das BPM der Bank), CPU- oder bescheidene GPU-Knoten (HW1; HW2, wenn eine LLM-Klassifizierungsschicht ergänzt wird).
  • Dokumentenseite: DOC-008 / DOC-014 zum Auswerten von E-Mails der Gegenpartei, Bestätigungen und SSI-Dokumenten, die den Textklassifikator für Ausnahmen speisen.

Aufwand, Kosten & Kennzahlen

  • Weg A: Wochen bis wenige Monate für Konfiguration und Daten-Feeds; Lizenz je Plattform.
  • Weg B: grob 3–6 Monate für Datenerfassung, Labeling, Modell, Integration und MRM-Validierung.
  • Weg C/D: ähnlicher Aufwand plus Infrastruktur; Hauptkosten sind Data Engineering und Modell-Governance, nicht Rechenleistung.
  • Kennzahlen: Abwicklungseffizienzquote (nach Wert und Volumen), Fehlerquote nach Markt/Gegenpartei/Instrument, CSDR-Strafkosten, Finanzierungskosten von Fehlern, Precision/Recall und Kalibrierung des Fehlermodells am betrieblichen Schwellenwert, Anteil der vor dem Annahmeschluss behobenen Fehler, manuelle Eingriffe je Geschäft, Alter der Klärfälle.

Menschen & Veränderung

Beziehen Sie die Geschäftsleitung und die Leitung der Abwicklung als Verantwortliche ein, die Mitarbeitenden für Abwicklung und Ausnahmen als tägliche Anwender, die IT für Nachrichten-Feeds und Integration, die IT-Sicherheit und Recht/Compliance (DORA, Auslagerungsregeln für die Cloud-Nutzung) sowie den/die Datenschutzbeauftragte(n) bei personenbezogenen Daten in E-Mails oder Kundennamen. Beginnen Sie mit dem Ausnahmeteam, bevor Sie die Warteschlange entwerfen, denn es kennt die wahren Fehlerursachen.

Betriebsrat: hängt vom Einzelfall ab. Die priorisierte Warteschlange und Aktivitätsprotokolle können zeigen, wer welche Ausnahme wie schnell bearbeitet hat; damit ist das System objektiv zur Leistungsüberwachung geeignet (§87 Abs. 1 Nr. 6 BetrVG, BAG); eine Betriebsvereinbarung, die die individuelle Leistungsbewertung ausschließt, ist ratsam. Informieren Sie ihn zudem nach §90 Abs. 1 Nr. 3 und ziehen Sie einen Sachverständigen nach §80 Abs. 3 in Betracht. Handelsdaten sind überwiegend nicht personenbezogen; eine DSFA ist normalerweise nicht erforderlich, wenn kein Scoring von Beschäftigten erfolgt.

KI-Kompetenz: Unterstützen Sie die Abwicklungsmitarbeitenden mit einer Schulung zu Wahrscheinlichkeiten und Automation Bias (GUIDE-006). Pilotieren Sie an einem Markt oder Zentralverwahrer im Schattenbetrieb und vergleichen Sie Vorhersagen mit tatsächlichen Fehlern. Typische Sorge: „Die Warteschlange diktiert meine Arbeit“ - die Mitarbeitenden können Prioritäten übersteuern, und zunächst läuft keine automatische Maßnahme ohne Freigabe. Siehe GUIDE-004, GUIDE-008 und GUIDE-009.

Risiken, Regulierung & Compliance

  • KI-Verordnung (AI Act): im typischen Fall minimales Risiko. Das Modell bewertet Geschäfte, keine natürlichen Personen; Anhang III nennt das Kredit-Scoring natürlicher Personen und Sicherheitsbauteile kritischer Infrastruktur, von denen keines das Scoring des Abwicklungsbetriebs auf Geschäftsebene abdeckt [1]. Vorbehalt: Wenn Scores auf Ebene der Gegenpartei natürliche Personen profilieren (z. B. einzelne Händler), gilt nach Art. 6 Abs. 3 Profiling immer als Hochrisiko [2]. Die KI-Kompetenz (Art. 4) gilt.
  • Finanzregulierung: CSDR-Abwicklungsdisziplin (VO 909/2014 und Änderungen), Übergangsregeln zu T+1, DORA (IKT-Risiko, Register der Drittanbieter und Auslagerungen für Cloud- und Anbietermodelle), MiFID II Best Execution/Aufzeichnungspflichten, Modellrisiko-Governance der Banken.
  • DSGVO: überwiegend institutionelle Daten (gdpr_personal_data: no); personenbezogene Daten können in Kundennamen oder Kontoreferenzen einzelner Kunden auftauchen – in den Merkmalen pseudonymisieren.
  • Betriebliche Risiken: falsch negative Ergebnisse bei großen Geschäften; automatisierte Maßnahmen auf veralteten Daten; übermäßiges Vertrauen in das Modell bei Marktstress. Gegenmaßnahmen: Schwellenwerte, Not-Aus, Drift-Überwachung, menschliche Freigabe für Stornierungen/Änderungen, Audit-Log von Empfehlung gegenüber Maßnahme.
  • Vertraulichkeit der Daten: Instruktionsdaten sind geschäftlich sensibel; bevorzugen Sie EU-Hosting oder On-Premises; prüfen Sie Klauseln des Anbieters zum gepoolten Lernen.

Erste Schritte

  1. Extrahieren Sie 12–24 Monate Daten auf Instruktionsebene mit endgültigem Abwicklungsergebnis und Zeitstempeln der Statusnachrichten; definieren Sie das Fehler-Label (vorgesehener Abwicklungstag gegenüber tatsächlichem).
  2. Ermitteln Sie die Ausgangslage des aktuellen Prozesses: Fehlerquote, Strafzahlungen, manuelle Eingriffe und welche Korrekturen wirken (SSI-Korrektur, Leihe, Teilabwicklung).
  3. Trainieren Sie eine zeitlich getrennte LightGBM-/XGBoost-Basislinie mit SHAP; kalibrieren Sie sie; vergleichen Sie sie mit der einfachen Rangfolge nach Alter/Größe.
  4. Betreiben Sie sie 4–8 Wochen im Schattenbetrieb, pilotieren Sie dann die priorisierte Warteschlange mit einem Abwicklungsteam und messen Sie die Korrekturquote vor dem Annahmeschluss.
  5. Ergänzen Sie ereignisgesteuerte Neubewertung und automatisierte Maßnahmen mit geringem Risiko; dokumentieren Sie unter Modellrisiko- und DORA-Kontrollen vor dem T+1-Wechsel.

Quellen

  1. AI Act Annex III (high-risk areas) — https://artificialintelligenceact.eu/annex/3/
  2. AI Act Article 6 (classification, Art. 6(3) derogation and profiling rule) — https://artificialintelligenceact.eu/article/6/
  3. ECB — TARGET2-Securities (T2S; partial settlement, DvP in central bank money) — https://www.ecb.europa.eu/paym/target/t2s/html/index.en.html
  4. XGBoost — https://github.com/dmlc/xgboost
  5. LightGBM — https://github.com/microsoft/LightGBM
  6. SHAP — https://github.com/shap/shap
  7. MLflow — https://github.com/mlflow/mlflow
  8. scikit-learn — https://github.com/scikit-learn/scikit-learn
  9. DTCC — US Treasury clearing and T+1 context page — https://www.dtcc.com/ust1
  10. Regulation (EU) 909/2014 (CSDR) — https://eur-lex.europa.eu/eli/reg/2014/909/oj (page content not retrievable in this session; cited for the legal basis only)