Navigation and Service


27 October 2015 | Regulatory services

Reference data reconnoitre

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:

  • How much data is there in the dataset?
  • How frequently does it change and by how much?
  • How easy is it to source the data?
  • How easy is it to validate the trade data against the "golden" copy?
  • Who manages the dataset and how does one interact with them?
  • Is the data in the transaction flow in the same format or does it need to be transformed? 

Look at each dataset individually

  • Legal Entity Identifier (LEI) [ISO17442] - issued by various Local Operating Units (LOUs) worldwide, with a collated database, currently of around 400k entries, maintained by Global LEI Foundation (GLEIF).
  • Currency Code (CCY) [ISO4217] - maintained by SIX Swiss Exchange and updated on an ad-hoc basis, on average twice per year; approximately 300 entries.
  • National ID [No ISO] - a proprietary format defined by ESMA involving a cascade of preferred identifier at an individual EU member state level; typically comprising of a national identifier, passport number or concatenation of individual names, DOB. Given the diverse data set there are likely to be millions of possible entries.
  • Country Code [ISO3166] - maintained by the imaginatively titled ISO3166 Maintenance Agency, based in Switzerland, with around 250 entries which are rarely updated.
  • Market Identification Code (MIC) [ISO10383] - maintained by SWIFT, with slightly more than 1000 entries, it is updated on the second Thursday of each month, with changes effective from the fourth Thursday.
  • International Securities Identification Number (ISIN) [ISO6166] - maintained by the Association of National Numbering Agencies (ANNA), within individual securities being allocated by the relevant National Numbering Agency. ANNA states that over 26 million ISINs have been issued to date.
  • Classification of Financial Instruments (CFI) [ISO10962] - again maintained by ANNA, this specification is under review with a new version due in Q4 2015, which aims to address the additional needs imposed by new regulation. 

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.

> Back to regulatory reporting solutions