Document Purpose - CME Regulatory Reporting€¦ · Web viewBy combining our compliance expertise...

NEX REGULATORY REPORTING

SERVICE DESCRIPTION

Version 9.6

VERSION CONTROL# Date Author Changes

9.6 26/06/2018 Michele Marsden Updated regime coverage

9.5 15/06/2018 Michele Marsden Finalised NATR and ARM. ISCI section in progress

9.4 14/06/2018 Michele Marsden Still in progress NATR, ARM and ISCI

9.3 01/06/2018 Michele Marsden New format, updated Hub, APA and inserted company info and glossary

9.2 30/11/2017 Nigel Stevens ISIN eligibility check

9.1 21/11/2017 Chris Thompson Removed standard enrichments

9.0 28/10/2017 Chris Thompson Updated ISCI section, connectivity and enrichment

9.0 28/10/2017 Chris Thompson Updated response file spec

8.4 02/10/2017 Chris Thompson Updated response file

8.4 02/10/2017 Chris Thompson Updated APA accepted ingestion protocols

8.3 27/09/2017 Chris Thompson Changed reference to accepting any format due to scalability

8.3 27/09/2017 Chris Thompson Removed response file specification pending further information

8.3 27/09/2017 Chris Thompson Updated NPD information to ISCI and changed specification

8.2 25/08/2017 Chris Thompson Novated new section ‘response file specification’

8.2 25/08/2017 Chris Thompson Amended all appropriate FCA references to NCA

8.2 25/08/2017 Chris Thompson Added header/page numbering, numerous formatting changes

8.1 23/08/2017 Chris Dingley Reporting coverage added

8.0 22/08/2017 Chris Thompson Added version control

PAGE 2 | 19 MAY 2023 | CONFIDENTIAL

CONTENTS

1. DOCUMENT PURPOSE 4

2. COMPANY OVERVIEW 5

3. SERVICE OVERVIEW 8

4. REGULATORY REPORTING HUB 11

5. NEX ABIDE TRADE REPOSITORY (NATR) 16

6. APPROVED REPORTING MECHANISM (ARM) 20

7. APPROVED PUBLICATION ARRANGEMENT (APA) 23

8. FIRDS SUBMISSION 28

9. INDUSTRY STANDARD COMMON IDENTIFIER 29

10. GLOSSARY OF ACRONYMS 30


1. DOCUMENT PURPOSE The purpose of this document is to provide an overview of the functionality, features and benefits of the services provided by NEX Regulatory Reporting.

This document does not form part of a legal contract.


2. COMPANY OVERVIEWNEX Regulatory Reporting (NRR), a NEX Group business and part of the NEX Optimisation division, provides regulatory reporting services for European and international regulatory regimes to over 220 clients1 including asset managers, banks, brokerage houses, hedge funds and investment managers.

2.1. NEX GROUP PLC (NEX)

NEX is a financial technology company that operates across the full transaction lifecycle. It provides platforms, tools and expertise that enables its clients to execute efficiently and optimise resources.

NEX MARKETS ACCESS LIQUIDITYThrough our robust electronic trading platforms.

• EBS BrokerTec

NEX OPTIMISATION SIMPLIFY COMPLEXITY Throughout the transaction lifecycle with services that mitigate risk, streamline workflow and optimize resources.

• TriOptima• Traiana• Reset• ENSO Financial• NEX Regulatory Reporting• NEX Data

NEX OPPORTUNITIES CHALLENGE CONVENTION By investing in pioneering financial technology firms who change the way the markets work for good.

• Euclid Opportunities DUCO Cloud 9 Digital Asset Axoni Utility Settlement Open Gamma Acadia Soft RSRCHXCHANGE

NEX EXCHANGE REACH INVESTORS By providing an exchange where a wider community of entrepreneurs can raise capital, develop ideas and grow.

• NEX Exchange

1 Figures correct as of May 2018.

> FTSE 250 company> Market capitalisation of £3.7 billion> Headquartered in London> 1,900 employees across 14 countries1


2.2. NEX OPTIMISATION

Leading the transformation of market structure, NEX Optimisation offers a portfolio of cloud-hosted services across the transaction lifecycle. Ranging from pre-execution credit checking to multilateral portfolio compression; our purpose is to simplify clients’ workflow and help them optimise their resources.

NEX Optimisation is dedicated to mitigating risk, increasing efficiency, reducing costs and streamlining increasingly complex processes for its clients. We offer the opportunity to optimise both regulatory and financial resources.


2.3. NEX REGULATORY REPORTING (NRR)

NRR has built its pedigree across MiFID, MiFID II and EMIR and has grown its business to over 220 clients since its inception as Abide Financial in 2011. Founded by industry experts in financial markets, it’s aim was to increase the service level, efficiency and accuracy in this area, from onboarding and consultancy through to service support.

NRR combines industry and regulatory expertise, specialised consultancy, ongoing support, agile technology and global regulatory endpoints to ensure clients stay fully compliant with trade and transaction reporting requirements at go-live and beyond.

We are a reporting partner to our clients, helping them to:

Comply with evolving reporting requirements. Enhance control of the reporting process. We help to monitor,

identify and correct discrepancies within reporting workflows. Optimise resources. By outsourcing to an expert, the amount of time and resource dedicated to

complex reporting tools is significantly reduced. Stay protected. We advise our clients on the ever-changing regulatory landscape keeping them

insulated from change.

2.4. CORPORATE GROUP STRUCTURE

Detailed below are the legal entities that form the NEX Regulatory Reporting group of companies and the services they provide:

