Post-Brexit regulatory reporting wish list: EMIR trade reporting

Post-Brexit regulatory reporting wish list: EMIR trade reporting

We recently speculated that now might be a good time to think about what changes you might want to see in the UK reporting regimes at the end of the transition period. The UK Chancellor’s assertion that he is seeking “outcomes based” equivalence rather than complete alignment appears to have left the door ajar for some sensible changes to the reporting regimes.

Previously I shared my top ten suggestions for changes to the MiFIR transaction reporting regime. Now it’s time for my top ten changes for EMIR trade reporting which I believe will make reporting more proportionate for firms without degrading regulator’s ability to use the data for the intended purposes. In fact, some of them may help increase the quality of the data for the regulators:

  1. Eliminating trade reporting for ETDs

Since the main purpose of EMIR trade reporting is to monitor for systemic risk, there appears to be little value in collecting reports of ETD trades when they are immediately netted into an end of day position report. Additionally, key elements of EMIR trade reporting like lifecycle events and collateral reporting can only really be sensibly applied to the end of day positions for ETDs. Perhaps the only value of ETD trade reports is for the detection of market abuse – but this is the driver behind MiFIR transaction reporting and their inclusion in EMIR is an expensive duplication.

  1. Review some of the roles of the trade repositories (TRs)

The trade repository ‘layer’ between firms and the FCA appears to be a potential hindrance for the regulator as it needs to access multiple databases which may have their own systems and fields. It would also help the production of useful public data aggregations from a single source and reduce problems in performing the pairing and matching reconciliations. Having multiple TRs appears to increase risks, so given that the regulators have the ability to act as the single repository themselves as the FCA has demonstrated with MiFIR transaction reporting, it should now be reviewed.

The entities behind the TRs can still have an extremely important role to play, but this would be more akin to the role that ARMs have in helping firms report to the NCAs.

  1. ‘Beneficiary’

“The party subject to the rights and obligations arising from the contract…” Is there a situation when this party is not going to be the reporting counterparty! OK, there is a small case where it could be argued that a sub-fund could be the beneficiary rather than the reporting fund counterparty, but does this really justify the confusion this seemingly superfluous field causes?

  1. Reporting Timestamp

“Date and time of reporting to a trade repository”. This used to be populated by the trade repositories as it is the same as the time they receive it. Asking firms to report this field is duplication and leaves firms exposed to making errors.

  1. Trading Capacity

For EMIR, we have ‘principal’ and ‘agent’ as possible values. However, we are told that only principals to a trade need to report; not any party acting as agent. This field has no value other than to cause confusion in interpretation and should be removed.

  1. Don’t ask for data you’ve already got

It sounds obvious, but there’s no justification for regulators to ask firms for data that they already have. It creates the potential for firms to supply different data to the ‘golden source’ – do the regulators think it would be a good idea to use this sub-optimal data rather than the pristine data they have? For example, the regulators will already have reference data collected from EEA trading venues (even post-Brexit) for ‘product classification’, ‘underlying identification’, ‘notional currency 1’, notional currency 2’ ‘delivery type’, ‘price multiplier’ and ‘maturity date’ where the instruments is tradeable on an EEA trading venue. If the instrument is an OTC derivative and has an ISIN, a golden source of this data is also available on the ANNA DSB.

  1. Country of the other counterparty

“The code of the country where the registered office of the other counterparty is located or country of residence in case that other party is a natural person” So, similar to the argument in point six, this information is contained in the GLEIF database for organisations. Asking firms to populate this field for organisations is again unnecessary (firms cannot deal with an organisation unless they have an LEI).

If the counterparty is an individual, why ask for the country of residence? For a start, it is different from the equivalent field for MiFIR. Additionally, natural persons often have multiple residences and move around. It is difficult to understand how collecting the country of residence for natural person counterparties can be of any use for monitoring systemic risk.

  1. Basket derivatives

Firms executing transactions in OTC basket derivatives have to populate the underlying ISIN field with all the ISINs that comprise that basket (similar to, but not the same as MiFIR). For example, if they trade a pharmaceutical basket comprising 421 stocks, they have to populate the ISINs of all 421 stocks. Since there is no information of the individual stock weightings, it is extremely difficult to see how any regulatory authority can use the data to help monitor systemic risk. This is very onerous for firms and can be of very little value to the regulators.

  1. Duplicate fields

There are a number of required fields that can be derived from other fields. For example, the information provided in a CFI code (Classification of the financial instrument) renders the following mandatory fields obsolete:

  • Contract type
  • Asset class
  • Delivery type
  • Option type
  • Option exercise style
  1. Report tracking number (RTN)

“A unique number for the group of reports which relate to the same execution of a derivative contract”. At Kaizen, we can find very little evidence of this field being populated for the scenarios described in the ESMA Q&A. Where it is mandatory, for the action type of ‘position component’ at a trade level, our findings show that there is a common failing to assign the same code to all the trades that comprise a particular position report. If the field is only mandatory for trades that are going to be netted into a position report, it is questionable whether this troublesome field offers any real value to the regulators.

So these are my top ten and again I have to add the caveat that there may be perfectly valid reasons why the regulators need this information. However, there is a view in the industry that the EMIR trade reporting regime needs a fundamental review rather than simply tinkering round the edges. Nobody can deny the importance of a reporting regime to monitor for systemic risk, but the poor quality of much of the data reported and the lack of appetite amongst certain NCAs to address these deficiencies six years after go-live, suggests that the current reporting regime doesn’t achieve its objectives. 

Check out the first blog in this series on MiFIR transaction reporting. Forthcoming blogs will detail our wish lists for SFTR reporting and Post-Trade Transparency reporting.

For help with your EMIR trade reporting accuracy or to discuss your own post-Brexit EMIR trade reporting wish list with one of our regulatory specialists, please contact us.