EMIR REFIT RTS und ITS im Investment Management

Die Marktinfrastrukturverordnung (kurz: EMIR, Verordnung (EU) NR. 648/2012) zur Regulierung des OTC-Derivatemarkts wurde 2012 veröffentlicht und umfasst Anforderungen an Risikominderungstechniken, Transaktionsregistermeldungen und das Clearing von Derivaten. Ziel der EMIR ist es, durch Erhöhung der Transparenz in den OTC Märkten, Mitigation von Kreditrisiken und Reduzierung von operationalen Risiken, systemischen Risiken aktiv entgegenzuwirken. Seit Februar 2014 müssen Derivatetransaktionen auf täglicher Basis unter der EMIR gemeldet werden.  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 hat die Europäische Kommission im Nov. 2017 EMIR II eingeführt, die eine Aktualisierung des Meldestandards beinhaltet. Die überarbeiteten RTS/ITS konzentrierten sich dabei auf den Collateral-Austausch, die Meldelogik und Kreditderivate. 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, die regulatorischen Anforderungen unter der EMIR zu vereinfachen, unnötige Compliance-Kosten zu vermeiden, Meldungen zu standardisieren sowie Transparenzprobleme und unzureichenden Zugang zum Clearing für bestimmte Gegenparteien zu verbessern. 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 Q1/Q2 2022 erwartet.

Die neuen RTS und ITS unter EMIR REFIT konkretisieren die Anforderungen an das Clearing, die Risikominderungstechniken und die damit verbundenen Prozesse sowie die Meldefelder der Transaktionsmeldung. Ziele dieser Vorgaben sind die Anpassung an internationale Standards, eine globale Datenharmonisierung mit den Meldepflichten gemäß MiFIR und SFTR für alle Transaktionsregister (TR) und die Verbesserung der Datenqualität. Die Änderungen treten voraussichtlich in Q3/Q4 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 beispielsweise Berichtslogiken, konkretisieren. Vom 13. Juli 2021 bis 30. September 2021 konnten die Marktteilnehmer im Rahmen der zweiten Konsultationsphase ihre Anmerkungen zum Entwurf dieser Guidelines an die ESMA richten. Im November 2021 wurde die aktualisierte Q&A zur Implementierung von EMIR Refit veröffentlicht. 

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. Gleichzeitig ist die NFC- dafür verantwortlich, der FC korrekte Daten zur Verfügung zu stellen, um die Meldung korrekt durchführen zu können. NFC- sind jedoch nicht verpflichtet, Daten zu Collateral, Mark-to-Market- oder Mark-to-Model-Bewertungen der zugrundeliegenden Kontrakte zu melden. Folgende Informationen müssen die NFC- bei Abschluss von OTC-Derivatekontrakten den FCs zur Verfügung stellen: 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 gegenüber der FC angezeigt 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. Die Harmonisierungsgruppe, bestehend aus CPMI (Committee on Payments and Market Infrastructure) und IOSCO (International Organization of Securities Commissions), entwickelte dafür die globale Guidance hinsichtlich Definition, Format und Verwendung kritischen Datenelemente (CDE) für das Reporting von Derivatetransaktionen.  

Damit erweitert sich die Anzahl der Meldefelder erheblich von 129 auf 203. 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 den ISO 20022 XML Standard 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, Counterparty Data (Tabelle 1) und 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 und zur Unique Transaction ID (UTI) sowie 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 die systemischen Risiken besser erkennen zu können. Im Gegensatz zur SFTR ist die Tabelle für die Meldung der Collaterals sowohl für zentral abgewickelte als auch für nicht zentral abgewickelte Verträge anzuwenden. Dabei müssen die Datenfelder auf täglicher Basis gemeldet werden.

Erweiterung der Meldelogik

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

Wie bisher zeigt der Action Type, ob eine Transaktion neu erzeugt, modifiziert, korrigiert oder geschlossen wurde. Zwei neue Action Types „Revive“ („Wiederbelebung“ von stornierten oder versehentlich geschlossenen Derivaten) und „Margin Update“ (Updates von Margins, analog zur 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), identifizieren zu können.

Durch die Einführung von Event Types sollen Geschäftsvorfälle bzw. korrespondierende Lifecycle-Events genauer spezifiziert und konkretisiert 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 auf Transaktions- und Positionsebene 56 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 der XML Standard für die Transaktionsmeldung auf ISO 20022 umgestellt. Ziel ist es, die Meldung unter der EMIR zu vereinheitlichen, da der ISO 20022 Standard bereits für die MiFIR und SFTR Meldung Anwendung findet. Gleichzeitig werden damit die Datenformate und -standards präziser.

