Best-Execution-Nachweis mit LLM-Agenten: MiFID-II-Reporting 2026 ohne RTS-27-Falle

Warum Best Execution 2026 neu gedacht werden muss

Die Lage ist unübersichtlich geworden. RTS 27, jahrelang das verhasste Quartals-Reporting für Handelsplätze, ist seit 2021 ausgesetzt und mit dem MiFIR-Review faktisch erledigt. RTS 28, das jährliche Top-5-Venue-Reporting der Wertpapierfirmen, wurde von der EU-Kommission im Rahmen des MiFID-II-Quick-Fix gestrichen. Wer jetzt aufatmet, hat den Kern verpasst.

Die Nachweispflicht für Best Execution selbst (Artikel 27 MiFID II) ist nicht weg. Sie ist nur entformularisiert. ESMA hat in den Q&A und in den 2024 finalisierten Leitlinien zu Best Execution klar gemacht: Wertpapierfirmen müssen weiterhin belegen, dass sie hinreichende Schritte unternommen haben, um das bestmögliche Ergebnis für den Kunden zu erzielen. Auf Anfrage. Mit Daten. Pro Kundenauftrag, wenn es darauf ankommt.

Das ist die schlechte Nachricht. Die Standard-Templates sind weg, aber die Beweislast hat sich verschoben. Statt einmal im Jahr ein PDF zu erzeugen, müssen Broker und Banken jederzeit nachweisbereit sein. Bei Kundenbeschwerden. Bei BaFin-, FMA- oder FINMA-Anfragen. Bei internen Audits. Das ist keine geringere Pflicht, das ist eine schwerere.

Manuell wird das nicht funktionieren. Ein mittelgroßer Broker mit 200.000 Kundenaufträgen pro Monat über fünf bis acht Handelsplätze produziert Datenmengen, die kein Compliance-Team in akzeptabler Latenz aufbereiten kann. Genau hier setzen LLM-gestützte Reporting-Pipelines an. Aber nur, wenn sie richtig gebaut sind.

Was ein LLM-Agent im Execution-Reporting leisten kann und was nicht

Fangen wir mit dem an, was LLMs gut können. Sie strukturieren unstrukturierte Daten. Venue-Reports, Market-Data-Auszüge, OMS-Exports, Beschwerdetexte, interne Policy-Dokumente. Das alles zu einem kohärenten Narrativ zu verdichten, das die Frage „Warum wurde dieser Auftrag an Venue X geleitet?" sauber beantwortet, ist eine Aufgabe, für die Sprachmodelle gemacht sind.

Was LLMs schlecht können: rechnen. Genauer gesagt, verlässlich rechnen. Ein Sprachmodell, das den volumengewichteten Durchschnittspreis von 47 Teilausführungen über drei Handelsplätze ermittelt, ist ein Compliance-Risiko. Nicht in 95 Prozent der Fälle. In genau den 5 Prozent, in denen es darauf ankommt.

Die Konsequenz ist klar: Numerische Operationen gehören in deterministische Module. SQL, Python, dedizierte Berechnungs-Engines. Das LLM übernimmt die Narrativ-Generierung, den Policy-Abgleich, die Strukturierung. Es entscheidet nicht über Preisvergleiche und es führt keine Ausführungslogik aus. Wer ein LLM als Execution-Decision-Engine einsetzt, hat MiFID II nicht verstanden.

Klare Rollentrennung also: Das LLM ist ein Reporting-Layer. Es übersetzt geprüfte Zahlen in prüfbare Sätze. Mehr nicht. Aber das ist viel.

Die LLM-Pipeline: Architektur für revisionssichere Execution-Quality-Reports

Eine produktive Pipeline besteht aus fünf Schritten. Jeder davon ist nicht verhandelbar, wenn das Ergebnis auditfähig sein soll.

Schritt 1: Datenbeschaffung mit klarer Ground Truth. Die Quelldaten kommen aus dem OMS, dem EMS, den Venue-Reports und einer Market-Data-API für Referenzpreise. Diese Daten werden in einem Reporting-Datawarehouse normalisiert. Das LLM bekommt nie direkten Zugriff auf Produktiv-Handelssysteme. Punkt. Es liest aus dem Warehouse.