NEX Abide Financial Limited (AFL) is registered in England and provides NEX Regulatory Reporting services.

NEX Abide Trade Repository (NATR) is registered in Sweden and, as of 24 November 2017, is a registered Trade Repository (TR) with ESMA under EMIR.

Abide Financial DRSP Limited (AFDL) is registered in England and is an Approved Publication Arrangement (APA) following approval by the FCA on 24 August 2017, and a MiFID II Approved Reporting Mechanism (ARM) following approval by the FCA on 29 September 2017.

By understanding the detail, NRR ensures that our client’s regulatory reporting needs are fully met. We are a specialist provider who enables our clients to deliver timely, controlled and complete reporting.


3. SERVICE OVERVIEWEvery organisation has a unique set of regulatory reporting requirements. The NRR service begins with a comprehensive analysis of the client’s reporting environment performed by our team of regulatory experts. This is followed by the design, implementation and ongoing support of a tailor-made, end-to-end solution.

3.1.1. CUTTING-EDGE TECHNOLOGY

The NEX Regulatory Reporting Hub is a cloud-based workflow engine. Transactional data is fed into the Hub for data normalisation, enrichment, determination, reconciliation and validation before being delivered to the relevant regulatory end-point.

The Hub and accompanying client Portal have been designed to offer full transparency of the transaction lifecycle process along with offering powerful insights into reporting timeliness and underlying data quality.

Our cloud-hosted technology infrastructure is scalable, fully redundant, highly secure and is proven at handling high volume data loads. Our regulatory reporting Hub combines unrivalled technology and compliance IP to provide our clients with a simple, but highly effective way to meet all their regulatory reporting needs.

3.1.2. END-TO-END REGULATORY REPORTING SERVICE

NRR offers a truly end-to-end regulatory reporting service following the registration of its Trade Repository with ESMA under EMIR and having gained authorisation from the FCA for its Approved Publication Arrangement (APA) and Approved Reporting Mechanism (ARM) under MiFID II in 2017.


In addition to the services it provides for European regulatory regimes, NRR also provides specialised reporting services for entities subject to international regulatory regimes such as Dodd Frank, ASIC (Australia) and MAS (Singapore).

3.1.3. VALUE ADD CONSULTANCY AND SERVICE AS STANDARD

NRR is currently the only service provider in the market who provides ongoing consultancy support and a customised service layer. Our consultancy team provides clients with:

A rigorous gap analysis and consultancy review at the onboarding stage. Six monthly health checks to ensure the reporting logic supports the business flow for reports. Horizon scanning and thought leadership. Reporting and Portal training as standard. Proactive exception management and troubleshooting for validation errors. Access to [email protected] for ad hoc reporting consultancy support. Dedicated support staff for all reporting regimes:

- Account manager- Service delivery manager- Operations manager

Detailed documentation with full audit of data transformation and enrichment process – documenting solid systems and controls around the reporting function.

By combining our compliance expertise with our superior workflow engine IP, our clients can demonstrate robust systems and controls and remove systemic errors in their reporting – two key areas of concern for regulators. As a result, no organisation using our Regulatory Reporting Service has ever been fined. This is especially pertinent when you consider the large number of fines that have been given out in Europe for regulatory reporting errors and the sizable market share that NRR controls.

3.2. COVERAGE3.2.1. CLIENTS

NRR’s 220+ clients are distributed across Europe, the Americas and Asia Pacific and include:

Asset managers Corporate institutions Custodians Hedge funds Investment banks Proprietary traders Retail derivatives providers Wealth managers.

3.2.2. REGIMES

The table below details the regulatory regimes that NRR’s service currently supports (live), or will support in the near future (dev), and to which regulatory end-points it connects.


Status Regime Region Supported destinations

Regulation

Live EMIR EU Trade Repositories: NRR NATR, CME GRS, DTCC GTR, UnaVista

Regulation (EU) 648/2012 of the European Parliament and of the Council of 4 July 2012 on OTC derivatives, central counterparties and trade repositories stipulates that all standardised OTC derivative contracts should be cleared through a central counterparty (CCP) and that OTC derivative contracts should be reported to trade repositories.

Live MiFID II EU Approved Reporting Mechanism: NRR AFDL

(NCAs: FCA, AFM, AMF, CySEC, BaFIN)

Approved Publication Arrangement: NRR AFDL

Directive 2014/65/EU of the European Parliament and of the Council of 15 May 2014 on markets in financial instruments and amending Directive 2002/92/EC and Directive 2011/61/EU as implemented in the UK and EU.

Articles 20 and 21 of Regulation (EU) No 600/2014.

Live REMIT EU Registered Reporting Mechanisms: NRR, EFETNet, Trayport

Regulation (EU) 1227/2011 of the European Parliament and of the Council of 25 October 2011 on wholesale energy market integrity and transparency.

Dev ASIC Australia CME GRS, DTCC GTR ASIC Derivative Transaction Rules (Reporting).

Dev Dodd-Frank Act

US CME GRS, DTCC GTR Dodd–Frank Wall Street Reform and Consumer Protection Act 2010.

Dev FinfraG EU NRR, DTCC, SIX The Financial Market Infrastructure Act (aka ‘FinfraG’) & The Financial Market Infrastructure Ordinance (aka ‘FinfraV’).

Dev MAS Singapore

DTCC GTR

CME GRS – pending approval by the regulator

Securities and Futures (Reporting of Derivatives Contracts) Regulations 2013.

