Full PDF: Click here

INTRODUCTION

The updated version of the EU’s Markets in Financial Instruments Directive (MiFID) is due for implementation on 3rd January, 2018. MiFID II/MiFIR, to give the full acronym, includes an extensive set of transparency and reporting obligations, which can be found in the new ‘regulation’ part of MiFID II (the MiFIR piece).

MiFID II takes transparency and reporting to a new level, both in terms of depth and of scope. This depth and scope is evidenced by the range of instruments captured by MiFID II, and the depth of detailed information that must be provided in respect not just of trades and transactions, but also in terms of the reference data required to be provided for financial instruments trading on MiFID II venues.

Perhaps more than any other part of this legislation, the transparency aspect has been the subject of the most intensive industry scrutiny. Much of that scrutiny revolved around the various waivers and deferrals relating to the transparency obligations. The result has been a very complex set of thresholds and conditions whereby reporting obligations can be deferred, particularly in relation to nonequity instruments. In recent months the focus has moved on to practical issues of implementation, which increasingly come down to managing the data issues so that firms can navigate the complexity of MiFID II. This will help firms to successfully discharge their compliance obligations, while taking advantage of any transparency carve outs that are available.

Before looking in more depth at these challenges it is worth first reminding ourselves of the different approaches to data taken by the Delivered by the regulators in MiFID II. Taking into account the experience of the original MiFID regime from 2007, and the implementation of other data intensive regulations such as the European Market Infrastructure Regulation (EMIR), EU regulators determined early on to place more emphasis on the use of standards for MiFID II compliance. This was because of issues of data quality that had arisen in the reporting aspects of these earlier measures.

Accordingly, when it drew up the detailed rules for MiFID II—known as regulatory technical standards (RTSs), ESMA (the European Securities and Markets Authority) took the decision to be far more prescriptive about the data standards and formats to be used in various aspects of the transparency and reporting regime.

ESMA has chosen in the main to mandate some key standards issued and maintained by ISO—(the International Organisation for Standardisation). Examples of the key standards so mandated include: ISO 20022 reporting messages; ISO 4217 currency codes; ISO 3166 country codes; ISO 10383 market identifier code; ISO 8601 date and time format; ISO 17442 legal entity identifier; ISO 18774 financial instrument short name; ISO 10962 classification of financial instruments and ISO 6166 international securities identification number (ISIN).

All of the above are identifier standards in some way, with the exception of ISO 20022. It is worth pausing a moment to spend a little time on this important ESMA requirement. This ISO 20022 based approach to the construction and formatting of the MiFID II reports to regulators has a significant impact on the data challenge associated with MiFID II.

ISO 200221 is a methodology for the construction of electronic financial messages to match business processes and data f lows. It includes a data repository of standardised financial services metadata relevant to the various business processes for which ISO 20022 messaging is used. An additional layer of ISO 20022 enables the creation of actual messages according to XML schemas. Messages, though, can be ISO 20022 compliant without using an XML schema, but ESMA has chosen to implement ISO 20022 XML schemas for the MiFID II reporting to regulators (eg for transaction reporting). These message schemas have undergone a review within the ISO process, but it is likely that the initial versions will need some further revision once MiFID goes live. All of the ISO data elements listed above are compatible with use in ISO 20022 messages, and this use of ISO 20022 formats is a main driver for the data approach adopted for the content of the MiFID II reporting to regulators.

Within the ISO 20022 messaging and beyond, the main focus, however, in this paper is on financial instrument and entity identification challenges in MiFID II.

Being able to unambiguously identify what is being traded, and the parties involved in the transaction, goes to the heart of much of the new MiFID II regime. By far the most complex aspect of this relates to identifying the financial instruments affected by MiFID II.

IDENTIFYING FINANCIAL INSTRUMENTS