Schritt 2: Retrieval-Augmented Generation. Das Modell arbeitet ausschließlich auf retrieved Context. Konkret heißt das: Für jeden zu erklärenden Auftrag werden die relevanten Datensätze (Order, Teilausführungen, Venue-Quotes zum Zeitpunkt, Best-Execution-Policy-Snippet) per Retrieval bereitgestellt. Das LLM generiert das Narrativ. Wenn ein Datum nicht im Retrieval-Kontext ist, darf es nicht im Report stehen.

Schritt 3: Planner-Executor-Trennung. Ein Planungsagent definiert die Report-Struktur: Welche Felder werden benötigt? Welche Vergleichswerte? Welche Policy-Referenzen? Der Ausführungsagent füllt diese Struktur, aber nur innerhalb der validierten Datenräume. Das ist keine theoretische Architekturwahl. Es ist der Mechanismus, der verhindert, dass das Modell „kreativ" wird.

Schritt 4: Halluzinationskontrolle über numerische Assertions. Jede Zahl, die im LLM-Output erscheint, wird gegen die Quelldaten geprüft. Wenn das Modell schreibt „Der gewichtete Durchschnittspreis betrug 47,32 EUR", dann läuft im Hintergrund ein Validator, der diesen Wert aus dem Warehouse nachberechnet. Stimmt es nicht überein, wird der Report nicht freigegeben. Diese Grounding-Layer ist der Unterschied zwischen produktionsreif und Demoware.

Schritt 5: Audit-Trail mit Quellreferenz. Jeder Satz im finalen Report bekommt eine Quellreferenz auf den zugrundeliegenden Datensatz. Jede LLM-Generation wird mit Prompt, Modellversion, Retrieval-Kontext und Konfidenz-Indikator protokolliert. Bei einer Aufsichtsanfrage muss man in der Lage sein zu zeigen: Diese Aussage stammt aus diesem Datensatz, generiert mit diesem Modell, geprüft durch diesen Validator.

Halluzinationskontrolle bei Multi-Venue-Preisvergleichen: Das Kernproblem

Der kritische Punkt sind Preisvergleiche über mehrere Handelsplätze. Genau hier wird Best Execution sichtbar oder unsichtbar.

Stellen Sie sich einen typischen Fall vor: Ein Retail-Auftrag über 5.000 Stück einer DAX-Aktie wird zur Ausführungszeit T an Xetra geroutet. Zur gleichen Zeit gab es auf CBOE Europe und Aquis Quotes. Die Frage des Kunden zwei Monate später: Warum nicht CBOE? Dort war der Spread enger.

Die Antwort muss faktisch korrekt sein. Es reicht nicht, dass sie plausibel klingt. Ein LLM, das hier frei generiert, schreibt vielleicht „Zum Zeitpunkt der Ausführung war Xetra der Handelsplatz mit der höchsten Liquidität und dem engsten Spread". Das mag stimmen. Es mag auch nicht stimmen. Ohne harten Datenabgleich ist diese Aussage Compliance-Russisches Roulette.

Drei Kontrollmechanismen sind hier Pflicht:

Structured Output mit Schema-Validation. Das LLM liefert nicht Freitext, sondern JSON gegen ein striktes Schema. Felder wie bestquote_xetra, bestquote_cboe, executed_price, slippage_bps sind typisiert. Werte ausserhalb plausibler Ranges werden vom Validator zurückgewiesen.

Cross-Check-Agent. Ein zweiter Agent prüft den Output des ersten gegen die Rohdaten. Wenn Agent 1 behauptet, der CBOE-Spread sei höher gewesen, dann zieht Agent 2 die Quote-Historie und verifiziert. Bei Abweichung wird eskaliert.

Human-in-the-Loop-Trigger. Bei definierten Schwellenwerten (Auftragsvolumen über X, Slippage über Y bps, Kundentyp Professional) wird der Report nicht automatisch freigegeben, sondern landet bei einem Compliance-Officer. Das ist keine Bremse, das ist die Versicherung.

