SFTR – The regulatory reporting net is about to be cast a whole lot wider

The European Union (EU) Securities Financing Transaction Regulation (SFTR) is part of Europe’s continuing clampdown on potential risks in the banking & financial services sectors.  Scheduled for introduction in Q3 2019, it requires firms to report details of their Securities Financing Transactions (SFT’s) to trade repositories. This includes a range of instruments including; Repos, Securities and Commodities Lending, Buy/Sell Backs, Margin Lending and Total Return Swaps. 

In terms of transaction reporting, the proposed regulation is similar to that of EMIR. Its regulatory reach is however very different as it covers all SFT’s conducted anywhere in the world for organisations based in the EEA. It will have much greater business and logistical ramifications. To be clear, if a firm is headquartered in the EEA then it needs to report all eligible trades, wherever they occur. So, for example, a Spanish bank will need to report a repo trade between its office in Singapore and a customer in New York. 

Like EMIR, SFTR is dual-sided and requires a common Unique Transaction Identifier (UTI) for each trade, and a Legal Entity Identifier (LEI) for the counterparties of the trade. Delegated reporting is also permitted.  

The phased implementation timeline is shown below: 

Other Challenges 

Additional Data Overheads 

EMIR requires data in 129 fields from three categories to be collected: counterparty data, collateral data and common data. Under SFTR, the 18 counterparty fields are similar to EMIR, however, SFTR requires fields across three other categories: margin data (20 fields), transaction collateral data (99 fields) and collateral re-use data (16 fields). Adding up to a grand total of minimum of 158 fields! 

Intra- and Inter-TR Reconciliation 

Despite significant problems experienced with EMIR, ESMA have still chosen to rely on the trade repositories’ ability to match SFT’s. The difficulty is exacerbated by the number of fields required to be matched: in phase 1 a mere 62 but extending in phase 2 to a total of 96, mostly without any tolerance! Some of these fields (e.g. Booking Time or Netted Trades) are likely to be populated differently by counterparties. 

In anticipation of the matching difficulties ESMA has specified that matured trades which remain unreconciled for a month after the last submission will simply be dropped from the reconciliation process. This is different to EMIR where trades cannot be ignored and are included until they are fully reconciled.  

Unique Transaction Reference (UTI) 

As per EMIR both counterparties must report trades using the same UTI. Who generates the UTI also follows similar rules to the hierarchy under EMIR. SFTR is more complex however due to the different types of asset classes involved. For example, for a repo the collateral taker generates the UTI whereas for securities lending it should be created by the collateral provider.  CCP’s potentially will make life easier by being the source for the UTI but this could be a problem in phase 1 as CCP’s are not subject to SFTR until phase 2. 

One up-side of SFTR/EMIR & MiFID II is that UTI’s are now becoming ubiquitous providing a single common reference point for trades across instruments. Hopefully meaning that the cacophony of different contract and trade ID formats can be phased out. 

Collateral Re-use 

Some lessons have been learnt from EMIR. ESMA have acknowledged the challenges faced by market participants around the reporting of non-cash collateral; this now has to be submitted on Value Date + 1.  This makes it easier to accurately report this critical piece of information although it will require to be carefully managed as the underlying transaction still needs to be reported on T+1. In turn, the re-use of collateral could lead to a complex chain whereby the same piece of collateral is reported multiple times with a failure of one contract leading to a number of interconnected collateral defaults.   

Closing thoughts 

Ultimately, successful SFTR compliance, like previous regulations, will primarily be dependent on timely and accurate collation of data. The combination of collateral re-use, managing margin and counterparty data would most naturally be driven out of a single, technologically advanced treasury and trading solution which maintains agreements, collateral, trade and positional exposures in real-time. Alternative approaches, adopted for EMIR and MiFIR transaction reporting, of utilising simple bolt-on reporting and reconciliation packages will struggle to keep track of the correct and timely allocation of collateral at the trade and contract levels. Either a number of checks and processes will need to be duplicated or else a new post-reporting adjustment process will need to be carried out on a daily basis.  

Finally, if the proposal for global coverage is implemented then this process could necessitate a whole new dimension of intra-company and inter-continental communications.