By Silvano Stagni, co-chair of the FIX Trading Community SFTR Working Group and director of Perpetual Motion Consulting and Research (PMCR)

There is more to SFTR (Securities Financing Transaction Regulation) than one report, owner’s consent and changes to prospectuses and investors reports for UCITS and AI Funds.                      

SFTR technical standards for reporting to SFT (Security Financing Transaction) Repositories are very prescriptive; the format of data-fields is mandated, and reporting needs to follow ISO 20022.

Reporting can be delegated, in some cases, it must be delegated to the other (larger) counterparty. Even if you delegate reporting, you must provide certain data to the reporting entity, and the liability for data accuracy is not ‘delegated’ but stays with the delegating party. The same applies if you outsource the reporting or use a utility or an ARM (Approved Reporting Mechanism) to report.

SFTR also has an impact outside Europe because (a) third country branches of European entities need to report and (b) even if you do not need to report yourself the European counterparty must report and therefore, they need the relevant information.

Data issues represent the “land mines” in the path towards SFTR implementation. Some data rules affect your operation. For instance, SFTR requires only one ISIN per reported Security Lending transaction; an agreement to borrow shares from several FTSE 100 companies needs to be broken down into one separate transaction for each ISIN code.

SFTR rules can also affect how you source securities. For instance, if securities needed to cover a short sale are acquired through a Reverse Repo, the use of those certificates to settle a short sale is considered ‘collateral re-use' and must be reported to SFT repository.  If you borrow them, they are not considered collateral and therefore their use does not constitute ‘collateral re-use'.

The information that must be reported to SFT repositories are also required by other systems supporting different business process; systems that may structure that information in a different way or follow different rules. You need a strategy to reconcile these differences, you may also need protocols to transfer information from one system to another.

SFTR uses LEI to identify entities and ISIN and CFI codes to identify financial instruments. Do you have them? ISIN and CFI should not be a problem because you are unlikely to involve new instruments in a SFT, the LEI could be an issue especially when neither party have a business relationship with the entities that is being identified (for instance the issuer of the borrowed security.

Reporting to SFT repositories comes at the end of a transaction workflow, the vast majority of the data fields to report represent information that comes into the organisation during earlier stages (of the workflow). Reconciling the data requirements of the final step in the process with those of the steps that come before it will force changes to your data landscape. Whatever solution you use to implement SFTR you need to make sure that you manage those changes.