Known Issues

Execution Timestamp Tolerance

Status: For Review, Last Updated: 15/02/2023

Question:
Validation Field(s) in scope – 2.12

Counterparts to a transaction may, for legitimate business reason, generate different timestamps when reporting SFTs.

•Counterparties use booking times as a proxy for execution times may result in differences related to deal capture procedures. This leads to timestamp differences exceeding the current 1-hour tolerance.

•Where booking of a transaction is not automated, or where confirmation of transaction is delayed for various reasons, firms will generate individual booking times which may result in mismatching data.

•We note that actual booking times may provide extra insight to supervisory bodies reviewing SFTR data.

•Market participants concluded that the current one-hour tolerance causes unnecessary reconciliation breaks.

Best Practice:
ISLA members agree that increasing the currently mandated tolerance will reduce matching breaks and proportion of resource required to align those timestamps. Their proposal is therefore:

•To increase the timestamp tolerance to at three (3) or more hours which would significantly reduce reconciliation breaks while still providing regulators with useful insight into trading party practices.

•This proposal would not contradict the spirit of the regulation and would provide additional insight for supervisory bodies. (SFTR-452)

Returns Reporting

Status: For Review, Last Updated: 31/08/2023

Question:
Validation field(s) in scope – 3.00

ISLA best practice was drafted to create a market aligned consensus on approach. It should be recognised that Securities Lending transactions differ in some respects to other financial markets. Specifically, economic exposure begins prior to settlement of the loan (collateralisation), and this exposure may continue after an agreed termination date. Exposure continues until both loan and collateral are terminated and returned to the respective parties. To adhere to the spirit of the regulation, ISLA member firm’s preference is to report data that best reflects any relevant exposure(s). 

 As it relates to this field, ISLA members therefore agreed to report: 

•New Trades = Reported on contractual basis (i.e., by trade date +1)

•Returns = Reported on an actual basis (i.e., actual settlement date +1)

•Modifications = Reported on actual basis (i.e. effective date +1).

However, the Level 3 guidance published on 6^th^ January 2020 contradicted proposed best practice which has resulted in misrepresented exposure reporting and increased the  number of breaks^1^:

•Partial Returns = Reported on a contractual rather than actual basis, regardless of settlement failure.

•Future dated Full Returns = Reported on a contractually on event date+1 by sending a MODI to add a ‘Maturity date’ and mark the trade as fixed term

•Same day Full Returns = Reported on an actual basis (i.e., actual settlement date + 1) by sending an ETRM

Marking an open trade as fixed term maturity may:

•Contradict legal and regulatory requirements of some lending funds (e.g. UCITS)

•Not be physically possible within agent lending programmes that represent multiple lenders in single external loans

Agent lenders, representing >60% Securities Lending market activity, cannot meet this requirement without significant long-term development.

Best Practice:
ISLA members propose that:

•All Securities Lending lifecycle events should be reported on an actual basis (rather than contractual) which will represent the most accurate reflection of activity and counterparty exposure, and closely underpin the spirit of the regulation.

•Recognising the scope & limitations that exist outside the formal review process, ISLA propose that either a Q&A response or email be sent to clarify that it is acceptable industry practice to report loan closing events on the day settlement occurs, rather than a forward contractual date, which require complex systemic mappings. Similarly that partial returns be reportable on an actual rather than contractual basis. We believe this will provide supervisors with an accurate and the clearest possible view on exposures in our market, in keeping with the spirit of SFTR. ISLA members, in the Agent Lenders white paper, are seeking clarification that reporting returns on an actual settlement basis is acceptable, and that this will be considered as part of the SFTR review in 2022. (SFTR-337)

Limitations of Value Date of the Collateral in identifying netting set loans

Status: For Review, Last Updated: 31/08/2023

Question:
Current validation rules for net exposure collateral use “Value Date” (2.13) of the loan and “Value Date of the Collateral” (2.74) to identify which loans fall within the net exposure netting-set.  However, this is too simplistic and does not take into account the different pre-pay collateralisation processes used in exposure management.

Within the loan books linked to net exposure collateral, individual positions may be collateralised on a value date (VD) or a VD -1 basis.  VD-1 is generally chosen where there is a disparity between the settlement market of the loan and that of the collateral (or indeed where the collateral is managed). 

