Moving on to SFTR with confidence
Unlimitedly, the industry will gravitate to the vendors that are able to establish an ecosystem that makes it easy to get the data reported and that have a proven track record of delivering on regulatory change.
Let’s be blunt: there is no competitive advantage in regulatory reporting. There is certainly a disadvantage in getting it wrong (as evidenced by history of very substantial fines) and there are the lofty regulator motivations of transparency, orderly markets, etc. But what is the advantage of have the best regulatory reporting shop in town? Until recently the answer was: none. Good enough to get you over the compliance line was the prevailing mantra.
That opinion seems to be shifting recently driven by two factors – first the regulators insistence on systems and controls that let firms measure the quality of their reporting and second, and infinitely more exciting, the regulatory consequence of having an orderly, standardised data collection and management infrastructure.
It seems that as soon as the MIFD II project resources transferred their implementations to the BAU operational and run the bank teams – they moved onto the next wave of big European regulation: Securities Financing Transaction Regulation or ‘SFTR’. For us in the RegTech business this is an interesting period for two reasons; SFTR is peculiar and covers activity that have never been reported before; and the RegTech vendor landscape will be inevitably changed after this regulation goes live.
Other reasons that SFTR is interesting include:
- The staggered go-live date – driven by the complicated EU publishing and review process, at the time or writing. Credit institutions and investment firms are required to start reporting SFTs as of 11 April 2020. The reporting deadline is staggered as follows for other entities: CCPs and CSDs — 11 July 2020, other financial counterparties — 11 October 2020, non-financial counterparties — 11 January 2021. This schedule forces many firms to pause in their preparation projects, slowing down the usual gap-analysis and vendor selection cycles. This makes the projects tricky for both the industry and the vendors who support it.
- A new light - the regulators have been quite vocal about the purpose for SFTR; it is to shine a light on the opaque and not tightly regulated works of overnight lending. I have been to many industry sessions where the repeating message is that the data required by the regulators does not exist. ‘You cannot tie a piece of string to a collateral and track it through the night’ is one of my favourite quotes. Regulators nod and say: “understood but this is what we want” - they are using regulatory reporting to force industry infrastructure changes in the name of transparency.
- Regulatory evolution – ESMA, who are the principal architects of SFTR, are using it to further their regulatory reporting standardisation goals. From standardisation on (and actually enforcement of) ISO 20022 as the reporting standard, to reuse of existing TRACE (report dissemination infrastructure run by ESMA) and TR reconciliation (way for trade repositories to match double sided reports) - ESMA is slowly establishing a uniform reporting infrastructure that draws on EMIR, MiFIR and now includes SFTR.
- Business model evolution - like under EMIR, firms want to make money from or provide value added services to their clients. Since SFTR is double-sided, and in some cases delegated reporting is mandatory, firms will develop various business models to offer SFTR reporting services to their clients. Here at UnaVista, we think a lot of MiFR-like Assisted Reporting models (where data from many sources is collated to produce a complete report) will have direct applicability to SFTR.
- Some of it is MiFIR reportable – surprise, surprise, any securities financing transactions done with central banks are MIFR reportable, bringing with them the headaches of completely different data collection, workflows and GDPR personal information handling.
- To match or not to match – there seems to be few vendors who think that by offering pre-reporting matching capabilities, the post-reporting matching rates will improve. Based on our EMIR experience, we are sceptical – matching rates within large trade repositories are no different than between trade repositories, and matching rates for confirmation platforms are no better. The major problem with matching is usage and timing of the three trade pairing elements: the UTI and the counterparty LEIs – these are industry, not reporting infrastructure problems.
All of the above results in interesting vendor dynamics. Technology vendors (trading platforms, matching systems, etc.) prominent to the securities financing space are positioning themselves on the data quality angle, but lack any regulatory reporting experience, especially the EMIR and MiFIR capabilities that apply to SFTR. Regulatory reporting platforms have the experience and infrastructure and are busily aligning themselves with industry players to get some SFTR credibility (in our case this means partnering with clearing houses LCH, CC&G and MTS, who are all part of our LSEG family group and a broad partner programme for SFTR technology vendors).
Unlimitedly, the industry will gravitate to the vendors that are able to establish an ecosystem that makes it easy to get the data reported and that have a proven track record of delivering on regulatory change in the past (especially the recent EMIR L3 changes and MiFID II go live). It will be interesting to watch and may the best vendor win.