In October 2011, the European Commission tabled a revision proposal of the Markets in Financial Instruments Directive (MiFID II) with the aim of making financial markets more efficient, resilient and transparent, and to strengthen the protection of investors. In this article, Chris Johnson, Senior Product Manager, Market Data, at HSBC Securities Services explores how investment firms need to take early action to avoid gaps in their transaction reporting data for MiFID II/MiFIR. Data Managers within financial firms cannot afford an often-repeated mistake where market data requirements are tackled towards the end of a project’s lifecycle when it is too late to meet the requirements in time.
A stitch in time
Investment firms are making extensive preparations to ensure they achieve compliance for MiFID II/MiFIR, and no doubt currently assessing priorities for 2016, in particular which aspects of preparation could possibly wait until 2017. This is because MiFIR transaction reporting is now expected to commence in January 2018 instead of January 2017. There are some logical steps that really should be treated as a high priority now to prepare for transaction reporting data gaps and avert unnecessary and costly last minute implementation challenges.
Likely data gaps and the implications
The issue is that market data content, as specified by The European Securities and Markets Authority (ESMA) for MiFID II/MiFIR, in many cases is not yet fully formed and very possibly will not be available in time from data suppliers. Firms that take practical steps now to perform coverage checks to identify their gaps, and how to close them, will have the chance to influence their suppliers and investment counterparties to prioritise the generation of the necessary data. In other words, sourcing the market data is outside the direct control of firms and, if left to a late stage, could prove expensive with low chance of success, resulting in potential trading constraints and regulatory fines.
Regulators’ expectations
The expectation of regulators is that firms will respond to the data requirements specified in their published consultation papers, and take pro-active steps to source the necessary data in advance, to high standards of completeness, accuracy and appropriateness. The publicly accessible consultation process for MiFID II/MiFIR has been underway since December 2010, and the detailed requirements are very unlikely to change now, so the regulators will be unimpressed if there is a last minute dash in the weeks leading to implementation. There are two particular areas to watch out for: Counterparty/Client data and Asset data.
Counterparty/Client data: “No LEI; No trade”
The first area examined here is Legal Entity Identifiers (LEI) for counterparties, clients and other entities that have a role in the transaction process. The guidance from ESMA is that LEIs are required in advance of trading “No LEI; No trade”. MiFID II/MiFIR requires LEIs to be supplied for each of the parties involved in investment. Examples include executing entity, submitting entity, buyer, seller, transmitting firm for the buyer and transmitting form for the seller. Trading venues will require LEIs for issuers and there are also maintenance requirements for the entity that submitted the order, the client and any non-executing brokers. This means that investment firms and trading venues must obtain LEIs for multiple parties for each transaction report, must store these in their reporting system and have in place the necessary maintenance procedures.
Each of those entities must buy their LEI using a credit card, via a Local Operating Unit, and furthermore each of the LEIs must be ‘active’ to be eligible for transaction reporting. To remain ‘active’ the LEI must be renewed annually by its owner, rather like car tax renewal. As of mid-2015 the coverage levels for Issuer LEIs for rated instruments globally was as low as 15%. Market data is largely outside of the control of the firm so there will be gaps unless steps are taken well in advance. Leaving market data until the later stages is high risk. In many cases the data vendors have no influence and so active steps are necessary to generate the required data in advance.
Asset data
The second area of data challenge relates to assets (also known as securities or instruments). First, the ISIN (ISO 6166) is long established (albeit revised in recent years), is well known and, for example, is used extensively to support securities trade matching. However, for MiFID/MiFIR ESMA expects the ISIN to be extended to cover all exchange traded derivatives and OTC derivatives as well. It is possible that firms will need to pre-buy batches of ISINs from numbering agencies (such as the LSE, SIX and Cusip) to be allocated to their unlisted assets. The maintenance procedures for these will be significant. Another field is the CFI (ISO 10962), which again is not fully formed yet.
In conclusion
The “No LEI; No trade” requirement for MiFID places a very strong incentive for firms to tackle the data requirements as soon as possible given that the required data might not be in existence yet. The logical step that can be taken by all investment firms without any delay is to measure current data availability, for the required data fields, that is already available for their held assets and current counterparties and clients, and identify the data gaps. It would be a high risk strategy to assume that others will take steps to solve the regulatory market data gaps. It is only by performing coverage checks now, and speaking to suppliers and counterparties, that firms can assess the scale of the challenge and ensure that their needs are prioritised and data gaps closed and actioned in plenty of time to deliver compliant transaction reporting.
References
MiFIR RTS 22 (in ESMA/2015/1464), Article 13(2):
“Investment firm [sic] shall not provide a service that would trigger the obligation of an investment firm to submit a transaction report for a transaction entered into on behalf of a client who is eligible for the legal entity identifier code, prior to the legal entity identifier code being obtained from that client.”
