MiFID II Transaction Reporting. 29 September 2017

Size: px

Start display at page:

Download "MiFID II Transaction Reporting. 29 September 2017"

Delilah Richard
6 years ago
Views:

1 MiFID II Transaction Reporting 29 September

2 Welcome!

3 Summary Overview Transaction Reporting Process Registration Interface Validation Response Routing Testing Questions

4 Overview MiFID II introduces wholesale changes to the MiFID regime. The changes include massive increases in complexity increasing the number of reportable financial instruments, number of firms that have an obligation to submit transactions, number of data elements, and classification of data being transmitted (individual data). The purpose of this session is to provide an overview of the systems and controls introduced by the GFSC to support MiFID II Transaction Reporting. We intend to cover the testing strategy for October/November This presentation will not cover the general principles of MiFID II, the fundamentals surrounding transaction reporting such as the scope of coverage, reportable fields and detail on structure of the transaction report. Number of reportable fields MiFID MiFID II Transaction Reports Instrument reference data reports * Scale of change in number of reportable fields

5 MiFID II Milestones Design and delivery of the strategic MiFID II Transaction Reporting solution. ESMA issue Consultation Paper on draft ITS 31 Aug 2015 MiFID II transposed into national law 03 Jul 2017 Q GFSC Solution Design & Build 1/10 MiFID II transposed into national law Testing 1/11 Industry Test 3/1/18 3/1/18 Go-live & Transitional Upcoming milestones October 2017 o GFSC testing commenced o Industry testing commenced November 2017 o Kick off integration testing : Industry testing with GFSC January 2018 o MiFID II/MiFIR apply within all member states Current status: Build near complete, pending testing Q2 2018

6 Working Group Industry engagement commenced in early 2017 with a business working group for MiFID II. A technical sub-group was launched in July 2017 to gather feedback from industry bodies in the transaction reporting solution Purpose of Working Group o Technical and practical input o Forum to resolve technical matters o Facilitate dialogue between GFSC and industry Attendees o Gibraltar Funds and Investments Association o Gibraltar Bankers Association o Gibraltar Insurance Association Topics o o o o o Transaction reporting milestones Interface solution Technical Specifications Validation Industry progress and feedback

7 2. Interface Transaction Reporting Process 1. Registration 2. Interface 3. Validation 4. Feedback 5. Routing 4. Response 1. & 2. All firms must register for transaction reporting. Transactions are required to be reported T+1 (no more than one day after execution). 3. Validation takes place against the content and reference data (including Instrument identifier). 3. Validation 5. Routing 4. Response will be provided to the Submitting Entity. Response will be provided R+1 (where R is the received date) or as long as R+7 should the ISIN be pending validation. 5. Transactions are stored by the GFSC for internal processing. If applicable, they will be routed to NCAs that fall under the applicable routing criteria.

8 Registration 1. Registration 2. Interface 3. Validation 4. Feedback 5. Routing Registration form available on our website under Regulated Firms MiFID II Transaction Reporting, or can be requested via The form will request your firm name, GFSC Licensee number, primary contact person, further authorised personnel and a statement of confirmation indicating that you understand your reporting obligations under MiFID II. Furthermore, the firm will be required to state whether reporting will be delegated, and if so to which ARM. An IP address must be registered for firewall configuration. When processed, an will be issued with instructions, credentials and a certificate to support FTPS. Should the firm opt to delegate reporting to an ARM, the firm will be granted access to the GFSC Cloud for the purposes of obtaining reconciliation reports. Each firm will be required to register. Additional information from ARMs ARMS will be asked for additional information such as firm LEIs, authorisation details, firms servicing.

9 File Specification Requirements 1. Registration 2. Interface Further information is available on the GFSC Transaction Reporting Technical Specification, available on the GFSC Transaction Reporting website* Naming Convention Transaction reporting files must adhere to the following naming convention: SSSSSSSSSSSSSSSSSSSS_YYYYMMDD_NNN.zip File Contents a. SSSSSSSSSSSSSSSSSSSS the submitting entities LEI (20 alphanumeric characters) 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 3. Validation 4. Feedback 5. Routing 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; 7. The name of the Transaction Report XML file must be the same as that of the zip that contains it *

