STEFAN JELLINEK

As 2020 approaches so does the implementation of the transactional reporting phase of Securities Financing Transactions Regulation (SFTR); another element in the myriad of regulation imposed by the European Commission following the 2008 financial crisis.

SFTs refers to transactions where securities are used to borrow (where holding a long position) or lend cash (where holding a short position). As is often the purpose behind said regulation, SFTR looks to enhance transparency across the SFT market and improve investor protection. Ironically, it appears the need for SFTR has been in part a consequence of previous regulation (Basel III). The impact of this predecessor was to effect higher liquidity and capital standards reducing uncollateralised lending activity on the behalf of the banks. The result has been that this activity has moved into the realm of shadow banking (non-banking sector) with high involvement from buy-side institutions such as hedge funds. As a result, SFTR looks to hold both buy-side and sell-side individually accountable to report their activity.

Phase 3 of transactional reporting under SFTR brings buy-side organisations into scope in October 2020, however this article suggests the challenges presented by the enormity and character of required data reporting suggest targeting go-live for 1st October will be too late.

Immaturity of the SFT Market and Systems

In highlighting the difficulty of SFTR much comparison is drawn to its predecessors such as EMIR, a regulation that was very challenging for the industry. Attention must be drawn to the difference in the maturity of the SFT market compared to the derivatives market in 2014 (when EMIR was implemented). Considering the difficulty faced in the early stages of reporting under EMIR, within a far more centralised and developed derivates market, the challenge of replicating such within the SFT space is even greater.

Relevant data is fragmented across multiple systems. Collateral management systems tend to exist separate to SFT systems, which themselves may be further fragmented under different products (e.g. Repos or Securities Lending). This fragmentation only accounts for the assumed internal system of the bank trading with the relevant buy-side firm from whom they will have to request data.

A lack of accountability in the SFT space has led to lack of incentive to centralise relevant data which is now a requirement of SFTR which requests up to 155 data fields. Difficulties are further compounded by the specific events which occur within these systems which ESMA have stipulated for reporting.[1] Fixes will need to occur within relevant systems to flag such events for inclusion in the prescribed ISO 20022 format to fulfil the SFTR requirement to report all lifecycle events.

Further, practice discrepancies are characteristic of the SFT trading space. Where one firm will book a trade as a repo, its counterpart may book such as a buy-sell back. Previously this was not a matter of contention due to the result being the same and current contract affirmation including only basic trade economics. However, SFTR demands absolute uniformity between counterparts on dual-reportable fields or else face penalties. This also extends to trade lifecycle events (all must be reported[2]), under which again there is room for variances. The outcome will be the creation of mismatching Unique Trade Identifier’s (UTI) from each party, resulting in sanctionable breaks. This lack of standardisation requires buy-side firms to engage with their counterparts ahead of time to ensure that their practices are aligned and UTI generation and sharing is uniform.

There is also a significant degree of manual processing within the SFT space. The result of such is two-fold. Manual processing will be too slow to keep up with the necessary T+1 reporting timeframe suggesting firms need to be looking to automated solutions to address this. Manual processing also carries an inherent level of human error, especially considering the quantity of data fields, for which there is little tolerance under SFTR.

155 Data Fields

SFTR demands up to 155 data fields (dependent on the product, action type and trade type, e.g. floating rate vs. fixed rate loan) to be completed in the prescribed ISO 20022 format. This figure is then compounded multiple times as several reports (each requiring up to 155 data fields) must be completed for every trade lifecycle event meaning a single trade or lifecycle event may require at least roughly 800 data fields to be completed by T+1. By comparison EMIR required only up to 129 data fields illustrating the challenge posed simply by the sheer amount of data required. Effective reporting of such will require strong auditing capabilities and the ability to map clear data lineage across the life of trades. This combined with the requirement that records must be kept for a minimum of 5 years poses a significant challenge to the buy-side which has never had such stringent standards placed on it to date.

It is expected that the typical firm will have difficulty sourcing up to 40% of the relevant data (especially with regards to collateral re-use, where there may be extensive rehypothecation requiring the same collateral to be reported multiple times). Considering the fragmented landscape of the SFT world this is hardly surprising. Many relevant data fields may be unfamiliar to buy-side firms, which they will be required to both efficiently source and store.
However, difficulty may begin with far more rudimentary data points. Namely the Legal Entity Identifier (LEI) and the UTI (outreach by JDX to Tier 1 banks has identified that they believe sourcing these two data points will be a major challenge). These in turn require a revisiting of the relevant Counterparty’s reference and static data which may need to be amended. This is necessary as relevant data fields in the reports referenced above will differ dependent on the entity type (e.g. Dealer vs. Hedge Fund).  

As earlier mentioned, current contract affirmation focuses only on basic trade economics.  Combining this fact with the knowledge that a significant amount of buy-side trades are structured within aggregated portfolios by their Agent or Counterpart this poses a significant issue exemplified below:

Example 1:

Scenario:

A group of SFT’s are traded between Entity A (Buy-side) and Entity B (Sell-side) effective on 1st January 2020 reaching maturity on 1st December 2020. Per industry standard these are grouped into an aggregated portfolio and have only the basic cumulative economics provided by Entity B to Entity A.

Requirement:

Entity A must account for all the relevant data points per each individual SFT making up the portfolio. As the trades are in scope (have a maturity post 1st October 2020) they must allocate necessary time to source all relevant data for each individual trade making up the portfolio prior to the start of Phase 3 (1st Oct 2020).

