EMIR Reporting - Further IT Challenges

Thursday, 14/05/2015 | 07:18 GMT by Jeff Patterson
  • This recent publication of the ESMA Q&;A on April 27th dispelled a lot of rumours surrounding the Level 2 validation requirement.
EMIR Reporting - Further IT Challenges
Photo: Bloomberg

There was a strong rumour circulating until recently that ESMA would bypass the Level 2 validation requirement, and focus instead on letting firms prepare for the much more fundamental changes called for in December’s Consultation Paper. This rumour was dispelled with the publication of the latest ESMA Q&A on April 27, which set a deadline of the end of October 2015 for the implementation of Level 2 validation. What this means is that from November 1st Trade Repositories will be obliged to reject any submissions, which do not conform to the L2 validation standards.

The first problem this causes is to the Trade Repositories, some of whom have not been requesting data in the ESMA prescribed format, but rather in their own proprietary reporting pattern. If you have not been asking for a specific field to be supplied, how can you apply additional validation checks over it? Once the Trade Repositories have thought through the necessary changes to their ingestion systems, it will be the turn of the reporting firms to suffer, with significant effort in some cases required for the re-development of their current daily report generation systems.

So, there is a mountain to climb before the end of October, always in the knowledge that it needs to be done again before the Consultation Paper changes become a requirement, which is expected to happen in the first half of 2016.

At first (and second) sight, this may appear to be a wasteful use of IT resources, but it would be unfair to place the blame on ESMA. They have always been clear as to what fields should be submitted to TRs, and through the Q&A process they have progressively clarified how those fields should be populated. Had the TRs asked for precisely the fields stipulated in the Implementing Technical Standards (which were adopted into European law) and then adjusted their validations in the light of successive Q&As, the pain would have been minor and incremental, rather than a huge headache calling for firms to kick off yet another major regulatory reporting project.

With the MiFIR reporting requirements due to be announced later this year, for a reporting start date of January 2017, the reporting headache looks set to turn into a migraine. If you feel you need to see a doctor by this stage, you may be interested in visiting Abide’s Regulatory Reporting Clinic, which will be running for all three days of the 2015 IFX Expo in Cyprus in less than two weeks’ time. There we will be offering a complimentary half hour consultation on the practicalities of coping with the ever more complex task of compliant regulatory reporting. Take your chances on the day, or to secure your slot in advance contact rasa.balsytte@gmail.com to book a session. I look forward to meeting many of you there!

There was a strong rumour circulating until recently that ESMA would bypass the Level 2 validation requirement, and focus instead on letting firms prepare for the much more fundamental changes called for in December’s Consultation Paper. This rumour was dispelled with the publication of the latest ESMA Q&A on April 27, which set a deadline of the end of October 2015 for the implementation of Level 2 validation. What this means is that from November 1st Trade Repositories will be obliged to reject any submissions, which do not conform to the L2 validation standards.

The first problem this causes is to the Trade Repositories, some of whom have not been requesting data in the ESMA prescribed format, but rather in their own proprietary reporting pattern. If you have not been asking for a specific field to be supplied, how can you apply additional validation checks over it? Once the Trade Repositories have thought through the necessary changes to their ingestion systems, it will be the turn of the reporting firms to suffer, with significant effort in some cases required for the re-development of their current daily report generation systems.

So, there is a mountain to climb before the end of October, always in the knowledge that it needs to be done again before the Consultation Paper changes become a requirement, which is expected to happen in the first half of 2016.

At first (and second) sight, this may appear to be a wasteful use of IT resources, but it would be unfair to place the blame on ESMA. They have always been clear as to what fields should be submitted to TRs, and through the Q&A process they have progressively clarified how those fields should be populated. Had the TRs asked for precisely the fields stipulated in the Implementing Technical Standards (which were adopted into European law) and then adjusted their validations in the light of successive Q&As, the pain would have been minor and incremental, rather than a huge headache calling for firms to kick off yet another major regulatory reporting project.

With the MiFIR reporting requirements due to be announced later this year, for a reporting start date of January 2017, the reporting headache looks set to turn into a migraine. If you feel you need to see a doctor by this stage, you may be interested in visiting Abide’s Regulatory Reporting Clinic, which will be running for all three days of the 2015 IFX Expo in Cyprus in less than two weeks’ time. There we will be offering a complimentary half hour consultation on the practicalities of coping with the ever more complex task of compliant regulatory reporting. Take your chances on the day, or to secure your slot in advance contact rasa.balsytte@gmail.com to book a session. I look forward to meeting many of you there!

About the Author: Jeff Patterson
Jeff Patterson
  • 5446 Articles
  • 105 Followers
About the Author: Jeff Patterson
Head of Commercial Content
  • 5446 Articles
  • 105 Followers

More from the Author

Executives

!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|} !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}