FMA-Wegleitung 2017/19 Meldepflicht von Transaktionsdaten

Transkript

1 FMA-Wegleitung 2017/19 Meldepflicht von Transaktionsdaten Wegleitung betreffend die Schnittstellen-Spezifikation zur Meldung von Transaktionsdaten gemäss Art. 26 der Verordnung (EU) Nr. 600/2014 vom 15. Mai 2014 über Märkte für Finanzinstrumente (MiFIR). Referenz: FMA-WL 2017/19 Betrifft: Publikationsort: Art. 26 MiFIR Webseite Publikationsdatum: 18. Mai 2017 Letzte Änderung: 31. Mai 2017 Anhang: Schnittstellen-Spezifikation für die Transaktionsdaten-Meldung 1. Ausgangslage: EWR-relevante Rechtsakte werden gemäss Art. 7 des EWR-Abkommen (EWRA) in den liechtensteinischen Rechtsbestand übernommen. Die Richtlinie 2014/65/EU (MiFID II) befindet sich derzeit im Übernahmeprozess ins EWR-Abkommen. Mi- FID II sieht einen neuen Rechtsrahmen vor, der die Handelstätigkeiten auf Finanzmärkten besser regulieren und den Anlegerschutz verstärken soll. Die neuen Regeln werden zum 3. Januar 2018 gültig. Die Regelungen der Richtlinie MiFID II werden durch die Vorschriften der MiFIR ergänzt. MiFIR ist eine europäische Verordnung und somit nach erfolgter Übernahme ins EWRA direkt anwendbar. 2. Zweck und Bedeutung der FMA-Wegleitung Gemäss Art. 26 MiFIR haben Wertpapierfirmen, die Geschäfte mit Finanzinstrumenten tätigen, eine Meldepflicht gegenüber der FMA. Die Meldung soll so schnell wie möglich und spätestens am Ende des folgenden Arbeitstags erfolgen (T+1). Mit dieser Wegleitung werden Wertpapierfirmen über die technische Spezifikation der Transaktionsdaten- Meldung an die FMA informiert. Die technischen Anforderungen sind von allen Meldepflichtigen einzuhalten, welche die Daten an die FMA übermitteln. Landstrasse 109 Postfach Vaduz Liechtenstein Telefon Telefax li.li info@fma-li.li

2 3. Überwachung der Einhaltung Die FMA überwacht die Einhaltung der Meldungen gem. Art. 26 MiFIR und trifft die für den Vollzug notwendigen Massnahmen. 4. Regulatorische und technische Durchführungsstandards von Seiten der Europäischen Wertpapier- und Marktaufsichtsbehörde (ESMA) Weiterführende wesentliche Informationen sind in der Delegierten Verordnung (EU) Nr. 2017/590 der Kommission vom 28. Juli 2016 zur Ergänzung der Verordnung (EU) Nr. 600/2014 des Europäischen Parlaments und des Rates durch technische Regulierungsstandards für die Meldung von Geschäften an die zuständigen Behörden zu finden. 5. Schlussbestimmungen und Inkrafttreten Diese Wegleitung tritt gleichzeitig mit der Verordnung (EU) Nr. 600/2014 vom 15. Mai 2014 über Märkte für Finanzinstrumente (MiFIR) in Kraft. 6. Änderungsverzeichnis 31. Mai 2017: Es wurde eine Aktualisierung der DataReceptionInterface-Datei (Siehe Anhang S. 2) vorgenommen. Für Rückfragen steht die FMA zur Verfügung. Bereich Wertpapiere und Märkte Abteilung Aufsicht Telefon: Fax: Landstrasse 109 Postfach Vaduz Liechtenstein Telefon Telefax li.li

3 Schnittstellen-Spezifikation für die Transaktionsdaten-Meldung Mai 2017 Landstrasse 109 Postfach Vaduz Liechtenstein Telefon Telefax li.li

4 Abkürzungsverzeichnis ESMA FMA MiFIR WSDL XML European Securities and Markets Authority Finanzmarktaufsicht Liechtenstein Markets in Financial Instruments Directive Web Service Definition Language extensible Markup Language

