When I showed this blog to a chum of mine at another bank, he said my blogging’s now becoming like a London bus – you get nothing for two years and then two come along at the same time. He’s got a point! 🙂

Apparently it’s called ‘bus bunching’…

Anyway, I want to look at regulatory trade and transaction reporting and given we’ve just gone live with five brand new reporting regimes courtesy of MiFID 2, as well as the complete rewrite of EMIR trade reporting back in November last year, I really should have tried harder with my timing on this one because the ideas behind this blog were originally kicked around back in 2014 when I was at Barclays and I worked on the “what does good look like” for EMIR trade reporting first time round. Still, like a bus, better late than never and you’ll still be in good time to apply any findings ahead of SFTR and the CFTC’s rewrite of their Part 45!

So what am I talking about and why should you care?

In short, I’m talking about whether you really understand the quality of your regulatory reporting and whether it will stand the test of time, whilst you should really care about this because regulatory reporting with all these new reporting regimes is going to be an absolute paradise for regulatory fines – regulators are going to love reporting because each and every mistake is systematically repeated on each and every report, until it’s fixed, and in a world where fines are now being levied on a per report basis, that quickly adds up to a lot!

In order to understand where I’m going here, let me walk you through how a typical change delivery programme implements a typical regulatory reporting solution, such as we’ve just seen with EMIR trade reporting and the new MiFID 2 reporting regimes and thus consider the typical mistakes that are repeated time and time again:

1. Bank hires contract team of talented business analysts and project managers to read the rules and throw together telephone directory proportions of business and functional requirements that will allow IT to build a reporting solution.
2. IT builds reporting solution, project goes live and Bank kicks out contract team of talented business analysts and project managers as delivery is now complete.

And that’s about it. Sound familiar?

So what can go wrong with this strategy? Quite a lot actually, so let me break this down into the two parts – the quality part and the stand the test of time part and you can gauge how your solution stacks up against each of these.

Assessing the quality of your regulatory reporting

Regulatory reporting, as a requirement, is far more complex than the rules might suggest – individual field requirements do not consider how the solution will work across different asset classes, least of all across the multitude of different products that a firm will trade in each asset class, nor do they consider the different scenarios that the solution will need to accommodate across different business areas. When you look at it like this, particularly for derivatives, the number of ways in which a single field can be populated is just huge and your requirements need to accurately drill down into and capture this detail.

Typically, the solution to these complexities will be thrashed out on hours of industry working group calls in the run up to go-live as well as through further guidance from the regulators in the form of Level 3 text and so again, do your requirements accurately reflect what you need to report for each and every product and do they accurately incorporate this industry best practice and regulatory guidance or are they just a plain vanilla cut and paste of the rules? When the project team have all ‘left the building’, are your requirements and documentation fit-for-purpose such that anyone can pick them up in x-years time and understand how a field should be populated and thus why it is being populated as it is?

In essence this is the “what does a good report look like” part of the solution, such that does a firm clearly know how it should be reporting in order to be compliant and then why it is reporting as it does when challenged by a regulator? If a firm does not know what a good report looks like, how can that firm monitor the quality of a report over time and how can it then test those reports if it can’t calibrate and benchmark what a good report should look like in the first place?

This is fundamental to get right and given I’ve been banging on about it for years, it’s unsurprising, to me at least, to see that the regulators now kind of agree because the MiFIR T+1 transaction reporting technical standards have actually embedded this thinking into the rules. Article 15 of CDR (EU) 2017/590 (RTS 22) has a catch-all shopping list (I kid you not!) of quality control requirements that firms will need to implement. In particular, the real standouts include:

1.(d) Mechanisms for identifying errors and omissions within transaction reports;
1.(g) Mechanisms to avoid reporting of any transaction where there is no obligation to report;
1.(h) Mechanisms for identifying unreported transactions for which there is an obligation to report;

2. Where the trading venue or investment firm becomes aware of any error or omission within a transaction report submitted to a competent authority, any failure to submit a transaction report including any failure to resubmit a rejected transaction report for transactions that are reportable, or of the reporting of a transaction for which there is no obligation to report, it shall promptly notify the relevant competent authority of this fact.

3. Investment firms shall have arrangements in place to ensure that their transaction reports are complete and accurate. Those arrangements shall include testing of their reporting process and regular reconciliation of their front office trading records against data samples provided to them by their competent authorities to that effect.

4. Where competent authorities do not provide data samples, investment firms shall reconcile their front-office trading records against the information contained in the transaction reports that they have submitted to the competent authorities, or in the transaction reports that ARMs or trading venues have submitted on their behalf. The reconciliation shall include checking the timeliness of the report, the accuracy and completeness of the individual data fields and their compliance with the standards and formats specified in Table 2 of Annex I.

Quite frankly, the detail contained in these requirements is nothing short of staggering and so how a firm can even think about complying with them, without knowing what a good report looks like in the first place, would be beyond me.

Does your regulatory reporting stand the test of time

The second part to this is understanding that a regulatory reporting implementation is uniquely different to a typical change delivery project, such as an IT system upgrade. Your regulatory reporting solution is always evolving and needs to be nurtured as such if you want it to stay in good shape.

I am often asked what I mean by this and so let me give you some examples of what ‘evolves’ and what needs to be ‘nurtured’!

• First, over time, most firms typically develop more complex products that require different reporting approaches and these cannot always be shoe-horned into current solutions and so will require changes to the existing reporting solution. As an example, are you still jamming any vaguely non-vanilla derivative into an ‘exotics’ template for your EMIR trade reporting?
• Second, reporting regimes themselves are constantly in flux and they evolve and improve over time as firms and industry working groups better understand the requirements and manage best practice accordingly and this evolution doesn’t stop just because the regime goes live. As an example, do you still have people on the calls?
• Third, if EMIR has been anything to go by with its 136 pages (to date) of Q&As, the post go-live Level 3 guidance for MiFID 2 will likely be extensive and these updates will need to be monitored, processed and then prioritised for remediation where change is required. As an example, is anyone even tracking these?
• Fourth, firms get it wrong! This is complex stuff and decisions made first time round may not always have been right and so the reporting solution constantly needs to be reviewed and documentation updated. As an example, in the last month since we’ve been live with MiFID 2 and the last three months since we’ve been live with EMIR, has anyone bothered doing this, even for trivial fixes?

If I leave you my final thoughts, it’s that regulatory reporting is not a plug, play and forget implementation and that it takes real time and effort to maintain and keep up to date and so the next time you think that your trade reporting project is finished, just ask yourself how good does your trade reporting solution really look like?

Or do you even know?