Die Preisberechnung selbst gehört nie zum LLM. VWAP, Spread, Slippage werden in einem deterministischen Python- oder SQL-Modul berechnet. Das Modell beschreibt das Ergebnis, es produziert es nicht.

Die RTS-27-Falle: Warum alte Report-Templates gefährlich werden

Ein verbreiteter Fehler bei aktuellen LLM-Implementierungen: Die Entwickler nehmen alte RTS-27- und RTS-28-Templates und bauen sie in Prompts ein. Die Logik dahinter ist verständlich. Es gibt etablierte Felder, etablierte KPIs, etablierte Formulierungen. Warum das Rad neu erfinden?

Weil das Rad weg ist. RTS 27 verlangte quartalsweise Veröffentlichung von Ausführungsqualität nach standardisierten Tabellen. Diese Pflicht existiert nicht mehr. Wer in 2026 Reports nach diesem Schema produziert, dokumentiert nicht Compliance, sondern Realitätsverlust. Schlimmer noch: Manche der alten KPIs (etwa bestimmte Latenz-Metriken auf Venue-Ebene) sind in der heutigen Marktstruktur nicht mehr sinnvoll definierbar.

Was das aktuelle Regime verlangt, ist deutlich anders strukturiert:

• Eine Best Execution Policy, die nachvollziehbar erklärt, wie die Firma Ausführungsplätze auswählt und nach welchen Faktoren (Preis, Kosten, Geschwindigkeit, Wahrscheinlichkeit der Ausführung, Settlement) gewichtet wird.
• Periodic Disclosure in deutlich reduzierter Form, primär in Richtung Kunden über die Ausführungs-Policy.
• On-Request-Nachweis für einzelne Ausführungen. Das ist der eigentliche Hebel und der eigentliche Aufwandstreiber.
• Monitoring-Pflicht: Die Firma muss kontinuierlich die Qualität der Ausführungsplätze überwachen und ihre Policy bei Bedarf anpassen.

Das Reporting verschiebt sich also von „regelmäßiges Pflicht-PDF" zu „dauerhafte Nachweisbereitschaft". Die LLM-Pipeline muss darauf ausgelegt sein. On-Demand-Generierung pro Auftrag, nicht Batch-Reports pro Quartal.

Praktische Checkliste für die Template-Bereinigung:

• Felder wie Bid-Ask-Spread, ausgeführte Volumina, Anzahl Aufträge: weiterhin relevant, jetzt aber pro Anfrage statt pro Quartalstabelle.
• Latenz-Statistiken auf Mikrosekunden-Ebene nach altem RTS-27-Format: nicht mehr Pflicht, oft technisch fragwürdig.
• Likelihood-of-Execution-Quoten: weiterhin sinnvoll als Monitoring-KPI, aber nicht in der alten Tabellenstruktur.
• Venue-Ranking nach Volumen (Top 5): de jure weg, de facto in vielen Häusern weiterhin als internes Monitoring sinnvoll.

Implementierungspfad für Broker und Banken: Von der Pilotphase zur Produktion

Wer das jetzt umsetzen will, sollte nicht mit dem ehrgeizigsten Use-Case starten. Mein Vorschlag in drei Phasen.

Phase 1: Scoping mit Klassifikationsmatrix. Welche Report-Typen sind überhaupt LLM-tauglich? Kriterien: Strukturiertheit der Eingabedaten, Häufigkeit, regulatorische Kritikalität, Anteil numerischer vs. narrativer Inhalte. On-Request-Erklärungen für Retail-Aufträge im Standardhandel: gut geeignet. Komplexe Block-Trade-Erklärungen mit OTC-Komponenten: erst später, viel mehr Human-in-the-Loop. Diese Matrix ist keine Akademie-Übung. Sie verhindert, dass Phase 2 in einem Sumpf endet.

Phase 2: Proof of Concept mit Parallellauf. Drei Monate lang werden LLM-generierte Reports neben den bestehenden manuellen Reports erzeugt. Nicht produktiv ausgeliefert, sondern intern verglichen. Wo weichen sie ab? Sind die Abweichungen Verbesserungen oder Fehler? Wie oft greift der Validator ein? Wie oft eskaliert die Pipeline an einen Menschen? Diese Zahlen sind die Grundlage für die Go-Live-Entscheidung. Ohne harte Vergleichsdaten ist jede Aussage zur Auditfähigkeit Spekulation.

