129 September 2017

MiFID II – Transaction Reporting

Welcome!

Summary

• Overview

• Transaction Reporting Process‒ Registration

‒ Interface

‒ Validation

‒ Response

‒ Routing

• Testing

• Questions

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 2017.

• 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 22 65

Instrument reference data reports 17 48

* Scale of change in number of reportable fields

ESMA issue Consultation Paper on draft ITS

Upcoming milestones

• October 2017o GFSC testing commencedo Industry testing commenced

• November 2017o Kick off integration testing : Industry testing with GFSC

• January 2018o MiFID II/MiFIR apply within all member states

MiF

ID II

Design and delivery of the strategic MiFID II Transaction Reporting solution.

31 Aug 2015 03 Jul 2017

Q2 2018

Testing

1/10

GFSC Solution Design & Build

Q1 2017

MiFID II transposed into national law

Industry Test

1/11

Go-live & Transitional

3/1/18

Milestones

MiFID II transposed into national law

3/1/18

Current status: Build near complete, pending testing

• Purpose of Working Groupo Technical and practical input o Forum to resolve technical matterso Facilitate dialogue between GFSC and industry

• Attendeeso Gibraltar Funds and Investments Association o Gibraltar Bankers Association o Gibraltar Insurance Association

• Topics o Transaction reporting milestoneso Interface solutiono Technical Specificationso Validationo Industry progress and feedback

Working GroupIndustry 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

2. I

nte

rfac

e

1. & 2. All firms must register for transaction reporting. Transactions are required to be reported T+1 (no more than one day after execution).

4. Response

3. Validation 5. R

ou

ting

3. Validation takes place against the content and reference data (including Instrument identifier).

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.

Transaction Reporting Process3. Validation

4. Feedback 5. Routing

1. Registration 2. Interface

• Registration form available on our website under Regulated Firms – MiFID II – Transaction Reporting, or can be requested via email: infoTRS@gfsc.gi

• 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 email 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.

Registration3. Validation 4. Feedback 5. Routing1. Registration 2. Interface

Further information is available on the GFSC Transaction Reporting Technical Specification, available on the GFSC TransactionReporting website*

Naming Convention

Transaction reporting files must adhere to the following naming convention:

SSSSSSSSSSSSSSSSSSSS_YYYYMMDD_NNN.zip

a. SSSSSSSSSSSSSSSSSSSS – the submitting entities LEI (20 alphanumeric characters) b. YYYYMMDD – the submission date of the filec. NNN – an integer from 001 to 999 denoting the submission value for the dayd. .zip – the file extension, the file must be compressed before transmission

File Contents

The transaction report file must contain a single ISO 20022 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

* http://www.gfsc.gi/firms/mifidII/transactionreporting

File Specification Requirements3. Validation 4. Feedback 5. Routing1. Registration 2. Interface

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.

File Transmission Specification3. Validation 4. Feedback 5. Routing1. Registration 2. Interface

FTPS GFSC Cloud

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.

Transmission Channels3. Validation 4. Feedback 5. Routing1. Registration 2. Interface

./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.

Schema Definition(regular expressions, min/max occurs)

Reference Data (ISIN, ISO 3166, 4217, 10383, etc)

Definition between fields

Application level validationsOnly incorrect transactions are rejected

XML Schema ValidationIn case of error, whole file is rejected

Validation3. Validation 4. Feedback 5. Routing1. Registration 2. Interface

For Gibraltar nationals:

1. Passport 2. Concat

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.

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.

National Identifiers3. Validation 4. Feedback 5. Routing1. Registration 2. Interface

(note: With the introduction of MiFIR, Full name and Date of Birth has to be reported)

The Submission Status report includes a summary of the Transactions that had been received and processed, including a status for the submission

<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>

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

Submission Status3. Validation 4. Feedback 5. Routing1. Registration 2. Interface

• 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 email to infoTRS@gfsc.gi.

• The email 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.

Transaction Reconciliation3. Validation 4. Feedback 5. Routing1. Registration 2. Interface

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.

Routing Criteria Pre-condition

What was traded A transaction will be sent to the CA in charge of the most relevant market where the transaction was executed

Instrument admitted to trading

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

Underlying instrument is an instrument admitted to trading

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

Instrument admitted to trading or Underlying instrument admitted to trading

A transaction must be sent to the CAs which registered an interest in the index.

Indices identified by ISIN

What is the country branch A transaction where the country branch is indicated must be sent to the CA

Where was the trade executed A transaction must be sent to the home CA of the trading venue or SI where the transaction took place

Transaction executed on the EEA tradingvenue or internaliser

3. Validation 4. Feedback 5. Routing1. Registration 2. Interface

Phase Start Date End Date

Firm Functional Testing To be planned individually by firm

Integration Testing between Submitting Entity and GFSC (cycle 1)

6 Nov 2017 17 Nov 2017

Integration Testing between Submitting Entity and GFSC (cycle 2)

20 Nov 2017 1 Dec 2017

Pre-production testing 4 Dec 2017 15 Dec 2017

Testing

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.

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 6th of November to the 15th of December. For stability, an embargo on system change will be imposed on the solution in advance to the 3rd of January commencement date.

Timelines

Phase Detail

Operations 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 oftransaction reports?

Have operating procedures been updated to incorporate transaction reporting processes?

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.

What to expect next..

- (Ongoing) Continued engagement with ARMs

- 29th September: Webinar available on TR sub site

- 29th September: Registration Form published on website

- 9th October : Technical Sub-Group reconvenes

- 6th November : Industry Testing; Cycle 1

QuestionsComments