10 File Transmission Specification 1. Registration 2. Interface 3. Validation 4. Feedback 5. Routing There are two channels by which firms can submit transaction reports. The service is expected to be operational 24/7 except for scheduled maintenance outages. As such, transactions executed on a Friday can be submitted during the weekend. FTPS A means of secure file transfer, FTPS (File Transfer Protocol using the Secure Sockets Layer protocol) is scalable to allow for a less manual approach to transmission. Interaction can also be manually completed with the use of an FTPS client, such as Filezilla. GFSC Cloud A web based portal that allows files to be uploaded to the GFSC servers. The cloud will provide most beneficial for those firms that wish to upload files manually, with least setup and maintenance effort required. FTPS GFSC Cloud

11 Transmission Channels 1. Registration 2. Interface Credentials and the IP address to the FTPS server will be issued upon successful registration. It is recommended that every individual user that will upload files have their own credentials. Submissions will be amendable up to the point at which the file processing commences. Upon completion of processing, the file will be placed in a subfolder corresponding with its status. New submissions shall be placed in the./submission folder. The system will identify new files and commence processing shortly after the file has been uploaded. It is advised that ARMs separate submissions, grouping by Executing Entity. 3. Validation 4. Feedback 5. Routing./corrupted/./accepted/./partially_accepted/./rejected/./submission/ Those files that are found to not meet the required criteria Submissions that were accepted in their entirety Submissions that had been partially accepted; transactions may be in a Pending or Rejected status Submissions where all transactions had been rejected New submissions will be placed in this folder.

12 Validation 1. Registration 2. Interface 3. Validation 4. Feedback 5. Routing Schema Definition (regular expressions, min/max occurs) XML Schema Validation In case of error, whole file is rejected Reference Data (ISIN, ISO 3166, 4217, 10383, etc) Application level validations Only incorrect transactions are rejected Definition between fields

13 National Identifiers 1. Registration 2. Interface 3. Validation 4. Feedback 5. Routing For Gibraltar nationals: 1. Passport 2. Concat In case passport number is used, the following characters are only allowed: capital Latin letters (A- Z), numbers (0-9). It can be a string of 3 to 35 characters, where first two characters are letters. In case the CONCAT code is used, the following characters are only allowed: capital Latin letters (A-Z), numbers (0-9), number sign "#". It should be a string of exactly 20 characters where first two characters are letters, the next 8 characters are numbers and the remaining characters are letters or # where 11th and and 16th character are letters. (note: With the introduction of MiFIR, Full name and Date of Birth has to be reported)

14 Submission Status 1. Registration 2. Interface 3. Validation 4. Feedback 5. Routing <FinInstrmRptgStsAdvc> <StsAdvc> <MsgRptIdr>104</MsgRptIdr> <MsgSts> <RptSts>PART</RptSts> <Sttstcs> <TtlNbOfRcrds>2</TtlNbOfRcrds> <NbOfRcrdsPerSts> <DtldNbOfTxs>1</DtldNbOfTxs> <DtldSts>ACPT</DtldSts> </NbOfRcrdsPerSts> <NbOfRcrdsPerSts> <DtldNbOfTxs>1</DtldNbOfTxs> <DtldSts>RJCT</DtldSts> </NbOfRcrdsPerSts> </Sttstcs> </MsgSts> <RcrdSts> <OrgnlRcrdId>TXID1</OrgnlRcrdId> <Sts>RJCT</Sts> <VldtnRule> <Id>CON-072</Id> <Desc>Buyer MIC CHIR if not valid for the trade date</desc> </VldtnRule> <VldtnRule> <Id>CON-071</Id> <Desc>Buyer national identification code AB does not include valid country code</desc> </VldtnRule> </RcrdSts> </StsAdvc> </FinInstrmRptgStsAdvc> </Status> The Submission Status report includes a summary of the Transactions that had been received and processed, including a status for the submission This will include a breakdown of the number of transactions grouped under each status Each transaction that failed validation is listed, together with the validation rules that resulted in the rejection: in this case, CON-072, MIC not validated against reference data CON-071, Buyer identification code not a valid country code