Dev SFTR EU NRR, TBC Regulation (EU) 2015/2365 of the European Parliament.


4. REGULATORY REPORTING HUBCloud-based and therefore highly scalable, the Hub enables seamless processing of high data volumes, provides connectivity to multiple venues, covers multiple regimes and jurisdictions, and is asset class agnostic. The Hub is a key component of NRR’s end-to-end regulatory reporting service.

Transaction records are uploaded into the Hub and pass through a workflow that consists of a series of enrichments, determination and eligibility checks, validations and reconciliations in preparation for delivery to the regulatory end-points. The Hub and its Portal have been designed to offer full transparency of the transaction lifecycle process and offers powerful insights into underlying reporting timeliness and data quality.

The Hub is hosted by NRR, residing on Amazon Web Services with no requirement for onsite deployment.

4.1. DATA INGESTION

The Hub can accept data feeds from multiple sources, using comma-separated values (CSV) as the standard format. Additional formats may also be accepted, such as XML (additional charges may apply).

Connectivity is principally provided using SSH File Transfer Protocol (SFTP).

4.2. DETERMINATION AND ELIGIBILITY

The Hub’s determination engine uses regime outliers and logic to identify the eligibility of transactions and the appropriate regime for delivery. Child files are then created for each regime, and an audit path is maintained to the original ingested source file. Regime specific validations are carried out on each child file, and any breaks are reported via the Portal.

A full list of determination identifiers is available on request.

4.3. ENRICHMENT

Additional and amended data is applied to transaction fields based upon client static data, reference data and standardised regime logic to ensure compliance with regulatory standards before submission.

Enrichments can be broken down into the following categories:

Standard enrichment, e.g. time and date formats, truncation, rounding. Instrument enrichment, e.g. converting Bloomberg ticker to ISIN dependent on sourced reference

data. Bespoke enrichment, e.g. working with clients to deliver user specific enrichments to any level of

granularity.


4.4. VALIDATION

To ensure acceptance at the regulatory end-points, transaction data is validated using regime specific validation rules. Validation rules are regularly updated to reflect changes in guidance, for example following the issuance of a new Q&A (EMIR) or an updated version of the ESMA guidelines (MiFID II).

A full list of lifecycle, action types, raw and conditional validation rules can be found in the relevant NRR field specification documentation. This documentation also lists all fields required for reporting to the regulatory end-points and how the Hub identifies transaction and position level records for submission.

NRR also offers a range of additional validations to identify warnings and highlight specific areas to improve underlying data quality including:

Format and completeness: NRR performs field by field validation of all data with reference to the NRR file specification.

Core regulatory validation: NRR replicates the regulatory end-point validations for all supported regimes to ensure accuracy when reporting.

Value add validation: Regime specific, this logic will highlight optional fields that would not fail a regulatory validation, with a view to improving underlying data quality.

Business logic validation: Cross referencing reporting fields to ensure logical consistency. For example, ensuring we do not process a ‘cancel’ without having received a ‘new’.

Reference data validations: Use of our reference data to certify the validity of LEI/BIC/MIC/ISIN codes for example.

The system has a mechanism for classifying validation failures according to severity, being:

Error – A 'hard fail'. Records that generate an error are not processed further until intervention in the form of correction or deletion. Errors create an alert for clients and for NRR operational staff.

Warning – A ‘soft fail’. Warnings generate a notification. Transactions with a warning are passed on to the relevant foreign system(s), but are flagged in the Portal as they occur should the client wish to correct them.

Failures can be assigned to each of the categories per client preference. Failures whose behaviour are mandated by external rules (such as mandatory ARM validations specified by the NCA), cannot have their classification chosen by the client, but clients can elect to treat less severe events as more severe (e.g. specifying that unit price lookup failures should be classed as Errors).

Trades which fail NCA or NRR mandatory validation must be corrected before they are submitted to the trade repository or the NCA. Corrections must be completed by the client. Our managed service approach ensures that clients are informed by response file, via the Portal, by text and ultimately by phone call if no action is taken.

4.5. EXCEPTION MANAGEMENT

Response and exception management is a core component of the Hub’s workflow and gives our clients confidence that they remain compliant. The Portal provides visibility of any regulatory failures and insights into the quality of the underlying data by providing the following high-level management information:


Scheduled/ad hoc configurable reports of successful or failed transactions Visibility of historic and current transaction reporting lifecycles The ability to address field level failures for resubmission Notifications and downloads for large datasets Full audit trail of all transaction history.

NRR’s onshore service support team assists clients with exception management in the transaction reporting process. The team have deep knowledge and expertise in transaction reporting.

NRR’s service support team proactively monitor and are alerted to unexpected files, duplicate file exceptions, empty files, enrichment errors, validation errors, regulator errors and response delays.

4.6. ROUTING

The Hub’s routing engine connects to the regulatory end-points as specified by the client during onboarding. Similarly, NRR will specify the IP address to be used for submission as requested by the NCA/ESMA.

NEX has its own trade repository, NATR, which is registered with ESMA under EMIR, and we expect to extend this registration to SFTR.

In addition, the Hub supports reporting interfaces to the following third-party trade repositories:

CME TR, for EMIR reporting DTCC GTR, for ASIC and MAS reporting.

We will also be adding the NATR and CME ASIC trade repositories to this portfolio, and the CME MAS Trade Repository once registered.

In addition to these trade repository registrations and relationships, NEX is also authorised by the FCA as an Approved Publication Arrangement (APA) and Approved Reporting Mechanism (ARM) under MiFID II, and by ACER as a Registered Reporting Mechanism (RRM) under REMIT.

