Skip to content

Déjà vu All Over Again as ESMA Discusses SFTR Trade Reporting

On 11 March 2016, as part of its consultations on Level 2 measures under the Securities Financing Transaction Regulation (SFTR), the European Securities and Market Authority (ESMA) published a Discussion Paper incorporating draft Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) on transaction reporting under the SFTR.

At 187 pages and posing 145 questions, the discussion paper lacks brevity and, for the most part, addresses technical detail.  It covers three main topics:

  • Registration as a Trade Repository (TR);
  • Reporting; and
  • Transparency and availability of data.

A summary of the discussion paper is provided below.

Registration as a Trade Repository

Under Article 5 of the SFTR, ESMA is mandated to draft RTS and ITS regarding the registration of TRs for the purpose of reporting Securities Financing Transactions (SFTs) under the SFTR.  ESMA believes that the RTS should replicate, to the extent possible, RTS 150/2013[1] (the EMIR TR RTS), with amendments for specific SFTR issues and enhancements learnt from EMIR trade reporting.  In this context, more detail will be required from TRs as to internal control mechanisms[2], commercial viability[3], outsourcing arrangements[4], operational independence[5], operational risk and business continuity planning[6].

New provisions will also be implemented in order to comply with the requirement for TRs to establish procedures to verify the completeness and correctness of SFT data submissions, including:

  • Authentication of users;
  • Validity of reporting submissions;
  • Confirmation of authorisation of the reporting party to submit data on behalf of other entities;
  • Logical validation (i.e. ensuring that data relating to non-reported/cancelled SFTs is not modified);
  • Content validation;
  • Inter-TR data reconciliation; and
  • Timely feedback to participants on reporting submissions (e.g. if accepted or rejected (and why)).

TRs will also be required to:

  • Appoint at least one appropriate person who will assume responsibility for IT matters;
  • Provide a detailed description of the system used to report SFTs;
  • Evidence that they have complied with Article 12(3)(d) of the SFTR (which requires authorities to have direct and immediate access to data held in TRs)[7];
  • Evidence the steps they would take to port SFT data in the event of the withdrawal of their TR authorisation[8]; and
  • Evidence the steps they have taken to protect against cyber-attacks[9].



Drawing upon its EMIR experiences, ESMA acknowledges that “fully comprehensive and unambiguous rules regarding formats of information for reporting are indispensable”.  Furthermore, “such rules should not be limited only to the relevant data standards, the length of fields and the allowable values, but also should specify a technical format and common template in which the information should be submitted to TRs.”[10]  In order to limit operational costs, reporting formats will be aligned with existing frameworks such as those under MiFIR, the Market Abuse Regulation[11], EMIR and the Money Market Statistical Reporting Regulation[12] and will be based on an ISO 20022 technical format[13] using a common XML schema.

Reporting Logic

Reporting Business and Lifecycle Events

ESMA is considering two approaches for reporting SFT business and lifecycle events:

  • An EMIR-consistent approach; and
  • A combined business event and technical action approach.

The ‘EMIR-consistent approach’ adopts the same “action types” used under EMIR trade reporting, with two additions (“Re-pricing” and “Principal Increase”) and an amendment introducing an action type of “Collateral Update” rather than the EMIR action types “Compression”, “Valuation Update” and “Position Component” (as it is currently unclear whether it will be necessary to report SFTs at position level).

The ‘combined’ approach defines 7 “Event Types”:

· Repo / reverses trade event · Buy-sell back trade event
· Borrowing and Lending trade event · Margin lending trade event
· Adjustment lifecycle event for collateral, cash or both · Termination lifecycle event
· Repricing life cycle

Four “Technical actions” are capable of being specified for each “Event Type”, being:

·         New ·         Modification ·         Correction ·         Cancellation.

ESMA requests feedback as to the pros and cons associated with each approach.

Identification of ‘Buyer’ and ‘Seller’

Consistent with EMIR, ESMA proposes to introduce a “Counterparty Side” field which indicates whether a counterparty is a “buyer” or “seller” in relation to an underlying SFT.  It also suggests guidance on identification of the buyer or seller depending on transaction type[14].

Other Issues

Amongst other reporting logic issues, the discussion paper:

  • Clarifies that the definition of “SFT” extends to cover unsecured securities lending transactions[15];
  • Asks for feedback as to the way in which margin lending transactions and commodities financing transactions can be reported (and underlying commodities can be identified[16]); and
  • Seeks clarity on the role of tri-party agents.

Content and Structure of SFT Reports

