Securities Finance Transaction Reporting: It’s a Heptathlon not a Sprint

The next draft of the Securities Finance Transaction Reporting (SFTR) regulation is due soon. Given the responses to the consultation document, it is unlikely to be the final draft. On the advent of its release we examine some of the issues as highlighted by the respondents.


SFTR fills a gap left by EMIR. It will require transaction reporting on all securities financing transactions, including sale and repurchase agreements, stock loan / borrow and all collateral held against it. Rules concerning notification to the counterparty that re-use may occur, under a title transfer agreement, have been in place since July 2016.

We are, however, in danger of data overload. Firms are grappling with the demands of the additional data requirement under MiFID II, and there are serious concerns that the current draft requirements for SFTR are undeliverable. Market participants have challenged much of the consultation paper, the results of which we will see in ESMA’s review.

GFT have analysed 145 questions regarding Securities Finance Transaction Reporting answered by 35 respondents, made up of banks, associations and exchanges.

In terms of overall responses, we see that:

  • 37% of respondents had major concerns with elements of the proposed regulation; 46% had moderate concerns.
  • 85% of questions answered by respondents reflect either major or minor concerns with proposed reporting requirements.

Challenges with SFTR cut across data quality and volume, responsibility and duplication. The challenges highlighted can be broken down into seven disciplines:

  • Normalisation of data
  • Framework and standards
  • Ownership and stakeholder
  • Legal Entity Identifiers (LEIs)
  • Unique Trade Identifiers (UTIs)
  • Cross border settlement
  • Central clearing

Below, we expand the themes within these seven disciplines, and explore some potential shortcuts to transaction reporting. Clearly, if regulation is perfected, usage of the recorded data that it demands could be used to benefit the transacting party, and we look forward to seeing how the draft SFTR regulation develops.

Figure 1: A brief overview of the consultation

Normalisation of data

  • Data quality
    Most investment banks do not trouble the ‘medal tables‘ in this costly ‘Regulatory / Business / IT‘ exercise. Complex and silo’d business models and disaggregated data sources are likely to cause issues, much as they do under EMIR. Even without Unique Trade Identifiers (UTIs), data cleansing and harmonisation will prove challenging. However, lessons from risk reporting and aggregation regulation (BCBS239) and the ‘old’ enhanced mismatch reporting for BoE / PRA, should consolidate with SFTR, if a strategic approach to transaction reporting is taken.
  • Data volume
    Questions are raised on the effectiveness of receiving replicated data from different sources.Looking at the ten largest banks who have a minimum of a 100,000 open Securities Finance trades across the GRMA, GMSLA, OSLA and older agreement types, we quickly build up to millions of trades across the market, even if only considering one-sided reporting.Whilst we await conclusions to be shared from the consultation paper, it seemingly makes sense to simplify and normalise data collation, quality assurance and delivery, to provide a reporting framework that may be as useful to the organisation as the regulator. Simply put, too much data misses the mark, meaning that the low quality of data means that it cannot be interrogated effectively.

Framework and standards

Aside from the wider objectives of SFTR we deduce that the regulator seeks to highlight areas where clear trade aggregation is not obvious, such as where we have ‘baskets’ and trade-specific collateral. This would be a benefit, since improving and uniformly applying standards to the market is a noble principle, with which most market participants would agree.

The sector agrees with leveraging the six approved and new entry Transaction Repositories (TR’s) that will continue to be tasked to aggregate, match, reconcile and publish the sensitive client and trade data on a ‘next-day’ basis.

Appropriate operational standards such as control measures, security steps, and defined roles and responsibilities will apply for new players interested to complete a more simplified registration process under SFTR. For example, where a trade repository offers ancillary services, such as; trade confirmation, trade matching, credit event servicing, portfolio reconciliation or portfolio compression services, the trade repository will need to maintain those ancillary services as operationally separate from collecting and maintaining records of securities finance transactions.

The duty to ensure high quality data output and smooth reconciliation amongst the old and new transactions will almost certainly re-test and improve technical specifications and standardisation.

Creating a standard terminology across the different layers within a securities finance transaction is key. Margin terms, haircuts[1], trade lifecycle events, settlement status, terms and taxonomies, all differ from system to system, entity to entity and region by region. ESMAs emphasis on transparency is difficult to attain otherwise.

Ownership and stakeholders

SFTR will fall on EU counterparties to a transaction, which includes EU branches of non-EU companies, and non-EU branches of EU-based companies[2]. Paragraph 190 expects the following:

  • Identification of the trades where both counterparties have a reporting obligation and for which some type of reconciliation, intra-transaction reporting or inter-transaction reporting, should take place
  • Identification of the potential cases of over-reporting
  • Aggregation of data by trade repository, by relevant regulators and by FSB