5 Inhaltsverzeichnis Abkürzungsverzeichnis 1. Einleitung Data Reception Interface Datenformat Änderungen an diesem Dokument 1 2. Anhänge 2 3. Nachrichtenformat Business File Header Business Application Header Transaktionsbericht Feedback-Nachricht 4 4. Schnittstellenbeschreibung Transaktionsbericht einreichen Feedback-Nachrichten abholen ReceptionResult 7 5. Authentifizierung und Verschlüsselung 9 6. Testumgebung Kontakt Technischer Kontakt Fachlicher Kontakt Projektleitung 11

6 1. Einleitung Das vorliegende Dokument soll als Einführung und Beschreibung in die Nutzung des Data Reception Interface dienen. Die eigentliche Schnittstelle wird zusammen mit diesem Dokument als wsdl-datei (Web Service Definition Language) zur Verfügung gestellt. 1.1 Data Reception Interface Alle Transaktionsberichte, welche im Rahmen von MiFIR an die Finanzmarktaufsicht (FMA) Liechtenstein gemeldet werden sollen, müssen über den Data Reception Interface-Web Service eingereicht werden. Die Schnittstelle wird die eingereichten Transaktionsberichte auf technische Validität hinsichtlich der genutzten Schemata sowie auf inhaltliche Validität anhand von Validierungsregeln der ESMA (European Securities and Markets Authority) und der FMA prüfen. Die Ergebnisse der Validierung werden daraufhin als Feedback-Dateien ebenfalls über den Web Service zur Verfügung gestellt. 1.2 Datenformat Die einzureichenden Transaktionsberichte sowie die zur Verfügung gestellten Feedback-Berichte basieren auf den von der ESMA definierten XML-Schemata. Alle benötigten Schema-Dateien werden zusammen mit diesem Dokument zur Verfügung gestellt. 1.3 Änderungen an diesem Dokument Die FMA behält sich vor, Änderungen an diesem Dokument und der Schnittstelle vorzunehmen. 1

7 2. Anhänge DataReceptionInterface_draft.wsdl Beinhaltet die technische Schnittstellenbeschreibung im WSDL-Format ESMAUG BusinessApplicationHeader. zip Beinhaltet das XML-Schema sowie dazugehörige Dokumentationen für den Business Application Header ESMA BusinessFileHeader.zip Beinhaltet das XML-Schema für den Business File Header ESMAUG _Reporting_1.0.2.zip Beinhaltet das XML-Schema für die nationale Berichterstattung sowie dazugehörige Dokumentationen. ESMAUG _NationalReportingFeedback _1.0.1.zip Beinhaltet das XML-Schema für die zur Verfügung gestellten Feedback-Dateien sowie dazugehörige Dokumentation. 2

8 3. Nachrichtenformat Das Format aller Nachrichten aus dem MiFIR-Kontext folgt dem ISO20022-Standard. Das Grundelement aller Nachrichten ist der Business File Header (siehe 3.1). Dieser beinhaltet sowohl den Business Application Header (siehe 3.2) als auch die eigentliche Nachricht als Payload. Alle eingereichten sowie zur Verfügung gestellten Dateien müssen auf Basis dieser XML-Schemata valide sein, ansonsten können sie nicht verarbeitet werden. 3.1 Business File Header Der Business File Header kapselt den Business Application Header sowie die eigentliche Nachricht (Transaktionsbericht oder Feedback-Datei) wie folgt: 3.2 Business Application Header Der Business Application Header wurde von der ISO Gemeinschaft definiert und ist für jede im Mi- FIR-Kontext verschickte und empfangene Nachricht Plicht. Der Header beinhaltet Informationen über die sendende Entität, den vorgesehenen Empfänger und die Identität der Nachricht. Element From To Business Message Identifier Message Definition Identifier Beschreibung Der LEI-Code der sendenden Entität der Nachricht. Der Ländercode des Empfängers der Nachricht, in diesem Fall LI. Eindeutige Identifizierung einer Nachricht. Das genaue Format wird noch von der FMA bestimmt. Identifikation des Nachrichtentyps. Für Transaktionsberichte muss dies auth entsprechen. 3

