Collateral Type

Field 2.94 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: Yes>

Status: Best Practice Finalised, Last Updated: 26/04/2021

Field 2.94 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: Yes

Description:
Code that classifies the type of the security used as collateral.

Best Practice:
If Field 2.72 (Uncollateralised [SL] Flag) is populated with "TRUE", this field shall be left blank. Otherwise, it is conditional.

Where applicable, if Field 2.75 (Type of Collateral Component) is populated with "SECU", at least one code pertaining to the classification of collateral type shall be provided, of which there are 9 options, else it shall be left blank.

For the main index there is a list as part of the Capital Requirements Regulation. See Page 131 of the QA Commission implementing regulation (EU) 2016/1646 of 13 September 2016 . The suggestion is to use the same list to determine what is the main index. Therefore, this approach was agreed by the ISLA SFTR Working Group on a best endeavours basis.

As part of the Consultation Response on Guidelines for Reporting under Articles 4 and 12 SFTR from 27 May 2019 to 29 July 2019 ISLA submitted Q67 with the following recommendation:

In the cases where the trade parties do not agree the collateral type, members do not support the proposal to reconcile these fields. Broadly members are uncomfortable with relying on their counterparties data, given they have no oversight over its provenance, the mechanics of reconciling this data would be costly and problematic to the industry with no obvious benefit. Also, if the procedure is to reconcile or agree to another counterparties collateral type this is likely to lead to instances where a firm will report a different collateral type on the same security for trades with different counterparties. ISLA members think it most appropriate that firms report their own records. Therefore, there will be breaks on these fields which members feel presents the most accurate picture to persons reviewing the reports.

Therefore, there will be breaks on these fields which members feel presents the most accurate picture to persons reviewing the reports. Further, in order to reduce unnecessary noise in reports, members again request that these fields are made non-matching - but understand that will require a revision to RTS 2018/8332. (SFTR-114)