Introduction
The upcoming MiFID/MiFIR II regulations and directives being developed by ESMA, the financial regulator of the European Union, are the subject of much discussion within the financial industry. Technology companies working within this space, including Sinara, will also be examining the implications for their clients and how the products and services they offer can help them with the transition. Though many of the details are yet to be pinned down, it is clear that much IT work, often software development, will need to be done, both to integrate existing systems and to develop entirely new ones.
Instrument Reference Data Project
One aspect of the changes that has been subject to much scrutiny has been the plan by ESMA (termed the Instrument Reference Data Project) to develop a master reference data system for the entire EU market, to be shared between all of the national regulators. Each trading venue operating within the EU (including traditional exchanges as well as MTFs, OTFs and SIs) must transmit to ESMA, each day, a complete set of all new and updated reference data for all of the instruments being traded on their venue.
This data will comprise of all that may normally be expected to identify an instrument, including its ISIN (more on this later), long name, description, currency, etc.
The key point that has generated a great deal of discussion is that ESMA intends to publish this data, in full, on its website (in an ‘electronic, downloadable and machine readable format‘) and make it available to the public entirely free of charge. Inevitably, this raises significant commercial, licensing and technical issues. While helping our clients with their market data needs over the years, Sinara have worked with many reference data feeds, and have become familiar with the sheer complexity of some of these feeds, as well as the contractual details surrounding their use. Is paying for your reference data, at least for European symbols, really going to be a thing of the past?
Licensing
At a recent roundtable forum organised by FISD and hosted by Bloomberg in London, a broad range of representatives from data vendors, exchanges, and financial institutions exchanged their views on how this master reference data system would work and the implications for their own businesses. Several important points were highlighted:
- Reference data that is currently only available under license will now be available to the public, by ESMA, free of charge.
- Trading venues that have to deliver reference data to ESMA may not necessarily be the originators of the data, and may therefore have licensing limitations in place.
- Financial institutions and data vendors that make use of reference data may have to be in closer touch with ESMA to fully understand the implications for their businesses.
- It may be difficult to do a proper audit for fee-liability if all of the reference data is freely available and accessible.
The entire premise behind this centralised data source is to allow ESMA to perform and publish transparency and liquidity threshold calculations. Interestingly, ESMA has stated that it does not intend for itself to be considered a ‘golden source’ of reference data within the EU to be used for general trading purposes. However, if the data is of sufficient quality, then some firms many choose to standardise on it, due to ease of access and integration.
(See the recent article in Inside Reference Data for more industry reactions on this topic.)
ISINs
A key aspect of this system is that ESMA has stipulated the use of ISINs to identify instruments, rather than some combination of trading venue identifier and symbol. However, some ISINs (notably US ones) are fee liable. Does the fact that the data will be published ‘freely’ exclude any user from being liable for fees? At the FISD forum, there was much discussion on this. One view was that users of the data would only have to pay the originators if they republish the data in some way, perhaps to their own end users. If an institution uses the ISINs (and indeed any other reference data item) internally, they would not be fee liable.
Staying on the topic of ISINs, part of this proposal is that all financial instruments should be identified by an ISIN, including many derivatives that currently do not have ISINs. However, as there is sometimes no industry wide consensus on what the instrument behind some of these derivatives actually is, it may be difficult to accomplish this in practice. At the forum, there was much discussion that the ISIN standard may have to be revised to help cater for the much wider ‘universe’ of instruments that must be included. Note that the problem isn’t so much that the current ISIN standard cannot handle a larger number of symbols, just that it does not support the level of granularity to handle many non-equity instruments.
Another interesting and often less well known fact is that ISINs do not necessarily have to be unique–this may have to change, which will mean a new ISIN standard will have to be developed. Incidentally, this is something we found at Sinara while developing our Order Book Consolidator product–the software attempts to group instruments on different venues by their common ISIN, but sometimes unrelated instruments would be included that happened to have the same ISIN.
Another interesting debate at the forum was around ‘intelligence’ within identifiers. The current ISIN scheme has no way of telling, just by looking at the identifier, what type of instrument it is or indeed anything else about the instrument in question. One view was that this is in fact a good thing, as it allows identifiers to be conveniently reused. On the other hand, it means that a lookup always has to happen with a reference data source to find out more about the instrument.
Integration
A key point to note is that most financial organisations will generally obtain their market data from one or more of the well-known data vendors, who in turn will aggregate data from many different original sources throughout the world, not just Europe. Most of the firms Sinara work with require reference data from non-EU markets as well, and so wouldn’t be served by an EU-only feed. Even if they do restrict trading activities to the EU, they will have usually made significant investments in integrating with a particular vendor’s data feed, and will rarely want to work with individual feeds directly. Also, the data that ESMA require will generally be a subset of the much wider range of reference data that many vendors offer.
Looking at this from this point of view, it’s likely that there won’t be significant commercial disruption by the introduction of this new source. In fact, its main consumers will probably be data vendors, who may want to offer it to their clients through their existing delivery systems. Therefore, although financial institutions are unlikely to change overnight to obtaining their EU reference data directly from ESMA, they can certainly use it to validate existing data or to fill in missing information.
Trading venues will have more work to do in terms of ensuring timely contributions to the source. As soon as the technical standards are made available, Sinara will be examining them to see how we can help our clients who will need to submit daily data to ESMA, or who wish to access the data to use internally within their existing reference data systems.
Next Steps
Clearly, there is still a great deal to be clarified in terms of how this system will work going forward, both for consumers and providers. In the meantime, however, what can a financial institution do to take advantage of this centralised source of data? There could be great benefits to having correct and up-to-date reference data for all instruments traded in the EU. Although, as of writing, the technical specifications for the data are not yet available, there are several steps that can be taken to improve a reference data system in anticipation–these will be of benefit regardless of whether the ESMA system is adopted or not:
- Explore the possibility of standardising on ISINs in internal records to identify instruments
- Try to complete missing ISIN data
- Centralise reference data in one database/system that can easily be updated
- Extend reference data systems to incorporate more currently available data
- Generally ‘health check’ reference data systems to ensure they are easily extensible to accommodate future growth and changes in standards
Sinara can advise and assist with the technical aspects of these improvements. Like much of MiFID, the master reference database produces both challenges but also new opportunities from having better transparency and more efficient systems.
