Document Purpose - CME Regulatory Reporting



NEX Regulatory ReportingService description Version 9.6Version control#DateAuthorChanges9.626/06/2018Michele MarsdenUpdated regime coverage 9.515/06/2018Michele MarsdenFinalised NATR and ARM. ISCI section in progress9.414/06/2018Michele MarsdenStill in progress NATR, ARM and ISCI9.301/06/2018Michele MarsdenNew format, updated Hub, APA and inserted company info and glossary9.230/11/2017Nigel StevensISIN eligibility check9.121/11/2017Chris ThompsonRemoved standard enrichments9.028/10/2017Chris ThompsonUpdated ISCI section, connectivity and enrichment9.028/10/2017Chris ThompsonUpdated response file spec8.402/10/2017Chris ThompsonUpdated response file8.402/10/2017Chris ThompsonUpdated APA accepted ingestion protocols8.327/09/2017Chris ThompsonChanged reference to accepting any format due to scalability8.327/09/2017Chris ThompsonRemoved response file specification pending further information8.327/09/2017Chris ThompsonUpdated NPD information to ISCI and changed specification8.225/08/2017Chris ThompsonNovated new section ‘response file specification’8.225/08/2017Chris ThompsonAmended all appropriate FCA references to NCA8.225/08/2017Chris ThompsonAdded header/page numbering, numerous formatting changes8.123/08/2017Chris DingleyReporting coverage added8.022/08/2017Chris ThompsonAdded version controlContents TOC \o "1-1" 1.Document Purpose PAGEREF _Toc516754683 \h pany overview PAGEREF _Toc516754684 \h 53.Service overview PAGEREF _Toc516754685 \h 84.Regulatory Reporting Hub PAGEREF _Toc516754686 \h 115.NEX Abide Trade Repository (NATR) PAGEREF _Toc516754687 \h 166.Approved Reporting Mechanism (ARM) PAGEREF _Toc516754688 \h 207.Approved publication arrangement (APA) PAGEREF _Toc516754689 \h 238.FIRDS Submission PAGEREF _Toc516754690 \h 289.Industry Standard Common Identifier PAGEREF _Toc516754691 \h 2910.Glossary of acronyms PAGEREF _Toc516754692 \h 30Document 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 pany 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 clients including asset managers, banks, brokerage houses, hedge funds and investment managers. NEX Group plc (NEX)right156845FTSE 250 companyMarket capitalisation of ?3.7 billionHeadquartered in London1,900 employees across 14 countries100FTSE 250 companyMarket capitalisation of ?3.7 billionHeadquartered in London1,900 employees across 14 countries1NEX 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 MARKETSACCESS LIQUIDITYThrough our robust electronic trading platforms.EBS BrokerTecNEX OPTIMISATIONSIMPLIFY COMPLEXITY Throughout the transaction lifecycle with services that mitigate risk, streamline workflow and optimize resources.TriOptimaTraianaResetENSO FinancialNEX Regulatory ReportingNEX DataNEX OPPORTUNITIESCHALLENGE CONVENTION By investing in pioneering financial technology firms who change the way the markets work for good. Euclid OpportunitiesDUCOCloud 9Digital AssetAxoniUtility SettlementOpen GammaAcadia SoftRSRCHXCHANGENEX EXCHANGEREACH INVESTORS By providing an exchange where a wider community of entrepreneurs can raise capital, develop ideas and grow. NEX ExchangeNEX 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. NEX Regulatory Reporting (NRR)413893082783400413920215921600NRR 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.413893059964600NRR 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.left421005By 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. 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. Stay protected. We advise our clients on the ever-changing regulatory landscape keeping them insulated from change. Corporate group structureDetailed 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.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. Cutting-edge technologyThe 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. End-to-end Regulatory Reporting serviceNRR 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).VALUE ADD CONSULTANCY AND SERVICE AS STANDARDNRR 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 advice@abide- for ad hoc reporting consultancy support.Dedicated support staff for all reporting regimes:Account managerService delivery managerOperations managerDetailed 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.CoverageClientsNRR’s 220+ clients are distributed across Europe, the Americas and Asia Pacific and include: Asset managersCorporate institutionsCustodiansHedge fundsInvestment banksProprietary tradersRetail derivatives providersWealth managers.RegimesThe 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. StatusRegimeRegionSupported destinationsRegulationLiveEMIREUTrade Repositories: NRR NATR, CME GRS, DTCC GTR, UnaVistaRegulation (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.LiveMiFID II EUApproved Reporting Mechanism: NRR AFDL(NCAs: FCA, AFM, AMF, CySEC, BaFIN)Approved Publication Arrangement: NRR AFDLDirective 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.LiveREMITEURegistered Reporting Mechanisms: NRR, EFETNet, TrayportRegulation (EU) 1227/2011 of the European Parliament and of the Council of 25 October 2011 on wholesale energy market integrity and transparency.DevASICAustraliaCME GRS, DTCC GTRASIC Derivative Transaction Rules (Reporting).DevDodd-Frank ActUS CME GRS, DTCC GTRDodd–Frank Wall Street Reform and Consumer Protection Act 2010.DevFinfraGEUNRR, DTCC, SIXThe Financial Market Infrastructure Act (aka ‘FinfraG’) & The Financial Market Infrastructure Ordinance (aka ‘FinfraV’).DevMASSingaporeDTCC GTRCME GRS – pending approval by the regulatorSecurities and Futures (Reporting of Derivatives Contracts) Regulations 2013.DevSFTREUNRR, TBCRegulation (EU) 2015/2365 of the European Parliament.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. Data ingestionThe 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). 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.EnrichmentAdditional 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.ValidationTo 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.Exception managementResponse 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 transactionsVisibility of historic and current transaction reporting lifecyclesThe ability to address field level failures for resubmissionNotifications 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.RoutingThe 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 reportingDTCC 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.ReconciliationThe 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. PortalThe 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.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.Reference data Public reference data is captured from multiple sources to provide comprehensive coverage of global financial markets, counterparty and security identifiers. FunctionRequirementRegimeCoverageDeterminationWaivers/deferralsMiFID IIAverage Daily Turnover (ADT); Average Daily Notional Amount; Average Daily number of trades; Average Value of Transactions (AVT); Most Relevant Market (MRM)…SI determinationMiFID IIAggregated EU trading volumes per instrumentInstrument enrichmentProduct classification/identificationEMIR; MiFID IIETD ContractsProduct classification/identificationEMIR; MiFID IIEquities; Equity-likeProduct classification/identificationEMIRAdditional enrichment for ETD with currency enrichment Product classification/identificationMiFID IIOTC product detailsReference data reportingMiFID IIInstrument detailsOrganisation enrichmentOrganisation details and classificationsMiFID IIList of MiFID investment firmsOrganisation details and classificationsEMIR; MiFID IILEIs; Corporate sector; Nature of Counterparty; Country; …Transaction enrichmentTransaction reportingEMIR; MiFID IIISO codes for countries and currenciesValidationInstrument validationMiFID IIAll instrumentsPrice validationsMiFID IIEOD market rates/prices for all instrumentsleft603250Regulation (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. 00Regulation (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. 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. Reporting and publication of dataPublic DataArticle 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.National Competency Authority (NCA) ReportingNATR 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:IDQueryFrequencyDescription1Trade Data Aggregation ReportWeekly Aggregates values from individual trade reports into a summary. 2Reconciliation Status ReportWeeklyShows 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. 3Rejection reports to NCAsWeeklyNumber of rejection responses for the reporting entity.4Daily Activity ReportsDailyContains all EMIR submissions (including exposure data) received by the TR during a day.5Trade State ReportsDailyAll outstanding trades: contains last version of all outstanding trades of all asset classes received by a TR.ESMA ReportsESMA requires all TRs to make available the following reports to a restricted SFTP site:IDQueryFrequencyDescription1Reconciliation Status ReportWeeklyShows 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. 2Weekly Statistics ReportWeeklyProvides ESMA information on the following:Total number of reports received so farNumber of reports in the last weekTotal number of transactions reported so farNumber of transactions in the last weekTotal number of outstanding transactionsTotal notional value of outstanding trades (in EUR) (for all asset classes excluding Commodities)Total notional value of outstanding trades for CommoditiesTotal number of clients with signed contracts so farTotal number of counterparties with reported transactions so farNumber of counterparties with reported transactions in the last week.3Daily Activity ReportDailyContains all EMIR submissions (including exposure data) received by the TR during a day.4Trade State ReportsDailyAll outstanding trades: contains last version of all outstanding trades of all asset classes received by a TR.ESMA TRACETRACE 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. IDQueryFrequencyDescription1All reports submitted on the previous dayDaily 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.2All outstanding trades as of the end of the reporting periodDaily or weekly or monthlyMost 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.3All trades whose execution was reported during the previous dayDailyThis 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.4All trades matured, errored or whose termination was reported during the previous dayDailyThis 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.5All late reportsWeeklyThis 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.Data ingestionTransaction 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. Collateral reportingReporting 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. ValidationData 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.Inter-TR ReconciliationThe 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.PortalNATR 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. 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. Workflow overviewThe 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.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.Batching and SendingThe 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.NCA ResponsesResponse 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.Transaction Report StatusAll 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).Exception ManagementThe 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. Errors and OmissionsIn 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.Trade correctionsNRR 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.0469900The 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.00The 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.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.CoverageThe following asset classes and trading types require data to be published via an APA: BondsCertificatesDepositary receiptsDerivatives – Equity / Credit / IR / FX / Commodity / Listed / OTCEmission allowances ETFsSharesStructured finance products.Publication of dataDetailed 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.Pre-Trade Equity and Equity-LikeType 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. 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 Pre-Trade Non-EquityType 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. 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. Post-Trade Equity and Equity-LikeInstrument identification codePricePrice currencyQuantityTrading date and timeVenue of execution.Post-Trade Non-Equity (where instrument applicable)Instrument identification codeInstrument identification typeNotation of quantity in measurement unitNotional amountNotional currencyPricePrice currencyPrice notationQuantity Quantity in measurement unitReference period Trading date and timeTypeVenue 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.Data IngestionQuote and trade data can be sent to the NEX connectivity layer in the following formats: FIX version 5.02 CSV via SFTPCSV 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. Validation and EnrichmentQuote 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. 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.Pre-Trade PublicationOur 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.Post-Trade PublicationPublication 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).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 calculationsSupplementary 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.PortalThe 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 informationDaily volumesAsset class summariesBespoke queries and reportsSI determination and ongoing analysisIndustry reports and metrics. The Portal also provides additional information including:Publication information:PublicationsWaived and deferred information, including projected dates for publicationSuspensionsException management issues.Reference data:Liquid instrument look-upRegistered SI databaseRegistered Trading Venue databaseISIN database (subject to licensing arrangements)Large in Scale and SSTI thresholdsInstruments Traded on a Trading Venue.AnalyticsSummary benchmarking against peers and other industry typesProduct-by-product publication analysis, e.g. volumes, number of quotes/trades, sizes compared to thresholdsFunctional and timeliness performanceException management.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.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.FeaturesShort code generation ensures data protectionAutomated 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 uploadAutomated upload via STP with response filesCompatibility with FIX/AFME standardsMultifactor authentication: Domain authentication and single sign on (as provided by Okta)Controlled access rights: Access is according to pre-defined user roles and entitlementsBenefitsMember 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 onceEasy compliance with MiFID II RTS 22 and 24 whilst fulfilling GDPR requirementsGuaranteed data security with a provider backed up with robust technologySelf-service model promises convenience and speedData is never seen by anyone that does not need access to it therefore lowering the risk of a data protection breachMaximum 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 auditableFor further information please refer to the document ISCI Service Description.Glossary of acronymsACERAgency for the Cooperation of?Energy Regulators?ADTAverage Daily TurnoverAFDLAbide Financial DRSP LimitedAFLNEX Abide Financial LimitedAPAApproved Publication Arrangement ARMApproved Reporting MechanismASICAustralian Securities and Investments CommissionAVTAverage Value of TransactionsAWSAmazon Web ServicesBICBank Identifier?Code?CCPCentral Counterparty ClearingCPR Commodity Position Reports CSVComma-Separated ValuesDFADiscretionary Financial Assistance RegulationDRSPData Reporting Services ProviderEMIREuropean Market Infrastructure RegulationEODEnd of dayESMAEuropean Securities and Markets AuthorityETDExchange-Traded DerivativeETFExchange Traded FundFCAFinancial Conduct AuthorityFIRDSFinancial Instruments Reference Data SystemFIXFinancial Information eXchange?HKMAHong Kong Monetary AuthorityIFInvestment FirmIPIntellectual Property?ISCIIndustry Standard Common IdentifierISINInternational Securities Identification Number?ISOInternational Standards OrganisationJSONJavaScript?Object?NotationLEILegal Entity IdentifierLIS Large in ScaleMASMonetary Authority of SingaporeMICMarket Identifier CodeMiFID IIMarkets in Financial Instruments Directive IIMiFIRMarkets in Financial Instruments RegulationMRMMost Relevant MarketMTFMultilateral Trading FacilityNATRNEX Abide Trade RepositoryNCANational Competent AuthorityNRRNEX Regulatory ReportingOTCOver-The-Counter DerivativesOTFOrganised Trading FacilityREMITRegulation of Energy Market Integrity and TransparencyRMRegulated MarketsRRMRegistered Reporting MechanismRTSRegulatory Technical StandardSFTPSSH File Transfer Protocol SFTRSecurities Financing Transaction?RegulationSISystematic InternaliserSSTISize Specific to Financial InstrumentSWIFTSociety for Worldwide Interbank?Financial?Telecommunications?TRTrade Repository TVTrading Venues ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download