Challenges the Buy-Side Firm will face:

  1. There will be a multitude of data points to report likely numbering at a minimum in the thousands.
    Entity A must first source the correct UTIs for each individual trade. This is the initial data field required to support the effective reconciliation required under the double-sided reporting feature of SFTR. Prior to SFTR buy-side firms would not collect such granular data so time must be afforded to develop this process as it will not be readily available for reporting.
    Difficulties may arise due to the booking of trade lifecycle events in different fashions (e.g. rebooking vs. rolling a trade). These events, though effecting the same end, will create different UTIs which will cause a break when reconciled by the relevant Trade Repository.
  2. If the trade is an allocation.
    Entity B may wish to split the value of the trade across its sub-entities. The trade then becomes an allocation, meaning certain percentages of the portfolio are split between its legal subsidiaries (Entity B, C and D).
    Entity A must report data points to represent Entities B, C and D which will each have their own unique LEI and UTI which must be reported accordingly. This will be a complex and time-consuming process for which Entity A will need greater than T+1 to complete initially.

Hence investigation and preparation for such must begin now before the buy-side come into scope (whether the trade is frontloaded or not).

T+1 Reporting

SFTR demands all relevant data for a trade be submitted within T+1 for transactions and collateral known at the point of trade to the relevant TR. Combined with the sheer scale of data required this presents a mammoth task for which an existing solution (pre-October 2020) is essential.

Past the obvious time pressure associated with this time frame there is a further difficulty presented by the unique specifics of SFTR. Unlike EMIR and MiFiD, SFTR’s reach extends outside of the EU to affect the branches of firms whose parent is based in the EU. This may result in significant difficulties being placed on subsidiaries of EU buy-side firms who wish to trade SFT’s with lending agents existing outside the EU.

For example, if the Singaporean subsidiary of an EU based Asset Manager attempts to trade with a US Lending Agency they may struggle to report within T+1. These markets are active at different times and the US entity is under no regulatory pressure to report within T+1. This suggests that buy-side firms will need to find an automated solution to circumvent the time difference or reconsider their strategy within the SFT space entirely, both of which require significant planning.

No tolerance for breaks

SFTR demands 2-way reporting meaning both parties must report all terms to the trade from their perspective. These submissions are then analysed by the relevant TR to ensure consistency. Any inconsistency will then be documented as part of a reconciliation ratio passed on to regulators.

Considering the challenges set out above it can be assumed that with the current state of capabilities on the part of the buy-side they will likely fall victim to reconciliation breaks. The sell-side are also not exempt of this criticism as ‘the sell side don’t always get reporting right for their buy-side clients under the existing EMIR regime’[3] which is a less demanding regulation.

Regulators will utilise reconciliation ratios produced by TRs to assess which entities are not reporting correctly applying further scrutiny to them. This will likely result in penalties against the offending buy-side entity causing a cost in the immediate term. Repeated reconciliation problems may also result in long term reputational damage as other entities choose to avoid transacting with repeat offenders due to associated scrutiny. It is predicted this will likely occur due to differences in UTI’s submitted by involved parties due to practice discrepancies referred to earlier.

If entities can ensure that they use the same UTI it can be assumed to some degree that the associated data points will likely be identical avoiding a break. Therefore, by creating a pre-reporting solution to exist between relevant counterparts to check UTI’s match at first instance will greatly reduce the possibility of breaks occurring.

Conclusion

Buy-side firms need to be engaging in the process of reporting before October 2020. The range of challenges that derive from the transition from an absence of regulatory data requirements to the most burdensome data requirements seen post-2008 require buy-side firms to put controls in place long before they come into scope.

There are multiple externally provided solutions such as the counterpart providing reporting data on behalf of the relevant entity. However, responsibility for breaks remains with the entity in question and not the entity they deferred responsibility to. Considering known breaks by sell-side firms on behalf of their clients with regards to EMIR[4] it is fair to say this option may not be so attractive.
Alternatively, there are market vendors offering varied services to assist with the challenges raised. However, there aren’t many, so the question must be asked as to whether they will have a limited capacity between them resulting in the biggest and best clients being onboarded as priority? Once again pre-emptive action appears the only response to this possibility.

With all this in mind it may well be that many firms choose to exit the SFT market as the costs associated will simply be too much to manage. Whatever the decision, it is clear firms need to choose a path and onboard its relevant solutions as soon as possible or else face the scrutiny of the regulators.

[1] https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32019R0356&from=EN

[2] ibid

[3] ‘SFTR reporting for the buy side – don’t expect the sell-side to save you’ – Bovill (https://www.bovill.com/sftr-reporting-for-the-buy-side-dont-expect-the-sell-side-to-save-you/)

[4] Ibid

Bibliography

For more information, you can contact Stefan at [email protected]

Share this:

Share on linkedin
Share on twitter
Share on facebook

Related

JDX Establishes a Go Green Society

MONIKA MESKAUSKAITE Breaking the Plastic Habit is a programme which aims to eliminate single-use plastics from stores and businesses at Canary Wharf via new technology,

Posted in Blog, Diversity & Inclusion, Events, News | Comments Off on JDX Establishes a Go Green Society

JDX to support British Schoolgirls Skiing Races 2020

The British Schoolgirl Races, which are organised by the Ladies Ski Club, first took place on the slopes of Gstaad in 1959, moving to Villars in 1976. 

Posted in Events, News, PR | Tagged , , , | Comments Off on JDX to support British Schoolgirls Skiing Races 2020

Why Letting Data Go Matters to Customers and Companies

MARKUS BUHMANN We hear a lot of talk about how, why and when organisations collect data from individuals.

Posted in Technology, Thought Leadership | Comments Off on Why Letting Data Go Matters to Customers and Companies

It’s an attitude.

Have you got what it takes to join the JDX team?


Discover more.