For example, US Treasury collateral would need to be collected today in order for a Japanese loan to settle in APAC trading hours tomorrow.  However, the challenge is that the loan book between “Reporting Counterparty” (1.3) and “Other Counterparty” (1.11) often comprises assets settling in multiple locations and time-zones and will be split between VD and VD-1 collateral requirements, while the “Value Date of the Collateral” is a fixed value which must state the “latest value date contained in the netting set of SFTs….”.  This means that if even a single loan attracts collateral on a SD-1 basis, every loan sharing that value date is captured in that netting set on SD-1.

Example where Event Date = 03/10/22:

Loan 1:    10,000  Siemens  DE0007236101  €1,000,000   v/d 04/10/22  Collateral Date 04/10/22

Loan 2:  100,000  Vinci FR0000125486 € 8,200,000           v/d 04/10/22  Collateral Date 04/10/22

Loan 3:      1,000  Tokyo Electron JP3571400005 € 320,000  v/d 04/10/22   Collateral Date 03/10/22

In this example all three loans share the same value date (04/10/22), however only Loan 3 needs to be collateralised on 03/10/22 (VD-1).  On Event Date 03/10/22, the COLU report for this netting set would therefore be required to quote “04/10/22” as this is the “latest value date, suggesting enough collateral be collected to cover all three loans (€9,520,000). However, in reality the counterparty / agent would only collect €320,000 on 03/10/22 with the remainder collected prior to release of the loans on 04/10/22. This can create a massive disparity in what the COLU shows compared to what is expected

Best Practice:
The current validation rules use a single “Value Date of the Collateral” (2.74) field in the COLU report, to define which loans fall into scope of the netting set.

ISLA would like to propose that “Value Date of the Collateral” is added to the NEWT report so that it is the loan itself that defines the date of its inclusion into the netting set. This would remove any ambiguity and inaccuracy caused by the current netting logic. (SFTR-812)

Trading Venue allocations booked under a non-disclosed Agent Lender model

Status: For Review, Last Updated: 28/06/2022

Question:
Validation field(s) in scope – 2.08

In July 2020 ISLA consulted with ESMA regarding a set of questions intended to create further clarity on the subject of: “Whether allocations booked under a non-disclosed Agent Lender model should ever be reported as concluded on a Trading Venue in Field 2.08”.

In response to the consultation letter ESMA requested further information and clarity on those questions. Please see Annex#4 Correspondence regarding Trading Venue.

This issue relates to pooled transactions entered into by an agent lender on a trading platform and therefore the population of the Trading Venue field.

Using the example below, the trade of 100 shares on the Trading Venue is not reported under SFTR, but rather the allocations (50,20,30).  When reporting those three trades, some of our members populate the Trade Venue with “XXXX” as those child trades could be considered as not traded but rather allocated after the trade initiation. This is particularly true when substitutions occur after the initial pool trade.

Best Practice:
ISLA members propose that:

•ESMA can confirm that trades entered into by an agent lender, where the ultimate lender is not disclosed at point of initial trade, be reported as “XXXX” in place of a Trading Venue MIC code in field 2.08. (SFTR-813)

Insufficient Granularity Within Primary Key For Collateral

Status: For Review, Last Updated: 31/08/2023

Question:
Validation field(s) in scope – 1.03, 1.11 & 2.09

The current Primary Key for Net Exposure Collateral is insufficient for Trade Repositories to distinguish between netting sets where the “Reporting Counterparty” (1.3), “Other Counterparty” (1.11) and “Master Agreement Type” (2.9) are the same.  This regularly leads to the first netting set submissions being overwritten by subsequent submissions, due to “latest is greatest” treatment of Collateral Updates (COLU). 

Netting sets may be unique in a number of ways, all of which need to be considered when ingesting the COLU report 

•”Triparty Agent” (1.14) - Lenders and Agent Lenders employ a number of Triparty Agents in the collateralisation of their loan books.  If the Lender uses one Triparty Agent to manage their equity collateral (HPFHU0OQ28E4N0NFVK49) and a different one to manage Bond collateral (549300OZ46BRLZ8Y6F65), the use of both between the same Reporting Counterparty, Other Counterparty and Master Agreement will create two netting sets.  When reported to the Trade Repository, the later of the two submissions will automatically overwrite the earlier one and the data for the initial netting set will be lost in the Trade State Report.

•Agent Lender (1.18) - Some Lenders employ more than one Agent Lender to manage different assets within their portfolios.  Those Agent Lenders are likely to transact with the same borrowers and under the same Lending Master Agreement Type (GMSLA).  Where both Agent Lenders report COLU reports, the Reporting Counterparty, Other Counterparty and Master Agreement Type will therefore be identical.  Again, the Agent Lender that submits their COLU report last will be treated by the Trade Repository as the latest update, with the earlier report being overwritten.

