SFTR Shorts, Part 6


New SFTR Validations

in the post?



This article is the sixth part of the ‘SFTR Shorts’, a series of bite-sized discussions around various aspects of the Securities Financing Transaction Regulation (SFTR). Alan McIntyre, Senior BA and Industry Relations Lead at Regtek.Solutions drills into various aspects of the reporting requirements under SFTR and identifies some of the challenges that firms will need to consider.

On the 9th of August, ESMA published updates to the Validation Rules Under EMIR. And it seems likely that a few of these changes will find their way from the Derivatives department down the corridor, past the water cooler and around the corner to the Securities Finance section. The timing however is likely to depend on when the current impasse between ESMA and the EU Commission around the amendments (or lack thereof – depending on who wins this battle of wills) to the SFTR RTS ends.

The SFTR RTS is due to be approved imminently, but we find ourselves in fairly uncharted waters as the EU Commission published a letter to ESMA on the 24th of July stating that they were ready to approve the SFTR RTS but recommended some minor changes. ESMA had 6 weeks to respond and duly did so on the 5th of September. But intriguingly, the Paris based regulator declined the changes recommended by the Commission. This impasse (or bunfight as I prefer – cause let’s face it, in these deranged political times of Brexit and whatnot, the image of immaculately coiffured technocrats and bureaucrats throwing chocolate éclairs at one another brings some much-needed comic relief ?) makes it hard to accurately predict what will happen next and when.

Whilst the ‘when’ is more elusive, I’ll take a crack at the ‘what’. I think the following will happen:

  • The draft SFTR RTS, avec or sans amendments, will be approved
  • Immediately or at least very closely after the approval of the RTS, ESMA will publish Level 3 guidance. This will most likely include an SFTR Q&A document, technical reporting instructions and examples of different scenarios and how to report them.
  • ESMA will update the SFTR Validations based on feedback to date from the TRs, the Trade Associations and the industry.
  • ESMA will (hopefully) publish the long awaited ISO20022 schema for SFTR (after all, what’s so secret about an XML schema!)

As well as providing some much-needed clarity around when we can expect SFTR Transaction Reporting to commence, these additional Level 3 guidance documents will provide the level of detail the industry needs to finalise the planning and budgets required to get their projects and builds properly underway.

So, what’s in these EMIR Validation updates that’s likely to also surface in SFTR?

Reporting Timestamp rules

Reporting timestamp? That’s easy, right? Surely a slam dunk?

Well not quite.

I attended an SFTR conference last week where one of the presenters discussed the issues and pitfalls on this field. His points were related to the exact format prescribed by ESMA and the fact that failure to meet that exact format will result in rejections. He also quite rightly pointed out the minefield of issues that can arise out of the need to use UTC times where the submitters other systems may well work on a different time zone.

Well it’s now been four and a half years since EMIR went live and ESMA finds itself compelled to publish additional rules on this slam dunk field. The text in red below is newly added to the EMIR Validations and outlines the scenarios under which the Trade Repository must reject the report.


Relaxed GLEIF rules for certain Action Types

Some good news at least: some of the rules are being relaxed rather than tightened.

As part of the Article 9 RTS ReWrite of EMIR last year, ESMA introduced rules stating that LEIs for different parties must be validated in two ways against the GLEIF database of all LEIs issued globally. First and foremost, the LEI must be present on the GLEIF database. Secondly, the LEI must meet the prescribed Registration Statuses for that field.

EMIR is very similar to SFTR in terms of fields used to describe the two counterparties involved in the trade:

  • Reporting Counterparty ID [Reporting counterparty – in SFTR]
  • ID Of The Other Counterparty [Other counterparty – in SFTR]

The EMIR rules as of last October’s RTS re-write stipulated that the LEI for the Reporting Counterparty must be valid on GLEIF with one of the following Registration Statuses:

  • Issued
  • Pending transfer
  • Pending archival

The rules for ID Of The Other Counterparty were identical but permitted one additional Registration Status:

  • Lapsed

The rationale being that if you are the Reporting Counterparty, then you better ensure that your LEI is valid and you’ve taken care of the annual renewal.

The reporting party should not however be locked out of reporting because their pesky client has been less than diligent and allowed its LEI to lapse. Said pesky client will however be locked out of reporting their side of the transaction due to the lapsed LEI and ergo need to renew their LEI in order to resume reporting.

All perfectly sensible and a nice bit of data integrity policing from our Parisian pals on the banks of the Seine.

The update to the EMIR Validations looks quite complex but basically adds two new scenarios based on the Action Type being reported:

  • For Action Type ‘C’ (an early termination) an additional Registration Status of ‘Retired’ is now also permitted.
  • For Action Type ‘E’ (reported in error) the Registration Status no longer matters and the LEI only needs to be present on GLEIF

Again the text in red is new:

Considering that the SFTR RTS has the stated goal of aligning as much of SFTR to EMIR as possible, I find it hard to envisage ESMA asking the EMIR Trade Repositories to enforce these changes and not also require the SFTR TRs to do likewise. The Reporting Timestamp rules will almost certainly be copied and pasted verbatim into the SFTR Validations. The GLEIF rules for reporting counterparty and the other counterparty will be transposed onto the equivalent fields and translated onto the corresponding Action Types, ETRM (Termination / Early Termination) and EROR (Error).

We’ll hopefully find out soon depending on how long it takes for the current standoff between Brussels and Paris to find a conclusion.

Meantime, chocolate éclair anyone?!

Please join the discussion with Alan on the LinkedIn group: SFTR Transaction Reporting group 

Missed our latest SFTR Short? Read it here.

The post SFTR Shorts, Part 6 appeared first on RTS.