MiFID II. Overview: Transaction Reporting Riskcare Ltd. A Riskcare Service

Transcription

1 MiFID II Overview: Transaction Reporting Riskcare Ltd A Riskcare Service

2 KEY IMPLICATIONS Increase in the number of reportable fields, from 24 to a 81 fields. Previously unreported data fields e.g. trader id and algo id (for investment decision and execution), short sale flag, option exercise type and 'natural person' details. Increased technical burden at both static data and trade capture points. Extension of the financial instruments in scope. Expansion of 'transaction' definition. Over-reporting restrictions. t+1 reporting requirement. REPORTING OPTIONS There are several feasible solutions*: 1. Internal reporting engine build 2. Outsource technology to a third party vendor 3. Purchase a vendor-built technology solution and integrate internally 4. Use trading venues as reporting mechanisms 5. Delegate to an approved reporting mechanism (ARM) authorised to report transactions to trade repositories on behalf of investment firms. They will typically charge high continuous fees in exchange for management of the reporting process *Comparative analysis available upon request MiFID II finally presents a wide implementation timeframe to strategically implement solutions that harmonise reporting across the regulatory agenda, in an efficient and scalable manner for the long-term. If a firm has the capability and desire to manage their data reporting internally, then approaches 1) or 3) may be most suitable. DATA CHALLENGES 1) Natural persons: Movement from buy/sell indicators towards buyer and seller details, including decision makers. Increased static data is difficult to gather and maintain, increasing system complexity and impacting KYC. Client outreach will be required. Data consistency issues e.g. abbreviations/spelling etc. Joint accounts who's details should be reported?. 2) Algo id / Trader id (see workstream 4). 3) Short sales flag: Requirement to flag if a sale was short at the time of execution, however it is not always clear until later on whether a sale is short. A flag may prove difficult to implement accurately given these circumstances. DATA SYNERGIES There lies opportunities for data reuse from previous reporting: MiFID I / EMIR counterparty ids, various transaction details, various instrument details, underlying instrument details, transaction number, venue ID, option style. This does not guarantee that formats will be the same and data feeds may still need to be enhanced. However, the majority of MiFID II data is newly defined and cannot be replicated. 2

3 CHALLENGES IMMEDIATE CHALLENGES IMPLEMENTATION CHALLENGES MiFID II transaction reporting: key challenges COMPLEXITY SCALE UNCERTAINTY POPULATION IDENTIFICATION identifying in-scope teams, processes, systems, products and transactions. TECHNICAL IMPLEMENTATION involves numerous systems / databases across diverse technologies and locations. INTERNAL PROJECTS dependencies with existing projects need to be carefully managed to avoid disruption. FINANCIAL INSTRUMENTS wide expansion of in-scope instruments from MiFID I TRANSACTIONS broader definition to include transmission of orders and all product modifications REGULATORY TECHNICAL STANDARDS despite delays, experience dictates that they will still be unclear in Sept. GOVERNANCE CONTROLS need to be redefined across teams, processes and systems in line with MiFID II. TIMESCALES the MiFiD II implementation window is only 21 months ( due by January 2017). DATA PROTECTION ensuring compliance with data privacy laws (particularly when reporting client data). DATA FIELDS 81 newly defined data fields are now required to be reported. DATA STORAGE huge computational effort to hold transaction data for a minimum of 5 years. FORMATTING final details of reporting formats and processes are not yet defined. DATA RECONCILIATION - against internal and external systems). EXCEPTION MANAGEMENT identification and management of anomalies. SOLUTION TESTING there is a dependency on internal and external systems. UNIVERSAL IDENTIFIERS- ensure correct identifiers are used (e.g. LEIs and UTIs*). DATA VALIDATION ensuring all data outputs are accurate, complete and compliant. DATA SOURCING intensified by issues of accessibility, formatting and availability. EVOLVING REQUIREMENTS requirements will continue to evolve as the feedback of the industry is taken on board and programmes develop. * LEI = legal entity identifier; UTI = unique trade identifier 3

4 EXAMPLE: SYSTEM ARCHITECTURE AND SERVICES Whilst loosely following our MiFID II high level approach, transaction reporting requires additional data management steps to ensure all reportable data is accounted for and accurate. For each transaction, data from numerous trading systems and data warehouses, across multiple asset classes, instruments and technologies, needs to be: 1. Consolidated 2. Validated 3. Re-formatted 4. Assembled into one report 5. Stored internally 6. Reported to a trade repository by t+1 The diagram (right) shows the basic flow of data required to report transactions to the regulator. Regulatory knowledge and communication TRADING SYSTEMS Various asset classes Various instruments DATA STORES Various asset classes Various instruments CLIENT DATA SYSTEMS (KYC) Natural persons Decision makers OTHER MIFID II DATA SOURCES e.g. reference data stores OTHER REGULATORY DATA REQUIREMENTS e.g. EMIR, Dodd Frank Impact analysis Internal connectivity data feeds Data migration (from legacy systems) Future state design Data sourcing CONSOLIDATED REPORTING ENGINE DATA CONSOLIDATION Regulation specific rules Audit trail log Gap analysis DATA VALIDATION COMPLEX EVENTS MGMT ( Business rules ) Asset class specific rules PROCESSING Report generation Dashboard (GUI) DATA STORAGE ( Big Data principles) Transaction report data warehouse Instrument specific rules Error reports System enhancements and data feeds External connectivity (report submission) Data validation Regulatory data repository 1 Regulatory data repository 2 4

