SFTR – A Look at the Data Management Issues – Part 2 Required Data
On 22nd March 2019, the EU published the SFTR implementing regulation in the Official Journal of the European Union. Publication confirms the start-dates of transaction reporting for investment and non-financial companies. Data managers have a number of technical hurdles to surmount, so adequate planning is crucial. In the second of a series of SFTR Blogs, we highlight the main data management issues associated with the ‘what’ and ‘when’ of SFTR reporting.
If data managers have noticed a resemblance between EMIR and SFTR reporting, the resemblance is entirely intentional. ESMA sees SFTR as an extension of EMIR, widening the scope of its visibility over systemic risk. By way of compensation, ESMA does intend to learn from its EMIR experience and implement improvements. Hopefully, so will the data managers of liable companies.
Fortunately for some data managers, small NFCs (1) are not required to report. However, this is a double-edged sword because :
- Even if you are not in scope of SFTR, you may be asked for data from your counterparties who are, e.g. for beneficiary information and LEIs, so you will still need to be able to provide some SFTR data, and
- If you are the data manager of a larger firm with small NFC customers, you must report both sides of the transaction on their behalf.
In this Blog, we’ll take a look at some of the SFTR ‘Whats’ and ‘Whens’.
Reporting ’What’ and ‘When’ – key data management issues
The SFTR captures four product groups :
- Buy Sell Backs (BSB)
- Securities and Commodities Lending (SL)
- Margin Lending (ML)
Repos, BSBs, and SLs must be reported at transaction level on a T+1 timeline. ML activity must be reported at end-of-day on a position basis, unless it can be identified at the trade level, in which case it must be reported with the transaction (T+1). Margin posted at a CCP is reported separately. Collateral re-use is also reported separately, with availability included in the transaction report, and actual re-use reported separately, calculated at a portfolio level using the ESMA RTS calculation. Where collateral is not known at the point of trade, it is reported on an S+1 basis.
Cleared trades submitted to a CCP must be reported using the UTI generated by the CCP. Non-cleared trades may be reported using a UTI agreed between the counterparties, but if it is subsequently passed to a CCP for clearing, it must be re-reported using the CCP-generated UTI. There will also need to be an audit trail to trace back to the original counterparty-generated UTI.
Like EMIR, SFTR requires reporting of all life-cycle events that affect any of the data fields.
Data managers need to be aware that there are common ambiguities and inconsistencies in the use of these product groups – one company’s BSB may be another’s Repo. Others may store more than one product group in the same system, but then fail to maintain the SFTR differentiation between them.
Lastly, market participants must report the agreement governing each trade and the agreement version or year. New transactions must be assigned to the applicable agreement version, but then old transactions must retain the agreement reference that applied to them at the time of execution.
Field-count – comparison with EMIR
EMIR requires reporting of up to 129 fields. SFTR requires up to 155 data fields, grouped in four Tables (2) :
- Table 1 – Counterparty data (18 fields)
- Table 2 – Loan & Collateral data (99 fields)
- Table 3 – Margin data (20 fields)
- Table 4 – Re-use, cash reinvestment and funding sources data (18 fields)
Not all data attributes are needed for all reports, but then some fields repeat multiple times depending upon the data granularity of the underlying transaction. Like EMIR, some fields are mandatory, some conditional and some optional; others are specific to commodities. As has been stated elsewhere, energy and commodity companies are NOT exempt from SFTR if they are active in any of the four product groups.
Data sourcing – avoid the risk of data silos and multiple partial solutions
Data managers will need to establish the exact location within their company of all the SF trading in the various product groups. The bigger market participants may trade all four, and often locate trading across many subsidiaries and business lines, acting as both agent and principal. This gives rise to the real risk of fragmented solutions, and data-silos, and cost-duplication if each business unit addresses its SFTR problem in isolation.
If multiple business units are involved, it becomes vital to establish the scope of your SFTR solution project as early as possible. A senior management decision will need to be made at the outset about whether to start a centralised, cross-unit SFTR programme, sharing core data wherever possible, and ensuring consistency in their meaning and interpretation. We would strongly recommend a centralised data management approach for the larger companies with SFT activity spread across multiple product groups and business units.
TR Reconciliation – expect a rapid shift in ESMA focus to matching rates
96 of the fields reported under SFTR are subject to trade-level reconciliation by the TRs, assuming both trade counterparties are themselves in scope for reporting. Your TR will report back to you any mismatches, and it will be your responsibility to rectify the breaks. Furthermore, there are very limited tolerances on the fields to be reconciled. Given EMIR, this should not be too big a surprise.
As in EMIR, we expect that after a bedding-in period, ESMA will turn its attention from simply receiving reports (of any quality), to achieving high standards of data quality and TR matching rates. However, as ESMA is expecting itself and all market participants to learn from EMIR, we expect this bedding-in period to be very much shorter. We don’t think that reporting will go haywire from go-live, and if it did, ESMA would ask some very probing questions of all concerned.
That presents data managers with a bit of a dilemma – do they prepare for just fixing the biggest mismatches, i.e. those materially affecting exposure calculations, or take a more optimistic view of day one and be ready to cover everything? We anticipate that data managers will want to adopt rigorous data quality control mechanisms to minimise the risk of mismatches of any size.
Increased business process and process-flow digitisation?
Traditionally, the business processes underpinning securities financing have been largely manual, focusing mainly on transaction settlement between counterparties rather than reporting to an external agency. We believe that SFTR will make it harder for market participants to manage any data that has been generated manually as opposed to electronically. We expect to see a much greater take-up of electronic trading in, and electronic confirmation matching of, SF transactions.
We’ll return to some of these issues in our next SFTR Blog.
- As defined in Article 3(3) of Directive 2013/34/EU of the European Parliament and of the Council.
- ANNEX to the COMMISSION DELEGATED REGULATION (EU) supplementing Regulation (EU) 2015/2365 of the European Parliament and of the Council with regard to regulatory technical standards specifying the details of securities financing transactions (SFTs) to be reported to trade repositories. Brussels, 13.12.2018 C(2018) 8334 final
For more information on how deltaconX can advise you on the data management issues of reporting, trading and confirmation under SFTR, please contact our Compliance Help Desk.