Transaktionsmeldungen (MiFID II)

Bei der Meldungseinreichung muss ab dem 15.06.2018 statt des LEI-Codes der ausführenden Entität der LEI-Code der sendenden Entität übergeben werden. Dieser LEI-Code muss auch im genutzten Legitimationsmittel (Zertifikat) hinterlegt und als "submitting party" in jeder Transaktion des Berichtes angegeben sein. Siehe auch Kapitel 4.1" Data Reception Interface" der FMA-Wegleitung 2017/19.

Die Weiterleitung des Legitimationsmittels ist ab dem 15.06.2018 nicht mehr erforderlich, da jede sendende Entität "submitting entity" mit ihrem eigenen Legitimationsmittel delegierte Meldungen einreichen kann.

Um eine möglichst sichere Einreichung der Transaktions-Reports sicherzustellen, wurde eine zertifikatsbasierte Übermittlung eingerichtet. Die Übermittlung ist somit verschlüsselt. Sie erhalten einen öffentlichen und einen privaten Schlüssel. Die genaue Handhabung der Schlüssel entnehmen Sie dem Kapitel 5 "Authentifizierung und Verschlüsselung" der FMA-Wegleitung 2017/19.

Über das e-Service Portal der FMA können Sie mit der Rolle Superuser-Meldewesen ein gültiges Zertifikat beantragen, welches Sie sodann für die Einreichung der notwendigen Daten benötigen. Nach der Beantragung erhalten Sie ein Zertifikat, welches Sie gemäss der FMA-Wegleitung 2017/19 Kapitel 5  "Authentifizierung und Verschlüsselung" installieren müssen.

Über das e-Service Portal der FMA können Sie mit der Rolle Superuser-Meldewesen Ihre Zertifikate auch zurückziehen und für ungültig erklären. Dies ist insbesondere notwendig, wenn Sie die Kontrolle über Ihren privaten Schlüssel verloren haben. Die genaue Abwicklung entnehmen Sie der FMA-Wegleitung 2017/19 in Kapitel 5  "Authentifizierung und Verschlüsselung".

Soll die Schnittstelle im Browser aufgerufen werden, genügt es nicht, die Legitimationsmittel (Zertifikate) im Windows-System zu hinterlegen. Jeder Browser verfügt über einen eigenen Zertifikatsspeicher, in welchem die Zertifikate ebenfalls hinterlegt werden müssen.

Der Business Message Identifier setzt sich wie folgt zusammen:
“LI_{SubmittingPartyLEI}_{YYYY}_{sequential number}, with {SubmittingPartyLEI}: The LEI of the submitting party as reported in the transaction report {YYYY}: The current year {sequential number}: A unique, sequential number for the report. Shall be reset at the turn of every year.”

Die in der Business Message Identifier genutzte Konvention gilt auch für die XML-Datei. Für den ZIP-Container gilt keine Namenskonvention.

Für .NET und Java wird ein Beispiel-Code und ein Manual erstellt. Die Dateien können über folgende Links bezogen werden:

Wir können das Zertifikat zurzeit nicht im PEM-Format ausliefern. Die Umwandlung können Sie aber über OpenSSL einfach selbst durchführen.

Um die Sicherheit weiter zu erhöhen, haben wir uns entschieden, nur noch den TLS 1.2 Standard für den Aufbau des sicheren Kanals zu verwenden. Stellen Sie sicher, dass TLS 1.2 bei Ihrem Client aktiviert ist.

Stellen Sie sicher, dass Sie die Datenstruktur der neuesten ESMA-Spezifikation verwenden. Mehr Informationen entnehmen Sie den Functional Specifications der ESMA: 

ESMA MiFIR Reporting

Für die Proxy-Generierung muss die WSDL-Datei auf dem lokalen Dateisystem gespeichert werden. Die lokale WSDL kann dann im Anschluss zur Generierung eines Proxys z.B. aus Visual Studio verwendet werden.

Interpretationshilfen für die technischen Validierung-Feedbacks finden Sie in Kapitel 4.2 "Feedback-Nachrichten abholen" bis 4.4 "Dateivalidierung Fehler-Codes" der FMA-Wegleitung 2017/19. Die inhaltlichen Validierung-Feedbacks werden im ESMA-Dokument Annex 1 – MiFIR Transaction Reporting Validation Rules erklärt.

Die DRI-Zertifikate können von Benutzern mit der Rolle Superuser-Meldewesen direkt im e-Service Portal unter "Zahnrad-Symbol" → "Zertifikatsverwaltung" verwaltet werden.
Weitere Informationen finden Sie im  Kapitel 5 "Authentifizierung und Verschlüsselung" der FMA-Wegleitung 2017/19.