9 Business Service Creation Date Related Wird in diesem Kontext nicht genutzt. Datum und Uhrzeit der Erstellung der Nachricht im ISO 8601 Format. Feedback-Dateien beinhalten eine Kopie des Business Application Headers des zugehörigen Transaktionsberichts. Wird bei Transaktionsberichten nicht genutzt. 3.3 Transaktionsbericht Die Transaktionsberichts-Nachricht erlaubt die Einreichung von Transaktionsdaten nach Artikel 26 von MiFIR. Der Transaktionsbericht kann sowohl neu zu berichtende Transaktionen als auch Stornierungen bereits eingereichter Transaktionen beinhalten. Alle Dateien müssen den XML-Schema, welche zusammen mit diesem Dokument zur Verfügung gestellt werden genügen. 3.4 Feedback-Nachricht Die Feedback-Nachrichten beinhalten die Validierungsergebnisse für die eingereichten Transaktionsberichte. Ist ein eingereichter Bericht technisch nicht valide (z.b. durch fehlerhafte Verschlüsselung, Komprimierung oder invalides XML) wird die komplette Datei abgelehnt und dies entsprechend im Feedback vermerkt. Ist die Datei technisch valide beinhaltet das Feedback die Validierungsergebnisse für jede einzelne Transaktion. Transaktionen können den Status Angenommen (accpeted), Abgelehnt (rejected) oder als noch nicht abschliessend validiert (pending) annehmen. Transaktionsberichte mit Transaktionen im Status pending sollten solange erneut abgefragt werden, bis alle Transaktionen abschliessend validiert werden konnten. Ändert sich der Zustand einer Transaktion im Status «pending», wird diese Transaktion im täglichen Feedack-Bericht aufgeführt. Das Format der Feedback-Datei wurde von der ESMA definiert und wird mit diesem Dokument zur Verfügung gestellt. 4

10 4. Schnittstellenbeschreibung Das Data Reception Interface ist in der Web Service Definition Language spezifiziert. Die aktuelle Version der WSDL-Datei wird mit diesem Dokument zur Verfügung gestellt. Die FMA behält sich vor, den Web- Service in Zukunft noch anzupassen. Es wird jedoch erwartet, dass hier keine wesentlichen Änderungen mehr stattfinden. Der Web-Service stellt drei Operationen zur Verfügung, welche das Einreichen von Transaktionsberichten sowie das Abholen von Feedback-Berichten erlauben. 4.1 Transaktionsbericht einreichen Einzureichende Transaktionsberichte müssen wie in Abschnitt 3.3 beschrieben dem angehängten XML- Schema genügen. Alle Dateien müssen zip-komprimiert eingereicht werden. Operation: FileTransactionReport Parameter: Name Beschreibung Typ executingentitylei compressedtransactionreport Muss den LEI-Code der ausführenden Entität beinhalten, analog zum berichteten Code im Transaktionsbericht. Muss die zip-komprimierte Datei als base64-enkodierte Zeichenfolge beinhalten. String Byte[] Base64-enkodierte Zeichenfolge Rückgabetyp: Reception Result (siehe 4.3) Nachdem ein Bericht über den Web-Service eingereicht wurde, gibt dieser ein Antwortobjekt vom Type ReceptionResult (siehe 4.3) zurück. 4.2 Feedback-Nachrichten abholen Feedback-Nachrichten zu eingereichten Transaktionsberichten müssen jeden Tag abgeholt und überprüft werden. Die einreichende Entität muss nachverfolgen, für welche Transaktionen bereits Feedback- Dateien abgeholt wurden oder noch werden müssen. Feedback-Dateien werden täglich zum Tageswechsel erstellt und können in der Folge abgeholt werden. Sie beinhalten das Feedback für den Bericht des letzten Tages sowie Transaktionen, welche zuvor im Wartestatus waren und deren Zustand sich in der Zwischenzeit geändert hat. Feedback-Dateien müssen einzeln pro eingereichtem Transaktionsbericht vom Web-Service abgeholt werden. 5