•“Branch of Reporting Counterparty” (1.7) and “Branch of Other Counterparty” (1.8) – Where entities operate out of different branches, this can also create separate COLU netting sets.  Where those branches do not have their own LEI and only identify themselves with an ISO Country code for reporting purposes, the current primary key at the Trade Repository cannot differentiate between them.  Again, the latest reported COLU will overwrite any earlier one, causing data to be lost from the Trade State Report.”

Best Practice:
ISLA members propose that:

Key reporting fields require additional and explicit Counterparty data fields so that Trade Repositories might distinguish and identify the reports uniquely and accurately.

Members have identified five (5) additional reporting fields and have proposed three (3) options to facilitate the above proposal: (SFTR-451)

Pricing Mismatches due to Tolerance

Status: For Review, Last Updated: 31/08/2023

Question:
Validation Field(s) in scope – 2.49, 2.56 & 2.57

There is no tolerance on Fields 2.49 (Security and Commodity price) and 2.56 (Loan Value) and Field 2.57 (Market Value) has an extremely strict tolerance of 0.000005. Matching dates for these fields commence on 1^st^ of January 2023.

ISLA members note two major concerns regarding these matching fields:

•The Level 3 guidance will cause large amounts of breaks when reconciliation on these fields begins on 1st January 2023 where ‘Loan value’ (2.56) and Loan ‘Market Value’ (2.57) are reconciled by the TRs.

•The Level 3 guidance to use ECB FX rates for SFTR reporting was unexpected by the industry and still challenging for firms to implement even after SFTR went live.

•A concern is raised that forcing price convergence in regulatory reporting may by incorrectly representing the  books and records of a reporting party. It is noted that centralised pricing was proposed and rejected during initial SFTR discussions.

Best Practice:
ISLA members proposed to have wider tolerances for the fields 2.49, 2.56 and 2.57 and suggested to bring up the tolerance levels at either of the four:

•0.025%

•0.050%

•0.075%

Or

•0.100% (SFTR-188)

Reporting of Loan and Collateral Data in CORRs

Status: For Review, Last Updated: 31/08/2023

Question:
Validation Field(s) in scope – 2.75

As per the Validation Rule, it was understood that the ESMA’s aim was to implement support for reporting CORR messages containing only loan data, collateral data, or both.

The industry supported the Regulator’s objective of reporting loans and collateral separately in CORR messages. However, the current validation rules (counterparty transaction) did not align with the ESMA’s objective.

It does align with the separate reporting of loan and collateral in NEWTs (when the collateral is not known until S+1) and separate COLUS.

However, to support the inclusion of collateral in CORRs, firms are required to store previously reported collateral and loan data and look this up to include in the CORR messages when a correction to loan or collateral data occurs. 

The above is a complicated logic to implement, and incurs a high cost from a data storage perspective. Therefore, market participants have adopted a mixture of approaches to overcome the issue however:

•Few member firms have managed to implement the logic.

•Other firms have opted to report MODIs and COLUs when corrections occur as an alternative (so loan and collateral data can be reported separately).

Best Practice:
ISLA members propose that:

The validation rules be revisited to facilitate separate loan and collateral data reporting in CORR messages.
(SFTR-438)

Type of Collateral Component and Collateral Basket Identifier issues with NEWT template reporting

Status: Backlog, Last Updated: 15/02/2023

Question:
Validation Field(s) in scope – 2.75 & 2.96

Due to the re-introduction of the validation rules on 2.75 and 2.96, securities lending participants have implemented a practical solution for the reporting of NEWTs related to Net Exposure SLEB transactions. 

As these SFTs are collateralised by a pool of collateral, 2.75 and the associated fields for collateral are not applicable, therefore 2.96 must be populated in order for the ‘NEWT’ to pass the validation.

The industry is now obliged to report Net Exposure (NE) SLEBs with 2.96 = ‘NTAV’, which creates misleading data in both fields. However, this is not a true reflection of the submitter's books and records.

Members also draw attention to

Article 3 para 4 of the Commission Delegated Regulation 2019/356 starting “"A counterparty collateralising several SFTs on a net exposure basis..” which highlights a misalignment with current validations

Best Practice:
ISLA members propose that:

The current validation rules be revisited and corrected to allow securities lending participants to report fields 2.75 and 2.96 accurately when the true conditions are met and thereby reflect activity correctly.

Pending any review, the proposed best practice3 is presented in below logical approach: (SFTR-811)

T vs T+1 Reconciliations Issues

