Interview with Alexander Becht, product manager for ABACUS/Transactions at BearingPoint.
The main challenges of implementing the daily reporting obligations under Art. 4 SFTR are data collection and timeliness. The reporting-relevant data fields under SFTR, especially with respect to the collateral information, are highly fragmented or even missing. Additionally, there are many market participants acting in the securities financing area, such as brokers, tri-party agents, and CCPs (central counterparties). All of them have reporting-relevant data, but none of them have all the information required under SFTR. So, bringing everything together, filling the data gaps and reporting in t+1 - on time and in sufficient quality, will be the biggest challenge.
Firstly, the regulator itself has learned a lot, especially from EMIR. SFTR has now implemented the mandatory ISO 20022 standard for receiving reporting files, which will help to reduce the differences between the trade repositories that we have seen under EMIR. Additionally, the data fields and values under SFTR are much more harmonized and standardized than EMIR and MIFIR, which helps to reduce misinterpretations. The industry itself has gained a lot of experience in daily transaction-based reporting in the last five years. EMIR was totally underestimated from the cost, implementation and especially from maintenance perspective. MiFIR/MiFID II was a bit better but still underestimated. Now, we see that the level of awareness of SFTR in the industry is much higher and most of the market participants have already started early their projects.
It helps but it does not solve every aspect of the problem. Generating the UTI, which is not yet implemented for many products in the securities financing market, is one part of the problem. What is much more complex than generating the UTI is exchanging the UTI between different counterparties. Once the UTI is generated, it must also be importable into the source system of the counterparty. And this point could lead to much more effort than expected due to changes in the whole IT architecture of a bank.
The pre-matching under SFTR looks more like a dream of the regulator than reality. A pre-matching of trades is already in place within the trade confirmation. However, to have a totally compliant pre-matching with respect to all relevant fields under SFTR, it would require a second pre-matching before sending the information to the trade repositories since the trade confirmation does not include every relevant data field. And even when a second pre-matching is performed and differences are detected, both counterparties need to have the time to correct the data in exactly the same way. When we consider the low matching and pairing rates of EMIR, we do not expect a much better situation under SFTR.
In the short-term, we have the Brexit, where it is still unclear when and what exactly must be done. In the mid-term, we will have the EMIR Refit to harmonize and simplify the current EMIR regulation. In the long-term, we strongly expect to see a harmonization among regulations and adjustments within each regulation. But we are not expecting another big regulation like MiFIR/MiFID II or SFTR.