Zudem wurde der Unique Trade Identifier (UTI), der ein Schlüsselelement für das Matching darstellt, 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 bilateralen Vereinbarungen zur Bestimmung der UTI generierenden Gegenpartei nicht zu den gewünschten Matching-Quoten führen. 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 Länge von 52 alphanumerischen Zeichen haben, wobei Sonderzeichen nicht mehr erlaubt sind. Alte UTIs, die diesen Anforderungen nicht entsprechen, können, aber nicht müssen, durch neue ersetzt werden. Generell gilt, dass ein UTI, sobald er einer meldepflichtigen Transaktion zugeordnet wurde, über deren gesamte Lebensdauer bestehen bleiben muss. Hinsichtlich der UTI Bereitstellung durch die UTI generierende Partei, schlägt ESMA eine feste Bereitstellungfrist vor. Laut ESMA hat die Mehrheit der Befragten die im Konsultationspapier vorgeschlagene Frist der UTI Bereitstellung, T+1 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 ohne einer ISIN müssen zukünftig mit einem UPI identifiziert werden.

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. ANNA DSB, die bereits die ISINs generiert, wurde beauftragt zukünftig auch die UPIs zu generieren und auszugeben. Jeder UPI wird einem Datensatz zugeordnet. Der Code und die Referenzdatenelemente beschreiben zusammen das Produkt. Die Referenzdatenelemente werden in einer UPI-Referenzdatenbibliothek, die von ANNA 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. Darüber hinaus ergeben sich dadurch Unterschiede in den von TRs beschlossenen Toleranzgrenzen, Unterschiede 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. 

Darüber hinaus sind die TRs für die Richtigkeit und Vollständigkeit des Derivateberichts und die Gewährleistung der Qualität der Berichtsdaten verantwortlich. Ein Transaktionsregister überprüft, ob die zur Meldung eines Derivats verwendete XML-Vorlage der ISO-20022-Methodik entspricht und ob die meldende Partei, sofern sie sich von der für die Meldung verantwortliche Partei unterscheidet, ordnungsgemäß befugt ist, im Namen der Gegenpartei oder für die Berichterstattung verantwortliche Partei Meldungen zu erstatten.
Gleichzeitig sollen TRs überprüfen, dass das gleiche Derivat nicht bereits früher eingereicht wurde und dass die Derivatberichte mit bestimmten Aktionstypen (z. B. Modification, Margin Update, Valuation, Correction, Error, Terminate, New, Revive) sich auf ein früher eingereichtes Derivat beziehen. Falls die Meldungen diese Anforderungen nicht erfüllen, müssen TRs die Derivatemeldungen ablehnen. Zum Schluss stellen die TRs den meldenden Parteien detaillierte Informationen über die Ergebnisse der Datenprüfung im XML-Format zur Verfügung.

Ein Transaktionsregister muss jedem Transaktionsregister, mit dem er Derivate abgestimmt hat, am Ende jedes Arbeitstages (EoD) die Gesamtzahl der gepaarten und abgestimmten Derivate bestätigen. Ein Transaktionsregister muss über schriftliche Verfahren verfügen, um die Lösung aller in diesem Prozess festgestellten Unstimmigkeiten sicherzustellen.

Sicherstellung der Datenqualität

Die Qualität der von Gegenparteien gemeldeten Daten ist ein Schlüsselaspekt, um eine breite Verwendbarkeit der Daten und aussagekräftige Analyseergebnisse sicherzustellen. Die Gegenparteien und CCPs sollen korrekt und ohne Duplikate melden. Um einen wirksamen Abgleich zwischen den TRs zu gewährleisten, müssen Vorkehrungen getroffen werden, um die Vertraulichkeit, Fristigkeit sowie Korrektheit der ausgetauschten Daten zu garantieren. Zudem sollen die meldenden Gegenparteien Datenqualitätsprobleme, die TRs mittels Datenablehnungen und erfolglosen Abgleich kennzeichnen, untersuchen und eine Datenkorrektur durchführen.

ESMA hat beschlossen den Umfang der angeforderten Benachrichtigungen bei Reporting-Breaks an die nationale Aufsichtsbehörde nur auf bestimmte Fälle zu beschränken: 

• Grobe Meldehindernisse;
• Fehlmeldungen aufgrund von Fehlern in den Meldesystemen;
• Signifikante Probleme, die zu Meldefehlern führen, die aber nicht zu einer Ablehnung durch ein TR gemäß den von der ESMA veröffentlichten Validierungsregeln führen würden.
  

Die Benachrichtigungen sollen mindestens die Art des Fehlers oder der Unterlassung, das Datum des Auftretens, den Umfang der betroffenen Berichte, die Gründe für die Fehler oder Unterlassungen, die zur Behebung des Problems unternommenen Schritte und den Zeitplan für die Lösung des Problems sowie die Korrekturen enthalten.

Darüber hinaus müssen Gegenparteien interne Prozesse definieren und dokumentieren, die beschreiben, welche Maßnahmen durchgeführt werden, um mögliche Reconciliation Breaks zu beheben. Weiters sind Gegenparteien dazu angehalten sich im Falle von Reconciliation Breaks gegenseitig zu kontaktieren, um eine rasche Behebung herbeizuführen.

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, definitiv herausfordernd sein: 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 Meldeinhalte 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.

Autoren

David Ausserladscheider

Senior Manager | Risk Advisory

dausserladscheider@deloitte.de