Status: For Review, Last Updated: 31/08/2023

Question:
Validation field(s) in scope – 1.01

Securities Lending participants rely on a variety of underlying platforms to maintain their SFTR activities. These many platforms present a significant diversity in processing abilities and mechanisms and, as it relates to SFTR reporting obligations, the timing of necessary output. As a result, TR submissions may arrive either on T+0 or T+1.  This creates a challenge regarding reconciliation of SFTR data within Trade Repository network.

From a practical perspective, changes to an entire operating model represent a significant development and therefore an ongoing challenge.

Best Practice:
ISLA members propose that:

•A cost-benefit analysis be undertaken to mandate the reporting of the trade activity to either T+0 or T+1. This guidance, to either of the two options will trigger the necessary development in technical reporting architecture. However, either option will undoubtedly incur high development costs.

•A second more pragmatic approach would be the inclusion of Event-Date of SFTs in the reconciliation output so that the reporting firms and TRs can easily prioritise the breaks to be investigated. This second option provides both the practical and pragmatic resolution to reconciliation breaks. (SFTR-448)

Post Maturity Date Reconciliations Issue

Status: For Review, Last Updated: 31/08/2023

Question:
Validation field(s) in scope – 2.14

The RTS for Trade Repositories mandates that unreconciled SFTR reports should be visible on the daily Trade State Report for 30 days following the maturity or termination of that report.

ISLA members raised concerns that:

•The current validation rules do not allow participants to submit a modification to a report, where the Event Date of the report is greater than the maturity or termination date.

•The result of this, is that participants are unable to fix unreconciled reports during this 30-day period.

•In addition, in scenarios where a settled return becomes unsettled again, participants are unable to 'resurrect' the corresponding report.

This is an acute issue for most of ISLA members, including Agent Lenders, where firms are unable to fulfil the regulatory obligation to match and reconcile reporting with respective counterparties.

Where it relates to Agent lenders, the reporting process is complex due to:

•The unreconciled reports, following maturity or termination, severely impact the Agency lender's reporting  (shell vs allocations) to the borrowers due to the mandatory pre-matching conditions for key pairing fields and, therefore, further impacts the timeliness and accuracy of reporting allocations under SFTR.

•The reconciliation on the matching platform can only occur with the latest event records received from the agent lenders, which cannot be reconciled on the historical event if not reported or incorrectly reported.

Best Practice:
ISLA members propose several approaches as potential solutions to this challenge:

Long-term solution:

The solution to several reconciliation and pairing issues should be addressed through an amendment to SFTR reporting rules which would require changes in Level 1 (primary) legislation.

Such as:

1. Change in the logic for updating the Trade State Report by TRs, that is:
•TRs to update the Trade State Report relying on the logical order derived from the “Event Date” without applying any restriction based on the “reporting timestamp”.

Or

2. Remove the existing limit of 30-day period and reconcile only Live SFT trades.

Or

3. Further widening the limit of 30 days period. (SFTR-210)

Reporting of the SFTs with EU central banks

Status: For Review, Last Updated: 31/08/2023

Question:
Validation field(s) in scope – 2.00

SFTs to which the counterparty is a member of the European System of Central Banks (ESCB), are only reportable under EU MiFIR and excluded from reporting under EU SFTR.

Best Practice:
ISLA members, and members of other associations, propose that there should be a complete exemption of reporting SFTs to ESCBs under EU MiFIR based on the following facts:

•SFTs with Central banks are not a source of systemic risk, nor are they directly price-forming or a source of market abuse and therefore are not relevant to MiFID/MiFIR transparency aims.

•The regulators can directly source data for SFTs with ESCB(s) from the respective central bank(s), thereby reducing the cost of reporting for market participants and also the cost of collection, processing and analysis.

•Our members note that the UK (FCA) excluded all central bank SFTs from being reported under UK MiFIR. (SFTR-166)

Misalignment in fields 2.18 & 2.20 impacting Method Used to Provide Collateral

Status: For Review, Last Updated: 31/08/2023

Question:
Validation field(s) in scope – 2.20

In comparison to field 2.18, it is mentioned in Validation rules that if the conditions do not meet, the field can be left blank. The absence of similar wordings for field 2.20 causes ambiguity where a trade is not collateralised.

Validation rules description of the field 2.20 states:

•“Indication whether the collateral is subject to a title transfer collateral arrangement, a securities finance collateral arrangement, or a securities finance with the right of use.”

•“Where more than one method was used to provide collateral, the primary collateral arrangement should be specified in this field.”

