Article

EMIR REFIT RTS und ITS im Investment Management

Neue regulatorische Anforderungen an den Derivatehandel

Die neuen EMIR REFIT RTS und ITS führen zu wesentlichen Änderungen in der Transaktionsmeldung des Derivatehandels. Dieser Artikel zeigt auf, was es jetzt zu beachten gilt, um die rechtlichen Bestimmungen auch in Zukunft einhalten zu können, und unterstützt bei der Identifikation von Handlungsfeldern. Da einige der Neuerungen einen hohen Umsetzungsaufwand in Bezug auf technische Anpassungen erfordern, ist eine frühzeitige Auseinandersetzung mit dem Thema notwendig.

Die Marktinfrastrukturverordnung (kurz: EMIR, Verordnung (EU) NR. 648/2012) zur Regulierung des OTC-Derivatemarkts wurde 2012 veröffentlicht und umfasst Anforderungen an Risikominderungstechniken, Transaktionregistermeldungen und das Clearing von Derivaten. Ziel der EMIR ist es, systemischen Risiken aktiv entgegenzuwirken. Im Jahr 2016 hat die Europäische Kommission die EMIR überprüft und festgestellt, dass diese zu unverhältnismäßigen Belastungen, insbesondere für nicht-finanzielle Gegenparteien (NFC), führt. Daher wurde EMIR in das Programm für Regulatory Fitness und Performance (REFIT) aufgenommen. Die daraus entstandene Änderungsverordnung (EU) Nr. 2019/834 („REFIT-Verordnung“) wurde im Mai 2019 veröffentlicht und ist im Wesentlichen seit dem 17. Juni 2019 verpflichtend anzuwenden.

EMIR REFIT und EMIR REFIT RTS und ITS

Die neue Verordnung zielt darauf ab, EMIR zu ändern und zu vereinfachen, unnötige Compliance-Kosten zu vermeiden, Meldungen zu standardisieren sowie Transparenzprobleme und unzureichenden Zugang zum Clearing für bestimmte Gegenparteien anzugehen. EMIR REFIT ändert die Definition der finanziellen Gegenpartei (FC) in Bezug auf Investmentfonds und Zentralverwahrer (CSD) sowie die Schwellenwertberechnung und die Clearinganforderungen in Bezug auf NFCs. Außerdem klärt EMIR REFIT, wer in bestimmten Szenarien meldepflichtig ist, und reduziert den Meldeaufwand für NFCs, die die Clearingschwelle unterschreiten (im Folgenden „NFC-“ genannt). NFC- können sich trotzdem dazu entscheiden, Transaktionen weiterhin selbstständig zu melden. Gleichzeitig sind NFC- für die Bereitstellung aller relevanten Transaktionsdetails an die finanzielle Gegenpartei, die für die Meldung verantwortlich ist, zuständig. Gruppeninterne Transaktionen werden künftig, unabhängig von dem Unternehmenssitz, von der Meldepflicht ausgenommen, sofern sie einem zentralisierten Verfahren zur Bewertung, Messung und Kontrolle von Risiken unterliegen.

Im Dezember 2020 hat die ESMA Vorschläge für technische Regulierungsstandards (RTS) und Durchführungsstandards (ITS) veröffentlicht, die die EMIR REFIT präzisieren. Die Annahme der Entwürfe durch die Europäische Kommission und die Veröffentlichung im EU Amtsblatt werden in Q4/2021 erwartet. 

Die neuen RTS und ITS unter EMIR REFIT konkretisieren die Anforderungen an das Clearing, die Risikominderungstechniken und den Prozess sowie die Meldefelder der Transaktionsregistermeldung. Ziele dieser Vorgaben sind die Anpassung an internationale Standards, die Harmonisierung von Datenqualitätsanforderungen mit den Meldepflichten nach MiFIR und SFTR für alle Transaktionsregister (TR) und die Verbesserung der Datenqualität. Die Änderungen treten voraussichtlich in Q2/2023 (18 Monate nach der Veröffentlichung im EU-Amtsblatt) in Kraft. 