5 Regulatory reporting comparison MiFID II solutions cannot be designed in isolation from pre-existing infrastructure or other regulatory implementations. For transaction reporting, there are synergies to other reporting obligations to be leveraged; including similar data fields, data sources, systems, data stores and external trade repositories. MiFID II / MiFIR MiFID I EMIR REMIT Dodd Frank Title 'Markets in Financial Instruments Directive' / Regulation' 'Markets in Financial Instruments Directive' 'European Market Infrastructure Regulation' 'Regulation on Energy Market Integrity and Transparency' Dodd Frank Wall Street Reform and Consumer Protection Act Purpose Investor protection Investor protection Market transparency and the reduction of systemic risk Detection and deterrence of market abuse. Reduction of systemic risk and prevention of another financial crisis. Implementation date January 2017 November 2007 February 2014 (valuations and collateral reporting August 2014). October 2015 (supply) / April 2016 (transportation) February 2013 Products inscope All financial instruments (i) which are admitted to trading on a trading venue or for which a request for admission to trading has been made. (ii) where the underlying is traded on a trading venue or is an index or a basket composed of financial instruments traded on a trading venue. Financial instruments trading on a regulated market. Any derivative contract (exchange traded and OTC, cleared and noncleared). 1) Contracts for the supply of electricity or natural gas. 2) Derivatives relating to electricity or natural gas. 3) Contracts/derivatives relating to the transportation of electricity or natural gas. Standardised OTC derivatives, (equities, rates, commodities, credit and FX), concerning with 'swaps' and 'securitybased swaps'. Exemptions apply. Reportable events 'Transaction' - any acquisition, disposal or modification of a reportable product. 'Transmission of orders' - unless a written transmission agreement in place and such agreement is adhered to. 'Transaction' - any purchase or sale of a financial instrument. When an in-scope entity concludes, modifies or terminates a reportable product. When an in-scope entity concludes, modifies or terminates a reportable product or places, terminates or modifies an order to trade a reportable product. The entry into or liquidation of a trade. Who must report? All investment firms, and credit institutions providing investment services and/or activities. All investment firms, and credit institutions providing investment services and/or activities. All counterparties and all CCPs. All counterparties, all CCPs and central securities depositories. Swap dealers, major swap participants, financial entities and non-financial or commercial end users. 5

6 Regulatory reporting comparison MiFID II / MiFIR MiFID I EMIR REMIT Dodd Frank Overreporting All non-reportable transactions must have reports cancelled. Whilst no compliance breach, over-reported transactions must be corrected. n/a n/a n/a n/a Backloading No No Yes (outstanding contacts pre-august 2012) Yes Yes (extending back to July 2010) Submission time As close to real-time as possible, and no later than the close of the following working day (t+1). As quickly as possible, and no later than the close of the following working day (t+1). By the working day following the conclusion, modification or termination of the contract (t+1). By the working day following the conclusion, modification or termination of the contract (t+1). As soon as technologically practicable (15-30mins) Data fields required 81 data fields Party details. Additional 'natural persons' details. Additional 'decision maker' details. Transaction. Instrument. Underlying instrument. Transmission of order information. Trader id and Algo id. Various indicator flags. 24 data fields Instrument. Transaction. Investment firm. 59 data fields Parties to the derivative contract. Beneficiary. Contract details. Valuation information. Collateral information. 62 data fields Product, price and. quantity agreed. Dates and times of execution. Parties to the transaction and the beneficiaries of the transaction. Dependent on report type Primary trade information (product, price, date and time of execution, clearing flag, material amount etc.). Secondary trade information (counterparties, trader, broker, platform, CCP, branch etc.). Lifecycle event information (assignments, novations, partial or full terminations, change in cash flows, change in title/date). Record keeping 5 years 5 years 5 years n/a 5 years after the termination / expiration date of the swap Unique trade id? Yes No Yes Yes USI - unique swap identifier Format TBC - RTS to announce a common European transaction reporting format Excel for all reports is acceptable Excel for all reports is acceptable TBC - most likely XML FPML for real time. Excel for t+1 6