11 Operation: IsTransactionFeedbackAvailable Parameter: Name Beschreibung Typ executingentitylei feedbackdate Rückgabetyp: Boolean Muss den LEI-Code der ausführenden Entität beinhalten, analog zum berichteten Code im Transaktionsbericht. Datum an dem die Feedback- Datei bereitgestellt wird. In der Regel der aktuelle Tag. Dabei kann von der Uhrzeit abstrahiert werden. Mit älteren Datumsangaben können auch ältere Feedback-Dateien angefragt werden. String DateTime Ist zu einem abgefragten Identifier eine Feedback-Datei vorhanden, kann diese mit der folgenden Operation als Base64-enkodierte Zeichenfolge abgeholt werden. Operation: GetTransactionReportFeedback Parameter: Name Beschreibung Typ executingentitylei feedbackdate Muss den LEI-Code der ausführenden Entität beinhalten, analog zum berichteten Code im Transaktionsbericht. Datum an dem die Feedback- Datei bereitgestellt wird. In der Regel der aktuelle Tag. Dabei kann von der Uhrzeit abstrahiert werden. Mit älteren Datumsangaben können auch ältere Feedback-Dateien angefragt werden. String DateTime Rückgabetype: Base64-enkodierte Zeichenfolge Ist zu einem übergebenen Identifier keine Feedback-Datei vorhanden oder stimmt die angegebene LEI nicht mit der Feedback-Datei überein wirft die Operation eine FeedbackNotAvailableException mit einer entsprechenden Nachricht. 6

12 4.3 ReceptionResult Das ReceptionResult-Objekt beinhaltet Informationen über den eingereichten Transaktionsbericht. Diese Informationen können genutzt werden, um den Status der Einreichung zu überprüfen und mit dem angegebenen Identifier die entsprechenden Feedback-Dateien abzuholen. Eigenschaft Beschreibung Typ ProcessingGuid Beinhaltet den eindeutigen Identifier für die Verarbeitung des Transaktionsberichts. TransactionReportId Beinhaltet die systeminterne Identifikation des Transaktionsberichtes. Kann genutzt werden, um doppelt eingereichte Meldungen zu überprüfen. Sollte bei etwaigen Fehlern zur Behandlung an die FMA mit übergeben werden. Message Beinhaltet die Fehlernachricht sofern ein Fehler auftritt und eine Meldung nicht initial eingereicht werden konnte. Sollte bei etwaigen Fehlern zur Behandlung an die FMA mit übergeben werden. Guid Integer String IsDuplicateFiling DuplicateTransactionReportId XmlFileMd5Hash Gibt true zurück, sofern die exakt gleiche Datei bereits eingereicht wurde. Wenn IsDupliateFiling true zurückgibt, beinhaltet dieses Feld die TransactionReportId des bereits eingereichten Berichtes. Beinhaltet den berechneten Md5- Hash der eingereichten Datei zur Überprüfung der korrekten Einreichung. Boolean Integer String IsRejected Zeigt an, falls die eingereichte Datei nicht erfolgreich angenommen werden konnte. Weitere Details werden in der Message- Boolean 7

13 IsServerError Eigenschaft übertragen. Zeigt an, ob die Ablehnung aufgrund eines Serverfehlers stattfand. Boolean 8

14 5. Authentifizierung und Verschlüsselung Die Authentifizierung und Verschlüsselung der übermittelten Dateien wird über Zertifikate stattfinden. Der genaue Prozess wird von der FMA noch definiert und rechtzeitig zur nationalen Testphase bekanntgege- ben. 9

15 6. Testumgebung Eine Testumgebung steht zum Zeitpunkt der Veröffentlichung dieses Dokumentes noch nicht zur Verfügung. 10

16 7. Kontakt 7.1 Technischer Kontakt AMANA consulting Janis Reichardt Tel: Mail: Richard Bössen Tel: Mail: 7.2 Fachlicher Kontakt Finanzmarktaufsicht Liechtenstein Bereich Wertpapiere und Märkte Franz-Anton Steurer Tel: Mail: Josef Meusburger Tel: Mail: 7.3 Projektleitung Finanzmarktaufsicht Liechtenstein Philipp Kaufmann Tel: Mail: 11