As mentioned above, ESMA have chosen to mandate the ISIN as the standard identifier for financial instruments in MiFID II (and this has been extended to other reporting regimes including the updated EMIR reporting coming in November 2017, and the reporting under the forthcoming Securities Financing Transaction Regulation—SFTR, due later in 2018). While on the surface this approach appears uncontroversial, in reality it has proven problematic, and is presenting an ongoing challenge to the industry. The reason harks back to the scope of MiFID II, which demands varying levels of transparency across a wide cross section of asset classes—with ISIN as the common identifier. ISIN as an ISO standard has been around for 25 to 30 years. The ISIN is issued by a network of National Numbering Agencies (NNAs) all of which are members of an umbrella organisation called the Association national Numbering Agencies (ANNA). The NNAs have typically assigned ISINs to equities and bonds as part of the issuance process for these instruments. ISIN is a 12-character identifier that includes the country code of the issuing NNA as the first two characters, and the local securities identifier bulked out to 12 characters, including a check digit. So, for example, in the UK the ISIN is essentially the local Sedol code expanded to 12 characters, including a GB code on the front and a check digit at the end.

There are other financial instrument identifier standards, for example, the financial instrument global identifier (FIGI), which is now an open standard under the Object Management Group (see below). ISIN is the chosen identifier for MiFID II, however.

Although not without problems, the ISIN coverage for such fungible instruments as equities and bonds broadly works, and enables them to be traded and settled beyond their domestic market. Although, ISIN has had problems with both a lack of uniqueness in some cases, a lack of granularity down to the trading platform level and also a failure to adopt persistence of the code through corporate actions processes. Approximately 14 million active ISINs were in existence in 2015 according to figures from ANNA.2 It is the case, however, that the coverage of ISIN across all the assets falling into the MiFID transparency regime is far from complete; indeed in some areas it is currently non-existent.

Derivatives, both listed and over-thecounter (OTC), present the biggest problem. Although some listed derivatives have ISINs today, most do not and it is far from clear whether the local NNAs are geared up in each market to issue these ISINs. The bigger problem though is OTC derivatives.MiFID II extends across the derivatives world and aims to bring more transparency to these markets. This includes an obligation in MiFID II for some OTC derivatives to trade electronically on the trading venues recognised under MiFID II; regulated markets, multi-lateral trading facilities and organised trading facilities.

The trading obligation in MiFID II is designed to force standardised OTC derivatives onto these venues to trade electronically. The regulatory technical standards relating to this trading obligation are still being worked through by the EU, but the direction of travel is clear. This is coupled with the decision by many market players to move their trading onto venues ahead of any regulatory requirement to do so. Pure OTC trading will remain, but this will tend to be for more exotic products. All products moving to venues will need an ISIN in order to be MiFID compliant for trading on a venue.

The ISIN requirement has recently been clarified to mean in practice that all new financial instruments/products admitted to trading on a venue, or traded by MiFID systematic internalisers (SIs), must get an ISIN by the end of their first trading day. This is so that the ISIN can be quoted on the financial instrument reference data reports that must be made to regulators by trading venues and systematic internalisers by the end of trading day. This reference (and market volume) data, including ISINs, ultimately ends up at ESMA.

So how will venues, SIs and others be able to get the ISINs they need across all products to be able to comply with ESMA’s reference data rules?

ANNA announced in 2016 that ISINs for OTC derivatives would not be issued by their National Numbering Agency members, but would instead be issued by a new infrastructure being built specifically for the purpose—the Derivatives Service Bureau (DSB).

This new infrastructure began user testing in April 2017 and is scheduled to be live by October 2017. Market participants that need ISINs for a defined range of OTC derivative instruments will have to request them from the DSB.

The DSB is developing product templates to be used to request these ISINs. These are needed because the products—interest rate swaps, credit default swaps, etc.—are fairly complex and give rise to multiple use cases. The product templates help to define the attributes (data elements) that are required to describe each OTC derivative product within asset class. The issue as to just what data goes with an OTC derivative ISIN is central to the identifier challenge for these products in MiFID II and beyond.

