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 SubmittingParty in jeder Transaktion des Berichtes angegeben sein. Siehe auch Kap. 4.1 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 auf Zertifikaten basiere Ü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 der Wegleitung, welche Sie hier beziehen können.
Über das e-Service Portal der FMA können Sie 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 Wegleitung installieren müssen. Die Wegleitung können Sie hier beziehen.
Über das e-Service Portal der FMA können Sie 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 Wegleitung in Kap. 5.
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 selber 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 neusten ESMA-Spezifikation verwenden. Mehr Informationen entnehmen Sie den Functional Specifications der ESMA.
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 Validierungsfeedbacks finden Sie in Kapitel 4.2 bis 4.4 der Wegleitung. Die inhaltlichen Validierungsfeedbacks werden im ESMA Dokument Annex 1 – MiFIR Transaction Reporting Validation Rules erklärt.
Die DRI-Zertifikate können von Benutzern mit der Rolle Superuser direkt im e-Service Portal unter Einstellungen (Zahnrad oben rechts) verwaltet werden. Weitere Informationen finden Sie in der Anleitung https://www.fma-li.li/files/list/wl-19-2017-de-final.pdf in Kap. 5.