Please note, NRR does not offer Commodity Position Reports (CPR) submissions to Trading Venues (TV). Instead NRR provides the functionality to download a CSV file, which the client can then submit to the relevant TV.

4.7. RECONCILIATION

The ability to guarantee data quality and be able to accurately identify data breaks and lineage is a mandatory requirement of the regulator. In addition, it is mandated that reconciliation check points must exist for investment firms and Approved Reporting Mechanisms (ARM) (MiFID Investment Firm RTS 22 Article 15(3) (4), DRSP ARM RTS 13 Recital 14 and Article 11(4)).

In partnership with Duco, NRR offers reconciliation check points to identify breaks and failures between client-held data, NRR-held data and data held at the regulatory end-point across all supported regimes. Visibility of the performed reconciliations is available via the Duco Cube UI or via email of SFTP for the client to download.


4.8. PORTAL

The Hub’s Portal is a sophisticated HTML5 application, designed as a customisable tool for managing the end-to-end reporting lifecycle and facilitating analytical insight.

The Portal is accessed via a secure single-entry point, and is available to users across operations, compliance, support and management. It is an essential tool that provides insights into transaction pre/post trade status with the regulator, both historically and in real-time.

The Portal incorporates responsive design, offering an intuitive experience for the user to quickly identify errors for correction, whilst constantly being mindful of data security and integrity.

For further details about the Portal including user administration, please refer to the document NEX Regulatory Reporting User Interface Guide.

4.8.1. MANAGEMENT INFORMATION

A key component of the Portal is management information: providing users with an essential overview of the transaction reporting process. The Portal aims to fully facilitate the reporting process, regulatory requirements and more, offering a rich and highly configurable interface packed with meaningful insight and analytics.

The Portal includes the following high-level functionality:

Customisable web-based user interface, bespoke per user. A view of current and historic data quality and validation failures at both a holistic and granular

level.

4.9. REFERENCE DATA

Public reference data is captured from multiple sources to provide comprehensive coverage of global financial markets, counterparty and security identifiers.

Function Requirement Regime Coverage

Determination Waivers/deferrals MiFID II Average Daily Turnover (ADT); Average Daily Notional Amount; Average Daily number of trades; Average Value of Transactions (AVT); Most Relevant Market (MRM)…


Function Requirement Regime Coverage

SI determination MiFID II Aggregated EU trading volumes per instrument

Instrument enrichment

Product classification/identification

EMIR; MiFID II ETD Contracts


EMIR; MiFID II Equities; Equity-like


EMIR Additional enrichment for ETD with currency enrichment


MiFID II OTC product details

Reference data reporting MiFID II Instrument details

Organisation enrichment

Organisation details and classifications

MiFID II List of MiFID investment firms

Organisation details and classifications

EMIR; MiFID II LEIs; Corporate sector; Nature of Counterparty; Country; …

Transaction enrichment

Transaction reporting EMIR; MiFID II ISO codes for countries and currencies

Validation Instrument validation MiFID II All instruments

Price validations MiFID II EOD market rates/prices for all instruments


5. NEX ABIDE TRADE REPOSITORY (NATR)

With regards to EMIR, a Trade Repository (TR) centrally collects and maintains the records of all derivative contracts. They play a central role in enhancing the transparency of derivative markets and reducing risks to financial stability.

On 24 November 2017, NEX Abide Trade Repository (NATR) received approval from ESMA for its Swedish-based Trade Repository under EMIR. The approval allows NRR to operate a Trade Repository for European derivatives trades. We expect to extend this registration to SFTR.

5.1. REPORTING AND PUBLICATION OF DATA5.1.1. PUBLIC DATA

Article 81(1) EMIR and Article 1 of Commission Delegated Regulation 151/2013 requires a TR to publish, in an easily accessible way and at least on a weekly basis, aggregated information of the data reported to that TR. NATR satisfies this requirement by publishing the relevant data on a website.

5.1.2. NATIONAL COMPETENCY AUTHORITY (NCA) REPORTING

NATR is required to produce a set of reports, which are made available to each NCA via a restricted SFTP site. The report suite includes the following:

ID Query Frequency Description

1 Trade Data Aggregation Report

Weekly Aggregates values from individual trade reports into a summary.

2 Reconciliation Status Report

Weekly Shows by counterparty ID the total number of accepted UTIs by the TR, UTIs not reconciled, total number of single-sided EEA paired UTIs, total number of single-sided EEA matched UTIs and total number of non-matched UTIs.

3 Rejection reports to NCAs

Weekly Number of rejection responses for the reporting entity.

4 Daily Activity Reports

Daily Contains all EMIR submissions (including exposure data) received by the TR during a day.

5 Trade State Reports Daily All outstanding trades: contains last version of all outstanding trades of all asset classes received by a TR.

Regulation (EU) 648/2012 of the European Parliament and of the Council of 4 July 2012 on OTC derivatives, central counterparties and trade repositories stipulates that all standardised OTC derivative contracts should be cleared through a central counterparty (CCP) and that OTC derivative contracts should be reported to trade repositories.


5.1.3. ESMA REPORTS

ESMA requires all TRs to make available the following reports to a restricted SFTP site:


1 Reconciliation Status Report

Weekly Shows by counterparty ID the total number of accepted UTIs by the TR, UTIs not reconciled, total number of single-sided EEA paired UTIs, total number of single-sided EEA matched UTIs and total number of non-matched UTIs.

2 Weekly Statistics Report

Weekly Provides ESMA information on the following:

