28 Oct SFT Reporting – Have medium-sized companies reached a fork in the road?
Starting with banks and investment firms, SFT Reporting starts in April 2020; non-financials have another 9 months. Between now and then, some medium-sized market participants will need to decide if they want to continue with delegated reporting or move over to direct reporting. There are merits to both approaches.
For some financial companies, SFT reporting starts in April 2020. Non-financials have until January 2021. Large firms who self-report under EMIR will no doubt continue to do so under SFTR. Small financials companies, and some non-financial firms who delegate their EMIR reporting, will no doubt do the same under SFTR. But what about those medium-sized firms who actually have a choice between direct and delegated reporting? Will SFTR trigger a change of their reporting strategy? In this Blog we consider their options.
It has been commented that “SFTR is like EMIR, but more so”. No doubt this refers to the number of, and similarity in, the SFTR fields that have to be reported, along with their format. EMIR introduced some robustness into data management; SFTR goes a stage further, with ESMA mandating the use of ISO 20022 for data traffic. This time round, ESMA is much better prepared for go-live, but at the same time it will be less tolerant of tardy or poor-quality reports, believing that all market participants have had plenty of warning to get there reporting systems in order. That said, market participants are still waiting for ESMA to publish their level 3 implementation guidance containing additional technical details, due out later this year.
In reality, with respect to SFT reporting market participants subject to SFTR probably fall into three camps :
- The largest financial companies, for whom SFTR is genuinely a technical extension of EMIR, so they will approach it in the same way and carry out their own SFTR self-reporting to a Trade Repository;
- The smallest companies, including small non-financials caught under SFTR, who currently delegate their EMIR reporting, and elect to do so under SFTR Article 4 on the grounds of size, cost, and/or complexity;
- The medium-sized companies, some of whom may be non-financial, who sit on the cusp of self-reporting or delegation and are pondering whether SFTR is the catalyst for a change of tack into self-reporting, or justification for staying in the delegated reporting camp.
At deltaconX, we think the medium-sized camp who to date have opted for delegated reporting have reached a fork in the road on their journey to SFTR compliance. They will need to decide if they want to continue EMIR delegation into SFTR under Article 4, or move to a position where they are more in charge of their own destiny, and self-report. Both approaches have their strengths and weaknesses.
On the one hand, delegated reporting as a concept does have merit, which relative to EMIR may be strengthened by the added complexities of SFTR. There are extra fields to report, and the ISO 20022 XML schemas to master (including validations), which may be a step too far for some. Meeting these requirements consumes IT resources that the market participant either does not have, or is not willing to commit to a mundane activity such as regulatory reporting. Assuming the market participants enjoys a trusted and reliable working relationship with their counterparty or services provider, for SFTR it may be a case of saying, “If EMIR delegated reporting ain’t broke, don’t fix it for SFTR”.
Furthermore, some non-financials may be in the position where the submitting party is required to report both sides of the transaction, thus excusing the small non-financial from the obligation to report directly.
However, for all other firms the drawback of delegated reporting is that the responsibility for data quality and timeliness cannot be delegated, so the cost to the small financial and the big non-financial firms of oversight over the entity to whom their reporting is delegated may be a great as self-reporting.
On the other hand, market participants with an existing EMIR and MiFID II reporting liability and with substantial IT resources may regard SFTR as an opportunity rather than a threat. This is because there are the clear advantages to market participants of taking direct control over their data management and reporting solutions. Introducing robust controls to ensure the quality, completeness and timeliness of data is essential, and meets the international ‘best practice’ requirement to reduce business risk arising from inaccurate or largely inaccessible data.
Other advantages associated with taking direct control include the introduction of more automation into the capture and management of SFTs. Up until now, this area of the back-office still retains a very high proportion of disparate manual processes, and is out of step with the degree of automation in other back-office areas such as electronic confirmation and settlements matching.
At deltaconX, we would be inclined to favour a move to self-reporting for market participants who already have an EMIR and MiFID II transaction reporting obligation. There are clear benefits as stated above, which become stronger when the cost-overhead of the oversight of 3rd parties entrusted with delegated reporting is factored in.
We also believe that SFT will see the introduction of greater process automation. Up until now, the business processes underpinning securities financing have focused mainly on transaction settlement between counterparties rather than reporting to an external agency. We believe that SFTR will make it harder for market participants to manage any data that has been generated manually as opposed to electronically. We also expect to see a much greater take-up of electronic trading in, and electronic confirmation matching of, SF transactions. Market participants large enough to reap these benefits may miss out by opting for delegated reporting.
Another benefit from direct control over data and the introduction of automated processes is the optimisation of the use (and re-use) of collateral. As a deal settles, the underlying collateral can be released, and re-allocated to new transactions in seconds, rather than waiting hours, perhaps days, for the manual ledger system to catch up.
Even with these benefits, the move to self-reporting is not without difficulties of its own, especially given the challenging starting point of disparate systems and data sources. Regarding IT solutions, we think it is essential to use a single platform for consolidated EMIR, MiFID II and SFTR transaction reporting, one which is connected to the relevant data sources, validates incoming data, fills or alerts gaps, and applies business logic for the correct routing of orders and transaction data to the designated Trade Repository or alternative destinations.
A single platform that offers a consolidated view of the orders and transaction data also facilitates compliance with the MAR, as the timeline of market-sensitive events correlated with that of order placement and trade execution can be more easily assembled.
Large and small market participants might have already decided upon staying with the status-quo, or in some cases, having that decision already made for them. Medium-sized companies on the cusp of self-reporting need to make that decision now, based on rigorous cost-benefit analysis. Investment firms have probably left it too late for April 2020 to develop an own reporting solution, but we can help them to meet the deadlines and to introduce a cost, time and resources-efficient reporting solution.
Furthermore, Investment Funds, Asset Managers and Insurance Companies, as well as non-financials, should take the decision now. They must decide how they want to comply with their reporting obligation under SFTR in order to have enough time to meet their respective reporting deadlines of October 2020 and January 2021.
For more information on how deltaconX can advise you on your SFTR decision to adopt delegated or self-reporting, and on the implications of this decision for your business, please contact us at firstname.lastname@example.org .