Report once, govern once - Was ESMAs Holistic Review für Banken bedeutet
Der folgende Fachartikel beleuchtet die aktuellen Entwicklungen rund um die von der European Securities and Markets Authority angestoßene Vereinfachung des transaktionsbasierten Reportings (EMIR, SFTR, MiFIR), skizziert mögliche zukünftige Entwicklungen und zeigt die daraus resultierenden Implikationen für Institute auf.
ESMA 2026: Strategische Weichenstellung für die Vereinfachung des transaktionsbasierten Reportings
Die Regulatorischer Hintergrund und Zielsetzung
Mit dem im Mai 2026 veröffentlichten Zwischenbericht “Holistic review of the regulatory reporting – Interim report” hat die ESMA (European Securities and Markets Authority) einen wichtigen Impuls für die künftige Ausgestaltung regulatorischer Meldeanforderungen im europäischen Kapitalmarkt gesetzt. Der Bericht ist Teil der breiter angelegten Simplification and Burden Reduction Initiative und adressiert ein Thema, das für Banken, Kapitalmarktinstitute und Finanzdienstleister seit Jahren von hoher Relevanz ist: Die zunehmende Komplexität, Fragmentierung und Kostenintensität regulatorischer Transaktionsmeldungen.
Bemerkenswert ist dabei weniger die Tatsache, dass ESMA bestehende Belastungen anerkennt. Wesentlich ist vielmehr, dass die Aufsicht erstmals einen strukturierten Ordnungsrahmen für eine grundsätzliche Neuausrichtung des transaktionsbasierten Reportings skizziert. Auch wenn der Bericht ausdrücklich noch keine finalen Policy-Empfehlungen enthält, markiert er einen strategischen Wendepunkt. Der folgende Zeitstrahl skizziert die wichtigsten Meilensteine der Vergangenheit und Zukunft. Als nächste wichtige Haltepunkte wird die Finalisierung des CBAs und des Berichts im Mai bzw. Juli 2026 erwartet.
Abbildung 1: Timeline ESMA - Eigene Darstellung
Warum ESMA die Reporting-Landschaft überprüft
Die europäische Reporting-Landschaft ist in den vergangenen Jahren regulatorisch stark gewachsen. Insbesondere unter EMIR, MiFIR und SFTR wurden umfangreiche Transaktions- und Positionsmeldungen etabliert. Diese Regelwerke entstanden jedoch in unterschiedlichen regulatorischen Kontexten, mit jeweils eigenen Zielsetzungen, Meldearchitekturen, Datenmodellen und Governance-Strukturen.
Abbildung 2: Timeline Melderegime
Das Ergebnis ist kein integriertes Reporting-Framework, sondern ein historisch gewachsener, teils heterogener Meldekosmos, dessen Auswirkungen man bei den meisten Instituten auch in der Architektur wiedersieht:
Abbildung 3: Status Quo Architektur
Genau an diesem Punkt setzt ESMA an. Grundlage des Zwischenberichts ist ein 2025 gestarteter Call for Evidence, auf den mehr als 100 Marktteilnehmer reagierten. Die Rückmeldungen bestätigten deutlich, dass regulatorisches Reporting inzwischen nicht nur ein Compliance-Thema, sondern ein struktureller Kosten- und Transformationsfaktor geworden ist.
Aus aufsichtsstrategischer Sicht verfolgt ESMA dabei zwei Ziele gleichzeitig:
1. Reduktion des operativen Aufwands für Marktteilnehmer
2. Verbesserung der Datenqualität für Aufsichtsbehörden.
Diese doppelte Zielsetzung ist wesentlich, da Vereinfachung nicht Deregulierung bedeutet, sondern eine effizientere und konsistentere Datenerhebung.
Zentrale Schwächen des heutigen Reporting-Frameworks
Die gemeinsam mit den betroffenen Stakeholdern durchgeführte Analyse hat neun wesentliche Herausforderungen identifiziert. Dieses Kapitel gibt zunächst einen Überblick über die identifizierten Handlungsfelder und erläutert diese anschließend anhand ausgewählter Beispiele näher.
Kurze Erläuterung der von den Stakeholdern identifizierten Herausforderungen
Abbildung 4: Die neun identifizierten Herausforderungen von der ESMA und Stakeholdern - Eigene Darstellung
1. Häufige regulatorische Änderungen durch mehrere unabhängige Melderegimen
Banken müssen ihre Systeme ständig an neue oder geänderte Vorgaben aus unterschiedlichen Regulierungen (EMIR, MiFR, SFRT) anpassen.
Beispiel: EMIR und MiFID ändern gleichzeitig Datenfelder oder Formate.
2. Doppelte Meldungen von Finanzdaten in verschiedenen Melderegime
Dieselbe Transaktion muss mehrfach an unterschiedliche technische Datenempfänger gemeldet werden.
Beispiel: Ein Derivategeschäft wird sowohl unter EMIR als auch unter MiFIR26 gemeldet.
3. Inkonsistente Terminologie und Definitionen
Unterschiedliche Regelwerke verwenden verschiedene Begriffe für denselben Sachverhalt.
Beispiel: Es gibt eine Ermittlung des relevanten Legs bei einem Zinsswap und Notation.
4. Meldungen auf Transaktions- und Positionslevel
Daten müssen sowohl für einzelne Trades als auch aggregiert als Position gemeldet werden.
Beispiel: Sowohl ein einzelner Aktienkauf plus Gesamtbestand derselben Aktie muss gemeldet werden.
5. Beidseitige Meldungen (Dual-Side Reporting)
Beide Geschäftspartner melden dieselbe Transaktion separat.
Beispiel: Käufer und Verkäufer melden denselben Swap an ein Transaktionsregister.
6. Konzerninterne Meldungen (EMIR)
Auch Geschäfte innerhalb desselben Konzerns müssen gemeldet werden.
Beispiel: Eine deutsche Tochter meldet ein Derivat mit der Londoner Konzerngesellschaft.
7. Doppelte Referenzdaten
Stammdaten werden mehrfach in verschiedenen Systemen gepflegt.
Beispiel: LEIs, Produktdaten oder Counterparty-Daten existieren redundant.
8. Unterschiedliche Meldekanäle (z.B. Transaktionsregister)
Verschiedene Behörden verlangen unterschiedliche technische Einreichungswege.
Beispiel: Bei einer Behörde gibt es einen XML-Upload, bei einer anderen eine API-Schnittstelle.
9. Doppelte IT-Systeme und Prozesse
Für ähnliche regulatorische Anforderungen existieren getrennte Systeme und Teams.
Beispiel: Die Nutzung von separierten Reporting-Plattformen für EMIR und SFTR trotz ähnlicher Datenbasis.
Die fragmentierte regulatorische Landschaft führt dazu, dass ein und dasselbe Produkt – etwa ein Derivat oder Repo – gleichzeitig mehreren Reportingpflichten unterliegt, jedoch mit unterschiedlichen Klassifikationen und Datenanforderungen.
Dies erzeugt redundante Prozesse, Inkonsistenzen und signifikante Kosten.
Beispielsweise stellt sich für Marktteilnehmer regelmäßig die Frage:
Müssen Derivate gleichzeitig unter EMIR, MiFIR Transaction Reporting (Art. 26) und ggf. MMSR gemeldet werden?
Wie sind Wertpapiere vs. Derivate regulatorisch eindeutig abzugrenzen?
Fallen Repos unter Geldmarktstatistik (MMSR), Wertpapier-Reporting (MiFIR) oder beides?
Diese Mehrfachzuordnung führt dazu, dass:
Daten inkonsistent gemeldet werden,
Systeme parallel gepflegt werden müssen,
und dadurch erhebliche operative Kosten und Komplexität entstehen.
Das nachfolgende Diagramm visualisiert diese Überschneidungen und verdeutlicht die daraus resultierenden Herausforderungen.
Abbildung 5: Beispiele Produkte-Segmente in den einzelnen Melderegimen
Die im Bericht diskutierten Lösungsansätze
Die ESMA diskutiert zwei Lösungsansätze, die nun gemeinsam mit den Banken weiter konkretisiert werden sollen. Option 1 ist kurzfristig umsetzbar, bietet jedoch nur begrenzte langfristige Vorteile und ist mit erheblichen Implementierungskosten verbunden – insbesondere bei den Meldewesen-Softwareanbietern. Option 2 verfolgt einen deutlich umfassenderen Ansatz mit potenziell nachhaltigen Effizienz- und Kostenvorteilen, erfordert jedoch einen längeren Umsetzungszeitraum von etwa fünf bis sieben Jahren. In diesem Szenario könnte ein erheblicher Teil der bisherigen Logik in der Meldesoftware entfallen; entsprechend wäre zu prüfen, ob einzelne bestehende Lösungen perspektivisch obsolet werden.
Übersicht über die Lösungsansätze
Abbildung 6: Die im Artikel vorgestellten Lösungsansätze – Eigene Darstellung
Abbildung 7: Option 1 und dessen Varianten aus dem Artikel - Eigene Darstellung
Option 1: Abbau redundanter Strukturen in den bestehenden Reporting-Frameworks
ESMA präsentiert im Call for Evidence zwei eigenständige Hauptoptionen mit unterschiedlicher Reichweite und Implementierungskomplexität. Option 1 setzt auf den Abbau von Redundanzen innerhalb der bestehenden Rahmenwerke, ohne die zugrundeliegenden Meldeinfrastrukturen fundamental zu verändern. Sie gliedert sich in zwei wechselseitig ausschließende Untervarianten.
Option 1a – Delineation by Instrument: Dieser Ansatz schlägt eine klare Abgrenzung des Anwendungsbereichs nach Instrumententyp vor. MiFIR würde künftig ausschließlich für ETD-Transaktionen zuständig sein, EMIR für OTC-Derivate inklusive Post-Trade-Events. Valuation- und Margins-Daten für ETDs sollen aus CCP-Quellen bezogen werden. Das ETD-Reporting an Trade Repositories – weltweit ein EU-Alleinstellungsmerkmal – würde entfallen. Gleichzeitig wäre das EMIR-Template um Felder für die Marktmissbrauchsüberwachung zu ergänzen, da diese bislang in MiFIR-Daten enthalten sind.
Option 1b – Delineation by Event: Dieser Ansatz definiert die Zuständigkeit nach dem Ereignistyp. MiFIR würde sämtliche Transaktionen (ETD und OTC) abdecken, EMIR die Post-Trade-Events (End-of-Day-Positionen, Margin- und Valuationsdaten). SFTR würde in diesen Rahmen integriert werden. Die Abgrenzung nach Ereignislogik ist konzeptionell klarer, erfordert jedoch tiefergehende Anpassungen in den Meldesystemen und -prozessen der Institute.
Beide Suboptionen sehen zudem eine Überprüfung der doppelseitigen Meldepflicht vor, um diese mit dem internationalen Standard zu harmonisieren. ESMA betont, dass Option 1 im mittleren Zeithorizont (ca. fünf Jahre) umsetzbar wäre, da keine fundamentalen Änderungen an den Meldeinfrastrukturen erforderlich sind. Gleichwohl bedürfen beide Varianten L1-Rechtsänderungen, deren politische Zeitplanung außerhalb ESMAs Kontrolle liegt.
Option 2: Prinzip der einmaligen Datenerhebung und Mehrfachnutzung
Option 2 ist konzeptionell ambitionierter: Sie basiert auf dem "Report Once"-Prinzip, also der einmaligen Datenerhebung und der mehrfachen Weiterverwendung durch unterschiedliche Behörden. Dieser Ansatz setzt unmittelbar auf Option 1 auf und entwickelt sie in Richtung einer grundlegend integrierten Reporting-Infrastruktur weiter.
Kerngedanke ist die Schaffung einer zentralen Datenerhebungsplattform, an die Institute ihre Transaktionsdaten einmalig liefern. Die Daten würden nach fachlicher Logik aufbereitet und den jeweils zuständigen Behörden – ESMA, NCAs, EBA, ACER – bedarfsgerecht zur Verfügung gestellt. Damit würden redundante Datenflüsse an unterschiedliche Empfänger entfallen; stattdessen würde die Steuerung des Datenzugangs auf behördlicher Seite organisiert.
ESMA sieht in diesem Ansatz das höchste Reduktionspotenzial bei den Compliance-Kosten – langfristig und bei vollständiger Umsetzung erheblich größer als bei Option 1. Allerdings sind die initialen Transformationskosten deutlich höher, die Implementierungszeit länger (über fünf Jahre) und die Abhängigkeit von funktionierenden technischen Infrastrukturen, gemeinsamen Datenstandards und behördenübergreifender Governance erheblich.
Kritisch ist, dass das "Report Once"-Modell nur dann seinen Mehrwert entfaltet, wenn alle beteiligten Behörden ihre internen Prozesse auf die neue Datenlogik umstellen. Solange einzelne Behörden weiterhin institutseigene Ergänzungen oder Direktmeldungen verlangen, entstehen de facto parallele Strecken – ein Risiko, das ESMA selbst im Bericht benennt. Die Qualität der Datenarchitektur und die Verbindlichkeit der behördenübergreifenden Koordination werden damit zur Systemvoraussetzung.
Alle diskutierten Optionen werden von ESMA an vier Leitprinzipien gemessen:
1. Erhalt des Informationsumfangs
2. Abbau von Überlappungen
3. Globale Alignierung
4. Kosten-Nutzen-Proportionalität
Diese Prinzipien sind sinnvoll, bringen aber auch inherente Spannungen mit sich: Eine vollständige Redundanzbeseitigung kann temporär aufsichtliche Lücken erzeugen, die durch Übergangsmaßnahmen oder alternative Datenquellen kompensiert werden müssen.
Bewertung der diskutierten Optionen aus Sicht des VÖBs und uns
Der Ansatz 1 würde in der Tat Doppelte Logik / Redunanzen / … insbesondere bei den ETDs entfernen. Der Aufwand der Umsetzung und das Testen aller betroffenen Meldemodule ist aber in diesem Fall so hoch, dass der gesamte „Business Case CBA“ nicht mehr funktionieren wird. Daher schließen wir uns der VÖB-Meinung zu 100% an (vgl. [4] und [5]): … Langfristig kristallisierte sich die auch von uns befürwortete Zusammenführung der Melderegime als bevorzugte strategische Option heraus. Wir werden uns weiter dafür einsetzen, dass keine schrittweise Umstellung erfolgt, sondern gleich die langfristige strategisch optimal Zielvorstellung umgesetzt wird. Jeder Zwischenschritt bedeutet erneuten Implementierungsbedarf in allen drei Melderegimen, der die Vorteile einer stufenweisen Einführung unter Kosten-Nutzen-Aspekten nicht rechtfertigt. …
Exkurs: Simplifaction Regulatory Reporting & IReF
Gemeinsame Stoßrichtung
Die ESMA-Initiative zur Vereinfachung des Transaction Reportings steht nicht isoliert im regulatorischen Raum. Sie ist Teil eines breiteren europäischen Reformprogramms, das auf eine nachhaltige Entlastung der Institute im Meldewesen zielt. Zwei weitere Initiativen verdienen in diesem Kontext besondere Aufmerksamkeit: das EBA Supervisory Reporting Simplification Package sowie das Integrated Reporting Framework (IReF) der Europäischen Zentralbank.
Das EBA Simplification Package verfolgt eine weitreichende Straffung der aufsichtlichen Meldepflichten im FINREP- und COREP-Bereich. Im Konsultationsprozess hat die EBA eine Gesamtreduktion des Datenumfangs um rund 50 % in Aussicht gestellt – durch Streichung redundanter Datenpunkte, stärkere Proportionalitätsregelungen (etwa durch einen Core-Plus-Supplement-Ansatz) und die Integration von Benchmarking-Templates in das reguläre Reporting. Ab 2027 sollen erste Maßnahmen greifen.
Mehr zu Simplification gibt es hier:
Updates aus dem EBA Simplification Package
Das Integrated Reporting Framework – kurz IReF – zählt zu den weitreichendsten Reformvorhaben, die EZB und EBA derzeit vorantreiben. Im Kern geht es darum, die Datenlieferung von Banken an Aufsichtsbehörden grundlegend neu zu strukturieren.
Heute sind Banken verpflichtet, Meldungen an verschiedene Empfänger in unterschiedlichen Formaten zu übermitteln: Die EZB erhält statistische Meldungen, die EBA die aufsichtlichen FINREP- und COREP-Meldungen, das SRB die Daten für die Abwicklungsplanung – und nationale Behörden wie die Bundesbank erhalten zusätzliche Meldungen, etwa nach der Außenwirtschaftsverordnung. Das Ergebnis dieser gewachsenen Struktur ist erhebliche Redundanz: Daten werden mehrfach gehalten, Zahlen widersprechen einander, und der Meldeaufwand bindet intern beträchtliche Ressourcen.
IReF soll das ändern. Das Grundprinzip ist einfach formuliert: Banken melden künftig einmal, in einem einheitlichen Format, und alle Behörden greifen auf denselben gemeinsamen Datenbestand zu. Die Umsetzung dieses Prinzips ist allerdings komplex. Neben Anpassungen im Meldewesen selbst sind tiefgreifende Eingriffe in Datenintegration und -architektur zu erwarten.
Derzeit befindet sich IReF in einer frühen Projektphase. Im Juni 2026 wurde von der EZB ein Zeitplan veröffentlicht, der einen Regelbetrieb ab 2031 vorsieht. Als eine Art Vorläufer gilt AnaCredit – ein granulares Kreditdatenregime, das Banken seit 2018 zur Meldung detaillierter Kreditinformationen auf Einzelkreditebene verpflichtet und das zentrale Elemente der IReF-Logik bereits vorwegnimmt.
Für Banken bedeutet das eine zweigeteilte Perspektive: Langfristig sind echte Einsparungen im Meldeprozess realistisch. Kurzfristig stehen erhebliche Investitionen in IT-Systeme und Datenarchitekturen an.
Aus aufsichtlicher Sicht steht hinter IReF auch ein Lehrstück aus der Finanzkrise. Lückenhaftes und inkonsistentes Datenmaterial war damals ein strukturelles Problem – Risiken konnten von Behörden nicht rechtzeitig erkannt werden, weil die verfügbare Datenlage es schlicht nicht zuließ. Ein einheitliches, granulares Datenmodell soll solche Schwachstellen dauerhaft beseitigen.
Mehr zu IReF gibt es hier:
BIRD und IReF - Auf dem Weg zu einem Integrierten Reporting System
Die gemeinsame Stoßrichtung aller drei Initiativen ist unverkennbar: Abbau von Doppelungen, Vereinheitlichung von Datenmodellen, Aufbau einer einheitlichen Logik: einmal melden, mehrfach nutzen. Sie bündeln sich zu einer regulatorischen Reformwelle, die das Meldewesen der nächsten Dekade strukturell neu ordnen wird.
Abbildung 8: Status Quo des Regulatory Reportings (ohne IReF-Umsetzung)
Abbildung 9: IReF finales Zielbild
Die Abbildungen zwei und drei zeigen wie im Regulatory Reporting heute Anforderungen gestellt werden und gemeldet wird, und wie das ideale IREF-Zielbild aussehen soll. Der Weg vom Status Quo bis hin zum finalen Zielbild soll auch nicht direkt erfolgen, sondern schrittweise beginnend mit den Statistischen Meldungen.
Unterschiede in Zielsetzung und Anwendungsbereich
Bei aller konzeptionellen Gemeinsamkeit bestehen zwischen der ESMA-Initiative zum Transaction Reporting und den parallelen Reformvorhaben im aufsichtlichen und statistischen Meldewesen grundlegende Unterschiede, die für die strategische Planung der Institute von Bedeutung sind.
Anwendungsbereich und regulatorische Einbettung
Die ESMA-Initiative adressiert das Transaktions-Reporting im Kapitalmarktbereich – konkret Derivatemeldungen unter EMIR, Wertpapiertransaktionen unter MiFIR sowie Wertpapierfinanzierungsgeschäfte unter SFTR. Das EBA Simplification Package hingegen zielt auf die aufsichtlichen Meldepflichten im FINREP- und COREP-Rahmen, also auf die periodische Berichterstattung zu Eigenkapital, Liquidität, Verschuldung und Finanzinformationen. Das IReF der EZB wiederum fokussiert auf das statistische Meldewesen des Eurosystems – Bilanzstatistik, Zinsstatistik, AnaCredit. Jede Initiative operiert damit in einem eigenen regulatorischen Ökosystem, mit eigenen Rechtsgrundlagen, eigenen Behörden und eigenen Governance-Strukturen.
Der entscheidende konzeptionelle Unterschied: Transaktion versus Bestand
Der fundamentalste Unterschied liegt jedoch nicht im Anwendungsbereich, sondern in der zugrundeliegenden Meldelogik.
Im Transaction Reporting – also im Kernbereich der ESMA-Reform – steht das Ereignis im Mittelpunkt. Gemeldet wird grundsätzlich / vereinfacht jede neue Transaktion, jede Modifikation, jede Beendigung eines Kapitalmarktgeschäftes. Die Meldepflicht entsteht mit dem Ereignis und erlischt mit seiner Übermittlung. Ein Trade, der um 10:03 Uhr abgeschlossen wird, muss in der Regel noch am selben bzw. am nächsten Handelstag – in einigen Fällen nahezu in Echtzeit – gemeldet sein. Die Datenmenge ist entsprechend hoch, die Anforderungen an Systemverfügbarkeit und Datenqualität in der Verarbeitungskette sind groß.
Das aufsichtliche und statistische Meldewesen – also FINREP, COREP und IReF – folgt einer grundlegend anderen Logik. Hier steht der Bestand im Mittelpunkt: Wie hoch ist das Eigenkapital zum Stichtag? Wie groß ist das Kreditportfolio? Wie entwickeln sich Zinsmargen im Zeitverlauf? Diese Meldungen sind periodisch – monatlich, quartalsweise, halbjährlich – und bilden einen Zustand zu einem definierten Referenzpunkt ab. Die zeitliche Dringlichkeit ist vergleichsweise gering, dafür sind Konsistenz, Vergleichbarkeit und Zeitreihenstabilität entscheidend.
Zeithorizont und Umsetzungsreife
Das EBA Simplification Package ist bereits in der Konsultation und zielt auf Umsetzung ab September 2027 ab. Das IReF geht von einem Produktivstart 2032 (mit einem Prototyp 2031) aus. Bei der ESMA-Reform wird von einer Umsetzung 2031 ausgegangen.
Praktische Auswirkungen auf Banken und deren Reporting-Architektur und Fachprozesse
Unabhängig davon, welche der diskutierten Vereinfachungsoptionen letztlich Eingang in die Regulierung findet, werden die Auswirkungen auf die Reporting-Architektur der Institute tiefgreifend sein. Für Banken bedeutet die aktuelle Überprüfung zunächst eine strategische Zäsur: Sie sollten die Weiterentwicklung ihrer Reporting-Landschaft nicht kurzfristig-inkrementell planen, sondern eine mittelfristig tragfähige Zielarchitektur entwickeln, die verschiedene Reformszenarien berücksichtigt.
Im Kern werden Banken ihren Datenhaushalt grundlegend neu denken müssen. Heute existieren in vielen Instituten getrennte Datenstrecken für MiFIR, EMIR und SFTR, die historisch gewachsen und oft fachlich wie technisch entkoppelt sind. Ein zukünftiges Regime, das auf stärkerer Integration oder dem "Report Once"-Prinzip basiert, erfordert hingegen ein einheitliches, qualitätsgesichertes Golden-Source-Datenmodell, aus dem alle regulatorischen Meldungen konsistent und vollständig abgeleitet werden können.
Konkret bedeutet das: Datenfelder, die heute nur in einem der Regime definiert sind, müssen künftig in einem gemeinsamen Datenmodell verfügbar sein. Entitäten-Identifikatoren (LEI, BIC, MIC), Instrument-Taxonomien (ISIN, CFI, UPI), Gegenpartei-Klassifikationen und Trade-Lebenszyklusereignisse müssen über alle Meldestrecken hinweg konsistent definiert und befüllt sein. Abweichungen, die heute durch separate Validierungslogiken toleriert werden, wären in einem integrierten System systemgefährdend.
Besondere Aufmerksamkeit verdient die Frage der Datenqualität im Lebenszyklusmanagement von Derivaten. Post-Trade-Events wie Novationen, Kompressionen, Margin-Anpassungen und Valuationsupdates sind heute zwischen EMIR und MiFIR inhomogen definiert. Eine Neuordnung der Zuständigkeiten (z.B. nach Option 1b) erfordert eine vollständige Überarbeitung der entsprechenden Datenmodelle und Prozesse in den Instituten.
Hinzu kommt die Referenzdatenproblematik: Stammdaten zu Handelsstätten, Instrumenten und Gegenparteien werden heute parallel gepflegt – teils durch Institute selbst, teils durch externe Anbieter, teils durch CSD-Datenfeeds. Eine Konsolidierung setzt voraus, dass Banken ihre Referenzdaten-Governance straffen und die Abhängigkeiten von Drittdatenanbietern vertraglich und technisch neu strukturieren.
Die folgenden beiden Schaubilder skizzieren die oben genannte Thematik.
Status-Quo:
Abbildung 10: Status Quo TR- Reporting
Mögliches Zielbild für Option 2:
Abbildung 11: Zielbild TR-Reporting
Konsequenzen für Fachprozesse, Governance und Transformationsprogramme
Die regulatorische Neuausrichtung des Transaction Reportings betrifft nicht allein IT und Datenpipelines – sie hat unmittelbare Konsequenzen für Fachprozesse, Governance-Strukturen und laufende Transformationsprogramme.
In der Aufbauorganisation müssen Institute die Verantwortlichkeit für übergreifende Reporting-Qualität neu klären. Heute agieren MiFIR-, EMIR- und SFTR-Teams oft in separaten Silos, mit unterschiedlichen Führungslinien und Eskalationspfaden. Eine integrierte Meldearchitektur erfordert eine stärkere Vernetzung dieser Teams, idealerweise unter einer konsolidierten Regulatory-Reporting-Governance mit klarer Dateneigentümerschaft und behördenübergreifender Verantwortung.
Im Bereich der Fachprozesse sind insbesondere die Trade-Capture-Prozesse, die Derivate-Buchführung und das Collateral Management betroffen. Änderungen an der Meldelogik – etwa die Verschiebung von Post-Trade-Events in ein anderes Regime – können kaskadierende Anpassungen in diesen Prozessen erfordern, die über das reine Reporting-System hinausgehen und in die Risiko- und Handelssteuerung eingreifen.
Transformationsprogramme, die derzeit noch auf Basis des bestehenden Frameworks geplant sind (MiFIR-Review-Umsetzung, EMIR 3.0-Anpassungen), stehen vor einem strategischen Dilemma: Eine zu frühe technische Festlegung auf die heutige Architektur könnte bei einer grundlegenden Neuordnung Nacharbeit erzwingen – verbunden mit erheblichen Mehrkosten. Andererseits kann das Abwarten auf regulatorische Klarheit (frühestens 2026/2027) operative Lücken erzeugen. Empfehlenswert ist deshalb ein zweistufiges Vorgehen: Kurzfristig sollten Institute die notwendigen regulatorischen Pflichten (EMIR 3.0, MiFIR Review) in einer architekturell modularen Form umsetzen, die spätere Anpassungen ermöglicht. Mittelfristig sollte eine aktive strategische Positionierung zur bevorstehenden Reform stattfinden – etwa durch Mitwirkung an Konsultationsverfahren und frühzeitige Szenarien-Analyse für die eigene Transformationsplanung.
Hinweis:
Am 02.07.2026 hat die ESMA ihren Final Report veröffentlicht:
Ein entsprechendes Update zu diesem Artikel folgt hierzu in Kürze.
Ihr direkter Draht zu uns:
Sie planen ein Projekt oder möchten sich unverbindlich zu diesem Thema austauschen? Wir sind für Sie da!
Unser interdisziplinäres Netzwerk aus naturwissenschaftlicher und wirtschaftlicher Expertise freut sich darauf, Sie kennenzulernen und Ihr Anliegen gemeinsam voranzubringen.
Kontaktieren Sie uns – wir freuen uns auf den Dialog!
Quellen
[1] „Bundesbank IReF,“ 2026. [Online].Available: https://www.bundesbank.de/de/service/meldewesen/bankenstatistik/integrated-reporting-framework-iref-611262 zuletzt abgerufen am 26.06.2026.
[2] ESMA TR-Reporting,“ 2026. [Online]. Available: https://www.esma.europa.eu/document/call-evidence-comprehensive-approach-simplification-financial-transaction-reporting. zuletzt abgerufen am 26.06.2026.
[3] EBA Simplification, 2026. [Online].Available:
https://www.eba.europa.eu/publications-and-media/press-releases/eba-consults-major-simplification-supervisory-reporting-deliver-simpler-smarter-and-more zuletzt abgerufen am 26.06.2026.
[4] ESMA: Vereinfachung transaktionsbasierter Meldungen 2026.[Online].Available:
https://www.voeb.de/fachthemen/detail/esma-vereinfachung-transaktionsbasierter-meldungen zuletzt abgerufen am 26.06.2026.
[5] Vereinfachung des kapitalmarktrechtlichen Meldewesens 2025.[Online].Available:
https://www.voeb.de/fachthemen/detail/vereinfachung-des-kapitalmarktrechtlichen-meldewesens zuletzt abgerufen am 26.06.2026.
Mehr zu Regulatorik
Autoren
Matthias Markl
Senior Manager
Financial Engineering
matthias.markl at finbridge.de
Jannis Bartikowski
Financial Engineer
Financial Engineering
jannis.bartikowski at finbridge.de
Simon Gläser
Senior Financial Engineer
Financial Engineering
simon.glaeser at finbridge.de