Developments in transaction reporting infrastructure – observations from a practitioner
By Christian Thygesen, Partner I May 26, 2023
Financial institutions are subject to a range of transaction reporting requirements. From the first such regulation back in 2007, the mood has changed from build-it-yourself solutions to an almost unanimous appetite for vendor-supported solutions. This is clearly illustrated by the preparations that the industry is making for the introduction of EMIR Refit in the spring of 2024. We’re looking at why this change came about and where we are heading from here.
All financial institutions transacting in the capital markets are subject to various kinds of reporting obligations. The reports are compulsory and failure to comply to report in a correct, timely, and complete manner can lead to substantial fines. As such, transaction reporting is a “license to operate” for these institutions. At the same time, it is not a core service for a bank to excel in and it is not a competitive field. Customers, counterparts, and competitors really couldn’t care less if you are good at transaction reporting or not. Furthermore, it is a specialised field with a substantial amount of complexity. Finally, it is a service with significant economies of scale. Once you have understood, say, the validation rules under MiFIR transaction reporting and built the necessary automated validation logic and error-handling procedures, you might as well use it to validate as many trades as possible. The same logic goes for the ISO 20 022 XML formats required under the upcoming EMIR Refit. Once you have interpreted them and built a re-formatting engine, you might as well pump as many transactions as possible through that engine.
An obvious candidate for outsourcing?
Being complex, non-competitive and with clear economies of scale, transaction reporting is a logical area to consider for outsourcing. Based on what we have observed among our clients over the past decade, this blog describes the trends and tendencies when it comes to outsourcing transaction reporting.
To be more precise, what I mean when talking about the outsourcing of transaction reporting is that the trade itself is certainly not outsourced. After all, that is a core activity of institutions participating in the capital markets. So, the core data characterizing the trade must come from the trading systems of the institution in question. The same goes for the supporting data from customer-, collateral- and contract-management systems. This must come from the institutions involved. However, any downstream activity from the generation of the core reportable data can in principle be outsourced, among that the decision of when to report what, the validation and enrichment of the data to be reported, the (re)formatting, the link to the final destination of the reporting, the handling of the feedback from the entity to which the report was sent, the display of the reported trades and possible errors, processing support correction and re-sending of erroneously reported trades, management information on the overall status of reporting, error rates, handling speed etc. This multitude of specialized, downstream activities is what I refer to when discussing the outsourcing of transaction reporting. Also, although transaction reporting hits financial institutions broadly, I use the term bank as a general label for the institutions subject to transaction reporting obligations.
The beginning: MiFID & EMIR
Transaction reporting by individual banks started with MiFID in 2007. At the time, to the best of my knowledge, no vendors offered platforms supporting this reporting. Part of the reason may be that transaction reporting under MiFID was the first of its kind. Also, MiFID was a directive and therefore the reporting was not identical across the European countries. E.g., in Denmark, the authorities chose to include bonds in the mandatory reporting. Most other countries stuck to equities and UCITS & ETFs as mentioned in the directive.
In 2012 came EMIR. For one it was a regulation and therefore entirely homogeneous across all EU countries, for another, it was now the second time that financial institutions were met with this kind of requirement. The scope was large – all derivatives – and the complexity was perceived as high. The latter partially because the clarification process was difficult. When implementing directives, local banks could go to their local regulators and ask detailed questions on how this or other detail should be understood. EMIR being a regulation, only ESMA could answer such questions, and the road from the local banks to ESMA was long and the clarification process troublesome. This made life difficult for the banks that became subject to this regulation, but in a way, it was worse for the vendors trying to step into the space of transaction reporting. They seemed to be always one step behind, and very few banks were willing to run the risk of introducing an intermediary in the reporting process, maybe because these intermediaries were no more able to interpret the requirements than the banks themselves.
It goes on: MiFIR & SFTR
Then came MiFIR. Whereas transaction reporting was a central piece of EMIR, it was but one of a multitude of requirements under MiFIR. Banks were scrambling to be broadly compliant, and willing to look at whatever could be outsourced. The clarification process vis-à-vis ESMA had improved, and all of that combined to make vendors more attractive. I believe that in the end, about 60% of all Danish banks chose the support of a vendor rather than building everything themselves.
Then came SFTR. By comparison, SFTR implied but a fraction of the work needed to implement MiFID II. The banks had more time to think about how best to handle this and most were in favour of choosing a vendor – also those that had not done so for MiFIR reporting. The logical thing would be to go with the vendor you were already working with, but there had been quite some turbulence on the vendor side. Two of the dominant in the Nordic market (Deutsche Börse & Abide) had left the reporting business, leaving room for new players, some being well-established firms that made a bid for the reporting business, others being focused, newcomers. When the dust settled, a quite fragmented picture appeared with some banks using their known vendors also for SFTR, while others joined forces with the newcomers.
And then: EMIR Refit
And now we are looking at EMIR Refit. There is certainly complexity in some of the new fields, dependencies and reconciliation requirements compared to the existing EMIR reporting, but my distinct impression is that there is less rush compared to both the original EMIR and MiFIR. This has allowed the banks to consider their options more carefully. No one is arguing for building their own reporting solutions anymore. Reporting vendors is the preferred choice across the industry, but a new dimension has emerged in what the banks are looking for in their transaction reporting partners.
Such a partner must be able to handle the mechanics of reporting, but more than that, a partner must also be able to lift some of the analytical and adaptation burdens off the banks when new requirements appear. Simply put, the vendors must step up and assure their (would-be) clients, that they will look into new regulations early in the process. They will of course adapt their platforms accordingly and make UAT environments available irrespective of whether the downstream recipients (the TRS and NCAs) are ready with their test systems, but more than that, they will reach out to their platforms and advice their customers on how they must adapt their platforms and to the extent possible, minimize this burden of adaptation. In my mind, we see some clear examples of this already: There is a quite significant difference in how well the various vendors understand the challenges arising from EMIR Refit and the extent to which they shoulder this burden for their customers – and assist the banks in their work. The first example is the action/event combinations – does the bank need to tell the vendor where in the matrix they are every time a report is sent, or can the vendor figure it out based on previous reports and internal logic? The second is the ability to support the interbank reconciliation process. Not part of the reporting process per se, one could argue that it is not necessarily a part of the vendors’ offering to the banks, but whether the vendor can support this process or not makes a quite significant difference to the effort that the bank must put in to comply with EMIR Refit without drowning in manual processes.
The future of transaction reporting
We know that transaction reporting is here to stay and that changes will keep on coming. We already know that in all likeliness, transaction reporting under MiFIR II will implement features introduced with EMIR Refit, notably the use of UPIs. It is my prediction, that over the next five years, most banks will consolidate their transaction reporting around a single, strategic partner, and that those vendors that can reliably lift most work of these changes off the shoulders of the banks both when it comes to analysing the coming changes, adapting your systems to these changes and running your bank under the new regime will be the partners of choice.
About CMP
Our name, Capital Market Partners, reflects what we define as our core service: Business understanding based on extensive experience in applying technology in the capital market area.
As a business partner, we offer consulting services based on our combination of business understanding and IT know-how. Our work analyzes, implementation of IT systems and other projects supports strategic decisions at different levels in complex business contexts.
For further information – Please contact:
Lars Christiansen
Managing Partner
Tel: +45 2993 4678
