SFTR Shorts #3

SFTR Shorts, Part 4

Is the Action Type following the EMIR model?

 

This article is the fourth 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

As part of the consultation paper, ESMA had sought feedback on whether to follow the EMIR Action Type model or design another method (reporting based on Event Type & Technical Action). The result of the discussion is detailed in the RTS and indicates that ESMA is proceeding with the EMIR Action Type model for SFTR.

But it’s not that simple. Indeed, as similar as the Action Types might be to those used within EMIR, there are some slight differences requiring our attention.

The first one is related to the nomenclature. This time, ESMA has gone for four letter codes instead of the single letters used within EMIR (N for New, M for Modify etc).

There are also separate lists of Action Types available for each of the three submission types:

  • The Margin Data submissions support four Action Types:
    • ‘NEWT’ – New
    • ‘MARU’ – Margin update
    • ‘EROR’ – Error
    • ‘CORR’ – Correction
  • The ReUse submissions support four very similar Action Types:
    • ‘NEWT’ – New
    • ‘REUU’ – Reuse Update
    • ‘EROR’ – Error
    • ‘CORR’ – Correction

While these two lists are very similar in terms of format and functional usage, they differ from the corresponding messages in EMIR – the Valuation & Collateral submissions – as each of these only supported Action Type ‘V’ (Valuation Update).

All of this means that there is a functional gap between EMIR and SFTR for firms to wrestle with. Under EMIR, firms merely had to submit Collateral or Valuation messages under one Action Type. However, under SFTR firms will need to manage the Action Type choreography across newly submitted Margin Data or ReUse messages, modified messages, messages submitted in error (and hence being withdrawn) or corrections to previously submitted Margin Data or ReUse messages.

The Counterparty Loan & Collateral message also differs, as it now supports different Action Type lists based on whether the submission is being made at Trade or Position level:

  • Trade Level>
    • ‘NEWT’ – New
    • ‘MODI’ – Modification
    • ‘VALU’ – Valuation
    • ‘COLU’ – Collateral update
    • ‘EROR’ – Error
    • ‘CORR’ – Correction
    • ‘ETRM’ – Termination / Early Termination
    • ‘POSC’ – Position component
  • Position Level>
    • ‘NEWT’ – New
    • ‘MODI’ – Modification
    • ‘VALU’ – Valuation
    • ‘COLU’ – Collateral update
    • ‘EROR’ – Error
    • ‘CORR’ – Correction
    • ‘ETRM’ – Termination / Early Termination

The eagle-eyed amongst you (or at least those who have had their morning coffee!) will have spotted that the Position Component is the odd one out as it can only be submitted at Trade Level.

For those with experience of EMIR, the Action Type concept will be all too familiar. But regardless of previous encounters, the Action Type model will undoubtedly be one of the most significant challenges for firms when building their reporting solution and controls. The Action Type model adds an additional level of complexity: as well as needing to map all the various data elements from various sources into the SFTR ISO20022 data model, firms will also need to map the various events and triggers within their various source system into the relevant Action Type category.

Additionally, there is a choreography that needs to be implemented to ensure that the sequence of Action Type reported across any given UTI or Trade makes sense and is permitted. ESMA have published rules stating that the Trade Repositories cannot accept Action Type MODI (modification) on a UTI where no Action Type NEWT (New Transaction) or POSC (Position Component) has not be previously submitted AND accepted.

The high volumes of submissions anticipated for many firms reporting under SFTR combined with any issues related to incorrectly implemented Action Type solutions could very quickly result in many submissions being rejected. And obviously, this would lead to a daunting remediation process to both resolve the rejected submissions, and correct the flaws in the Action Type part of the solution.

All in all, meeting the requirements and establishing effective frameworks to accurately process Action Type should be high on the list of, well, Actions for firms designing their SFTR reporting solution.

Alan McIntyre

Senior BA and Industry Relations Lead at RegTek.Solutions

 

Download the PDF version of this article.

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

Missed our latest SFTR Short? Read it here.