MiFID II and Poor Data Quality: Costly Showstoppers or Just Roadbumps?

Full article: Click here

With the huge dependence on ISIN for all things driving MiFID II reporting (ToTV, SI, and so forth), data quality is of the utmost importance. Therefore, it should be concerning if that data is not available or otherwise unreliable for the existing listed market (equities, fixed income, and listed derivatives). If you are responsible in any way for MiFID II data or reporting

around listed and cash instruments, you should take a second look at the data you receive and ensure it is in proper shape.

Using a case study of a single EU member country, we examine the data quality issues firms will need to deal with prior to January 3, 2018, or risk having potentially costly sanctions for failure to properly report under MiFID II, MAR, and CDSR.

MiFID II has mandated the use of ISINs within reporting for a number of directives. The argument has been based upon promises by representatives of the trade association, the Association of National Numbering Agencies (ANNA), and assurances by ANNA that the ISO6166 standard (the official designation of ‘ISIN’) is complete, clear, well managed, and can cover all instruments.

The quality of this foundational data, that almost all else is built upon, must be top notch and without reproach.

As we look at the 28 European Union members that are primarily affected by MiFID II (indeed, MiFID II has significant impact beyond just those 28 countries), there is an expectation that there is clarity and quality of that data necessary to use. Indeed, if there is a mandate, and there is a problem with the data – who will be at fault? Likely it will be the reporting firm to suffer any consequences.

A major focus over the past year has been the new ‘Derivatives Service Bureau’ (DSB), created by ANNA, and expected to be fully operational sometime in the coming months (currently 'open for business' since October 2, 2017). However, the non-OTC market is the responsibility of separate entities. Indeed, even though the ANNA Service Bureau (ASB, not to be confused with the DSB) is responsible for collecting ISIN data from each National Numbering Agency (NNA), there are over one hundred independent companies that have specific responsibilities for issuing ISINs in their specific market.

This would seem to be a reliable primary data source, but we can look further into a single market to see where firms that have obligations to report using ISIN (else face some sort of regulatory action) may encounter problems.

We find two concerning points. First, where real ISINs being issued are questionable in their data quality and adherence to the standard. Second, and likely more troublesome for users, where numbers are being presented and distributed from a primary source as 'ISINs' but are not actually ISINs at all.

The Czech Republic is an EU member state. On ANNA’s website, it lists the Czech “Central Securities Depository” as a “Full Member.” So we should assume that this is where a firm should go to in order to obtain ISINs, especially for anything non-OTC that they do not have an ISIN for. Exchanges, presumably, would need to go to the “Central Securities Depository” to request ISINs for any new listings.

The website is given as www.cdcp.cz. For the ‘free online services’, there is an option to get “List of Issues.” However, the function requires you to already have an ISIN to input. So it does not seem you can get a list of ISINs that CDCP has issued.

Digging further, we find the associated Prague Stock Exchange (PSE) at www.pse.cz. Here, we see listings with accompanying and associated ISINs, in Market Data. Under Standard Market, we have a selection of instruments. One UK instrument (NWR – GB00B42CTW68), and 7 other instruments. 

Those 7 instruments are split between “CS” and “CZ” based ISINs. CS, however, is the old currency code for Czechslovakia, and has been removed from the country code list since 1993, while CZ is the proper prefix country code for the Czech Republic. There are approximately 3,800 ‘CS’ ISINs issued, with about 1,000 of them still being active. Most have delisted, it would seem. And you would expect firms with CS-based ISINs that have survived since 1993 would remain with the same ISIN.

Additionally, any ISINs issued since 1993, when CS ceased being a valid country code, should have been issued with CZ based ISINs. However, a quick search finds this is not true.  for example, ISIN CS0005006758, according to the search on CDCP’s website, was issued in 2010. Other data indicates this was ‘New’ in 2001.

The main question is if the National Numbering Agency is still using CS for certain asset types, in conflict with the ISO6166 standard, or if the data regarded the creation date is just wrong. Either case should be concern to firms that depend on this data and will be affected in regards to their regulatory reporting obligations.

This also gets a bit more complicated. Indicies have both XC and CZ ISINs (XC0009698371 and CZ0160000001 for example). XC being issued by substitute numbering agency, WM Dataservice. There also seems to be a large set of 'DE' based ISINs in the market.

Further, trying to look these up on CDCP’s website yields a null result. And it appears in some places that the ISIN XC0009698371 was deactivated in 2008 – even though it is in use at the Prague Stock Exchange (https://www.pse.cz/en/indices/index-values/overview/?ID_NOTATION=325088&ISIN=XC0009698371)

Trying to unbundle these data issues is complex in and of themselves. But introduce that PSE also has listings for Gibraltar, Austria, Slovakia, The U.K. and others – the issues regarding ToTV/uToTV begin to be of concern, let alone tracking these issues, or having confidence in the identification and underlying data.

More concerning is when we shift to the energy market at PXE (www.pxe.cz). Futures contract list strikes against an ‘ISIN’, but immediately, the veracity of that is in question. PXE quotes ISINs like FCZBLY221231 (https://www.pxe.cz/Produkty/Detail.aspx?isin=FCZBLY221231#KL) and GCZBLM170831 (https://www.pxe.cz/Produkty/Detail.aspx?isin=GCZBLM170831#KL).

Yet ‘FC’ and ‘GC’ are not country codes. These are not ISO6166 codes at all, but 12 character codes seemingly created by PXE. By all appearances, it seems like the first character indicates ‘Power’ or ‘Gas’, the CZ for Czech Republic, and then the rest is a concatenation of the maturity and other properties.

These 'pseudo ISINs' are also labeled and represented as actual ISINs in the specifications and download files for PXE.

As expected, a search for these ‘ISINs’ does not provide a return on CDCP’s website. Though PXE is one-third owned by PSE, which in turn, is related to CDCP.

Due to these issues, there could be cause for concern for firms that will be mandated to use ISIN for all reporting, via MiFID II. This is just a single country example of the 28 EU members. 

In just this single market, on the following issues exist:

• ISINs being issued using CS versus CZ
• When does XC substitute numbering come into play, especially considering firms will need to request ISINs for non-OTC derivatives instruments as of January 3, 2018, if one does not exist
• How embedded is the PXE pseudo-ISINs in the current environment? Wholesale remapping of databases, not to mention a significant re-tooling and renaming across PXE services will likely be extremely disruptive and expensive, not to mention likely to introduce further confusion.
• How do non-Czech ISINs listed on Czech markets ensure proper ToTV/uToTV identification, especially if they are not listed elsewhere (i.e. Gibraltar issues)
• Why is there disparity in the data, and incorrect indication if ISINs issued are delisted/deleted or active? Who is going to clean up that data?

It is not known if this market is simply an outlier or representative of the ISIN data quality overall. In any case, firms should consider the quality of their data, and how they are applying definitions in regards to mandated ISIN use for reporting.

Problems can range from over or under reporting, to utilizing data believed to be an ISO6166 ISIN, and causing rejection by ESMA at submission (or by an APA). ESMA, as well, could see its data quality significantly corrupted by pseudo-ISINs being submitted by venues that either do not understand the ISO6166 standard, or are conflicted on where to go in a particular market when both a National Numbering Agency has been designated, but there is also a Substitute Numbering Agency operating.

The main takeaway from this look into a single EU market is that firms need to recheck their data, and re-verify even primary sources. Also, it is likely that many of these issues won't be resolved by the MiFID II January 3rd, 2018 implementation deadline, so firms should have conversations internally about data quality and reporting to the competent authorities.