ESMA proposes splitting SFT data into two categories – “Counterparty data” and “Transaction data”.  This is consistent with EMIR, where data is grouped into “Counterparty data” and “Common data” (which relates to transactions).  Comment is sought on proposals to include a number of specific data fields, including:

  • Branch identification[17] through the combined use of LEIs and ISO country codes (a helpful table provides guidance on when an SFT-like transaction involving one or more branches creates a reportable SFT[18]);
  • ‘SFT Beneficiary’ identification (i.e. the party – not necessarily being the party which executed the SFT – which is subject to the rights and obligations arising from the contract);
  • Linking of different SFT reports by a common identifier so that the transaction can be tracked as it evolves over time (e.g. if a bilateral transaction subsequently becomes cleared, to distinguish the roles that major dealers play in the repo market and to assist in ensuring underlying data quality); and
  • Collateral (and collateral re-use) reporting in terms of:
    • “Trade-based collateral allocation”[19] versus “collateral allocation based on net exposure”[20];
    • “Trade-dated collateral allocation”[21] versus “value-dated collateral allocation”[22]; and
    • The elements of collateral to be reported, split by reference to:
      • Cash collateral;
      • Securities or commodities collateral;
      • Collateral pools; and
      • Margin lending;
    • Linking of SFT collateral data to SFT loan data;
    • Additional data fields required in the case of margin lending transactions;
    • The calculation of collateral re-use; and
    • Whether collateral is available to be re-used (an element that will largely be driven by the terms of the underlying master agreement);
  • Clearing information (in order to monitor adoption of central clearing and the clearing models used, which in turn will provide insight into CCP exposures), including:
    • Whether a transaction was centrally cleared or not;
    • The identity of the relevant CCP and Clearing Member; and
    • A clearing timestamp;
  • Settlement-related information so as to facilitate the monitoring of interconnectedness between large SFT market participants, including:
    • The identity of any Central Securities Depository;
    • Any “direct or indirect participant” which settles the SFT;
    • Any “settlement internaliser”;
    • The “place of settlement”;
  • Master Agreement Information (similar to the data already reported under EMIR);
  • Methods of trading – trading venue, but also additional information such as whether an SFT was executed by way of:
    • Telephone;
    • Automated trading system (i.e. systems in which transactions cannot be executed and settlement cannot be initiated or completed); and
    • Automatic trading systems (i.e. systems in which transactions can be executed and settlement can be initiated and completed).

The data fields themselves are annexed to the discussion paper.  They adopt an approach parallel to that of EMIR transaction reporting, with obvious changes to take account of the different underlying transactions.  In addition, commodities classifications by “Base Product”, “Sub product” and “Further sub product” are provided.

Transparency and availability of data

Operational Standards for Data Collection

ESMA has proposed a number of practical rules for the collection of data so as to ensure that TRs are able to comply with the requirement to establish procedures “to verify the completeness and correctness of the details reported to them”[23].  The proposals are broken down into the following categories:

  • Validation, including:
    • Authentication of participants;
    • Schema validation (against the ISO 20022 reporting standard for SFTs);
    • Evidence of authorisation from the entity on behalf of which reports are submitted;
    • Logical validation (e.g. to ensure that a report is not attempting to modify a non-existent/cancelled SFT); and
    • Business rules/content validation.
  • Reconciliation:
    • Intra-TR and inter-TR reconciliation of (at least) all “common data fields” which should take place on t+1, using consistent formats and methodologies, with notification of conflicting values provided back to relevant parties same day;
    • Reconciliation of collateral data to be performed separately from the reconciliation of SFT data (“loan data”);
  • Standardised feedback:
    • Indicating, within one hour of submission, whether the submission has been accepted or rejected by a TR (and, if rejected, the basis for rejection);
    • Confirming, for all accepted submissions, whether an SFT is/is not reconciled (by the end of the day on which the reconciliation takes place);
    • Providing a minimum set of feedback reports detailing:
      • Daily activity;
      • Trade status;
      • Rejections; and
      • Reconciliation status.

Public Data

Article 12(1) of the SFTR provides that “A trade repository shall regularly, and in an easily accessible way, publish aggregate positions by type of SFTs reported to it.”  This requirement is essentially identical to that existing under EMIR which, being high level, has not resulted in the creation of standardised public data.  ESMA asks for comments as to whether a more granular approach to public data – but one that still does not allow for the identification of individual counterparties –would be appropriate so as to increase its value to the general public.

Data Made Available to Authorities

Article 12(2) of the SFTR requires TRs to ensure that certain regulatory authorities have “direct and immediate” access to SFT data.  Data should be made available as soon as possible and no later than 7 hours following submission to the TR by the counterparties to the SFT.  TRs should not delay the provision of data to authorities on account of any ongoing reconciliation process.  Information should be provided in the same ISO 20022 format as it is received and should comprise all of the data elements submitted by reporting parties, together with the additional fields specified below:

  • Information regarding the reconciliation status of each SFT (possibly enhanced to include the reconciliation status of associated collateral); and
  • Whether an SFT submission has been rejected before its acceptance by the TR or not.