Ergänzend zu den RTS und ITS wurden von der ESMA Guidelines in Bezug auf EMIR REFIT ausgearbeitet, die sämtliche Rahmenbedingungen, Prozessanforderungen sowie weitere Anforderungen, wie Berichtslogiken, konkretisieren. Am 13. Juli 2021 hat die ESMA eine Konsultation zum Entwurf dieser Guidelines gestartet, die bis zum 30. September 2021 läuft. 

Im Folgenden geben wir einen Überblick über die wesentlichen Änderungen der regulatorischen Anforderungen, Auswirkungen und Herausforderungen, die die EMIR REFIT RTS und ITS mit sich bringen.

Neue Meldepflichten der FCs für NFC

Die EMIR REFIT RTS sehen vor, dass FCs nun im Namen von NFC- die OTC-Derivatekontrakte melden. FCs sind künftig für die Berichterstattung im Namen beider Kontrahenten verantwortlich und haftbar. Gleichzeitig ist die NFC- dafür verantwortlich, der FC korrekte Daten zur Verfügung zu stellen, um ihr die Meldung zu ermöglichen. NFC- sind jedoch nicht verpflichtet, Daten zu Collateral, Mark-to-Market- oder Mark-to-Model-Bewertungen der Kontrakte zu melden. NFC- müssen beim Abschluss von OTC-Derivateverträgen die folgenden Informationen an die FCs liefern: Broker ID, Clearing Member, Type of ID of beneficiary, Beneficiary ID sowie eine Auskunft, ob die Transaktion im Zusammenhang mit einer „commercial activity“ oder mit „treasury financing“ steht. Bestandsgeschäfte, die bei Meldebeginn ausstehend sind, sind ebenfalls an das neue Format anzupassen. 

Zudem steht es NFC- frei, Transaktionen selbst bzw. teilweise selbst zu melden. Dies muss jedoch der FC kommuniziert werden. Die Anzeigefrist gegenüber der FC beträgt zehn Geschäftstage. Außerdem müssen NFC- alle zwölf Monate ihre Positionen anhand der neuen Clearingschwellen (gemäß Artikel 10 der EMIR) überprüfen. Wird eine NFC+ (Gegenpartei oberhalb der Clearingschwelle) zu einer NFC- oder vice versa, sollten sowohl die vertraglichen Vereinbarungen als auch die prozessualen Schritte bereits klar definiert und implementiert worden sein, damit die FC ihren Verpflichtungen nachkommen kann.

Erweiterung der Meldefelder und Meldeinhalte

Mit der EMIR REFIT werden kritische Datenelemente basierend auf den CDE Guidelines harmonisiert („CPMI-IOSCO Technical Guidance on Harmonisation of critical OTC derivatives data elements“ des Komitees der Bank für Internationalen Zahlungsausgleich und der internationalen Organisation der Wertpapieraufsichtsbehörden). 

Hierdurch wird die Anzahl der Meldefelder von 129 auf 203 erheblich erweitert. Insgesamt wurden 77 neue Felder ergänzt sowie 67 Felder angepasst. Unverändert bleiben 59 Felder, wobei drei Felder entfallen. Die Anpassungen weisen teilweise eine hohe Komplexität auf und nur in den seltensten Fällen ist ein 1:1-Mapping möglich. Die Exportdatei aus dem Meldetool und die Schnittstelle zum Transaktionsregister sind auf ISO 20022 XML anzupassen. Am stärksten von den Änderungen betroffen sind Preisdaten, Package-Strukturen, Payment-Anweisungen und Datenfelder betreffend Clearing, Settlement, Confirmation und Collateral.