15 Transaction Reconciliation 1. Registration 2. Interface 3. Validation 4. Feedback 5. Routing For those firms delegating Transaction Reporting to ARMs, it will be expected that regular periodic reconciliations are completed. The purpose of the reconciliation is to ascertain the completeness and accuracy of transactions submitted to the GFSC on behalf of the Executing Entities. It is the executing firms responsibility to implement reconciliation, quality assurance and data validation processes. Should it be found that the GFSC holds incomplete or incorrect data on transactions reported by the Submitting Entity on behalf of the firm, it is the obligation of the firm to inform the GFSC of the discrepancy. Reconciliation reports can be requested by a member on the firms authorised personnel list (as requested on registration) sending an to infotrs@gfsc.gi. The should include the firms LEI, start and from date. The report will be issued on the GFSC Cloud on a best efforts basis. In accordance to local record retention legislation submitting entities and executing entities are required to maintain data sent to and received from the GFSC for 7 years.

16 Routing 1. Registration 2. Interface 3. Validation 4. Feedback 5. Routing Each NCA should have access to all transactions within its surveillance remit, regardless of the member state where the transaction was report. Transactions submitted to the GFSC will be routed to the Relevant Competent Authority. Only valid transactions can be routed. Pending and rejected transactions will not be included. What was traded What is the country branch Where was the trade executed Routing Criteria A transaction will be sent to the CA in charge of the most relevant market where the transaction was executed An OTC derivative transaction must be sent to the CA in charge of the most relevant market in terms of liquidity of the underlying instrument A transaction wher ethe underlying is a basket must be sent to the relevant CAs for each of the basket constituents that are reportable under MiFIR A transaction must be sent to the CAs which registered an interest in the index. A transaction where the country branch is indicated must be sent to the CA A transaction must be sent to the home CA of the trading venue or SI where the transaction took place Pre-condition Instrument admitted to trading Underlying instrument is an instrument admitted to trading Instrument admitted to trading or Underlying instrument admitted to trading Indices identified by ISIN Transaction executed on the EEA trading venue or internaliser

17 Testing In addition to internal testing of the GFSC solution, functional and non-functional tests between the firm and the GFSC will be executed. Industry testing will run from 6 th of November to the 15 th of December. For stability, an embargo on system change will be imposed on the solution in advance to the 3 rd of January commencement date. Timelines Phase Start Date End Date Firm Functional Testing Integration Testing between Submitting Entity and GFSC (cycle 1) Integration Testing between Submitting Entity and GFSC (cycle 2) To be planned individually by firm 6 Nov Nov Nov Dec 2017 Pre-production testing 4 Dec Dec 2017 The firm is expected to have undertaken a degree of testing in advance to commencing integration testing. The first round of integration testing will validate connectivity testing, generation of application header and validity of submission against XSD, and reference data rules. Submission response will be tested. The second cycle of integration testing will include scripts to test transaction lifecycle, content validation and reconciliation reports Pre-production testing will be driven on an ad-hoc basis should it be found that re-tests or further functional testing be required.

18 How ready are you? The below list is not exhaustive. It lists a number of suggested areas firms will need to consider when assessing compliance with the MiFID II Transaction Reporting requirements. Phase Operations Detail Ensure all necessary parties are suitably equipped with LEIs Determine the scope of MiFIR applicable transactions Determine where transaction data resides If necessary, establish data feeds to ARM If necessary, have you established a reconciliation process? Have you validated that your reference data will meet the MiFID II standards? Development Transaction Reports are being generated and validated If required, file transmission is being automated via FTPS If required, Status Response file retrieval is automated via FTPS. Testing Prepare test submissions per GFSC scenarios Integration testing to access firms transaction reporting folder structure (FTPS or GFSC Cloud) Approval received by GFSC on validity of test XML files Ability to access and process status reports Training Have the necessary staff members that are taking on responsibility for transaction reporting participated in training on preparation and validation of transaction reports? Have operating procedures been updated to incorporate transaction reporting processes?

19 What to expect next.. - (Ongoing) Continued engagement with ARMs - 29th September: Webinar available on TR sub site - 29 th September: Registration Form published on website - 9 th October : Technical Sub-Group reconvenes - 6 th November : Industry Testing; Cycle 1

20 Questions Comments

Transaction Reporting under Regulation 600/2014 ( MiFIR ) Operational and Technical Arrangements Central Bank of Ireland

Transaction Reporting under Regulation 600/2014 ( MiFIR ) Operational and Technical Arrangements Central Bank of Ireland Data standards and formats for MiFIR transaction reporting are prescribed in the