SFTR System Testing – “Are we nearly there yet?”


With less than 3 months to go before the first SFT reporting deadline, firms subject to that deadline should now be very well advanced with their system testing. Yet we hear that there is still a sizeable number of firms who have not even started their SFTR preparations, let alone embarked on a system test programme. We would like to remind firms that SFT reporting is much more than a simple extension to EMIR, so systems need very robust testing.

The first of the SFT reporting deadlines for MiFID investment firms, credit institutions, and relevant 3rd country firms falls on 11th April 2020. ESMA has made it very clear that it believes both itself and all market participants have learned the lessons from their EMIR implementation, so there is little or no excuse for firms not to be ready.

Yet despite the close proximity of the first of these deadlines, at deltaconX we continue to hear talk from the industry that there is still a significant number of firms who haven’t even started their SFTR system designs, let alone commenced testing. Given ESMA’s likely dismissal of any excuses for delay based on IT issues, some firms still have much work to do ahead of April.

Some may say that ESMA’s late publication of the final version of the ISO 20022 XML Schema has contributed to the delay in finalising system designs and testing. We think this excuse remains a ‘red herring’, in that virtually all of the SFTR reporting requirements have been known to the point where system designs and testing could have been, and should have been, started several months ago. Given that all past EU transaction reporting regimes have been subject to post-implementation tweaking, no reporting system should have such an inflexible design where a minor change to a piece of XML brings the whole system down.

That’s not to say that designing an SFTR reporting system is easy, just that the core requirements have been known for some time, and known well enough to empower a test programme.

At deltaconX, we see a number of key data-management requirements underlying system design :

  • There are 5 major data-sets to source, manage and master :
    • Counterparty data
    • Margin data
    • Collateral data
    • Loan data
    • Re-Use data

This diversity of sources results in a major risk of data fragmentation, and is of concern to many firms. Specifically, the quality and format of these data vis a vis that required will raise some pointed questions about system functionality.

  • SFT reporting is based on a T+1 or S+1 timeline. This entails a narrow time-window for data gathering, processing, validation, and submission. It may be challenging to meet, so any bottlenecks need to be quickly identified and relieved before they hinder system design.
  • ISO 20022 is the mandatory format for reporting SFTs to Trade Repositories, so the ability to create and manage XML data in this format is a primary system requirement;
  • Data accuracy and validation checks need to be implemented before data are sent to the Trade Repository – the TR will simply reject any data in the wrong format, but if the firm submits inaccurate data in the right format, it and not the TR retains legal responsibility for the errors.
  • Firms looking to delegate reporting cannot delegate their legal responsibility for its accuracy. They need to implement control mechanisms to oversee the conduct of the entity to whom they have delegated their reporting to ensure accuracy and timeliness.
  • Submitting the SFT report is not necessarily the end of the process because life-cycle events have to be reported as well. Given the 5 major data sets involved, there are numerous different processing paths through the data-sets that a life-cycle event could initiate.
  • As well as the 5 main data-sets, the SFT sector supports a diverse range of types of firms, and their service providers, each with their different roles and business processes. They may not all share the same interpretations of the SFTR to be applied to the data.

This core list of requirements dictates the system test-programme. At deltaconX we believe the major areas to test include :

  • Field matching – the number of SFTR fields that must match between counterparties is greater than that under EMIR. This needs to be recognised, and no undue reliance placed on using a re-hash of the EMIR test scenarios for field-matching.
  • Action Types – the number of SFTR Action Types which trigger further actions and submissions is more complex than EMIR’s. Firms need to map out all the possible combinations that do (or could) apply to them, and draft their test scripts accordingly. ‘Sod’s Law’ says that a combination that wasn’t tested because it was of very low applicability will be the one that causes the most trouble on go-live.
  • Interactions between different actors – the different types of firm mean the involvement of multiple actors depending upon the type of SFT executed. All these interactions need to be modelled and tested accurately. We think that covering all the main combinations could involve around 100 individual test scenarios involving over 200 trade and event types. This could result in over 1,000 individual test cases that need to be scripted, executed, and signed-off.
  • Differing interpretations of the SFTR – the diversity of types of market participants also engenders the risk of differences in interpretation around areas such as trade booking and transaction processing that could lead to mis-matches and rejections. At the same time, compliant SFT reporting does not itself offer a competitive advantage (we’re not aware that ESMA will close down any firm for non SFTR-compliance). On that basis, we believe that testing should not be done in isolation. It may be very worthwhile for a firm to agree a common or collaborative test programme with its major counterparties and service-providers using a common data-set. Commonality would then highlight any differences in interpretation among the actors.

Taking the above points into consideration, we would allocate at least 3 months for testing, and up to 5 months if multiple systems are involved with new integration pathways. Readers with a large SFTR footprint involving multiple systems who haven’t started testing yet, but have an April 2020 deadline, may be in for a challenging Christmas!

The biggest incentive for thorough testing remains 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, start testing now if you can, and don’t fall into the “It’s too close to Christmas” trap. If possible, look at the benefits of joining a collaborative test programme with your major counterparties and service-providers, using an agreed common data-set.

If you plan to delegate reporting to a 3rd party, you will need to have an oversight programme in place by go-live, so this needs to have been designed and incorporated in their system tests. Remember that if they are late with their testing and implementation, their failure also means your failure!

If your solution is to be provided by an external IT software company, don’t forget that in addition to testing, there are a number of legal issues around service-level agreements that must be agreed, and is a process which itself could take between 1 and 2 months.

Good luck, and a Merry Christmas from the deltaconX team!

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.

Get in touch with us