When providing access to regulators, it is proposed that TRs ensure that, at least, the following types of reports are provided to authorities:

  • Transaction-level reports:
    • All SFT submissions made on the previous working day;
    • The latest status of outstanding SFTs as of the close of the previous working day;
    • All SFT submissions made in accordance with any criteria specified by the authority (to be produced same-day);
    • Daily report detailing all rejected SFTs and the reasons for rejection; and
    • Daily report detailing the reconciliation status of all accepted SFTs and the reasons for lack of reconciliation;
  • Position-level reports (frequency and timing yet to be determined), to include:
    • Gross and net exposure between counterparties;
    • Jurisdiction of the reporting counterparty;
    • Jurisdiction of the other counterparty;
    • Sector of the counterparty;
    • Type of SFT (repo, securities lending, etc.);
    • Indication of whether cleared or not;
    • Type of collateral asset class (cash, equities, corporate bonds, government bonds, etc.);
    • Currency of the cash leg;
    • Maturity bucket; and
    • Haircuts applied;
  • Standardised aggregate SFT reports so as to enable EU authorities to meet their commitment to submit standardised aggregate data on a monthly basis to the FSB.

Other Matters and Next Steps

Article 13 and 14 of the SFTR require UCITs and AIFMs to provide pre-contract and periodical disclosure to investors, specifying the information that must be provided in Annex A and Annex B of the SFTR.  The SFTR also give ESMA power to draft regulatory technical standards further specifying the contents of those Annexes.  However, ESMA feels that this would not be the “best approach at this stage”.  In addition, ESMA will consult at a later stage regarding the ITS required under Article 25 of the SFTR regarding exchange of information between competent authorities and ESMA in relation to sanctions imposed on firms for breaches of the SFTR.

The discussion period is open until 22 April 2016.  Thereafter, ESMA expects to publish a consultation paper early in Q3 2016.  There will be only one round of consultation[24].  Thereafter, the final report and the draft technical standards will be submitted to the EU Commission for endorsement by 13 January 2017.


The EMIR experience has demonstrated a clear need to define in detail both the format and content of the data to be reported to, and made available by, TRs.  Under the SFTR, over 100 authorities will have access to SFT data reported to TRs, emphasising the need for standardisation.  In fairness, ESMA seems to have understood this.  Certainly, the format in which information is to be provided is far more prescriptive than under EMIR – a welcome development.  More generally, the contents of the discussion paper represent a first good step towards building a robust reporting framework.

However, the expedited nature of the consultation process is more regrettable.  If EMIR has taught the industry nothing else it is that, with the best will in the world, transaction reporting (particularly 2-sided transaction reporting) is highly complex and hence incredibly easy to get wrong.  The result – as seen with EMIR – may be that regime restructuring can become necessary in relatively short order.  Although the SFTR reporting rules are unlikely to take effect until around Q3 2018, the experience of EMIR also shows that this is not a long lead-time for an exercise of this magnitude.  ESMA is largely absolved from responsibility on this front as the regulatory timeframe is hardwired into the SFTR itself.  Nonetheless, this train is now leaving the station.  If the market wants to make its views known, it needs to get on board now.

[1] Which details the application process for registration as a TR under EMIR

[2] See paragraph 43.  Currently only an “overview” is required under Article 7 of the TR RTS

[3] See paragraph 44

[4] See paragraph 45

[5] See paragraph 46

[6] See paragraph 49-50

[7] See paragraph 61-62

[8] See paragraph 64

[9] See paragraph 65

[10] See paragraph 73

[11] Regulation (EU) No 596/2014

[12] Regulation (EU) No 1333/2014

[13] See paragraph 90

[14] See paragraph 140

[15] See paragraph 167

[16] Probably via use of an ISIN

[17] As required by Article 2(1)(a) of the SFTR

[18] See page 58

[19] Where collateral is explicitly linked to a specific SFT, resulting in a one-to-one or one-to-many relationship between the trade and the collateral

[20] Where there is a many-to-one or a many-to-many relationship between trades and collateral

[21] Where both counterparties have agreed the collateral for an SFT at the time it is executed, allowing explicit securities used as collateral to be reported on t+1

[22] Where collateral is assigned to an SFT on the value date of the start leg of the SFT, meaning that it may not be possible to report explicit securities used as collateral by t+1

[23] As required by Article 5(6) of the SFTR

[24] See paragraph 332

Contact Us