Interview with Alexander Becht, product manager for ABACUS/Transactions at BearingPoint.

1. What are the main challenges of implementing SFTR (Securities Financing Transactions Regulation) reporting?

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.

2. What have we learned from EMIR (European Market Infrastructure Regulation) and MiFIR (Markets in Financial Instruments Regulation)? How can the industry benefit from these lessons in view of the upcoming SFTR implementation?

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.

3. The Unique Transaction Identifier (UTI) is not yet implemented in the securities financing market but it is a requirement of SFTR. Does the ESMA hierarchy scheme for generating the UTI solve the problem?

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.

4. Is the pre-matching requirement of SFTR feasible or just a dream of the regulators? What is the status of EMIR pre-matching after five years of reporting obligation?

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.

5. What else can the industry expect in the future in the area of transaction-based reporting?

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.

Video-Interview: Implementing SFTR

Video-Interview: Implementing SFTR

Watch the interview
Request a demo Toggle

Request a demo

We use reCaptcha to secure our forms. This requires JavaScript enabled.

Complete all fields marked with an asterisk