Anticipating the need to define OTC derivatives product attributes against ISINs, ISO set up a study group in 2016 to work through this problem. The group, which included experts from across the industry, came up with a fairly comprehensive series of use cases covering OTC derivatives for credit, rates, FX, equities and commodities. The DSB is basing its product templates on some of this work, although the driving force for the product templates is the product reference data fields that EU regulators have said must be reported against the ISIN.

These fields, which were specified by ESMA in the annex to RTS 23 of MiFID II, have caused the industry some problems, as they are not organised in the way that the derivatives industry is used to. The classic example is the inclusion of expiry or maturity date in the fields that are required to be submitted against an ISIN to satisfy RTS 23. This means that, for example, a 6 month fixed float plain vanilla interest rate swap, trading on two different days, will need two separate ISINs, as the maturity dates will differ (in this case by 1 day), even though the products are otherwise the same.

The initial roll out of ISINs for OTC derivatives from the DSB will be focused on collecting the base set of attributes needed for the MiFID II reference data reporting, although they may add other product attributes based on further industry feedback over the summer months of 2017. Either way, it is likely that the OTC derivatives ISINs so defined will be unlikely to be usable outside of EU reporting requirements, which is the primary (and so far only) reason for their creation. This is because an effective scheme for identifying OTC derivatives across the transaction lifecycle from, for example, the original curve through trading and post trading, really requires a hierarchy of identifiers. Such a hierarchy would contain the appropriate level of granularity (data elements) at each stage, and each level would be linked together. The initial roll out of ISINs for OTC derivatives from the DSB will be a single level ISIN representing something of hybrid in terms of industry requirements (albeit of sufficient granularity to satisfy the MiFID II and other EU reporting requirements).

Thinking about other potential use cases brings us to the current global regulatory initiative to define a unique product identifier (UPI) for OTC derivatives. This initiative is driven by the obligations in many markets to report OTC derivatives trades to trade repositories. Regulators would like to be able to aggregate this data in order to get a better picture of risks building up globally. Defining a consistent identifier for these products would greatly assist with turning this global reporting into useful data. This work is proceeding in parallel to the implementation of MiFID II, and will have its own technical and governance requirements, which are expected to be finalised by the first half of 2018. It is by no means certain that global regulators will agree to use the ISIN for the UPI as things currently stand; although, neither the final technical guidance nor the governance consultation (which are the next steps on the UPI) have yet appeared at the time of writing.

MiFID II ISINs will be issued along with two other ISO standards; the CFI code (Classification of Financial Instruments) and the FISN (Financial Instrument Short Name), as both of these are required by ESMA for some of the MiFID II reporting fields, in addition to the ISIN. The CFI code, is currently undergoing revision in order to make it more descriptive for OTC derivatives, but this process is unlikely to be complete before MiFID II goes live, so the existing version will be used, and issued by the DSB, along with each ISIN that is created. The DSB is working on a mapping between the widely used International Swaps and Derivatives Association (ISDA) derivatives taxonomy and the current CFI coding system. This would enable the ISDA (the trade association for the OTC derivatives industry) taxonomy to be used for submission of an ISIN creation request to the DSB. The returned CFI and ISIN combination will, however, need to be used on any subsequent regulatory reporting, as ESMA will not accept the ISDA taxonomy in MiFID II reports.

The FISN, which is required for the reference data reporting under RTS 23, is a new standard intended to harmonise the description of financial instruments Correct and precise identification of financial instruments is not just important in terms of the content of MiFID II reports, but also so that firms can correctly manage their reporting obligations. One key determinant of MiFID reporting obligations is whether the financial instrument is trading

on an EU venue. Some MiFID instruments are mandated to trade on venues, but in many cases instruments will trade both OTC and on venue. Instruments that only trade OTC do not carry the same reporting obligations as those trading on venue. So, for example, an instrument that only trades OTC does not need to be reported under the post-trade transparency regime (within 15 minutes for non-equity instruments). If, however, the instrument trades on an EU venue, the trade will need to be reported even if it was traded OTC. This means it is necessary to keep track of the trading status of each financial instrument.