Total number of reports received so far Number of reports in the last week Total number of transactions reported so far Number of transactions in the last week Total number of outstanding transactions Total notional value of outstanding trades (in EUR) (for all

asset classes excluding Commodities) Total notional value of outstanding trades for Commodities Total number of clients with signed contracts so far Total number of counterparties with reported transactions

so far Number of counterparties with reported transactions in the

last week.

3 Daily Activity Report

Daily Contains all EMIR submissions (including exposure data) received by the TR during a day.

4 Trade State Reports Daily All outstanding trades: contains last version of all outstanding trades of all asset classes received by a TR.

5.1.4. ESMA TRACE

TRACE is an ESMA project that facilitates the submission of data queries, through a centralised file exchange hub (the TRACE System), to subscribed TRs. NATR has subscribed to this project and will submit the following TRACE reports to the TRACE System.


1 All reports submitted on the previous day

Daily All the trades for which the date part of the reporting timestamp is equal to previous working day to the one in which the report is generated. For instance, if a query is sent on 3 June 2016 and it is processed early on 4 June 2016, the result of the query should contain all trades reported on 3 June 2016.



2 All outstanding trades as of the end of the reporting period

Daily or weekly or monthly

Most up to date values for each field for all the trades which were not terminated, neither errored nor matured as of the close of the previous working day. For instance, if a query is sent on 3 June 2016 and it is processed early on 4 June 2016, the result of the query should contain all the outstanding trades as of close of business of 3 June 2016.

3 All trades whose execution was reported during the previous day

Daily This query is similar to query 1, but allows the user to limit the scope of data to be received to the executions that were reported on the previous working day, i.e. all reports with action types N and P.

4 All trades matured, errored or whose termination was reported during the previous day

Daily This query is similar to query 1, but allows the user to limit the scope of data to be received to the errors or terminations reported the previous working day, as well as to the trades which matured on the previous working day.

5 All late reports Weekly This query should return as a result: (i) all reports with action type N and P where the reporting timestamp is later than the next working day (according to the TARGET calendar) after the execution timestamp; (ii) all reports with action type ‘V’ where the reporting timestamp is later than the next working day (according to the TARGET calendar) after the valuation date; (iii) as well as all reports with action types C or Z, where the reporting timestamp is later than the next working day (according to the TARGET calendar) after the termination date. The reports included in the response must have been reported within the week preceding the generation of report.

5.2. DATA INGESTION

Transaction data can be sent to the NEX connectivity layer as CSV via SFTP connection.

NATR then performs mechanical validations on the files to determine if records can be processed. Files must follow a prescribed naming convention, include all required fields/rows and be in the correct format. For further information please refer to the document NATR EMIR 2 File Specification. Files that do not conform to this specification will result in a failure.

On completion, an XML receipt file is automatically generated for each CSV file to confirm whether it has passed this validation. Receipt files for those that have failed will include the cause of failure.

Valid files will be transformed into a normalised object ready for validation of the individual records.

5.2.1. COLLATERAL REPORTING

Reporting firms can complete their collateral reporting requirement in two ways: at record level, or at portfolio level.


At record level, every report submitted to NATR should have the specific collateral associated with that record reported on it. (Note: both position and trade reports can have collateral posted which represents the collateral associated with that record).

At portfolio level every record reported to NATR, whether trade or position, should have a portfolio code attached to it and the collateral numeric and currency values left blank. Where reporting at portfolio level, the reporting firm is also required to submit a collateral record containing the most recent collateral posted by the reporting firm, with date and time information.

5.3. VALIDATION

Data is validated against ESMA’s validation specification. Validations include, but are not limited to, the following: checking the accuracy of submitted trade reports, checking the data is in the correct format (ISO standards), and that it contains valid LEIs, currency and country codes. For further information please refer to the document NATR EMIR 2 File Specification.

On completion, an XML receipt file is automatically generated for each CSV file to confirm whether it has passed this validation. Receipt files for those that have failed will include the cause of failure.

Only records which successfully pass validation will be stored in the TR database.

5.4. INTER-TR RECONCILIATION

The inter-TR process requires a TR to reconcile trade data within their own infrastructure, where possible. If the TR only holds one side of the trade, they will co-ordinate with the other TR to ensure both sides of the counterparty have paired correctly, and that each side of the trade is correct.

5.5. PORTAL

NATR provides clients, ESMA and NCAs access to a restricted Portal, which provides visibility of the data held by the TR. In addition, it also gives them the ability to query the data and download reports via SFTP connection.


6. APPROVED REPORTING MECHANISM (ARM)A MiFID II Approved Reporting Mechanism (ARM) is a company authorised under the provisions established in the MiFID II Directive to provide the service of reporting details of transactions to domestic competent authorities or ESMA on behalf of investment firms (Article (4)(1)(54) MiFID II).

Abide Financial DRSP Limited (AFDL) is a MiFID II Approved Reporting Mechanism (ARM) following approval by the FCA on 29 September 2017.

The NRR ARM and its data transfer process are designed to conform to the technical specifications defined in the Market Data Processor (MDP) Market Interface Specification (MIS) and referenced documentation.

6.1. WORKFLOW OVERVIEW

The ARM ingests reports from the NRR Hub, which it then validates and formats into the required XML schema before sending onto the relevant NCAs. The ARM consumes and processes NCA responses, and sends messages to the Hub at various stages of the process regarding the progress of each transaction.

The ARM performs all field, format and content validations as defined in EU Regulation (No) 600/2014, RTS22, Table 1 of Annex I on every transaction report processed by the ARM.