Validation rules description of the field 2.18 states:

•“If, for SL, field 2.73 is populated with 'true', or if field 2.72 is populated with 'false' and field 2.75 is populated with 'SECU', this field shall be populated. Otherwise it shall be left blank...”

Best Practice:
ISLA members propose that:
The existing validation rules be revisited to clarify if the wording “Otherwise, it shall be left blank” was purposefully not added under Conditional Validation for 2.20.

Clarification on this point will feed into industry practice, aligning firms reporting practices and reducing related reconciliation breaks. (SFTR-815)

General Collateral Indicator impacting Cash Collateral reporting

Status: For Review, Last Updated: 31/08/2023

Question:
Validation field(s) in scope – 2.18

In current ESMA guidelines, field 2.18 only applies to the securities provided as collateral with the validation rules requiring mandatory population of field (2.18) when the Net Exposure (Field 2.73) is “True” for SLEBs.

The validation rule causes a reporting issue where Cash is used as collateral.

ISLA members concluded that Field 2.18 can be populated with GENE or TTCA for securities used as collateral. However, for Cash collateral, the field should be populated with GENE to avoid data rejections.

Although this is not precisely a challenge, ISLA members concluded that as best practice and short-term solution, field 2.18 should be populated with ‘GENE’ where Cash collateral is used. This should be done to avoid data rejections.

The ISLA SFTR Best Practice on this point is currently “Validation rules (31 Jan 2022) require mandatory population, therefore regarding cash pool collateral a default value of 'GENE' should be used to avoid data rejection”.

Best Practice:
ISLA members propose the following short-term solution:

•Clarification on whether Field 2.18 “General Collateral Indicator” apply only to SECU6 collateral?
and
•Since the current Validation rules do not consider Net Exposure SLEBs against a cash pool, would there be a consideration for agreeing with current ISLA Best Practices5 that GENE can be populated where collateral type is Cash?

Long term solution:

•The current validation rules be revisited to have provisions for a "Blank" value or any other alternative value that could be populated in Field 2.18 for the cash pool’s Net Exposure collateral. (SFTR-816)

ESMA Q&A update on Reporting of settlement fails under SFTR

Status: For Review, Last Updated: 31/08/2023

Question:
Further to Question 2 of ESMA’s SFTR Q&As update (25/Jan/2022) on the reporting of settlements fails, which states:

“Counterparties should report the remaining or outstanding SFT with a new UTI and specify accordingly the complete and accurate details of that SFT and its maturity date.”

ISLA members raised a number of strong concerns such as:

•The unsettled trade(s) remain reflected on books and records as an active exposure, the act of generating a new UTI for regulatory reporting would impact up-stream processes. For example, new trade generation is based on trading desk authorities which create new exposures, draws down trading limits and requires new collateral.

•The unique nature of the proposed new trade would create double counting of the existing trade,  that is not settled and remains active for purpose of exposure and risk measures in Securities Lending platforms until settlement occurs.

•The proposed fictional trade could create entries in lending ledgers that break concentration limits (e.g., UCITS Efficient Portfolio Management).

•Further concerns include the different abilities of the diverse market practitioners. Specifically, that counterparts to a trade would react at different times and ways that will increase reconciliation challenges. E.g. where one party changes and the other has not at the same time.

•A further concern is the accounting within agent lenders books and records where the lender’s loan(s) exist within a shell/omni structure. Creating a ‘new’ trade would fall outside that structure and be unrecognizable to the borrower.

ISLA members agree that reporting should reflect the realities of settlement state and resulting exposures, however the nuances of different SFT markets create a challenge that this recent amendment compounds. 

Best Practice:
ISLA members propose several pragmatic approaches that might be consider as potential alternative solutions to this challenge:

1. Relaxing Validation rules for the maturity dates of the trades regarding reporting failed settlements.

2. Introducing REVIVE functionality to re-open the historic closed transaction in SFTR reporting in alignment with EMIR reporting.

3. Adding the requirement to report failed settlement on a maturing SFT in the Level 2 legislation.

Benefits:

•This will provide an explicit reporting obligation for firms to comply with and ensure that all in-scope firms would report a “MODI”.

•This will also ensure a ‘consistent’ reporting approach by counterparties to a transaction.

4. Allowing reporting flexibility:

•Removing the block on back-dated reporting and report corrections after the reporting window for maturity or termination is closed.
Or
•Increase the settlement date to SD+2. The extra day would ensure accurate and consistent reporting of settlement fails by both counterparties to the trade. (SFTR-817)