Zusätzlich zu den aktuell bestehenden Tabellen zu Counterparty Data (Tabelle 1) und zu Common Data (Tabelle 2) wird die Meldung um eine neue Margintabelle ergänzt. Diese Tabelle besteht aus 29 Feldern und umfasst Informationen zu den Handelspartnern von Derivaten, zum Collateral sowie zur Unique Transaction ID (UTI) und den Action Types. Ausführliche Informationen zur UTI und zu den Action Types finden sich in den beiden nachfolgenden Absätzen. 

Des Weiteren müssen Angaben zur Pre- und Post-Haircut Margin gemacht werden. Der Regulator erhofft sich hierdurch, die Entwicklung des Leverage im Markt und systemische Risiken besser erkennen zu können. Im Gegensatz zur SFTR ist die Tabelle für die Meldung des Collateral sowohl für zentral abgewickelte als auch für nicht abgewickelte Verträge anzuwenden. Die Datenfelder müssen täglich gemeldet werden.

Erweiterung der Meldelogik

Um zu jedem Zeitpunkt einen klaren Überblick über die Engagements im Markt sowie umfangreiche Informationen zu Lifecycle-Events zu gewinnen, passt EMIR REFIT die Action Types an und führt neue Event Types ein. 

Wie bisher zeigt der Action Type, ob eine Transaktion neu erzeugt, modifiziert, korrigiert oder geschlossen wurde. Neue Action Types „Revive“ („Wiederbelebung“ von stornierten oder versehentlich geschlossenen Derivaten) und „Margin Update“ für Updates von Margins, wie bei SFTR, werden eingeführt. Der Action Type „Compression“ fällt weg, da er über den Action Type „Position Component“ in Kombination mit dem neuen Event Type „Inclusion in Position“ abgedeckt wird. Sofern ein bestehendes Derivat in eine Meldung auf Positionsebene am selben Tag aufgenommen werden soll, wird dieses Derivat nun mit dem Action Type „Position Component“ gemeldet. Durch den Event Type „Inclusion in Position“ werden einzelne Kontrakte zu einer fungiblen Position gebündelt, die mit der Subsequent Position UTI identifiziert wird. So können Portfolios in Form einer 1:N-Beziehung abgebildet werden. Die Meldung von Prior UTI und PTRR (Post-Trade Risk Reduction, marktrisikoneutrale Transaktionen zur Risikoreduzierung) ist verpflichtend, um Kontrakte, die geschlossen und anschließend wieder geöffnet wurden (z.B. Clearing oder Compression), zu identifizieren.

Die neu implementierten Event Types konkretisieren, wodurch Geschäftsvorfälle ausgelöst werden. Es gibt zwölf Event Types, wobei nicht alle Action und Event Types miteinander kombinierbar sind. Insgesamt entstehen durch die Kombination von Action und Event Types 57 neue Meldungsmöglichkeiten. Die Kombination der Meldung eines Action Type und eines dazugehörigen Event Type erfordert eine komplexe Umsetzungslogik sowie die Identifikation und die (Daten-)Verfügbarkeit der korrekten Trigger Events.

Harmonisierung des Meldeinhalts und der Meldungsstandards

Mit EMIR REFIT wird ISO 20022 in XML der Standard für Kommunikation und Datenmeldung. Ziel ist es, die Meldung unter EMIR zu vereinheitlichen, da ISO 20022 bereits in ähnlichen Meldesystemen (SFTR und MiFIR) verwendet wird. Gleichzeitig werden die Datenformate und -standards präziser.

Zudem wurde der Unique Trade Identifier (UTI), der ein Schlüsselelement für das Matching ist, analog zur CPMI-IOSCO UTI-Guidance als kritisches Datenelement (CDE) klassifiziert. Der UTI ist kontraktspezifisch, was bedeutet, dass beide Parteien den gleichen UTI für die Transaktion melden müssen. Um Diskrepanzen in der beidseitigen Meldung zu vermeiden, wurden die UTI-Struktur und deren Generierungsprozesse überarbeitet. Die ESMA hat erkannt, dass die bisherigen Vereinbarungen zwischen den Gegenparteien nicht immer die korrekte Generierung des UTI gewährleistet haben. Aufgrund dessen sind diese Vereinbarungen nicht mehr die erste Option zur Bestimmung der Verantwortlichkeit. Bilaterale Vereinbarungen dürfen nur noch als Fallback-Lösung in bestimmten Szenarien genutzt werden. Primär bestimmt jedoch ein neu eingeführter Wasserfallprozess, welche Partei für die UTI-Generierung verantwortlich ist. Der Wasserfallprozess wird in der folgenden Abbildung dargestellt.

