On 22nd March 2019, the EU published the SFTR implementing regulation in the Official Journal of the European Union. Publication confirms the start-dates of transaction reporting for investment and non-financial companies. Data managers have a number of technical hurdles to surmount, so adequate planning is crucial. In the third of a series of SFTR Blogs, we highlight the main data management issues associated with the Action Type aspect of SFTR reporting.
Depending upon your point of view, one of the most important (or tedious!) aspects of regulatory software functionality is ensuring that all combinations of the underlying business logic for initiating transaction reporting are adequately captured. This importance is most manifest in the requirement to correctly manage all entries into the ‘Action Type’ field, i.e. accurately stating if the report in question pertains to a new transaction, a modification to an existing one, or a confession to, and/or correction of, a previous error. The Action Type fields do have a logic or ‘choreography’ of their own, in that only some sequence combinations are valid.
If non-technical readers are tempted to leave our Blog at this point, we do have to say that ESMA (and its energy market sibling, ACER), has often lamented the frequency with which market participants break the rules governing this ‘choreography’. These breaks usually entail a series of Action Type entries for a transaction which are at best inconsistent and at worst gibberish. Indeed, ACER includes the failure to manage Action Types properly high up on its list of sins against REMIT data quality.
Firms who have mastered the management of Action Type under EMIR may congratulate themselves, and could look forward to managing Action Types under SFTR with a fair degree of confidence. After all, they are nearly the same, aren’t they?
Well no, not quite – indeed, they are different enough to catch out the unwary, so some caution is advisable. Indeed, at deltaconX we recommend that testing of all combinations of SFTR Action Types is undertaken, tedious as this may sound.
This issue arises from the ESMA SFTR Consultation Paper (1) in which ESMA had asked for feedback on whether to introduce the EMIR Action Type model, or design another mechanism. The result of this aspect of the consultation is discussed in some detail in the RTS (2), and indicates that for SFTR, ESMA is going ahead with a mechanism based on the EMIR model.
However, a closer examination does reveal some key differences between SFTR and EMIR :
- SFTR uses 4-letter codes instead of EMIR’s single-letter, so EMIR’s ‘N’ becomes SFTR’s ‘NEWT’;
- Each of the three SFTR submission types has its own separate list of Actions Type;
- SFTR Collateral or Valuation messages branch into two Action Type lists, each requiring separate choreography covering Margin Data or ReUse messages, whereas EMIR offered only one Action Type;
- The SFTR Counterparty Loan & Collateral message now supports different Action Type lists, based on whether the submission is being made at Trade or Position level;
- SFTR Position Component can only be submitted at Trade Level.
No matter what level of experience firms have with successfully dealing with EMIR Action Types, we believe that the SFTR Action Type model will still present firms with some very great challenges for their system designs and underlying controls, such as :
- The need to map correctly all data elements from source into the ISO 20022 schema;
- The need to map correctly all the business process triggers and events into the appropriate category of Action Type;
- The need to support the correct execution of the ‘choreography’ of the sequence of Action Types that follow from a particular trigger or event.
Further to the last point, ESMA’s rules require Trade Repository systems to reject invalid submissions where the Action Type is inconsistent or simply wrong, e.g. MODIfying a transaction UTI that has never been previously reported as ‘NEWT’, or making other changes to a UTI that have not previously been both submitted and accepted.
There are, of course, numerous combinations of Action Types against Report Types. For testing purposes, we recommend that readers draw up some kind of matrix listing the main valid combinations. As an aide memoire,we have reproduced a Table from one of ESMA’s RTS documents (3) :
You may also wish to examine your system’s design for its execution of the correct ‘choreography’, and ask if is it clear what your system does against all combinations of events and triggers it is going to meet. You may also want to know under what circumstances your system could generate invalid combinations.
This is not an exercise in IT pedantry. Depending upon your scale of operations, you may be submitting thousands of SFT reports. If you haven’t mastered Action Type, and your Trade Repository is fully compliant with ESMA’s rules, you risk creating a major backlog of rejected submissions, each requiring correction, the unwelcome attention of ESMA, and an expedition into the underlying codebase to remedy the fault.
In conclusion, we do recommend that readers take some time to check their system’s mastery of SFTR Action Types, even if this involves additional testing of all the combinations (valid or otherwise). This is not to impugn the capability of our readers’ systems and the competence of their designers, but there are three points to bear in mind :
- The error-rate in managing the Action Type fields for previous regulations has been sufficiently high to cause ESMA (and ACER) to moan, so something isn’t quite right across everyone’s systems;
- SFTR Action Type fields are different from their counterparts in EMIR (and from REMIT, if you are coming into SFTR from energy), so a wholesale reliance on an EMIR design as the template for SFTR may be offering a hostage to fortune;
- ESMA believes it has made huge attempts to get the data management issues thrashed out well ahead of the reporting deadlines, and has gone further by mandating the use of ISO 20022. So if things go wrong on Day 1 because of a failure to correctly report Action Types, ESMA is more likely to levy a fine rather than listen to excuses.
Above we have included ESMA’s 2017 Table (3) which lists the valid combinations of Action Types for Report Types. We’ve included this only as a mnemonic – pre-Level 3 Guidance it’s not definitive, and may not be 100% current. But for the purposes of error-trapping, you may use it to establish if your system inadvertently generates invalid combinations, or conversely, you can generate your own ‘gibberish’ and see if your system traps the errors.
Some of us at deltaconX have 30 years of experience in working with business logic tables such as these, and dealing with the cost consequences of seemingly small errors. It is worth testing, we can assure you.
Good luck!
Footnotes
(1) Consultation Paper “Draft RTS and ITS under SFTR and amendments to related EMIR RTS” 30 September 2016 ESMA/2016/1409 https://www.esma.europa.eu/sites/default/files/library/2016-1409_sftr_consultation_paper_-_draft_rts_and_its_under_sftr_and_amendments_to_related_emir_rts.pdf
(2) ESMA “Final Report Technical standards under SFTR and certain amendments to EMIR” Date: 31 March 2017 ESMA70-708036281-82
(3) Ibid Page 44
For more information on how deltaconX can advise you on the data management and testing issues of SFTR, please contact our Compliance Help Desk.
