In an Effort to Harmonize, ESMA's Technical Guidance Leaves One Note Out of Place

Last Monday, the European Securities and Markets Authority (ESMA) published technical standards that describe how regulations such as the Markets in Financial Instruments Directive (MiFID II), the Market Abuse Regulation (MAR) and the Central Securities Depositaries Regulation(CSDR) will apply in practice to market participants. The technical standards document includes guidance for data usage and messaging solutions for cross-asset trade reporting requirements stipulated by these new regulations. It was a monumental effort to pull together guidance to help harmonize the objectives of these new regulations and improve market place transparency and efficiency. At the same time, some guidance in ESMA’s directive is puzzling and even concerning.

Given the broad scope of the standards document, it is understandable that some areas may not have garnered as much attention as others. The guidance regarding use of FpML or ISO20022 is one that was possibly the most discussed, as it impacts the core of messaging for the future. In that light, while FpML would be more appropriate for OTC derivatives, there is a strong argument for using a protocol that was built specifically with future systems and development standards in mind. There is also ongoing work in the industry to bring FpML and ISO20022 together, or at least harmonize the standards. This was a difficult but rational decision on ESMA’s part, which is why its guidance on instrument identification is confounding.

Buried on page 381 of ESMA’s Final Report for Regulatory and Implementing Technical Standards MiFID II / MiFIR, the following is provided regarding the use of instrument identifiers:

Usage of instruments identifiers

13. In general the respondents did not agree with the approach taken by ESMA regarding the suggested usage of ISIN and alternative instrument identifiers (Aii) as instrument identifiers.

14. Main issues include:

i. The Aii is not a standard and generally not used outside of EEA.

ii. The ISINs applicability is considered limited

15. Most respondents did provide feedback on alternative solutions to the suggested approach; however, there was not a clear preference on what that alternative solution should be.

16. After reviewing all the existing industry initiatives for reference data, ESMA has decided to use ISINs to identify reference data, given the open source nature and the low cost of the solution, as well as the flexibility and speed with which ISINs could be allocated to existing/new financial instruments.

ESMA, in the body of its technical standard, clearly states that the majority of industry participants were opposed to the approach of using Aii and ISIN for different reasons. While there was “not a clear preference” on an alternative, there is clearly a unified voice that the suggestions provided by ESMA (Aii and ISIN) were not suitable.

Further, the statement “given the open source nature and the low cost of the solution as well as the flexibility and speed with which ISINs could be allocated to existing/new financial instruments” is contradictory and even inaccurate.

There is a common assumption that if something is an industry ‘standard’ then it is also ‘open source,’ however, the two terms mean different things and should not be confused.

Something cannot be both ‘open source’ and have a cost or restrictions, no matter how low that cost may be. There are repeated claims of identification schemes (besides ISIN) that are ‘open source’ that are simply not true – especially when data underlying those schemes come with commercial license terms for usage.

Saying something is open source does not make it so – there are very specific and stringent criteria that must be met. Open source does not allow for cost recovery or RAND principles in regards to distribution and redistribution. (There is also the question of what constitutes ‘low’, and in what context).

Further, there is vast evidence to show that ISIN is neither flexible nor is it quick to market with changes. There are necessary protocols in place for revision of ISO standards, which help to protect the standard’s integrity and purpose. However, this does slow down the process of reacting quickly to sudden market changes and needs. Aside from ISO20022 (and in most cases ISO15022), the extensibility of legacy ISO standards in the financial industry is a concern.

This is not an indictment of ISIN. ISO6166 serves a specific and important purpose in the financial markets. However, it is not fit for purpose in this circumstance, and trying to shoe-horn a solution in, simply because it has an ‘ISO stamp’ may not be appropriate or the best solution for the future. Trying to force ISIN to fit or change from what it currently is can put in jeopardy the ISO6166 standard itself, and all the current applications that are dependent upon its current construct.

We understand there is a need to forge ahead with these technical standards, especially to ensure market participants have the time to implement and test dependent processes prior to the regulations going into effect. At the same time, there are multiple efforts underway across the industry to determine the best way to comprehensively identify financial instruments. These efforts will have material impact on the harmonization of regulations and may propose solutions that are more fitting for the industry as a whole. For example, IOSCO-CPMI consultations are still in progress on UPI and UTI, ISDA is in the middle of its symbology initiative, and there are non-public efforts underway to examine symbology standards globally.

Lack of a unified, comprehensive open source symbology for financial instrument identification has been a significant impediment to the financial industry for decades. More complex assets, such as OTC derivatives, compound the existing issues, especially as they become more standardized and pervasive.

Bloomberg continues to be involved in various industry initiatives and discussions related to instrument identification. While we understand the desire to use existing approaches, a single comprehensive symbology needs to satisfy the individual functional needs across the instrument and trade lifecycle. Any symbology solution needs to exist and work over the holistic view of the industry, as well as be positioned for the future as the industry and technology evolves. Open source solutions have proven in multiple industries the value they bring in this regard.

As the European Commission considers the draft standards, more consideration should be paid to the point that while a standard can be open source, not all (and indeed, very few) standards are open source. We whole heartedly support true open source efforts within the financial industry in identification and other spaces, and welcome having the discussion on the difference between something that is a ‘standard’ and something that is ‘open source.’

Click here:

https://www.bloomberg.com/enterprise/blog/in-an-effort-to-harmonize-esmas-technical-guidance-leaves-one-note-out-of-place/