Der Wasserfallprozess spezifiziert die Verantwortung der UTI-Generierung auch für grenzüberschreitende Transaktionen. Bei solchen Transaktionen ist die Partei aus der Jurisdiktion mit strengeren Regeln und früheren Meldefristen für die Meldung verantwortlich. Die Struktur und Generierungslogik sind auf Trade- und Positionsebene identisch.

Ebenfalls wurde auch die Struktur des UTI angepasst. Die CPMI-IOSCO UTI-Guidance empfiehlt, dass neue UTIs eine verkettete Kombination aus der LEI der generierenden Entität und einem eindeutigen Wert, der von dieser erstellt wurde, sein sollen. Diese Kombination darf eine maximale Größe von 52 alphanumerischen Zeichen haben, wobei Sonderzeichen nicht erlaubt sind. Alte UTIs, die diesen Anforderungen nicht entsprechen, können durch neue ersetzt werden. Generell gilt, dass ein UTI, sobald er einer meldepflichtigen Transaktion zugeordnet wurde, über deren gesamte Lebensdauer bestehen bleiben muss. Laut ESMA hat die Mehrheit der Befragten die im Konsultationspapier vorgeschlagene feste Frist der Bereitstellung der UTI an T+1 um 10:00 Uhr UTC bestätigt.

Der neue Unique Product Identifier (UPI) wird die ISIN ab 2022 bei der Identifikation und Kategorisierung von Derivaten ergänzen. Alle zum Handel zugelassenen sowie an einem Handelsplatz oder über einen systematischen Internalisierer gehandelten Derivate müssen mit einer ISIN identifiziert werden. Alle übrigen Derivate werden mit einem UPI identifiziert.

Laut der Technical Guidance soll der UPI aus einem Code und aus Referenzdaten bestehen. Die UPI Guidance enthält eine Liste von Referenzdatenelementen mit den jeweils zulässigen Werten für jede Anlageklasse. Die Datenstandards für den UPI-Code und die UPI-Referenzdatenelemente werden als internationale Datenstandards festgelegt und von der ISO veröffentlicht und gepflegt. Das Derivatives Service Bureau (DSB), das auch die ISINs generiert, wird die UPIs ausgeben. Jeder UPI wird einem Datensatz zugeordnet. Der Code und die Referenzdatenelemente beschreiben dann zusammen das Produkt. Die Referenzdatenelemente werden in einer UPI-Referenzdatenbibliothek, die vom DSB verwaltet wird und für die Datenbenutzer zugänglich ist, hinterlegt. Die Gegenparteien sollen zur Meldung des UPI verpflichtet werden, sobald der entsprechende ISO-Standard und die UPI-Vergleichsdaten fertiggestellt sind. Dies wird für das dritte Quartal 2022 erwartet. Aktuell gibt es zu den UPI-Vergleichsdaten 25 Datenfelder. Zehn neue Felder, die noch nicht unter EMIR gemeldet werden, kommen hinzu. Die ESMA schlägt vor, dass die Meldung von UPI-Referenzdaten eingestellt wird, sobald die UPIs voll verfügbar sind.

Reconciliation Prozess

