With 7 months to go before the first SFT reporting deadline, firms subject to that deadline should be very well advanced with their system preparations. Many firms should have started their user acceptance and integration tests, or at least should have signed-off test scripts. Even firms who have elected to delegate their reporting should have established their oversight procedures and systems, always remembering that their regulatory responsibility cannot itself be delegated.
As if we didn’t need reminding, the first of the SFT reporting deadlines for MiFID investment firms, credit institutions, and relevant 3rd country firms is 11th April 2020.
The SFTR requires the reporting of a broad range of financing transaction-types which include repurchase agreements, securities lending, and margin-lending trades. These have to be reported to an authorised Trade Repository, normally on a T+1 or S+1 basis, so in the mechanics of reporting are very similar to those of EMIR.
Will the liable organisations be ready on time? Some fear not, but if past experiences with EMIR and MiFID II are anything to go by, the final details may not be available until late in 2019. Last month, ESMA published the results of its public consultation on Guidelines for reporting under Articles 4 and 12 SFTR (1). ESMA will assimilate the responses it received and should publish its Level 3 regulatory guidance text some time in Q4 2019.
We’ll now share with you where we think you need to be with your system preparations.
As of early-September, and despite the lack of final Level 3 technical detail, there has been ‘plenty to be going on with’. Many firms have spent 2019 discussing complex issues at industry level, and are thus evolving industry best practices for SFT business processes, legal interpretation, and data management. This evolution may cause some firms to change the way they process SF transactions, including front office trade booking, and back office management of life-cycle events. Firms should now have a much clearer view of the collaborative business process aspects of SFTR on which to base their system designs.
Hopefully, as well as the industry-wide collaborative effort, individual business functions within those firms should be working with their siblings on their corporate solution designs. By now, firms should know where their ‘golden’ sources of data are, especially their counterparty reference data, security reference data, transaction terms, legal and collateral data. Firms should have completed a comprehensive audit of their data to first locate it, then established its format vis a vis the ISO 20022 requirement, plus determined the need for any further enrichment or transformation, and defined the data’s incorporation into the final operational reporting flow.
Assuming they have completed their data audit, firms should have decided on whether or not to elect for using delegated reporting (assuming that they are not in the position of having reporting delegated to them). Smaller firms may be tempted to minimise their operational and administrative burden by delegating, but they need to remember that the responsibility for reporting accuracy still remains with them. If they do delegate, they should have designed their business processes and systems ready to guarantee effective oversight over their service provider.
At deltaconX, we believe that many firms see the SFTR as an opportunity to take control over their data management and reporting solution, even if seizure, in data management terms, this is a radical departure from what they did for EMIR. Having robust controls in place to ensure the quality, completeness and timeliness of data is essential from day 1 of go-live, and also considerably reduces business risk arising from inaccurate or largely inaccessible data. Also, taking control of data management and reporting may have knock-on benefits, such as the introduction of more automation into the capture and management of SFTs. Up until now, this area of the financial markets still retains a very high proportion of disparate manual processes.
If firms do take control of their own SFT reporting destiny, they will need to choose an authorised Trade Repository. If they have already appointed one for EMIR, all well and good, but they are advised to review what deals are on offer for extension into SFT reporting. Like renewing insurance, staying with the incumbent may not be the best option.
And so to testing. We think market participants need to allocate adequate time to testing, given that that we believe the industry and ESMA have learnt from previous implementations like EMIR and MiFID II where, for good reasons, testing wasn’t quite as thorough as it needed to be. ‘Conduct adequate testing’ is easy to say, but often easier to neglect. The 7 months to April may seem like enough time, but given the complexities around system integration, external interfaces, and data enrichment, it probably isn’t. We would budget at least 3 months for testing, and up to about 5 months if multiple systems are involved with new integration pathways.
The situation to avoid is still to be testing when any backloading should have started. For medium and larger firms with backloading obligations, the quantities of backloaded data will not be trivial, so they must allow for this in their implementation plan for the final approach to their firm’s specific deadline(s).
For SFTR there are a number of the 155 fields that must match between counterparties. This entails an active bilateral exchange of trade and reference data between counterparties, and a robust matching process (preferably automated for the larger market participants). So testing needs to include the interface between the in-house system, and those of each counterparty matching data. At least adoption of ISO 20022 should ensure that there are only minor variations between counterparties’ systems, but to quote the Russian proverb, “Trust, but verify”. This may not help if counterparties have adopted different trade booking approaches in their front offices, but any differences here should have been resolved at the industry level.
Lastly, the biggest incentive for thorough testing derives from ESMA’s likely attitude towards firms that do fail to report as required. We believe there won’t be much of a grace or ‘amnesty’ period for system glitches, so fines – heavy fines – will be levied on the miscreants sooner rather than later after go-live.
In conclusion, if you haven’t already started, we recommend that it can only be a matter of a few working days before the commencement of user acceptance testing of all systems involved in your SFTR data management and reporting, and that’s assuming there is a system in place to be tested. If your solution is to be provided by an external IT software company, a number of legal issues around service-level agreements must also be agreed (a process which itself could take between 1 and 2 months). And all this has to be completed before the ‘real’ data can be onboarded (taking another month or so).
Blink and it’s Christmas with a two-week layoff of key business staff; blink twice and you’ll hit the April 2020 deadline.
Time is of the essence!
Footnotes
(1) ESMA “CONSULTATION ON GUIDELINES FOR REPORTING UNDER ARTICLES 4 AND 12 SFTR” https://www.esma.europa.eu/press-news/consultations/consultation-guidelines-reporting-under-articles-4-and-12-sftr#TODO
For more information on how deltaconX can advise and help you on the data management and testing issues of SFTR, please contact our Compliance Help Desk.
