Baskets, ISINs and bank holidays – ESMA publishes new guidance on EMIR
ESMA has been busy updating its Q&As. Last week it was MiFID II and this week it’s EMIR. The newly updated Q&A gives guidance on how some specific fields should be populated and which competent authorities should receive certain data. They emphasise once again that simply passing validations is not good enough; the regulator is expecting accurate submissions. In this blog, we outline some of the key updates.
If maturity date falls on a weekend or bank holiday this is the date that is expected to be reported and not any adjusted date. From a matching perspective this makes logistical sense as different countries have different bank holidays. As well as this, for trades that have expiry dates many years in the future, bank holidays may not be known at the time of execution. I wonder however, if the trade’s adjusted maturity occurs at a later date than the unadjusted date, if we could see any failures to report some post-trade events that happen in between this period. Should ESMA have provided the same clarity for settlement dates?
The guidance states that if an index does not have an ISIN it should be reported with the name that is identical to the names published by the index provider and include special characters. Trading systems tend to dislike special characters so there could be some circumstances where these are difficult to report. Lucky the S&P 500 has an ISIN!
Access to data by competent authorities
If the Cambridge Analytica scandal has taught us anything it’s that people care about who has access to their personal data. The same holds true for business data. Until now the guidance for derivatives where the underlying is a basket or an index has been for TRs to allow access to the data for all EU competent authorities. The new guidance is that authorities will only have access to the data if they share the same country as the ISIN or any ISINs that that basket or index is composed of. Other authorities will be allowed access to the data if they need it to carry out their responsibilities. It’s a well-meaning sentiment but it is a difficult change to implement and there are a lot of questions around this which we will follow up separately.
The new Q&A mandates that deliverable currency should be populated in most cases. Our accuracy testing reveals that this is not usually the case within the industry and repositories generally classify the fields as optional. In order to comply with the regulation some changes will need to be made in participants reporting processes.
The last new piece of guidance is that if there is no effective date specified in the contract it should be reported as the same date of the execution of the derivative. This is already fairly common practice in the industry but the guidance does not explicitly mention novation events. In the case of a novation where the contract does not contain an effective date, should it be reported as the execution date of the original contract or the date of step in? You decide … just make sure your counterparty agrees!