The ARM leverages the aforementioned Hub services and the following extended services.

6.2. ELIGIBILITY

Eligibility of the reportability of transaction reports is determined by the latest Financial Instruments Reference Data System (FIRDS) list, which is released by ESMA every day at 9am CET.

All transaction reports received after 9am CET on T+1 will be fully validated and processed against the FIRD list for T.

Reportability of a product for T+1 is determined by inspection of three fields: Instrument ID (which must be an ISIN), Underlying Instrument ID (one or more ISINs) and Index Name (“Official” name of Index).

If the ISIN is populated in the Instrument Identification code field, or if blank and populated in the Underlying instrument code field and present in FIRD, then the transaction report will pass validation, batched by the ARM and submitted to the relevant NCA.

If the ISIN is not present in FIRDS, the transaction report will be marked as ‘Validation Failure – Pending ISIN’.

For records in a ‘Validation Failure - Pending ISIN’ state, clients will be given the option to group override the ISIN FIRDS check within the Hub and submit to the NCA.

All transaction reports received before 9am CET on T+1 will be fully validated except for the ISIN check against FIRDS. The transaction report will transition into a waiting area until the FIRDS list for T has been loaded, at which point the ISIN eligibility check will be invoked. Transaction reports in the waiting area can be cancelled and corrected.

Any transaction report received after T+1 will use the latest ISIN reference data at the point of processing to harmonise with NCA processing.


In the event the latest FIRDS list has not been made available by ESMA, NRR will process against the previous day’s data to match the approach of the NCAs.

For any records that have a Trading Date Time on or before the previous day, the lookup will be completed against the current ISIN reference data using the appropriate date and ISIN.

Additional ISIN reference data will be sourced for global indices. This will allow us to determine dynamically whether a trade based on a certain named index is eligible for reporting.

6.3. BATCHING AND SENDING

The ARM can process, batch and send transaction reports to the NCAs 24/7. Files are formatted into the required XML schema, as stipulated by ESMA, and encrypted in accordance with the NCA guidance prior to submission.

The recipient NCA is identified during client onboarding and/or in alignment with the reporting firm’s identifier on each transaction report.

6.4. NCA RESPONSES

Response files are retrieved via SFTP connection and processed by the ARM. Transaction report results are disseminated to the appropriate source location and contain the transaction unique identifiers and the full ARM and NCA response information in both error code and human readable forms.

6.5. TRANSACTION REPORT STATUS

All transaction report statuses are captured by the ARM and included in the response files, which are then sent to the client for processing and remediation where appropriate. NCA states have been defined in accordance with the MiFIR Transaction reporting technical reporting instructions (ESMA/2016/1521).

6.6. EXCEPTION MANAGEMENT

The ARM’s comprehensive exception management functionality allows clients and our support teams to securely and safely resolve issues in the event of a content or file error or omission.

In real-time the ARM monitors all received file status messages and, upon receiving a ‘Rejected’ or ‘Corrupted File’ transaction message, produces an automated alert which is sent to the relevant client and our support teams. The alerts contain an appropriate failure reason and relevant transaction details for the client/ support teams to take the necessary remedial action at source.

6.6.1. ERRORS AND OMISSIONS

In the event a file or transaction report has an error or omission caused by the client, the ARM will automatically halt the progression of the file or transaction report and assign a status to the transaction report that will require intervention by the client to resolve. At the request of the client, our support teams can assist in resolution.

In the event of an error or omission caused by the ARM that requires data corrections within the ARM, our support teams will apply pre-configured correction and amendment tools to resolve all the


possible errors outlined within the Market Data Processor (MDP) Market Interface Specification (MIS), Section 5.8.

The ARM has been designed to keep transaction reports available to correct or cancel indefinitely to assist in future reporting, back reporting and data access requirements of our clients.

6.6.2. TRADE CORRECTIONS

NRR advises clients to make transaction report corrections, amendments, or cancellations at source wherever possible. Submission can then be processed through the normal ARM transaction flow.

In the event a transaction report has failed ARM or NCA validation and the client is unable to make the necessary amendment at source, NRR offers the client the ability to update the failed validation transaction via the Portal, revalidate the transaction report and resubmit to the ARM and subsequently the NCA.


7. APPROVED PUBLICATION ARRANGEMENT (APA)An APA is a regulated end-point authorised under the provisions established in the MIFID II Directive to provide the service of publishing trade reports on behalf of investment firms (Article (4)(1)(52) MiFID II). APAs are designed to provide services to an investment firm so that it meets its obligations under Articles 20 and 21 of MiFIR.

Abide Financial DRSP Limited (AFDL) is an Approved Publication Arrangement (APA) following approval by the FCA on 24 August 2017.

7.1. COVERAGE

The following asset classes and trading types require data to be published via an APA:

Bonds Certificates Depositary receipts Derivatives – Equity / Credit / IR / FX / Commodity / Listed / OTC Emission allowances ETFs Shares Structured finance products.

7.2. PUBLICATION OF DATA

Detailed below is the type of data to be made public based on the type of trading systems according to MiFID II Regulatory Technical Standard (RTS) 1 Annex 1 Table 1 and RTS 2 Annex 1 Table 1.

7.2.1. PRE-TRADE EQUITY AND EQUITY-LIKE

Type of trading system Information to be made public

Continuous auction order book trading system

The aggregate number of orders and the shares, depositary receipts, ETFs, certificates and other similar financial instruments that they represent at each price level for at least the five best bid and offer price levels.