Within SFTR a Trade Repository’s role is to gather data from both counterparties to the securities finance transaction, and deliver these to the regulator.

European Trade Repositories (ETR) already provide reporting under EMIR, however, Unique Trade Identifiers (UTIs) remain problematic. Currently more than 80% of transaction reporting is one-sided, due to:

  • Poor data quality
  • Non-EMIR / Legal Entity Identifiers (LEI) entity
  • Mismatch of European Trade Repositories (ETRs)

Clearly, providing a consistent and accurate reporting source still requires a collaboration, directive or agreement on the approach, but it is not clear at this point whether the new draft will make a recommendation in this space.

Collaboration on determining and delivering transaction reporting is also required within each transacting organisation. Whilst regulatory reporting areas would be expected to adhere to key regulation and supply the core data, the governance, policies and quality assurance may ultimately sit with the business and operational support functions. These roles need to be clearly understood, with the appropriate allocation of accountability for the underlying reporting process.

Everyone should be working together to provide an automated standardised solution which enhances in-house management information as much as meeting the regulatory obligation.

Cross-border settlement

The settlement and location of cash and the use and re-use of collateral in a Securities Finance transaction is paramount. However, where multiple CSD’s are involved (as in the case of cross-border settlement), each counterparty may use different values[i]

Within the responses to the consultation paper, ECSDA expect that, for a given SFT, both counterparties will report the same “place of settlement” but they may each report a different code in the “CSD” field. This is likely to be the case in cross-border scenarios where multiple CSDs are involved.

Triparty facilities (as well as T2S and central clearing) combined with a custodian network (e.g. the collateral highway and liquidity hub) may have a part to play in offering cross-border delivery against single electronic instruction, thereby ‘simplifying’ reporting.

Legal Entity Identifiers (LEI’s)

The use of Legal Entity Identifiers (LEIs) to identify parties to each transaction is mandated for derivatives reporting under EMIR. SFTR will no doubt expand the LEI system and – aside from completion levels and system changes to support LEIs across various trading models – the attribute remains fairly unchallenged.

Those respondents with a collateral or risk management background see the LEI as the key mapping field for ESMAs data scientists. Counterparty exposure, Settlement risk and certain other operational risk gaps are mostly visible at legal entity level and would therefore simplify implementation.

Unique Transaction Identifiers (UTI’s)

The matching of SFT’s at the trade repositories requires a Unique Trade Identifier (UTI) applied on a trade level to prevent double counting. This seems reasonable, however, from the outset this attribute has raised the most concerns from all respondent banks, associations, service providers and advisors.

EMIR stipulates that the UTI must be agreed with the other counterpart. Change managers involved in UTIs under EMIR know all too well what a challenge the UTI generation application and pairing can present. A regularly cited example is where mandatory fields have no underlying data, and therefore will not match a counterparty’s trade detail.


One of SFTR’s objectives is to increase transparency, by enabling the identification of related transactions and ensuring data quality, so that authorities can engage in richer market analysis. To complete this, set target SFTR reports are to be linked and the UTI’s should extend into the cleared world to identify lifecycle events according to ESMA’s assessment. In other words the bilateral UTI matures upon novation and several new UTI’s are required for each leg, leading to ‘multiple UTI legs’.

Counterparties may find themselves creating at least three UTI’s for house transactions, and five UTI’s for client cleared transactions, against what is essentially a single Repo or Loan. This will constrain novation of securities finance transactions to clearing.

Other suggested options (such as LEIs) to tackle transparency concerns at a different level in the reporting structure seem much more appropriate, and are also able to reduce the (much commented on) implementation costs and data inaccuracies.

In conclusion…

As highlighted at the outset, we expect further review of the draft SFTR given the concerns from many market respondents, and we believe there is an opportunity to heed the lessons learned from EMIR, in order to create the desired outcome for regulators and market participants alike. We have yet to see if the bar can be raised so high that it is easier to walk under it!

[1] In traditional Repo and SBL infrastructures, it is not uncommon to find up to eight haircut fields related to SFTs
[2] Extract from the SFTR paper: “The identification of branches is important both in the case of EU counterparties and non-EU counterparties. It is worth mentioning that the identification of non-EU branches of EU entities is only relevant for the global aggregation by the FSB, whilst the identification of the EU branches of non-EU counterparties is relevant for the three aspects listed under paragraph 190”
[i] As highlighted by ECSDA in a response to the consultation paper