Financial market participants require fast, concise and accurate information to successfully operate in today’s markets. Deutsche Börse’s ...
The September publication of RTS 22 lists 65 fields for transaction reporting, with over a third defined as standards based, non-trivial, reference data. Of these 26 reference data fields there are 7 different data types that are used throughout. In order to fulfil their reporting obligation firms will need to source the relevant data per transaction and ensure its accuracy, which typically means checking it against an up to date, complete source of reference data.
There are a number of factors to consider with respect to the reference data sets:
Look at each dataset individually
These are the raw facts, but what does this mean for the firm required to report the data under MIFID II?
Three obvious pain points stand out:
1. National Identifiers are unlikely to be part of the trade flow already due to the personal data that they are based on, so this either needs to be added to the trade flow (time and cost to modify existing systems) or composed with the trade data at a later point in the flow, for example in a transaction reporting hub. There is no single definitive database that a national identifier can be compared against to determine validity, so this will be challenging for firms, ARMs and NCAs to manage. Given the ability for each EU member state to issue or rescind identifiers on a daily basis this is also likely to be a highly volatile dataset.
2. ISINs currently exist and are well-used in markets and have support in systems; they are likely to be part of the existing trade data flow. However, with MIFID II ESMA has mandated that all instruments (also derivative instruments), and their underlying instruments be identified by an ISIN and this is very much not the case in the market. In EMIR ESMA permitted multiple identification schemes for instruments including ISIN, Alternative Investment Identifiers (AII) and CFI codes to be used. One of the main challenges will be to source ISINs for all traded instruments in a timely fashion. The second significant challenge will be to validate reportable ISINs. Whilst lists of ISINs are available there is no definitive list of reportable ISINs under MiFIR.
3. LEIs have been embraced in light of their requirement for EMIR derivatives reporting that started in early 2014, however firms may still find that not all of their trading counterparties have an LEI. Two notable groups are third country participants, where there is no enforceable requirement to possess an LEI, and fund managers, where each individual fund may require an individual LEI, which can be an onerous and expensive process. A final complication is the fact that LEIs must be managed, and paid for, on an annual basis, which many firms are not doing and so some LEIs are no longer valid.
Firms can start analysing their systems now, since further ITS or review by Commission, Council or Parliament are unlikely to change the reference data used. A first step is to identify all the systems that will contribute data to the transaction reporting process and find out where there are gaps in the trade data versus the requirements of the regulator. Firms then have a number of options: they can try to augment or upgrade existing systems to capture and report the new data; they can collate the data in some hub in-house and then enhance the data with feeds from external sources (such as data vendors); finally, they can leverage from market infrastructure vendors and ARMs who can help enhance and transform the data so it is suitable for reporting.
When it comes to reference data an investment in knowledge really does pay the best interest.