The Directive 2014/65/EU of the European Parliament and of the Council of 15 May 2014 on markets in financial instruments (MiFID II) alongside the Regulation (EU) No 600/2014 of the European Parliament (MiFIR) widens the scope around the level of pre- and post- trade information required under MiFID. Regulated Markets (RMs), Multilateral Trading Facilities (MTFs) and Organised Trading Facilities (OTFs), collectively known as Trading Venues (TVs) as well as Systematic Internalisers (SIs) and Investment Firms (IFs) will either be required to, or have the option to, provide transparency to the public on quotes and trades through an APA.


Type of trading system Information to be made public

Quote-driven trading system

The best bid and offer by price of each market maker in shares, depositary receipts, ETFs, certificates and other similar financial instruments traded on the trading system, together with the volumes attaching to those prices.

The quotes made public shall be those that represent binding commitments to buy and sell the financial instruments and which indicate the price and volume of financial instruments in which the registered market makers are prepared to buy or sell. In exceptional market conditions, however, indicative or one-way prices may be allowed for a limited time.

Periodic auction trading system

The price at which the auction trading system would best satisfy its trading algorithm in respect of shares, depositary receipts, ETFs, certificates and other similar financial instruments traded on the trading system and the volume that would potentially be executable at that price by participants in that system.

Request for quote trading system

The quotes and the attached volumes from any member or participant which, if accepted, would lead to a transaction under the system’s rules. All submitted quotes in response to a request for quote may be published at the same time but not later than when they become executable.

Any other trading system Adequate information as to the level of orders or quotes and of trading interest in respect of shares, depositary receipts, ETFs, certificates and other similar financial instruments traded on the trading system; in particular, the five best bid and offer price levels and/or two-way quotes of each market maker in that instrument, if the characteristics of the price

7.2.2. PRE-TRADE NON-EQUITY

Type of system Information to be made public

Continuous auction order book trading system

For each financial instrument, the aggregate number of orders and the volume they represent at each price level, for at least the five best bid and offer price levels.

Quote-driven trading system

For each financial instrument, the best bid and offer by price of each market maker in that instrument, together with the volumes attaching to those prices.

The quotes made public shall be those that represent binding commitments to buy and sell the financial instruments and which indicate the price and volume of financial instruments in which the registered market makers are prepared to buy or sell. In exceptional market conditions, however, indicative or one-way prices may be allowed for a limited time.

Periodic auction trading system

For each financial instrument, the price at which the auction trading system would best satisfy its trading algorithm and the volume that would potentially be executable at that price by participants in that system.


Type of system Information to be made public

Request-for-quote trading system

The quotes and the attaching volumes from any member or participant which, if accepted, would lead to a transaction under the system’s rules. All submitted quotes in response to a request for quote may be published at the same time but not later than when they become executable.

Voice trading system The bids and offers and the attaching volumes from any member or participant which, if accepted, would lead to a transaction under the system’s rules

Trading system not covered by first 5 rows

Adequate information as to the level of orders or quotes and of trading interest; in particular, the five best bid and offer price levels and/or two-way quotes of each market maker in the instrument, if the characteristics of the price discovery mechanism so permit.

7.2.3. POST-TRADE EQUITY AND EQUITY-LIKE Instrument identification code Price Price currency Quantity Trading date and time Venue of execution.

7.2.4. POST-TRADE NON-EQUITY (WHERE INSTRUMENT APPLICABLE) Instrument identification code Instrument identification type Notation of quantity in measurement unit Notional amount Notional currency Price Price currency Price notation Quantity Quantity in measurement unit Reference period Trading date and time Type Venue of execution.

For further information regarding time stamping, currency standards, decimal precision, publishing times and management of incomplete or potentially erroneous information, please refer to the document MiFID II APA Service Description.

7.3. DATA INGESTION

Quote and trade data can be sent to the NEX connectivity layer in the following formats:

FIX version 5.02 CSV via SFTP


CSV upload via the client Portal.

Each message is then transformed into a normalised JSON object ready for real-time validation, enrichment and determination prior to publication.

7.4. VALIDATION AND ENRICHMENT

Quote and trade messages pass through a validation and enrichment process. This layer validates the format of each field, including valid ISINs, currency codes and venues. Errors in submissions are flagged as exceptions and withheld from publication.

Bespoke enrichment can be elected at onboarding level.

7.5. PUBLICATION ELIGIBILITY

NRR uses multiple regulatory and reference data sources to filter out eligible quotes and trades for publication. These tools also flag quotes and trades which are eligible for waiver and deferral according to Large in Scale (LIS), Size Specific to Financial Instrument (SSTI) and liquidity thresholds per instrument. These quotes and trades are then held by the APA.

7.6. PRE-TRADE PUBLICATION

Our publication channels handle 400 million quotes a day from our internal execution venues; we have extended this capability to handle pre-trade quoting from other TVs and SIs. Quotes must be published in a timely manner, no later than the time they become available to trade.

7.7. POST-TRADE PUBLICATION

Publication of trades from IFs, SIs and TVs are available both at real-time and on a 15-minute delay basis, in accordance with MiFIR Articles (12) and (13).

7.8. THRESHOLDS, WAIVERS AND DEFERRALS

A core feature of the NRR APA logic is the facility to assess trades for reporting; scrub, hold, pass. Trades are assessed for suitability for reporting or whether they should be withheld or removed altogether e.g.

Filter out non-reportable instruments Provide waiver and deferral calculations Supplementary deferral calculations.