Das Fehlen einer anfänglichen Spezifikation des Reconciliation-Prozesses führte zu inkonsistenten Abstimmungsverfahren und Abstimmungszeiten, Unterschieden in den von TRs beschlossenen Toleranzgrenzen, Unterschieden in der Kategorisierung von Feldern, langen Umsetzungszeiten für Änderungsanträge und einer Anhäufung von nicht abgestimmten Geschäften. Die „Pairing Rate“ erreichte 2020 gemäß dem im April 2021 veröffentlichten Quality Report der ESMA nur zwischen 40 und 53 Prozent. Deshalb hat die ESMA durch EMIR REFIT eine Reihe von Anpassungen vorgenommen, um den Prozess zu harmonisieren.

Der Reconciliation-Prozess soll nach Ablauf der Meldefrist für die Gegenparteien (d.h. T+1) beginnen und alle Derivate (Transaktionen und Positionen) umfassen, die am Vortag übermittelt oder zuvor eingereicht, aber nicht erfolgreich abgestimmt wurden. Der tägliche Prozess soll für alle TRs nach demselben Zeitplan erfolgen und zum frühestmöglichen Zeitpunkt beendet werden.

Die nachfolgende Grafik veranschaulicht den Reconciliation-Prozess.

173 Felder sollen der Reconciliation unterliegen, wobei 41 Felder eine Toleranzschwelle erlauben. 107 Felder werden mit dem Beginn der neuen Meldung bereits abstimmungspflichtig und 66 weitere Felder folgen zwei Jahre später. Bestimmte Felder, wie z.B. die Freitextfelder, müssen nicht abgeglichen werden. Um einen wirksamen Abgleich zwischen den TRs zu gewährleisten, müssen Vorkehrungen getroffen werden, um die Vertraulichkeit der ausgetauschten Daten zu garantieren. Außerdem müssen Vereinbarungen geschlossen werden, die die Bereitstellung von Informationen an meldende Gegenparteien, Meldepflichtige sowie Dritte, denen gemäß Artikel 78 Absatz 7 EMIR Zugang zu Informationen über Fehlmeldungen für alle Felder der Reconciliation gewährt wurde, ermöglichen. Das Vorliegen jeglicher Art von Reconciliation Break oder Pairing-Fehlern muss den relevanten Stellen so schnell wie möglich und auf standardisierte sowie harmonisierte Weise mitgeteilt werden.

Fazit zu den Neuerungen unter den EMIR REFIT RTS und ITS

Die Änderungen, die die EMIR REFIT RTS und ITS mit sich bringen, zielen deutlich auf eine Verbesserung der Datenqualität und eine Standardisierung der Meldungen ab. Die Implementierung der Neuerungen sowie die Anpassung von bestehenden Prozessen und Feldern werden für die Parteien, die an der Meldung beteiligt sind, aber definitiv herausfordernd: Erste Analysen zeigen, dass bei zahlreichen neu eingeführten Meldefeldern die Datenbereitstellung in der geforderten Qualität komplex und zeitaufwendig sein wird, da ein direktes Mapping vorhandener Meldungsinhalte in vielen Fällen nicht möglich ist. Wir empfehlen deshalb, frühzeitig in die Planung einzusteigen, potenzielle Auswirkungen zu prüfen und entsprechende Vorkehrungen zu treffen.

Gerne stehen wir Ihnen als Ansprechpartner zum Thema der Transaktionsmeldung unter den EMIR REFIT RTS und ITS zur Verfügung. Unsere Expertise ergibt sich aus langjähriger Erfahrung im regulatorischen Umfeld, einem regen Austausch mit dem Gesetzgeber und umfassender Projekterfahrung im Themengebiet der Transaktionsmeldung. Gerne unterstützen wir Sie bei der Analyse der Ausgangssituation, einem Soll-Ist-Vergleich, der Überprüfung der Meldungsprozesse, dem Mapping der Meldefelder, der Migration auf die neue Meldelogik und weiteren Anforderungen.

Sprechen Sie uns gerne an. Wir freuen uns auf den Austausch mit Ihnen.

Autor

Christian Boeth

Senior Manager | Risk Advisory 

cboeth@deloitte.de

Fanden Sie diese Information hilfreich?