Phase 3: Governance-Integration. Wer zeichnet LLM-generierte Reports formal ab? Das ist keine technische, sondern eine organisatorische Frage. Die Model-Risk-Policy muss angepasst werden. Das LLM-System wird als Modell im Sinne der Model-Governance behandelt. Mit allem, was dazugehört: Validierung, Performance-Monitoring, Periodic Review, Change-Management bei Modell-Updates. Ein Wechsel von GPT-4 auf GPT-5 oder von Claude 3.5 auf 4 ist nicht „Update der IT-Infrastruktur". Es ist ein Modellwechsel mit Validierungspflicht.

Stolpersteine, die ich immer wieder sehe:

• Vendor-Lock-in. Wer die gesamte Pipeline auf ein Modell eines Anbieters aufbaut, ist erpressbar bei Preisänderungen und liefert das Risiko mit, dass eine Modell-Deprecation die Compliance-Funktion kippt. Modell-Abstraktion einbauen.
• Modell-Drift. Anbieter ändern Modellverhalten ohne Vorankündigung. Eine Pipeline, die heute saubere Reports liefert, kann in drei Monaten anders formulieren. Regression-Tests mit Gold-Standard-Beispielen sind Pflicht.
• Regulatorische Änderungen. ESMA, BaFin und FMA arbeiten weiter an Leitlinien. Die Pipeline muss so gebaut sein, dass Policy-Updates ohne Modell-Retraining funktionieren. Policy als versionierter Retrieval-Kontext, nicht als hartcodierter Prompt.

Regulatorische Risiken und nächste Schritte

Die Haftungsfrage ist offen und gleichzeitig klar. Offen, weil es keine Präzedenzfälle gibt. Klar, weil die Verantwortung in jedem Fall bei der Wertpapierfirma liegt, nicht beim KI-Anbieter. Wer einen fehlerhaften Best-Execution-Nachweis vorlegt, kann sich nicht auf „das Modell hat das so generiert" zurückziehen. Die Geschäftsleitung haftet für die Eignung der eingesetzten Systeme. Das ist in MiFID II, in den ESMA-Leitlinien und in den nationalen Umsetzungen identisch geregelt.

Dokumentationsanforderungen werden über mehrere Regime hinweg relevant: MiFID II für die Ausführungsqualität selbst, DORA für die operationelle Resilienz des eingesetzten IT-Systems, der EU-AI-Act für die KI-Komponente (Best-Execution-Reporting fällt nach aktueller Lesart nicht zwingend in Hochrisiko, aber die Transparenz- und Dokumentationspflichten greifen). BaFin- und FMA-Rundschreiben zu KI-Einsatz in beaufsichtigten Instituten verlangen explizit Nachvollziehbarkeit, Validierung und menschliche Aufsicht.

Konkret heißt das: Wer 2026 mit einer LLM-Pipeline für Best Execution live gehen will, sollte 2025 mit dem Scoping anfangen. Nicht früher (die regulatorische Lage stabilisiert sich gerade erst), nicht später (sonst überholt der Wettbewerb).

Mein Rat: Beginnen Sie mit einem klar abgegrenzten Use-Case. Standard-Retail-Aufträge im Aktienhandel. Drei Handelsplätze. On-Request-Reports an Kunden bei Beschwerden. Wenn diese Pipeline läuft und auditiert ist, erweitern Sie. Anleihen. Derivate. Block Trades. Schritt für Schritt. Jeder Versuch, gleich alles zu automatisieren, endet im Pilot-Friedhof.

Wenn Sie ein Trading Desk oder eine Compliance-Abteilung führen und über diesen Pfad nachdenken, lohnt ein strukturiertes Gespräch. Was funktioniert in Ihrem konkreten Setup, was nicht. Welche Daten haben Sie sauber, welche nicht. Wo sitzen die echten Engpässe. Das lässt sich in einem halben Tag klären. Die Implementierung dauert länger.