The concept of trading on a trading venue (TOTV) is a crucial one as a driver of reporting obligations under MiFID II. An equity or bond is easy to compare, but how, for example, do you determine if an interest rate swap is the same as one trading on a venue—there are many data points that

could be relevant—so this is not straightforward. ESMA issued some guidance in late May 2017 which sought to clarify how this determination might be made. This guidance pointed back to the instrument fields required to be reported as reference data by trading venues under RTS 23. At the time of writing this clarification is still being digested by the industry, but it has already led to a further stream of questions and requests for further clarifications. Essentially the ESMA guidance, by focusing TOTV on the RTS 23 data attributes has produced a rather granular definition that potentially leaves room for small differences in product attributes to affect TOTV status.

Transaction reporting creates more problems at the instrument level, as even if the trade was done OTC, and not reportable under post trade transparency, it may still have a transaction reporting obligation if it relates to an underlying instrument that itself is trading on a venue. So again, this

presents an instrument level challenge which needs to be managed. A particular example would be a trade with an index underlier. If any element of the index contained an asset trading on an EU venue, then even if all other variables indicated to the contrary, this transaction would still need to be transaction reported.

Other instrument level challenges including determining if a counterparty is an SI or not in the instrument that is being transacted. If an investment manager sells off venue to a counterparty, then the post trade reporting obligation will rest with the counterparty if they are an SI, otherwise the investment manager will have to make the report.

Reporting waivers and deferrals based upon liquidity classifications and trade size thresholds are also highly relevant for the reporting obligations in MiFID II. These come down to where an instrument sits within asset class and sub-asset class classifications in MiFID II. Managing this all comes down to successful identification at the financial instrument level.

Some of the information needed for making crucial MiFID II determinations will be available from ESMA. ESMA are developing a reference data system known as Financial Instruments Reference Data System (FIRDS), which will collect all the reference and market volume data provided by EU trading venues. ESMA will use the submitted volume data for calibration of some of their thresholds, for example, to determine SI status; they will publish the reference data submitted in a free daily file. This daily file will be a valuable source of reference data relating to MIFID II obligations; however, it is unlikely to be enough by itself. MiFID II firms will need to tap other sources, including data vendors in order to obtain a complete data picture on which to base their compliance.

A final point on financial instrument identification is to recognise that because of the broad coverage of financial instruments in MiFID II, it is highly likely that firms will have various identifiers in their own systems for these instruments. Indeed, the preponderance of securities master files at many firms will likely add to the complexity here. A recent TABB group report (Building a Framework for Innovation and Interoperability V15-009 FinTech March 2017),3 which covered financial instrument identification issues across the industry, found that the majority of firms maintain between two and five securities master files (with some maintaining up to ten).

The challenge, then, for firms is to ensure that they can efficiently manage their instrument reference data—given the increasingly vital need to demonstrate this to regulators with accurate and efficient reporting. This is where firms need to consider an operational anchor identifier that can provide unique and granular identification of financial instruments across asset class, and that can be mapped as needed to identifiers, like ISIN, for reporting purposes. As mentioned earlier, such an identifier is the FIGI. FIGI was originally a Bloomberg proprietary identifier, but it has now been adopted as an open standard by the Object Management Group (OMG), and it is currently entering the process for adoption as an ISO standard. Almost 400 million FIGIs exist today and it has far wider coverage at a higher level of granularity than ISIN. FIGI supports identifier hierarchies such that for example on equities FIGIs exist at a global, country and trading venue level—all linked together, offering granularity levels as required.

FIGIs can be downloaded from OpenFIGI.com for free and used along with associated reference data without restriction. ISIN mapping is provided, and this will be extended as ISINs begin to be issued for MiFID II OTC derivatives by the DSB.

IDENTIFYING ENTITIES

