MiFID II Transaction Reporting. Technical Specification

Transcription

1 MiFID II Transaction Reporting Technical Specification 11 August 2017

2 Version Control Date Version Details 11/08/2017 Version 1 1

3 Technical Specification The purpose of this paper is to outline the technical specification for submitting transaction reports under MiFIR to the (GFSC). The MiFIR Transaction Reporting Technical Reporting Instructions ( Reporting Instructions ) published on the European Securities and Markets Authority (ESMA) website describes the reporting definition. Transactions should reach the GFSC no later than 23:59:59 of the working day following the day of the transaction. Working days are all weekdays except for all officially recognised national holidays in Gibraltar. MiFIR Reporting Instructions- Registering to Report Transaction reports can only be submitted to the GFSC by authorised firm personnel at a submitting entity. To register with the GFSC for access to submit reports, please infotrs@gfsc.gi In order to use the sftp service, the submitting entity will be issued with the following: a. A digital Certificate, issued to ensure only trusted traffic is permitted to the GFSC platforms; b. sftp path for the upload of transaction report files; and c. Account credentials, for each delegated reporting officer assigned from the submitting entity. It is required that each user for the submitting entity be registered with a unique login. File Naming Convention Transaction reporting files must adhere to the following naming convention: SSSSSSSSSS_YYYYMMDD_NNN.zip a. SSSSSSSSSS the submitting entities 10 digit GFSC identifier b. YYYYMMDD the submission date of the file c. NNN an integer from 001 to 999 denoting the submission value for the day d..zip the file extension, the file must be compressed before transmission The file naming convention applies to files loaded via sftp. File Contents The transaction report file must contain a single ISO compliant XML file, valid in accordance to the transaction reporting schema. The file name of the XML file must be consistent with the name of the Zip file. The transaction report file must adhere to the following: 1. Up to 500,000 transaction reports can be uploaded in a single file; 2. A firm can upload up to 999 files in a single day; 3. The file must meet the File Naming Convention; 4. The maximum file upload size is 30Mb; 5. Files must be uploaded in a compressed (Zipped) format. Files must have a *.zip extension; 6. Each compressed file must have only one Transaction Report file, which must be an XML file; 2

4 7. The name of the Transaction Report XML file must be the same as that of the zip that contains it. ISO Transaction Reporting Schema File Status The following file status will be assigned to a submitted file. The submitting entity will be notified at the point of a file status being changed. Status Accepted Partially Accepted Rejected Corrupted File Definition Transaction Reporting File has been accepted Transaction Reporting File has been partially accepted. A number of transactions have been accepted, whereas another number of transactions are pending Transaction Reporting File has been rejected. Transaction Reporting File is corrupt. The file status can be recognised as the folder within which the acknowledgement report is placed. For example, should a file be processed with an outcome status of Partially Accepted, this report will be available in the Partially Accepted folder. Transaction Status The following transaction status will be assigned to a submitted transaction report. Status for each transaction can be reviewed in the transaction report outcome XML. Status Received Accepted Pending Rejected Definition (Internal to GFSC) Transaction has been received, but not processed All validations OK Instrument does not exist in Instrument Reference Data and all other validations OK Validation not OK Feedback Process Transaction report files that are uploaded to the GFSC will be added to a queue and processed as soon as possible. An notification will be issued to the user that had uploaded the transaction report informing them that the file has been processed and the current status of the submission. For security reasons, only the authorised personnel will have to access the sftp location to view any error messages. Cancellation of Transaction Reports As documented on the ESMA Reporting Instructions, cancelled transactions must be reported in a subsequent transaction report. Transaction reports can be updated by a cancellation to a prior report, followed by the submission of a new transaction report. 3

5 File Upload via sftp Authorised personnel will be able to transfer transaction reports to a sftp target using the credentials provided by the GFSC. Reports must be placed in the following location /EEEEEEEEEE_SSSSSSSSSS/submission Or /SSSSSSSSSS/submission Where EEEEEEEEEE is the 10-character identifier for the executing entity and SSSSSSSSSS is the 10- character identifier for the submitting entity. The submitting entity identifier is only required should the submitting entity be the executing party on the transaction. Following the processing, and dependent on the status of the transaction report, the file will be placed in one of the following folders../corrupted/./accepted/./partially_accepted/./rejected/ Validation For each transaction report file submitted there are three levels of validation: Naming, File and Content. a. The file name is validated in accordance to the File Naming Convention. i. The Executing Entity is identified as a valid, registered GFSC entity ii. iii. iv. The Submitting Entity is identified as a valid, registered GFSC entity The integer value corresponds with the sequence expected The file is a valid compressed zip b. File validation will verify that the file is compliant with the XML schema the syntax to which the whole file and transactions must comply. In the event that the file is not compliant, all transactions in the report will be rejected. c. Content validation will trigger those validation rules to verify the content of specific fields on each transaction. i. Individual transactions in the report can be rejected, while those transactions that pass validation may be progressed. ii. All errors will be available on the sftp folder against the appropriate transaction report. Statistics on Submitted Transaction Reports On a monthly basis, reports will be provided to the submitting entity with statistics pertaining to details of volumes of transaction report files and transaction report statuses during the month. Submitting entities will be able to obtain the statistics report in the sftp folder./reports/monthly. 4

6 Error Codes The following error codes correspond to file processing, and are in addition to the transaction error codes. MiFIR Annex II Data Validation Rules Transaction Reporting Error Reference Error Message Action GFSC_TR_E001 GFSC_TR_E002 GFSC_TR_E003 An unhandled exception has occurred in file processing The maximum file size permissible for uploaded files is 30Mb File name does not follow the required naming convention Please Ensure that the size of the compressed file is no greater than 30Mb Rename the file per convention in section File Naming Convention GFSC_TR_E004 The file extension must be.zip Ensure that the file that is being uploaded has been compressed GFSC_TR_E005 The file cannot be decompressed Check your compression and correct the problem GFSC_TR_E006 GFSC_TR_E007 GFSC_TR_E008 GFSC_TR_E009 GFSC_TR_E010 GFSC_TR_E011 The file contains more than one XML file The name of the XML file is not consistent with the name of its container Zip file The ISO Message Identifier in the BAH must refer to the latest schema approved The file structure does not correspond to the XML schema [result of XML validation] File <Filename> has already been submitted once The previous version of the file has been accepted Resend the files with only one XML file per Zip file Resend the file with the same name for the XML and Zip Correct the Message Identifier according to the latest XSD schema Check the result of the validation, it should correspond to formats defined in the MiFIR Transaction Reporting Technical Reporting Instruments document If the file has to be sent, increase the sequence number and resend the file Only one version of a file can be accepted by the GFSC. If the previous version of the file has been accepted and there are changes to be made to the transactions included in the accepted version of the file, the Submitting Entity shall include those changes in a file with a new sequence number. 5

7 Published by: PO Box 940 Suite 3, Ground Floor Atlantic Suites Europort Avenue Gibraltar