LIS, SSTI and liquidity thresholds per instrument will benefit from a publishing waiver for pre-trade transparency and deferral for post-trade transparency.

Large compression style orders are handled on a deferred basis to prevent market impact and will require suitable flagging within the architecture platform.

Package trades will be managed by flags TPAC (Package transaction flag) and XFPH (Exchange for physicals transaction flag). Where deferral is required for the transaction, each component of the transaction will be made public after the deferral period.


ESMA’s rules on waivers and deferrals will be maintained, including any indefinite deferrals that need to be applied and any aggregated reporting requirements from NCAs. This information will be readily available in the Portal.

7.9. PORTAL

The client Portal provides secure access and full transparency on the trade reporting process and includes the following functionality:

Manage reporting exceptions Display reporting metrics and management information Daily volumes Asset class summaries Bespoke queries and reports SI determination and ongoing analysis Industry reports and metrics.

The Portal also provides additional information including:

Publication information:

Publications Waived and deferred information, including projected dates for publication Suspensions Exception management issues.

Reference data:

Liquid instrument look-up Registered SI database Registered Trading Venue database ISIN database (subject to licensing arrangements) Large in Scale and SSTI thresholds Instruments Traded on a Trading Venue.

Analytics

Summary benchmarking against peers and other industry types Product-by-product publication analysis, e.g. volumes, number of quotes/trades, sizes compared

to thresholds Functional and timeliness performance Exception management.


8. FIRDS SUBMISSIONIn accordance with RTS 23, NRR provides a Financial Instrument Reference Data System (FIRDS) submission service for MiFID II.

For further information please refer to the document MiFID II – Approved Publication Arrangement (APA) Service Description.


9. INDUSTRY STANDARD COMMON IDENTIFIERNRR has developed a short code identifier service, which is designed to enable easy compliance with MiFID II whilst fulfilling the General Data Protection Regulation (GDPR) requirements. The Industry Standard Common Identifier (ISCI) solution supports Transaction Reporting under MiFID II RTS 22 and Order Record Keeping under MiFID II RTS 24.

ISCI allows investment firms and trading venues to substitute personal information (PI) and entity information (EI) in transaction reports and order records with unique short codes, so that it will not be possible to identify an individual or entity from the transaction reports submitted to the NEX reporting Hub for processing or from the order record keeping storage.

9.1. FEATURES Short code generation ensures data protection Automated encryption: Data is both encrypted at rest, and encrypted in real time (using AWS Key

Management Service) ISCI service user interface: Entries can be made manually or by csv upload Automated upload via STP with response files Compatibility with FIX/AFME standards Multifactor authentication: Domain authentication and single sign on (as provided by Okta) Controlled access rights: Access is according to pre-defined user roles and entitlements

9.2. BENEFITS Member firms can leverage extensive network of the world’s leading investment firms already

connected to the ISCI service, meaning data only needs to be provided and updated once Easy compliance with MiFID II RTS 22 and 24 whilst fulfilling GDPR requirements Guaranteed data security with a provider backed up with robust technology Self-service model promises convenience and speed Data is never seen by anyone that does not need access to it therefore lowering the risk of a data

protection breach Maximum control over personal and entity data. Access to client data is granted on a 'need to

know' and 'least privilege' basis and is monitored and fully auditable

For further information please refer to the document ISCI Service Description.


10. GLOSSARY OF ACRONYMSACER Agency for the Cooperation of Energy Regulators ADT Average Daily TurnoverAFDL Abide Financial DRSP LimitedAFL NEX Abide Financial LimitedAPA Approved Publication Arrangement ARM Approved Reporting MechanismASIC Australian Securities and Investments CommissionAVT Average Value of TransactionsAWS Amazon Web ServicesBIC Bank Identifier Code CCP Central Counterparty ClearingCPR Commodity Position Reports CSV Comma-Separated ValuesDFA Discretionary Financial Assistance RegulationDRSP Data Reporting Services ProviderEMIR European Market Infrastructure RegulationEOD End of dayESMA European Securities and Markets AuthorityETD Exchange-Traded DerivativeETF Exchange Traded FundFCA Financial Conduct AuthorityFIRDS Financial Instruments Reference Data SystemFIX Financial Information eXchange HKMA Hong Kong Monetary AuthorityIF Investment FirmIP Intellectual Property ISCI Industry Standard Common IdentifierISIN International Securities Identification Number ISO International Standards OrganisationJSON JavaScript Object NotationLEI Legal Entity IdentifierLIS Large in ScaleMAS Monetary Authority of SingaporeMIC Market Identifier CodeMiFID II Markets in Financial Instruments Directive IIMiFIR Markets in Financial Instruments RegulationMRM Most Relevant MarketMTF Multilateral Trading FacilityNATR NEX Abide Trade RepositoryNCA National Competent AuthorityNRR NEX Regulatory ReportingOTC Over-The-Counter DerivativesOTF Organised Trading FacilityREMIT Regulation of Energy Market Integrity and Transparency


RM Regulated MarketsRRM Registered Reporting MechanismRTS Regulatory Technical StandardSFTP SSH File Transfer Protocol SFTR Securities Financing Transaction RegulationSI Systematic InternaliserSSTI Size Specific to Financial InstrumentSWIFT Society for Worldwide Interbank Financial Telecommunications TR Trade Repository TV Trading Venues


Document Purpose - CME Regulatory Reporting€¦ · Web viewBy combining our compliance expertise...

Documents

Transcript of Document Purpose - CME Regulatory Reporting€¦ · Web viewBy combining our compliance expertise...