The second part of the core identifier challenge in MiFID II is related to entities. As with instruments, the regulation is very focused on a single mandatory identifier – the LEI. LEI has been gaining traction in respect of regulatory reporting since 2012, when this ISO standard was first used in reporting on derivatives to US regulators. LEI was subsequently mandated in the EU for the derivatives reporting to trade repositories under EMIR. Now it is mandatory for use in MiFID II, so that all reporting entities must have an LEI, and they must ensure that all other parties to their trade-counterparties and clients—also have LEIs. All parties to a trade that can be identified with an LEI must be so identified, which in practice means that all clients other than natural persons must have an LEI. It does not matter if the client is in Hong Kong or Afghanistan, if the transacting firm is in the EU then they must ensure that their clients have an LEI.

This is going to be something of a challenge, the more so if firms leave it to late 2017 before working with their clients to ensure they get LEIs. Helpfully, there is a growing network of accredited issuers for LEIs, recently joined by Bloomberg.4 These organisations are accredited by the Global Legal Entity Identifier Foundation (GLEIF) to issue LEIs according to the ISO specification for the LEI. LEI is a 20 character code that is associated with a data set providing brief details about the entity, although the system is expanding to add in more granular parent and ultimate parent ownership data going forward. Those needing LEIs can also work with a new network of registration agents who help applicants to obtain LEIs, and indeed some of the larger investment firms may well consider partnering with one or more LEI issuance organisation (known as local operating units—LOUs) in order to proactively help their clients get the LEIs that they will need.

Of course, as indicated earlier, instrument and entity identifiers are not the whole story in the immense data challenge that is MiFID II, though they are key elements. Firms will need to understand the MiFID II specific classifications of instruments at the asset class and sub-asset class level, and be able to interpret the size specific to instrument and large in size thresholds for these in terms of liquidity calibrations, and the resultant transparency reporting consequences. Understanding where instruments fit in terms of the transparency thresholds, trading on a trading venue status and the SI status of the counterparty are all major data challenges within the new MiFID II reporting regime.

Further data challenges emerge with the granularity required in the reporting regime—particularly in transaction reporting. Firms need to provide identifiers for algorithms that may have been used in trading, as well as codes and data to identify the person in the firm responsible for execution, if

appropriate.

All of this takes the importance of efficient data management to a new level, and it is crucial that firms have a clear strategy across asset class for how they will obtain the data they need, and how they will manage it.

Data service providers will offer packages down to the financial instrument level to provide firms with the granularity they need across the instruments they are trading. Firms may, though, decide to augment such packages with their own connection to the new sources of reference data we have discussed such as the DSB for OTC derivatives and the ESMA FIRDS database, although it is likely that the data vendors will include such new sources in their data offerings anyway. Others may outsource much of the complexity as far as possible by using third party reporting solution providers offering approved publication arrangements (APA) and approved reporting mechanism (ARM) services, etc. to take away much of the pain.

CONCLUSIONS AND RECOMMENDATIONS

MiFID II represents a massive data challenge for industry and regulators alike. The successful implementation of MiFID II, delivering the anticipated levels of transparency across a broad range of asset classes, relies on the ability to correctly identify what is being traded and by whom.

Whatever the role taken by a firm impacted by MiFID II, buy side, sell side or trading venue, it is essential that a robust approach is taken to the management of reference data. Without effective reference data management, firms risk falling foul of their MiFID II reporting obligations and incorrectly applying any transparency carve outs. They need to factor MiFID II into their reference data strategy as a matter of urgency. Key considerations include:

•• Identifying sources of MIFID II reference data, including the ANNA DSB, ESMA FIRDS and also third party data package providers.

•• Maintaining data, including ensuring that MiFID II classifiers are applied correctly to all financial instruments that a firm or its clients are trading with.

•• Ensuring that all relevant LEIs are obtained and maintained for reporting purposes.

•• Developing a strategy for managing inventory, including choice of identifier to use as a master key offering the best granularity. This may include identifiers such as FIGI that are not used for the actual reporting itself, thus requiring a robust mapping capability.

Whatever route firms take to tackle the MiFID II data challenge, unambiguously identifying the instruments they are trading, and the parties to their transactions, will be attributes of MiFID that cannot be ignored.