On 31st October 2019, ESMA published further technical details of the XML Schemas for the reporting of Securities Financing Transactions (SFTs) as required under the SFT Regulation (SFTR). Under ESMA’s mandated use of ISO 20022 in SFT reporting, these Schemas must be approved by ISO’s Evaluation Team. Unfortunately, there has been a delay in ISO approval of the October (third draft) schemas, which means that the prospect of implementing costly and time-consuming ‘workarounds’ has reared its ugly head in IT departments. We opine on an interim course of action.
Much has been made of ESMA’s decision to mandate the use of ISO 20022 in the design of SFT reporting XML message schemas. The intended process is that ESMA submits its proposed schemas to the ISO 20022 Securities Standards Evaluation Group’s Evaluation Team, who reviews (and, in theory,) approves them, enabling ESMA to publish them with ISO’s stamp of approval. Once approved, everyone from market participants’ IT teams to software vendors can get on with supporting the schemas in their SFTR systems. Alas, all is not well with the approval process of the third draft, and creates the risk that market participants may not be able to fully complete their preparations by the first of the 2020 reporting deadlines. Some market participants have always feared this situation could arise – now they might be right.
On October 31st, ESMA published the third draft of its SFTR XML Schemas, including the validation rules for :
- Counterparty and TR data exchange;
- Intra-TR data exchange; and
- TR to authority data exchange.
This is NOT the final set – at a fourth is due to be submitted to the Evaluation Team for review on November 15th, and is anticipated to resolve the outstanding known defects in time for the April 2020 deadline. Assuming no further issues, final ISO approval should be granted in late-November, or soon after if there are.
Unfortunately, at deltaconX we have heard talk in the industry that the ISO 20022 Evaluation Team was not given enough time to review the third draft and have its concerns addressed before ESMA went ahead and published them, despite an acknowledgement by ESMA of the validity of the Evaluation Team’s concerns. The third draft is still under the Team’s review, and negotiations for approval remain ongoing. On the plus side, word in the industry is that the Evaluation Team regards the third draft as a big improvement on the second, but still falls short of the standard required for approval.
Consequently, and contrary to the required standard laid out in the Level 2 text of the SFT Regulation, the October third-draft schemas are still not ISO-registered. Furthermore, it is also feared that hot on the heels of the as-yet-to-be-approved third draft, the fourth draft will follow next week containing its own set of defects, and may only complicate things still further, delaying final formal approval.
Does it matter at this stage if a fourth draft resolves all the outstanding defect issues by late November or early December? Probably not, assuming that the review process allows the Evaluation Team and ESMA sufficient time to agree and resolve all the outstanding third-draft issues, AND that the fourth draft doesn’t add a whole lot more defects of its own. That is one big ‘If’, given the third draft is already late, and considering the generally chequered history of implementing data standards in regulatory reporting.
So, what will happen if market participants do not see a fully-approved fourth draft by December?
We expect that most market participants are well down the road of implementing their SFTR systems to the point where a delay in publication of the final schemas is problematic. On that assumption, from a focused IT system-implementation perspective we have to consider the creation of ‘workarounds’, especially if the third draft is all we have to work with. However, given it’s only around six months to the first reporting deadline, the last thing we need is to have to embark on a lengthy programme of amendments to the reporting templates to solve known defects. This programme will be costly, and by introducing delays will shorten the testing timetable still further.
Furthermore, given the diversity of SFT reporting systems, a defective draft creates more freedom of interpretation across firms, potentially leading to mis-matches between market participants’ and Trade Repository systems. And all this is before the inevitable teething problems we expect after go-live, based on our experiences with EMIR and MiFIR.
There is a feeling in the industry that despite ESMA’s best intentions with ISO 20022, they are still under-prepared, not fully understanding the issues, and leaving things to the last minute. This provides little comfort to compliance IT teams, so the in the interim, some action must be taken at industry-level.
In previous deltaconX Blogs, we have commented on the need for a thorough SFTR system test programme. At this stage of the implementation project, we recommend that readers start activating their contingency plans for a delay in receiving the final schemas, and prepare for its consequent knock-on delay in completing the test programme. We do not want to add ourselves to the ‘voices of doom’, but have had enough experience to conclude that the final approach to SFTR go-live is looking uncomfortably close to that of EMIR.
As an interim course of action, we would advise our readers to take a very close look at the ESMA schema published on 31st October, and determine how closely they meet the industry-agreed requirements and interpretations of the SFTR. It will then be a judgement call on the part of individual SFTR project managers on whether their system implementation is so far gone as to require the implementation of workarounds, or hasn’t gone far enough to rule out waiting for a fully-approved final draft in late-November (or early December). Both strategies have their strengths and weaknesses, but given all regulatory compliance IT projects have had some element of delay caused by late or unclear data standards, we would tend to recommend embarking on the ‘workaround’ path.
As part of the workaround strategy, and ahead of receipt of the approved final draft, we would recommend readers contacting their counterparties and Trade Repositories to :
- Determine if they have detected the same defects in draft three as you have, and
- Where you can agree defects, negotiate a consensus on the interpretation of the key affected fields to minimise the risk of your mismatches on go-live.
In a perfect world, this issue could be over by Christmas, but’s that’s been said of many a crisis!
We’ll be keeping a
close watch on this situation, and will raise this topic again in later Blogs.
(1) ESMA VALIDATION RULES AND XML SCHEMAS FOR SFTR REPORTING 31/10/2019 https://www.esma.europa.eu/press-news/esma-news/esma-publishes-validation-rules-and-xml-schemas-sftr-reporting
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 email@example.com .