About ISLA
Regulation & Policy
Legal Services
Our Events
News & Insights
Status: Best Practice Finalised, Last Updated: 29/11/2021
Field 2.01 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
The unique reference assigned to the SFT to identify the trade.
Reporting entities that transact with each other should pre-agree which of them will be responsible for generating UTIs but should make provisions for dealing with the responsible party's failure to do so. Counterparties must agree:
How the UTI is shared in all scenarios;
What should be done if the UTI generating party does not generate their UTI on time.
Best Practice:
Firms should follow the ISLA approved UTI waterfall method. If an agent lender arranges a loan with multiple beneficial owner allocation, those agents should generate the UTI for each beneficial owner allocation. In all other cases, parties should agree bi-laterally which party generates the UTI and how it should be communicated to the other.
If the generating party has not shared the UTI with the reporting counterparty in-order for them to meet their reporting deadline then firms may do one of the following.
Send with a blank UTI
Send with their own UTI
Wait indefinitely until they receive the UTI from the generating party.
When the Brexit transition period ends on December 31st 2020, there will be a change to the regulatory requirements for exchanging UTIs where one party is reporting under UK SFTR and the other under EU SFTR. Further information can be found here.
For CPMI - IOSCO white paper regarding UTI creation see here. (SFTR-21)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.02 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No
Description:
In the case of transactions resulting from clearing, the prior UTI (i.e. UTI of original bilateral transaction. The prior-UTI is not required to be reported by counterparties that are CCPs that cleared the SFT.
Where an SFT was executed on a trading venue and cleared on the same day, a number generated by the trading venue and unique to that execution.
Best Practice:
If Field 2.05 (Cleared) is populated with "TRUE" and Field 1.03 (Reporting Counterparty) does not equal Field 2.07 (CCP), this field shall be populated with the UTI of the original, bilateral, SFT providing that the transaction was not executed at a recognised Trading Venue and therefore a registered Multi-Trading Facility (MTF).
When populated, this field shall contain up to 52 alphanumerical characters.
Only upper-case alphabetic characters A-Z and the digits 0-9, inclusive in both cases, are allowed.
If Field 2.05 (Cleared) is populated with "false", then this field should be left blank. (SFTR-22)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.03 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No
Description:
Date on which the reportable event relating to the SFT occurs.
Best Practice:
Event date should be populated with the date on which the event happened. In the case of action types "Valuation update", "Collateral update", "Reuse update", "Margin update", the date for which the information contained in the report is provided. (SFTR-23)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.04 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
Specifies the type of SFT transaction as defined under Article 3(7)-3(10) of Regulation (EU) No 2365/2015
Best Practice:
Populate with "SLEB" in all cases for securities or commodities lending or borrowing. Where structured finance SLBs (also known as 'reverse securities loans') are transacted, populate as "REPO". (SFTR-24)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.05 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
Indicates, whether central clearing has taken place.
Best Practice:
Populate as 'TRUE' where a CCP is being utilised. This would result in an LEI being populated in Field 2.07 (CCP) which is conditional on this field (2.05) being 'TRUE'. Otherwise, 'FALSE'. (SFTR-25)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.06 | Matching Date: 2023-01-01 | Tolerance: 1 HOUR | Agent Lender Data Provision: No
Description:
Time and date when clearing took place.
Best Practice:
This timestamp will need to be provided by the CCP. Population of this field is dependent on Field 2.05 (Cleared) being populated as "TRUE". When this field is populated Field, 2.12 (Execution Timestamp) should have the same value. (SFTR-26)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.07 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
In the case of a contract that has been cleared, the unique code for the CCP that has cleared the contract.
Best Practice:
If Field 2.05 (Cleared) is populated with "TRUE", this field shall contain a valid LEI recognised by GLEIF. The LEI shall pertain to a legal entity and not a branch. The status of the LEI for all message templates can be either:
Issued
Lapsed
Pending Transfer
Pending Archival
If Field 2.05 (Cleared) is populated with "FALSE", this field shall be left blank.
Where applicable, this field is widely acknowledged to be populated with the LEI of the central counterpart clearing house. (SFTR-27)
Status: Best Practice Finalised, Last Updated: 01/09/2021
Field 2.08 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
Unique code identifying the venue of execution of the SFT.
Best Practice:
If traded on any venue that holds a registered Multi Traded Facility (MTF) or Regulated Markets (RM) or Organised Trading Facilities (OTFs) license, then a Market Identifier Code (MIC) should be populated. For all else then "XXXX" should be used.
MICs are issued under ISO 10383 to identify exchanges, trading platforms and regulated or non-regulated markets acting as sources of prices and related information and are not restricted to execution venues. (SFTR-28)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.09 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
Reference to master agreement under which the counterparties concluded a documented SFT.
Best Practice:
In all cases, the Master Agreement Type field must be populated with the 4-letter code corresponding to the classification of the master agreement type on which the trade was concluded. In all other cases use "OTHR" to ensure counterparty matching where the provided list is incomplete. (SFTR-29)
Status: Best Practice Finalised, Last Updated: 28/01/2022
Field 2.10 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No
Description:
The name of the Master Agreement, this field should only be filled in where "OTHR" is reported in the Master agreement type field
Best Practice:
If undocumented, populate Field 2.09 (Master Agreement Type) with "OTHR" and populate Field 2.10 with "Undocumented" (SFTR-30)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.11 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No
Description:
Reference to the year of the master agreement version used for the reported trade, if applicable (e.g. 1992, 2002, etc.)
Best Practice:
If Field 2.09 (Master Agreement Type) is populated with a value other than "BIAG", "CSDA" or "OTHR", then this field shall be populated in a common input format: YYYY with the first two digits either "19" or "20"; else it shall be left blank. Note Paragraph 228 of the ESMA guidelines states that the year the document was signed should be used if there is no version available. (SFTR-31)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.12 | Matching Date: 2020-04-01 | Tolerance: 1 HOUR | Agent Lender Data Provision: Yes
Description:
Date and time when the SFT was executed.
Best Practice:
In all cases the execution timestamp must be populated with the date and time of when the SFT was executed, this time should then be carried over on any subsequent reports including rebooking. For loans managed by agent lenders who utilise bulking/bulk delivery/omni models, the timestamp will be applied at beneficial owner allocation level. Where reallocating to an existing fund or allocation within this model, then the latest execution timestamp must be stated when the reallocation is made.
Execution timestamp should always be reported in Coordinated Universal Time (UTC).
The timestamp is derived from each allocation on the understanding that:
1) For new loans that the allocations will have the same timestamp as the omni or street side trade, and;
2) For re-allocations or substitutions that the allocations will have a different timestamp as the omni or street side of the trade.
For bilaterally transacted loans, if a loan is not booked electronically within the one hour tolerance (i.e. SFTR validation rule), parties should ensure that the time reported should be when the loan was executed (concluded) . This may require an additional time entry point in a booking system used for SFTR reporting purposes.
For non-MTF electronically executed trades, ISLA's recommendation is to book the loan immediately into your trading system to best capture the time the trade was executed and therefore within the matching tolerance.
When reporting execution timestamp for a corporate action event, please see here. (SFTR-32)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.13 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
Date on which the counterparties contractually agree the exchange of cash, securities, or commodities versus collateral for the opening leg (spot leg) of the securities financing transaction.
Best Practice:
When populated, this field shall be populated in a common input format: YYYY-MM-DD. The value date should be greater than or equal to, Field 2.12 (Execution Timestamp). (SFTR-33)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.14 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
Date on which the counterparties contractually agree the exchange of cash, securities, or commodities versus collateral for the closing leg (forward leg) of the secured financing transaction. This information shall not be reported for open term repos.
Best Practice:
Where Field 2.21 (Open Term) is populated with "FALSE", the maturity date should be populated with the contractual close or fixed term-date bilaterally agreed between the counterparties for the exchange of cash, securities, or commodities; else leave blank. The maturity date must be greater than or equal to the value in Field 2.13 (Value Date).
ISLA best practice is to only use term date where contractually agreed, this field should not be used for trade management notification purposes, as is often current market practice. If a date alert is needed, then another internal non reporting mechanism needs to be created. (SFTR-34)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.15 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
Termination date in the case of a full early termination of the reported SFT.
Best Practice:
ISLA advises that all returns should be reported on an actual basis. Best practice for reporting returns can be found here. (SFTR-35)
Status: Best Practice Finalised, Last Updated: 25/05/2021
Field 2.16 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No
Description:
The minimum number of business days that one of the counterparties has to inform about the termination of the transaction.
Best Practice:
REPO/BSB/ML related only; therefore out-of-scope for securities lending. (SFTR-36)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.17 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No
Description:
The earliest date that the cash lender has the right to call back a portion of the funds or to terminate the transaction
Best Practice:
REPO/BSB/ML related only; therefore out-of-scope for Securities Lending. (SFTR-37)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.18 | Matching Date: 2023-01-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
Indication whether the secured financing transaction is subject to a general collateral arrangement. In the case of a securities lending transaction, the field refers to the securities provided as a collateral, and not to the security on loan.
Best Practice:
While this field is not mandatory in the Validation Rules, as it is not accessible on a COLU message it should be populated on the NEWT, MODI, CORR & POSC for all SFTs which will be collateralised (ie. Field 2.72 (Uncollateralised SL Flag) = "FALSE") and only where that collateral will be non-cash (even when Field 2.75 (Type of Collateral Component) is left blank).
When populated, this field shall contain only one of the following values: "SPEC" or "GENE", with the value used derived from the master agreement type used.
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. (SFTR-38)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.19 | Matching Date: 2023-01-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
This field specifies whether the transaction was settled using the Delivery-by-Value (DBV) mechanism.
Best Practice:
When populated, this field should be populated with either "TRUE" to indicate when the trade is collateralised using DBV at Crest Co. or "FALSE" to indicate where it is not.
When booking a cash pool trade then report false for the NEWT for a securities loan, the DBV allocation is a secondary back office action and the DBV securities will be reported separately in the collateral position report. (SFTR-39)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.20 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
Indication whether the collateral is subject to a title transfer collateral arrangement, a securities financial collateral arrangement, or a securities financial 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.
Best Practice:
While this field is not mandatory in the Validation Rules, as it is not accessible on a COLU message it should be populated on the NEWT, MODI, CORR & POSC for all SFTs which will be collateralised (i.e. Field 2.72 (Uncollateralised SL Flag) = "FALSE") and only where that collateral will be non-cash (even when Field 2.75 (Type of Collateral Component) is left blank).
When populated, this field shall contain only one of the following values, with the value used derived from the master agreement type used.
"TTCA" - title transfer (Default value where for cash pool collateral is taken and population is required - see minutes of SFTR WG 03NOV2021).
"SIUR" - a security interest with the right to re-hypothecate.
"SICA" - a security interest without a right to re-hypothecate.
For pledge collateral contracts such as the Pledge GMSLA, this field should be populated with "SICA". (SFTR-40)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.21 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
Indication whether the transaction is open term (i.e. has no fixed maturity date) or fixed term with a contractually agreed maturity date. “TRUE” shall be populated for open term transactions, and “FALSE” for fixed term.
Best Practice:
This field shall contain one of the values: "TRUE" or "FALSE". Populate as "TRUE" where an open trade and "FALSE" for fixed-term trades.
Where Field 2.14 (Maturity Date [End Date]) is blank, then this field will always be "TRUE". (SFTR-41)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.22 | Matching Date: 2023-01-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
A code specifying whether the transaction is an evergreen or extendable SFT.
Best Practice:
This field shall contain only one of the following values:
"EGRN"
"ETSB"
"NOAP"
For fixed term trades which are neither evergreen (EGRN) nor extendable (ETSB) or where an open trade, then apply "NOAP".
Evergreens (EGRN) can be either open or fixed-term SFTs. (SFTR-42)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.23 | Matching Date: n/a | Tolerance: Up to third digit after decimal. | Agent Lender Data Provision: No
Description:
In the case of repos, the annualized interest rate on the principal amount of the repurchase transaction in accordance with the day count conventions. In the case of margin lending, the annualized interest rate on the loan value that the borrower pays to the lender.
Best Practice:
REPO/BSB/ML related only; therefore out-of-scope for securities lending. (SFTR-43)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.24 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No
Description:
The method for calculating the accrued interest on the principal amount; applies to any rates.
Best Practice:
REPO/BSB/ML related only; therefore out-of-scope for securities lending. (SFTR-44)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.25 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No
Description:
An indication of the reference interest rate used which is reset at predetermined intervals by reference to a market reference rate, if applicable.
Best Practice:
REPO/BSB/ML related only; therefore out-of-scope for securities lending. (SFTR-45)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.26 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No
Description:
Time period describing reference period of the floating rate.
Best Practice:
REPO/BSB/ML related only; therefore out-of-scope for securities lending. (SFTR-46)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.27 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No
Description:
Multiplier of the time period describing reference period of the floating rate.
Best Practice:
REPO/BSB/ML related only; therefore out-of-scope for securities lending. (SFTR-47)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.28 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No
Description:
Time period describing frequency of payments for the floating rate.
Best Practice:
REPO/BSB/ML related only; therefore out-of-scope for securities lending. (SFTR-48)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.29 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No
Description:
Multiplier of the time period describing frequency of payments for the floating rate.
Best Practice:
REPO/BSB/ML related only; therefore out-of-scope for securities lending. (SFTR-49)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.30 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No
Description:
Time period describing frequency of the floating rate resets.
Best Practice:
REPO/BSB/ML related only; therefore out-of-scope for securities lending. (SFTR-50)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.31 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No
Description:
Multiplier of the time period describing frequency of the floating rate resets.
Best Practice:
REPO/BSB/ML related only; therefore out-of-scope for securities lending. (SFTR-51)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.32 | Matching Date: n/a | Tolerance: Up to third digit after decimal. | Agent Lender Data Provision: No
Description:
The number of basis points to be added to or subtracted from the floating interest rate in order to determine the interest rate of the loan
Best Practice:
REPO/BSB/ML related only; therefore out-of-scope for securities lending. (SFTR-52)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.33 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No
Description:
Amount of a margin loan in a given currency.
Best Practice:
REPO/BSB/ML related only; therefore out-of-scope for securities lending. (SFTR-53)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.34 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No
Description:
Currency of the margin loan.
Best Practice:
REPO/BSB/ML related only; therefore out-of-scope for securities lending. (SFTR-54)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.35 | Matching Date: n/a | Tolerance: Up to third digit after decimal. | Agent Lender Data Provision: No
Description:
This reporting attribute specifies the rate as determined by the rate schedule
Best Practice:
REPO/BSB/ML related only; therefore out-of-scope for securities lending. (SFTR-55)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.36 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No
Description:
This reporting attribute specifies date as of which the rate is effective.
Best Practice:
REPO/BSB/ML related only; therefore out-of-scope for securities lending. (SFTR-56)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.37 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No
Description:
Cash value to be settled as of the value date of the transaction.
Best Practice:
REPO/BSB/ML related only; therefore out-of-scope for securities lending. (SFTR-57)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.38 | Matching Date: n/a | Tolerance: 0.000005 | Agent Lender Data Provision: No
Description:
Cash value to be settled as of the maturity date of the transaction.
Best Practice:
REPO/BSB/ML related only; therefore out-of-scope for securities lending. (SFTR-58)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.39 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No
Description:
Currency of the principal amount.
Best Practice:
REPO/BSB/ML related only; therefore out-of-scope for securities lending. (SFTR-59)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.40 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
Indication of the type of asset subject of the SFT
Best Practice:
When populated, this field shall contain only one of the following values: "SECU" where a security or "COMM" where a commodity. (SFTR-60)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.41 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
Identifier of the security subject of the SFT.
Best Practice:
Where no ISIN (due to events such as corporate actions or a private placement) has been provided then whatever temporary ISIN is in place (or blank field) should be populated.
With regards to missing ISINs; See ESMA Final Report Reporting under Articles 4 and 12 SFTR: 06 January 2020 :
332. While ESMA acknowledges that there may be cases where securities used as collateral might be issued by issuers that are not subject to the EU rules obliging them to obtain LEIs, and that similarly there may be instances in which a security cannot be identified with an ISIN, ESMA reiterates the importance of a correct identification of the issuer and issuance through the LEI and the ISIN in the context of SFTR reporting. (SFTR-61)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.42 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
CFI code of the security subject of the SFT.
Best Practice:
If Field 2.40 (Type of Asset) is populated with "SECU" then this field shall be populated with CFI code composed of 6 characters and compliant with ISO 10962 Standard.
At least the first 2 characters of the CFI code and the character representing asset class, if applicable for a given instrument, shall be provided, i.e. these characters cannot be "X", which represents not applicable or undefined value. All six characters must however be provided (e.g.: DBXXXX).
Otherwise, it shall be left blank.
As per final text guidance below counterparties can agree to synthesize a code if nothing is available. CFI methodology to be provided here.
ESMA Final Report Reporting under Articles 4 and 12 SFTR: 06 January 2020 :
296. On the contrary, in case of no availability of the CFIs, the industry proposed alternative solutions such as dummy CFI, (ii) not to populate it if it is not available, or (iii) to establish a clear procedure on how to build it correctly by themselves. Since SFTR and its RTS require the CFI according to the ISO 10962 standard, ESMA rejects the aforementioned options as not compliant.
297. Therefore, ESMA recommends, in the case the CFI is not available in ANNA, to address a request to the relevant NNA. The Guidelines have been amended accordingly.
ESMA Guidelines Reporting under Articles 4 and 12 SFTR: 06 January 2020 :
142. Counterparties should report only valid CFIs. If the CFI does not exist in the official sources, then it should be agreed between the counterparties, as the CFI is a reconcilable field. (SFTR-62)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.43 | Matching Date: n/a | Tolerance: None | Agent Lender Data Provision: No
Description:
The Base product as specified in the classification of commodities table.
Best Practice:
If Field 2.40 (Type Of Asset) is populated with "COMM", at least one code pertaining to the classification of the base product shall be provided, of which there are 14 options (x4 alphabetical characters), otherwise leave blank. (SFTR-63)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.44 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No
Description:
The sub-product as specified in the classification of commodities table.
Best Practice:
If Field 2.43 (Base Product) is populated with either "AGRI", "NRGY", "ENVR", "FRGT", "FRTL", "INDP", "METL", "PAPR" or "POLY", at least one code pertaining to the classification of the sub-product shall be provided, of which there are 39 options (x4 alphabetical characters), otherwise leave blank. (SFTR-64)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.45 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No
Description:
The further sub product as specified in the classification of commodities table.
Best Practice:
If Field 2.44 (Sub-product) is populated with either "GROS", "SOFT", "OOLI", "GRIN", "ELEC", "NGAS", "OILP", "EMIS", "WETF", "DRYF", "NPRM" or "PRME", at least one code pertaining to the classification of the sub-product shall be provided, of which there are 66 options (x4 alphabetical characters), otherwise leave blank. (SFTR-65)
Status: Under Review, Last Updated: 08/03/2023
Field 2.46 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
Quantity or nominal amount of the security or commodity subject of the SFT. In the case of bonds, a total nominal amount should be reported in this field (number of bonds multiplied by the face value). In the case of other securities or commodities, a quantity shall be specified in this field.
Best Practice:
Regarding Field 2.46 (Quantity or Nominal Amount), a nominal amount should only be reported for bonds, at the face value of the bond. The nominal amount should be reported in the original currency specified in Field 2.48 (Currency of Nominal Amount).
Other securities should be reported as a quantity, in which case Field 2.47 (Unit of Measure) has to be populated whereas Field 2.48 (Currency of Nominal Amount) is left empty.
In any full return scenario, this value should not be modified. (SFTR-66)
Status: Best Practice Finalised, Last Updated: 08/03/2023
Field 2.47 | Matching Date: n/a | Tolerance: None | Agent Lender Data Provision: No
Description:
Unit of measure in which the quantity is expressed. This field is applicable to commodities.
Best Practice:
If Field 2.40 (Type of Asset) is populated with "COMM", at least one code pertaining to the classification of the base product shall be provided, of which there are 72 options (x4 alphabetical characters), otherwise leave blank.
Field 2.47 is not applicable to Securities Lending therefore this should only be populated when the asset on loan is a commodity (2.40 = 'COMM'). This is not restricted by the validation rules. (SFTR-67)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.48 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
In the case where nominal amount is provided, the currency of the nominal amount shall be populated in this field.
Best Practice:
ESMA Guidelines Reporting under Articles 4 and 12 SFTR: 06 January 2020
Regarding Field 2.46 (Quantity or Nominal Amount), a nominal amount should only be reported for bonds. The nominal amount should be reported in the original currency specified in Field 2.48 (Currency of nominal amount).
Other securities should be reported as a quantity, in which case Field 2.47 (Unit of Measure) has to be populated whereas Field 2.48 (Currency of nominal amount) is left empty. (SFTR-68)
Status: Under Review, Last Updated: 08/03/2023
Field 2.49 | Matching Date: 2023-01-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
In the case of securities and commodities lending and borrowing, the price of the security or commodity used to calculate the loan value. In the case of buy-sell back, the price of the security or commodity used to calculate the trade amount for the spot leg of the buy-sell back.
Best Practice:
ESMA Guidelines Reporting under Articles 4 and 12 SFTR: 06 January 2020 states the following:
272. The Field 2.49 (Security or Commodity Price) should be reported in the currency in which the security or commodity price is denominated. This currency should be specified in Field 2.50 (Price Currency). Moreover, the security price should not include any margining requirement (discount, mark-up, add-on, etc.) which should instead be reported as part of Field 2.88 (Collateral Market Value), even if they are calculated from the loan side of the transaction.
The SFTR Working Group have agreed that the price should be expressed as the quoted dirty price for Fixed Income assets, including accrued interest and factor but excluding margin/haircut. Any change to price should be reported in alignment with the reporting of changes to Loan Value. The Frequency of reporting should mirror changes to Loan Value and practice should be aligned with ISLA Best Practice IBP127 (SFTR-69)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.50 | Matching Date: 2023-01-01 | Tolerance: None | Agent Lender Data Provision: Yes
Description:
The currency in which the security or commodity price is denominated.
Best Practice:
When populated, this field should contain an ISO 4217 currency code (x3 alphabetical characters)
ESMA Guidelines Reporting under Articles 4 and 12 SFTR: 06 January 2020 | ESMA70-151-2838
272. Field 2.49 (Security or Commodity Price) should be reported in the currency in which the security or commodity price is denominated. This currency should be specified in Field 2.50 (Price currency). (SFTR-70)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.51 | Matching Date: 2021-01-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
Code that classifies the credit risk of the security.
Best Practice:
If Field 2.40 (Type of Asset) is populated with "SECU", at least one code pertaining to the security quality shall be provided, of which there are 4 options (x4 alphabetical characters). Otherwise, this field should be left blank. Firms should report their own internal records for the quality of the security.
ESMA Guidelines Reporting under Articles 4 and 12 SFTR: 06 January 2020
281. "Counterparties should report the security quality information as consistently as possible since it will be used for reconciliation. However, ESMA was made aware of possible limitations that might prevent entities from sharing this information, in which case the reporting counterparties should report the value that best reflects their internal assessment." (SFTR-71)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.52 | Matching Date: 2021-01-01 | Tolerance: None | Agent Lender Data Provision: Yes
Description:
Maturity of the security
Best Practice:
If Field 2.40 (Type of Asset) is populated with "SECU", this field shall be populated in a common input format: YYYY-MM-DD. When maturity date is not applicable (e.g. perpetual bonds and equities), use default code "9999-12-31".
When the reported maturity of the security is reached, any trades that are still open need to be explicitly terminated with the TR using an ETRM message. (SFTR-72)
Status: Under Review, Last Updated: 30/06/2023
Field 2.53 | Matching Date: 2021-01-01 | Tolerance: None | Agent Lender Data Provision: Yes
Description:
Jurisdiction of the issuer of the security. In case of securities issued by a foreign subsidiary, the jurisdiction of the ultimate parent company shall be reported or, if not known, jurisdiction of the subsidiary.
Best Practice:
If Field 2.40 (Type of Asset) is populated with "SECU" this field shall be populated and shall contain a valid ISO 3166 country code, 2 alphabetical characters. Otherwise, it shall be left blank.
The country code provided in this field shall pertain to the country of the registered office of the issuer as specified in the LEI reference data, corresponding to the ‘Legal address’ in GLEIF data (SFTR-73)
Status: Under Review, Last Updated: 26/04/2021
Field 2.54 | Matching Date: 2021-01-01 | Tolerance: None | Agent Lender Data Provision: Yes
Description:
LEI of the issuer of the security.
Best Practice:
See ESMA LEI Statement published on 13 April 2021.
See also FCA April 2021 SFTR news from 6 April 2021.
Both authorities have extended the forbearance period for the reporting of third country issuer LEIs until:
FCA, for UK SFTR: "April 13th 2022, at the earliest."
ESMA, EU SFTR: "October 11th 2022, at the latest."
When the forbearance period comes to an end, and where no Issuer LEI is available, each firm would then decide whether to:
1) Leave the field blank, causing a validation error (NACK)
2) Provide an alternate Issuer LEI (e.g. GLEIF LEI, main exchange)
ISLA is continuing to work with industry participants, exchanges, vendors and numbering associations to improve LEI coverage globally.
Please see the ANNA ISIN UNIFORM GUIDELINES RELATING TO ISO 6166 (9th edition) which explains numbering association guidelines regarding Issuer LEI use in ISIN registration in chapter 9 'LEI & ISIN Linkage'.
When the LEI of an ETF is being reported, if the umbrella company of the ETF is the issuing entity then the LEI of the umbrella company should be reported in this field. (SFTR-74)
Status: Communications Review, Last Updated: 26/04/2021
Field 2.55 | Matching Date: 2021-01-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
Code that classifies the type of the security
Best Practice:
If Field 2.40 (Type of Asset) is populated with "SECU", at least one code pertaining to the security quality shall be provided, of which there are 8 options (x4 alphabetical characters). Otherwise, 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-75)
Status: Under Review, Last Updated: 08/03/2023
Field 2.56 | Matching Date: 2023-01-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
This reporting attribute specifies loan value, i.e. the quantity or nominal amount multiplied by the price
Best Practice:
The loan value should be reported in the underlying currency of the security (this will also apply to loan market value).
ESMA Final Report Reporting under Articles 4 and 12 SFTR: 06 January 2020 :
260. Taking into consideration the feedback, ESMA understands that the information reported on the loan side of SLB should exclude any such margin requirement or add-on. Therefore Field 2.56 (Loan Value) is reported without margin whether cash, non-cash or pooled trade.
ESMA Guidelines Reporting under Articles 4 and 12 SFTR: 06 January 2020 :
274. "Loan value" is calculated in the currency in which the security is denominated as per the formula below, rather than the currency in which the two counterparties have concluded a transaction.
275. The loan value will be reported in the underlying currency of the security (note this will also apply to loan market value) as follows: Field 2.56 (Loan Value) = Field 2.46 (Qty or Nominal Amt) x Field 2.49 (Security Price).
276. There may be instances in which the valuation of the securities on loan (or the securities used as collateral) is not possible, reflecting the unavailability of price information. This is the case, for example, with suspended shares, or some fixed-income securities in illiquid market segments. Upon the conclusion of SFTs that involve the use of such securities, counterparties should report the valuation that has been contractually agreed. If new price information becomes available, valuation updates should be reported by both counterparties in Field 2.57 (Market Value).
Reported Loan Value should as it is applied to the trade to reflect lifecycle event(s) such as quantity or price change. The value & price will therefore align with billing calculations and be a true reflection of firm’s books and records. Please note, Loan Value should be aligned with 2.49 (SFTR-69) regarding quoted dirty price for Fixed Income assets. Where a firm’s procedure differs from the above, parties should seek agreement bilaterally to avoid reconciliation breaks. (SFTR-76)
Status: Communications Review, Last Updated: 20/02/2024
Field 2.57 | Matching Date: 2023-01-01 | Tolerance: 0.000005 | Agent Lender Data Provision: Yes
Description:
Market value of the securities or commodities on loan or borrowed.
Best Practice:
Market Value should be reported in the underlying currency of the security (note this will align with the loan value). If a Market Value is not available, the Loan Value should be used (see 2.57 Market Value: Paragraph 276 of the ESMA Guidelines). For further reference please see ESMA Guidelines Reporting under Articles 4 and 12 SFTR note:131.
The market value of the securities should be the one as at close of business of each business day, and it should be reported no later than T+1, reflecting the valuation used for collateral management purposes (e.g., to calculate daily variation margin).132.
Counterparties should report the market value of their SFTs using the market prices and FX rates that those counterparties have used during the course of that business day for exposure management purposes. For securities lending transactions, this would generally mean that the market values reported as at close of business on any given day would be the closing prices of the securities as of the previous business day and reported no later than T+1.139.
When an FX rate has to be used by a counterparty to submit an accurate valuation, the relevant ECB rate should be used. In the event an ECB FX rate does not exist for the conversion, counterparties should agree between themselves which FX rate to use for valuation and reporting purposes.
Challenge / Problem:
•Example where firms are submitting VALU messages before the intended settlement date as per below:
oThe opening leg has not yet settled (start date reported by both parties is in the future).
oSome counterparties do not generate VALU messages until the opening leg of the stock loan contract has
settled, hence some counterparties reporting shows “market value” as blank.
oHowever as shown in the below Party B are submitting VALU updates (and hence populating “market value”
field) prior to settlement of the opening leg.
oIn both instances where the intended settlement date is in the future, and also where the trade has failed on the
intended settlement date, therefore the opening leg is in a pending system status.
| Reporting Counterparty | Other Counterparty | Type of SFT | Value Date (Start Date) | Market Value – Field LC.57 |
|---|---|---|---|---|
| Party A | Party B | SLEB | 2024-04-12 | |
| Party B | Party A | SLEB | 2024-04-12 | 1,000,000 |
SFTR Best Practice Suggestion:
oTo note field 2.57 Market Value within the trade validation rules is an “optional” field for action types NEWT & CORR and is also a reconcilable field with a tolerance of 0.0005% required from the 11th January 2023 phase in.
oUpon the analysis and implementation of SFTR coming into force it was recommended by trade associations working groups and task forces that any “optional” field under SFTR as a best practice should be populated where reference data is available.
oWhere reference data is available do not leave any “optional” fields as BLANK when reporting.
oThis would infer that on a new SLEB NEWT reporting message field 2.57 – Market Value should be populated from the generated system booking and then any subsequent CORR or VALU messages to clearly show the latest market values.
oAlthough settlement driven reporting is an aspect of SFTR to “only” report fully returned / closed transactions when they actually settle in the market, in no other aspect of SFTR should reporting be held back or indeed blocked.
oAlthough billing accruals and margins are required under actual settlement this is driven from a business perspective and not an SFTR regulatory reporting perspective hence there is need for distinction and separation.
oAs action type VALU is a Mandatory reporting SL field this should commence from T+1, with no need / requirement to hold back valuations until opening trade legs have settled
(SFTR-77)
Status: Under Review, Last Updated: 15/02/2023
Field 2.58 | Matching Date: 2020-04-01 | Tolerance: Up to third digit after decimal. | Agent Lender Data Provision: No
Description:
Fixed interest rate (rate agreed to be paid by the lender for the reinvestment of the cash collateral minus lending fee) paid by the lender of the security or commodity to the borrower (positive rebate rate) or by the borrower to the lender (negative rebate rate) on the balance of the provided cash collateral.
Best Practice:
If Field 2.73 (Collateralisation of Net Exposure) is populated with "FALSE", then one of the Fields 2.58 (Fixed Rebate Rate) or 2.59 (Floating Rebate Rate) must be populated.
Therefore, for the following loan booking collateral types and where Field 2.73 (Collateralisation of Net Exposure) is populated accordingly, then the please see the following population logic:
Cash Rebate SFTs
= "2.73 is FALSE", then 2.58 is mandatory
Cash Pool SFTs
="2.73 is TRUE", then 2.58 is
Non-Cash SFTs
="2.73 TRUE", then 2.58 is
Either Field 2.58 and Field 2.66, or 2.59 and 2.66, will be populated and are mutually exclusive.
Note:
In the case of a cash trade settlement DVP then this is set as FALSE for Field 2.73 and either Field 2.58 or Field 2.59 would be populated depending on its booking type. Due to a known issue with Field 2.58 (Fixed Rebate Rate) and 2.59 (Floating Rebate Rate) which has a conditional dependency on Field 2.73 (Collateralisation of Net Exposure), which makes one of them mandatory if the value is "FALSE", the unanimous decision was to always mark non-cash and cash pool SFTs as net exposure equal to "TRUE".
This decision was made to circumvent the alternative which would otherwise see users mandatorily having to provide a rebate rate for a non-cash/cash-pool trade SFT, which of course they cannot. An action that would see their reported message rejected at the TR. Therefore, following this logic where cash-pool there is no need to populate either Field 2.58 or Field 2.59.
This effectively, is an industry agreed solution for a known issue, which both ESMA and the NCAs are aware of. (SFTR-78)
Status: Best Practice Finalised, Last Updated: 01/09/2021
Field 2.59 | Matching Date: 2020-04-01 | Tolerance: Up to third digit after decimal. | Agent Lender Data Provision: No
Description:
An indication of the reference interest rate used to calculate the rebate rate (rate agreed to be paid by the lender for the reinvestment of the cash collateral minus lending fee) paid by the lender of the security or commodity to the borrower (positive rebate rate) or by the borrower to the lender (negative rebate rate) on the balance of the provided cash collateral.
Best Practice:
If Field 2.73 (Collateralisation of Net Exposure) is populated with "FALSE", then one of either Field 2.58 (Fixed Rebate Rate) or Field 2.59 (Floating Rebate Rate) must be populated.
When floating, at least one code pertaining to the floating rebate rate shall be provided, of which there are 37 options (x4 alphabetical characters).
ESMA Final Report Reporting under Articles 4 and 12 SFTR: 06 January 2020
258. When reporting floating rates, counterparties should indicate the relevant rate and the applicable spread. Counterparties should update this information only when they agree to change the rate or the spread, but not on a daily basis.
For reference purposes please see Annex II: ICMA List of recommended codes for interest rate indexes to be used as below;
The following list consists of four-letter ISO codes for some of the short-term interest rate indexes that are or may be used as reference rates in the European repo market and recommended four-letter codes for such indexes where there is currently no ISO code.
The list also includes the most relevant of the indexes in the list in Annex I of the RTS on transaction reporting under SFTR. When used to determine a floating repo rate, these codes would be reported in Field 2.25 (Floating Rate)
Australian Overnight Index Average (AONIA) - AONA
Broad General Collateral Rate - BGCR
CORRA Canadian Overnight Repo Rate Average - CORR
Effective Fed Funds Rate - EFFR
Euro Short Term Rate - ESTR*
Overnight Broad Funding Rate - OBFR
RepoFunds Rate Euro - RFRE
RepoFunds Rate Germany - RFRD
RepoFunds Rate France - RFRF
RepoFunds Rate Italy - RFRI
RepoFunds Rate Spain - RFRS
RepoFunds Rate Netherlands - RFRN
RepoFunds Rate Belgium - RFRB
Sterling RepoFunds Rate - RFRU
RONIA - RONA
SARON - SARO
SOFR - SOFR*
SONIA - SONA*
Singapore Overnight Rate Average - SORA
STOXX GC Pooling EUR ON - GCPO
STOXX GC Pooling EUR Extended ON - GPEO
STOXX GC Pooling EUR TN - GCPT
STOXX GC Pooling EUR Extended TN - GPET
STOXX GC Pooling EUR SN - GCSN
STOXX GC Pooling EUR Extended SN - GPSN
STOXX GC Pooling EUR Funding Rate - GCFR
STOXX GC Pooling EUR Deferred Funding Rate - GCDR
STOXX GC Pooling EUR 1 Week - GC1W
STOXX GC Pooling EUR 2 Weeks - GC2W
STOXX GC Pooling EUR 1 Month - GC2M
STOXX GC Pooling EUR 3 Months - GC3M
STOXX GC Pooling EUR 6 Months - GC6M
STOXX GC Pooling EUR 9 Months - GC9M
STOXX GC Pooling EUR 12 Months - GC12
Tri-Party General Collateral Rate - TPGR
TOIS - TOIS
TONAR - TONA
ISO code. (SFTR-79)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.60 | Matching Date: 2023-01-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
Time period describing reference period of the floating rebate rate.
Best Practice:
This field reports the units of time in which the rebate rate is reset and payments are calculated.
If Field 2.59 (Floating Rebate Rate) is populated, this field shall be populated and shall contain only one of the following values of which there are 4 options (x 4 alphabetic characters), otherwise the field shall be left blank:
YEAR
MNTH
WEEK
DAYS
For an example of an O/N reference rate on an Open/Overnight trade, see the following:
Field 2.60 = DAYS
Field 2.61 = 1
Field 2.64 = DAYS
Field 2.65 = 1
Also refer to Field 2.62 (Floating Rebate Rate Payment Frequency - Time Period) best practice.
Time periods should be measured in weeks rather than days, months rather than weeks or days, and years rather than months, weeks or days, except if this would result in a fractional frequency, in which case, the immediately shorter time period should be used. (SFTR-80)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.61 | Matching Date: 2023-01-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
Multiplier of the time period describing reference period of the floating rebate rate.
Best Practice:
If Field 2.59 (Floating Rebate Rate) is populated, this field shall be populated and shall contain up to 3 numerical characters, else the field should be left blank.
The multiplier for the time period describing the reference period for the floating rebate rate is specified in Field 2.60 (Floating Rebate Rate Reference Period - Time Period).
Fields 2.60 - Field 2.65 are only populated upon Field 2.59 being populated.
For an example of a multiplier on a trade, see the following:
Days
Field 2.60 = DAYS
Field 2.61 = 1
Week
Field 2.60 = WEEK
Field 2.61 = 1
Month
Field 2.60 = MNTH
Field 2.61 = 1
Year
Field 2.60 = YEAR
Field 2.61 = 1
Given the fact that reporting firms could express a year as DAYS = 365, for example, there is a risk that these fields may not match so it is incumbent on reporting parties to align to best-practice. (SFTR-81)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.62 | Matching Date: 2023-01-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
Time period describing frequency of payments for the floating rebate rate.
Best Practice:
If Field 2.59 (Floating Rebate Rate) is populated, at least one code pertaining to the floating rebate rate payment frequency time period shall be provided, of which there are 4 options (x4 alphabetical characters), else the field should be left blank.
Fields 2.60 - Field 2.65 are only populated upon field 2.59 (Floating Rebate Rate) being populated.
For an example of a floating rebate rate payment frequency time period on a trade, see the following. If fees and rebates are paid:
Monthly
Field 2.62 = MNTH
Field 2.63 = 1
At the end of the trade and the trade has a term date
Field 2.62 = DAYS
Field 2.63 = X (being the number of days between the value date and the term date).
At the end of the trade and the trade does not have a term date
Field 2.62 = Month*
Field 2.63 = 1*
*It was acknowledged this is not correct however the values in Field 2.62 do not allow us to report this field correctly for open trades. We have asked ESMA for an additional value of "TERM" for Field 2.62 however; if this is not granted, the decision was to populate this field with "MNTH".
Time periods should be measured in weeks rather than days, months rather than weeks or days, and years rather than months, weeks or days, except if this would result in a fractional frequency, in which case, the immediately shorter time period should be used. (SFTR-82)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.63 | Matching Date: 2023-01-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
Multiplier of the time period describing frequency of payments for the floating rebate rate.
Best Practice:
If Field 2.59 (Floating Rebate Rate) is populated, an integer based on Field 2.64 (Floating Rebate Rate Reset Frequency - Time Period) should be provided, else the field should be left blank.
Fields 2.60 - Field 2.65 are only populated upon Field 2.59 (Floating Rebate Rate) being populated.
For an example of a floating rebate rate payment frequency multiplier on a trade, see the following:
Days
Field 2.62 = DAYS
Field 2.63 =1
Week
Field 2.62 = WEEK
Field 2.63 = 7
Month
Field 2.62 = MONTH
Field 2.63 =1
Year
Field 2.62 = YEAR
Field 2.63 = 1
Given the fact that reporting firms could express a year as DAYS / 365 etc., there is a risk that these fields may not match so it is incumbent on reporting parties to align. (SFTR-83)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.64 | Matching Date: 2023-01-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
Time period describing frequency of the floating rebate rate resets.
Best Practice:
If Field 2.59 (Floating Rebate Rate) is populated, at least one code pertaining to the floating rebate rate reset frequency time period shall be provided, of which there are 4 options (x4 alphabetical characters), else the field should be left blank.
Fields 2.60-2.65 are only populated upon Field 2.59 (Floating Rebate Rate) being populated.
Time period describing how often the counterparties reset the floating rebate rate, whereby the following abbreviations apply:
Day = DAYS
Week = WEEK
Month = MNTH
Year = YEAR
Time periods should be measured in weeks rather than days, months rather than weeks or days, and years rather than months, weeks or days, except if this would result in a fractional frequency, in which case, the immediately shorter time period should be used. (SFTR-84)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.65 | Matching Date: 2023-01-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
Multiplier of the time period describing frequency of the floating rebate rate resets.
Best Practice:
If Field 2.59 (Floating Rebate Rate) is populated, an integer based on Field 2.64 (Floating Rebate Rate Reset Frequency - Time Period) should be provided, else the field should be left blank.
Fields 2.60 - Field 2.65 are only populated upon field 2.59 (Floating Rebate Rate) being populated.
For an example of a floating rebate rate reset frequency multiplier on a trade, see the following:
Days
Field 2.64 = DAYS
Field 2.65 = 1
Week
Field 2.64 = WEEK
Field 2.65 = 7
Month
Field 2.64 = MONTH
Field 2.65 = 1
Year
Field 2.64 = YEAR
Field 2.65 = 1
Given the fact that reporting firms could express a year as DAYS / 365 etc., there is a risk that these fields may not match so it is incumbent on reporting parties to align. (SFTR-85)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.66 | Matching Date: 2023-01-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
Spread for the floating rebate rate expressed in basis point.
Best Practice:
If Field 2.59 (Floating Rebate Rate) is populated, a value (x5 numerical characters) shall be provided, else the field should be left blank.
This field applies to cash rebate loans only. Note that, per paragraph 258: "Counterparties should update this information only when they agree to change the rate or the spread, but not on a daily basis". (SFTR-86)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.67 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
Fee that the borrower of the security or commodity pays to the lender.
Best Practice:
If Field 2.73 is populated with "TRUE", a value (x11 numerical characters including up to x10 decimals) shall be provided, else the field should be left blank.
Note: For uncollateralised trades, best practice is that conditionality does not mean that a fee cannot be reported where Net Collateral Exposure is set to "FALSE" . I.e. an uncollateralised loan set to "TRUE" in field 2.72 results in 2.73 being "FALSE" still means a Lending Fee can be reported in field 2.67, as there is nothing in the rules precluding doing this (It is mandatory to populate Field 2.67 where 2.72 is "FALSE" and 2.73 is set to "TRUE" but this does not mean that the loan fee on an uncollateralised trade should not be reported).
For an example of whether a lending fee should be provided on a trade, see the following:
Cash Rebate SFTs
Field 2.73 = "FALSE"
Field 2.67 = blank
Cash Pool SFTs
Field 2.73 = "TRUE" or "FALSE"
Field 2.67 = populate
Non-Cash SFTs
Field 2.73 = "TRUE" or "FALSE"
Field 2.67 = populate
Where Field 2.68 (Exclusive Arrangements) is set as "TRUE" members have indicated the fee will not be applied to a trade as it is not possible to apply or apportion given the nature of how exclusive fees are normally arranged on a portfolio basis and there is no other way to report within the current SFTR reporting structure. (SFTR-87)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.68 | Matching Date: 2023-01-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
In the case of securities borrowing and lending, indication whether the borrower has exclusive access to borrow from the lenders securities portfolio.
Best Practice:
If Field 2.40 (Type of Asset) is populated with "SECU" this field should be populated with either "TRUE" or "FALSE",
else it shall be left blank.
For securities lending and borrowing, this field indicates whether the borrower has entered into an exclusive arrangement to borrow from the lender's asset portfolio. This field is not applicable to commodities.
Note: Where indicated as "TRUE" members have indicated the fee will not be applied to a trade as it is not possible to apply or apportion given the nature of how exclusive fees are normally arranged on a portfolio basis and there is no other way to report within the current SFTR reporting structure. (SFTR-88)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.69 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No
Description:
Total amount of margin loans, in base currency.
Best Practice:
REPO/BSB/ML related only; therefore out-of-scope for securities lending. (SFTR-89)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.70 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No
Description:
The base currency of outstanding margin loans.
Best Practice:
REPO/BSB/ML related only; therefore out-of-scope for securities lending. (SFTR-90)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.71 | Matching Date: n/a | Tolerance: 0.000005 | Agent Lender Data Provision: No
Description:
Market value of short position, in base currency.
Best Practice:
REPO/BSB/ML related only; therefore out-of-scope for securities lending. (SFTR-91)
Status: Under Review, Last Updated: 26/04/2021
Field 2.72 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
Indicates whether the securities lending transaction is uncollateralised. This field shall not be used when the counterparties agree to collateralise the trade, but the specific allocation of collateral is not yet known.
Best Practice:
When populated, this field should be populated with either "TRUE" to indicate when the trade is uncollateralised or "FALSE" to indicate where it is collateralised. (SFTR-92)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.73 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: No
Description:
Indicates whether the collateral has been provided for a net exposure, rather than for a single transaction.
Best Practice:
If Field 2.72 (Uncollateralised Securities Lending [SL] Flag) is populated with "FALSE" this field must be populated and contain one of the values: "TRUE" or "FALSE", else the field should be left blank.
Where the collateral provider pledges collateral on a net-asset basis or specific collateral is unknown at the point of execution, then "TRUE" should be reported in all cases; therefore:
Cash Rebate SFTs
= "FALSE"
Cash Pool SFTs
="TRUE"
Non-Cash SFTs
="TRUE"
Notes with regards to the logic;
Cash Rebate: When you collateralise/margin a cash rebate trade, this is always done on a trade level basis. When you run your exposure figures, if you are short, you will contact the counterparty and agree a new loan price for the trade. You will then calculate how much cash will be received. You may perform a cash mark on several trades and decide to receive one lump sum, however you agree a new price for each trade individually, hence the trades are being margined at a trade level. Hence 2.73 = "FALSE".
Cash Pool: When you collateralise/margin a cash pool trade, this is done on a net exposure basis. When you run your exposures figures, if you are short, you will contact the counterparty and agree to receive one lump sum which will collateralise all of the cash pool trades. The cash pool is marked, not the price on the individual trades. Hence 2.73 = "TRUE".
Non-cash trades: Are the same as cash pool trades being TRUE except where on occasions, for non-cash SFTs, the collateral taker knows the specific ISIN to be received at the point of trading in a process often referred to as Bonds Borrowed. These are typically a one-for-one swap of Euro or Government Bonds at the (I)CSDs that may or may not be collateralised intraday with cash, therefore DVP or FOP. Any cash allocated would ordinarily net to zero once both legs of the transaction has settled.
Due to a known issue with Fields 2.58 (Fixed Rebate Rate) and 2.59 (Floating Rebate Rate) which has a conditional dependency on this Field 2.73 (Collateralisation of Net Exposure), which makes one of them mandatory if the value is "FALSE", the unanimous decision was to always mark non-cash and cash pool SFTs as net exposure equal to "TRUE".
This decision was made to circumvent the alternative which would otherwise see users mandatorily having to provide a rebate rate for a non-cash collateral SFT, which of course they cannot. An action that would see their reported message rejected at the TR.
This effectively, is an industry agreed solution for a known issue, which both ESMA and the NCAs are aware of. (SFTR-93)
Status: Best Practice Finalised, Last Updated: 02/02/2022
Field 2.74 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No
Description:
Where trades have been collateralised on a net exposure basis, the latest value date contained in the netting set of SFTs, considering all transactions for which the collateral was provided.
Best Practice:
If Net Collateral COLUs is non pre-pay Field 2.74 will be left 'Blank', however if Net Collateral COLUs are pre-pay Field 2.74 will be populated with 'MAX' (Field 2.13) Value Date from the netting set. (SFTR-94)
Status: Under Review, Last Updated: 03/07/2023
Field 2.75 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: Yes
Description:
Indication of the type of collateral component.
Best Practice:
Where Field 2.04 is populated with SLEB.
For NEWT template:
If Business Use Case = Uncollateralised SLEB and Field 2.72 = TRUE
Then do not populate Field 2.75.
If Business Use Case = Individually Collateralised SLEB (Cash Rebates), and Field 2.72 = FALSE, and Field 2.73 (NE) = FALSE and type of collateral is cash
Then populate Field 2.75 with 'CASH', also populate the related cash collateral fields.
If Business Use Case = SLEB against Net Exposure Collateral and Field 2.72 = FALSE and Field 2.73 (NE) = TRUE
Then do not populate Field 2.75.
For CORR Template:
If Business Use Case = Uncollateralised SLEB and Field 2.72 = TRUE
Then do not populate Field 2.75.
If Business Use Case = Individually Collateralised SLEB (Cash Rebates) and Field 2.72 = FALSE and Field 2.73 (NE) = FALSE and type of collateral is CASH
Then populate Filed 2.75 with 'CASH', also populate the related cash collateral fields. Please note that Collateral should be as per EOD for the event date (Field 2.03) being corrected.
If Business Use Case = SLEB against Net Exposure Collateral and Field 2.72 = FALSE and Field 2.73 (NE) = TRUE
Then do not populate Field 2.75.
For COLU Template:
If Business Use Case = Uncollateralised SLEB
Then not applicable as no COLUs are reported for Uncollateralised SLEBs
If Business Use Case = TB COLU for Individually Collateralised SLEB (Cash Rebates) and Field 2.73 = False type of collateral is cash
Then populate Field 2.75 with 'CASH', also populate the related cash collateral fields
If Business Use Case = NE COLU for SLEB against Net Exposure Collateral and Field 2.73 = TRUE
Then for Cash populate Filed 2.75 with 'CASH', also populate the related cash collateral fields.
For Non-Cash that is SECU populate Field 2.75 with ‘SECU’, also populate the related SECU collateral fields. (SFTR-95)
Status: Best Practice Finalised, Last Updated: 16/01/2024
Field 2.76 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: Yes
Description:
Amount of funds provided as collateral for borrowing the securities or commodities.
Best Practice:
If Field 2.75 (Type of Collateral Component) is populated with "CASH", a value (x18 numerical characters including up to x5 decimals) shall be provided, else the field should be left blank.
For an example of how a cash collateral amount should be provided on a trade, see the following:
Cash Rebate
Field 2.76 = loan value
Cash Pool
Field 2.76 = loan value
Non-Cash
Field 2.76 = blank
Cash Pool
Field 2.76 = loan value (of the cash pool)
SLEB Example (all figures are purely examples, the purpose of the table is to denote the signages):
| Action Type | Field 1.9 | Field 2.01 | Field 2.76 | Field 2.83 | Field 2.88 |
|---|---|---|---|---|---|
| NEWT/MODI/CORR | GIVE | 12345 | -100000 | -123456 | -123456 |
| NEWT/MODI/CORR | TAKE | 678910 | 150000 | 100000 | 999999 |
For further information see here. (SFTR-96)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.77 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: Yes
Description:
Currency of the cash collateral. If field 2.75 is populated with CASH this field will be populated with CCY code of the cash.
Best Practice:
If Field 2.75 (Type of Collateral Component) is populated with "CASH", this field should contain an ISO 4217 currency code (x3 alphabetical characters), else the field should be left blank. (SFTR-97)
Status: Best Practice Finalised, Last Updated: 07/06/2021
Field 2.78 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: Yes
Description:
Identifier of the security used as collateral.
Best Practice:
Where no ISIN (due to events such as corporate actions or a private placement) has been provided then whatever temporary ISIN is in place (or blank field) should be populated.
With regards to missing ISINs; See ESMA Final Report Reporting under Articles 4 and 12 SFTR: 06 January 2020 :
332. While ESMA acknowledges that there may be cases where securities used as collateral might be issued by issuers that are not subject to the EU rules obliging them to obtain LEIs, and that similarly there may be instances in which a security cannot be identified with an ISIN, ESMA reiterates the importance of a correct identification of the issuer and issuance through the LEI and the ISIN in the context of SFTR reporting. (SFTR-98)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.79 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: Yes
Description:
CFI code of the security used as collateral.
Best Practice:
If Field 2.75 (Type of Collateral Component) is populated with "SECU", a CFI code (x6 characters) compliant with ISO 10962 Standard shall be provided, else it should be left blank.
At least the first 2 characters of the CFI code and the character representing asset class, if applicable for a given instrument, shall be provided, i.e. these characters cannot be "X", which represents not applicable or undefined value. All six characters must however be provided. (e.g.: DBXXXX)
Otherwise, it shall be left blank.
As per final text guidance below counterparties can agree to synthesize a code if nothing is available. CFI methodology to be provided here.
4.14 Reporting of CFI for a security used as collateral.
When a security is used as collateral, the CFI code of that security should be reported in fields 42 and 79 of the table on Loan and Collateral data. This field does not apply to commodities. Counterparties should always use official sources for the CFI. For this purpose, the data issued by the relevant National Numbering Agency (NNA) should be used. Further information is provided by ANNA in the following this link , or by the relevant NNA of the security.
Counterparties should report only valid CFIs. If the CFI does not exist in the official sources, then it should be agreed between the counterparties, as the CFI is a reconcilable field. (SFTR-99)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.80 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No
Description:
Base product as specified in the classification of commodities table.
Best Practice:
If Field 2.75 (Type Of Collateral Component) is populated with "COMM", at least one code pertaining to the classification of the base product shall be provided, of which there are 14 options (x4 alphabetical characters), otherwise leave blank. (SFTR-100)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.81 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No
Description:
The sub-product as specified in the classification of commodities table.
Best Practice:
If Field 2.80 (Base Product) is populated with either "AGRI", "NRGY", "ENVR", "FRGT", "FRTL", "INDP", "METL", "PAPR" or "POLY", at least one code pertaining to the classification of the sub-product shall be provided, of which there are 39 options (x4 alphabetical characters), otherwise leave blank. (SFTR-101)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.82 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No
Description:
The further sub - product as specified in the classification of commodities table.
Best Practice:
If Field 2.81 (Sub-product) is populated with either "GROS", "SOFT", "OOLI", "GRIN", "ELEC", "NGAS", "OILP", "EMIS", "WETF", "DRYF", "NPRM" or "PRME", at least one code pertaining to the classification of the sub-product shall be provided, of which there are 66 options (x4 alphabetical characters), otherwise leave blank. (SFTR-102)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.83 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: Yes
Description:
Quantity or nominal amount of the security or commodity used as collateral. In the case of bond a total nominal amount should be reported in this field (number of bonds multiplied by the face value).
Best Practice:
If Field 2.75 (Type of Collateral Component) is populated with "SECU" or "COMM", a value (x18 numerical characters including up to x5 decimals) shall be provided, else it should be left blank.
SLEB Example (all figures are purely examples, the purpose of the table is to denote the signages):
| Action Type | Field 1.9 | Field 2.01 | Field 2.76 | Field 2.83 | Field 2.88 |
|---|---|---|---|---|---|
| NEWT/MODI/CORR | GIVE | 12345 | -100000 | -123456 | -123456 |
| NEWT/MODI/CORR | TAKE | 678910 | 150000 | 100000 | 999999 |
22 Regulation (EU) 2015/2365 of the European Parliament and of the Council of 25 November 2015 on transparency of securities financing transactions and of reuse and amending Regulation (EU) No 648/2012 (OJ L 337, 23.12.2015, p. 1–34).
23 On occasion these structured trades may be referred to as ‘fixed cash pool’ transactions, to refer to the fact that the associated cash collateral is fixed instead of being varied to maintain margin like in ordinary ‘cash pool’
transactions.
For further information see here. (SFTR-103)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.84 | Matching Date: 2022-04-01 | Tolerance: None | Agent Lender Data Provision: Yes
Description:
Unit of measure in which the collateral quantity is expressed. This field is applicable to commodities.
Best Practice:
If Field 2.75 (Type of Collateral Component) is populated with "COMM", at least one code pertaining to the classification of the base product shall be provided, of which there are 72 options (x4 alphabetical characters), otherwise leave blank. (SFTR-104)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.85 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: Yes
Description:
In the case where collateral nominal amount is provided, the currency of the nominal amount shall be populated in this field.
Best Practice:
When populated this field shall contain ISO 4217 Currency Code (official list only), else leave blank. This value should equal the currency in which the principal is to be repaid at the maturity of a security. (SFTR-105)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.86 | Matching Date: 2022-04-01 | Tolerance: None | Agent Lender Data Provision: Yes
Description:
Currency of the price of the collateral component
Best Practice:
When populated this field shall contain ISO 4217 Currency Code (official list only), else leave blank.
Further to an ISLA request (January 2020), this field has been flagged optional as participants may not necessarily know the collateral to be received at the point of execution for non-cash loans. (SFTR-106)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.87 | Matching Date: 2022-04-01 | Tolerance: None | Agent Lender Data Provision: Yes
Description:
Price of unit of collateral component, including accrued interest for interest-bearing securities, used to value the security or commodity .
Best Practice:
If Field 2.75 (Type of Collateral Component) is populated with "SECU" or "COMM", a value (x18 numerical characters including up to x5 decimals or x11 numerical characters including up to x10 decimals) shall be provided, else it should be left blank.
ISLA advocated that this field be optional as participants may not, at the point of execution, know the collateral to be received. Although the field was not changed to optional, a conditional validation is acceptable based on the logic that Field 2.75 is populated with "SECU". (SFTR-107)
Status: Best Practice Finalised, Last Updated: 15/02/2023
Field 2.88 | Matching Date: 2022-04-01 | Tolerance: 0.0005 | Agent Lender Data Provision: Yes
Description:
Fair Market value of the individual collateral component expressed in price currency.
Best Practice:
Contrary to the Level III Guidelines of 6 Jan 2020 from ESMA where it is written that Field 2.88 (Collateral Market Value) must also be reported with a negative number whenever Field 2.76 (Cash Collateral Amount) or Field 2.83 (Collateral Quantity or Nominal Amount) is reported with a negative number.
SLEB Example (all figures are purely examples, the purpose of the table is to denote the signages):
| Action Type | Field 1.9 | Field 2.01 | Field 2.76 | Field 2.83 | Field 2.88 |
|---|---|---|---|---|---|
| NEWT/MODI/CORR | GIVE | 12345 | -100000 | -123456 | -123456 |
| NEWT/MODI/CORR | TAKE | 678910 | 150000 | 100000 | 999999 |
This field in a COLU message should include pending and settled collateral for non-cash collateral.
ESMA Guidelines Reporting under Articles 4 and 12 SFTR: 06 January 2020
101. The collateral update should be reported as relating to the date when it becomes effective (i.e. on the expected settlement date). However, some updates might be agreed between the counterparties, but due to reasons attributable to the counterparties or to third parties, such as CCPs or CSDs, might not be finalised. This would mean that a given collateral update report should be resubmitted with the final correct data. The temporary settlement failures, not impacting the collateral agreed to be provided, should not be reported.
333. Field 2.88 (Collateral Market Value) should be reported at fair value, excluding haircut. In other words, the collateral market value should include all of the collateral posted by the collateral provider, including pending but not-yet-settled collateral, before any haircut deduction. (SFTR-108)
Status: Best Practice Finalised, Last Updated: 28/09/2021
Field 2.89 | Matching Date: 2020-04-01 | Tolerance: Up to third digit after decimal. | Agent Lender Data Provision: Yes
Description:
For securities lending: collateral haircut, a risk control measure applied to underlying collateral applied either at ISIN or portfolio-level whereby the value of that underlying collateral is calculated as the market value of the assets reduced by a certain percentage
Best Practice:
If Field 2.75 is populated with "SECU" or "CASH", a value (x11 numerical characters including up to x10 decimals) shall be provided, otherwise, it shall be left blank. This field allows negative values.
The FSB and BCBS framework does not apply to SLEB. The ISLA SFTR Working Group agree that the calculation in the Level III could not be used as it assumed that all collateral was applied with the same haircut, which it does not.
Instead a risk profile (schedule) is applied to different asset classes (type) and country of registration (market), which results in different haircuts being applied. Therefore, recommendation is to not use the ESMA calculation and instead use the following, referring participants towards their legal agreements for haircut details and applied at a 'per ISIN' basis. Therefore this field should be reported as the margin percentage, for example;
For a 95% haircut, this field should be populated with '5'. Where no haircut is added this field should be reported as 0.
ESMA Guidelines Reporting under Articles 4 and 12 SFTR: 06 January 2020
335. For SLEB, Field 2.89 (Haircut or margin) should only include haircuts that apply to the collateral side. Margin requirements will instead be captured through the Field 2.88 (Collateral Market Value) and the Field 2.76 (Cash Collateral Amount). Thus, the collateral market value and cash collateral amount should also be updated with any add-ons (i.e. loan mark-ups, that start applying in the course of the transaction). (SFTR-109)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.90 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: Yes
Description:
Code that classifies the risk of the security used as collateral.
Best Practice:
If Field 2.75 (Type of Collateral Component) is populated with "SECU", at least one code pertaining to the collateral quality shall be provided, of which there are 4 options (x4 alphabetical characters), else the field should be left blank.
ISLA made a recommendation to ESMA that these fields be made non-matching to avoid reconciliation breaks. These breaks would happen where counterparts sourced rating data from different agencies. The recommendation was not accepted.
ESMA Final Report Reporting under Articles 4 and 12 SFTR: 06 January 2020 :
433: A small number of respondents supported reporting the lowest applicable credit quality step as the default option. However, the large majority rejected this approach.
434. ESMA decided to forego this approach and to leave it to market participants to report a value that reflects their internal assessment and what is on their books. However, this is likely to lead to a higher rate of reconciliation breaks. (SFTR-110)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.91 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: Yes
Description:
Maturity of the security used as collateral.
Best Practice:
If Field 2.75 (Type of Collateral Component) is populated with "SECU", this field shall be populated in a common input format: YYYY-MM-DD. When maturity date is not applicable (e.g. perpetual bonds and equities), use default code "9999-12-31". (SFTR-111)
Status: Under Review, Last Updated: 26/04/2021
Field 2.92 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: Yes
Description:
Jurisdiction of the issuer of the security used as collateral. In case of securities issued by a foreign subsidiary, the jurisdiction of the ultimate parent company shall be reported or, if not known, jurisdiction of the subsidiary.
Best Practice:
If Field 2.75 (Type of Collateral Component) is populated with "SECU", a valid ISO 3166-1 country code shall be provided, else leave blank.
Where populated, the jurisdiction should correspond to the ‘Legal address’ in GLEIF data. (SFTR-112)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.93 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: Yes
Description:
LEI of the issuer of the security used as collateral.
Best Practice:
See ESMA LEI Statement published on 13 April 2021.
See also FCA April 2021 SFTR news from 6 April 2021.
Both authorities have extended the forbearance period for the reporting of third country issuer LEIs for UK and EU SFTR respectively until:
FCA: "April 13th 2022, at the earliest."
ESMA: "October 11th 2022, at the latest."
When the forbearance period comes to an end, and where no Issuer LEI is available, each firm would then decide whether to:
a) Leave the field blank, causing a validation error (NACK)
b) Provide an alternate Issuer LEI (e.g. GLEIF LEI, main exchange)
ISLA is continuing to work with industry participants, exchanges, vendors and numbering associations to improve LEI coverage globally.
Please see the ANNA ISIN UNIFORM GUIDELINES RELATING TO ISO 6166 (9th edition) which explains numbering association guidelines regarding Issuer LEI use in ISIN registration in chapter 9 'LEI & ISIN Linkage'.
When the LEI of an ETF is being reported, if the umbrella company of the ETF is the issuing entity then the LEI of the umbrella company should be reported in this field. (SFTR-113)
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)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.95 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: Yes
Description:
Indication whether the collateral taker can reuse the securities provided as a collateral.
Best Practice:
If Field 2.75 (Type of Collateral Component) is populated with "SECU", this field shall be populated and should contain either "TRUE" or "FALSE", else it should be left blank.
If the market trading agreement (GMSLA, GMRA, etc.) under which the SFT is governed permits re-use, then participants may decide that Field 2.95 (Available for Collateral Re-use) must be populated with "TRUE", regardless of any other client contracts (SLAA) or prevailing regulations (UCITS) that actually preclude re-use, otherwise populate with "FALSE".
At transactional level for repos it has been opined that this should be populated as "TRUE", as this contractually reflects the GMRA, even if UCITS funds are not actually permitted to re-use due to restrictions placed by ESMA.
Many participants have advised that they plan to always report re-use as zero for securities lending and borrowing activity, which means populating Field 2.95 (Availability for Collateral Reuse) as "FALSE", due to ESMA restrictions which forbids it, as do the triparty agreements. (SFTR-115)
Status: Under Review, Last Updated: 03/07/2023
Field 2.96 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: Yes
Description:
If the collateral basket can be identified with an ISIN, the ISIN of the collateral basket. If the collateral basket cannot be identified with an ISIN, this field should be populated with 'NTAV'.
Best Practice:
Where Field 2.04 is populated with SLEB
For NEWT template:
If Business Use Case = Uncollateralised SLEB and Field2.72 = True
Then do not populate Field 2.96
If Business Use Case = Individually Collateralised SLEB (Cash Rebates) and Field 2.72 = false and Field 2.73 (NE) = False and type of collateral is cash
Then do not populate Field 2.96
If Business Use Case = SLEB against Net Exposure Collateral and Field 2.72 = FALSE and Field 2.73 (NE) = TRUE
Then populate with 'NTAV'
For CORR Template:
If Business Use Case = Uncollateralised SLEB and Field 2.72 = True
Then do not populate Field 2.96
If Business Use Case = Individually Collateralised SLEB (Cash Rebates) and Field 2.72 = FALSE and Field 2.73 (NE) = FALSE and type of collateral is CASH
Then do not populate Field 2.96
If Business Use Case = SLEB against Net Exposure Collateral and Field 2.72 = FALSE and Field 2.73 (NE) = TRUE
Then populate with 'NTAV' (as per NEWT)
For COLU Template:
If Business Use Case = Uncollateralised SLEB
Then not applicable as no COLUs are reported for Uncollateralised SLEBs
If Business Use Case = TB COLU for Individually Collateralised SLEB (Cash Rebates) and Field 2.73 = False type of collateral is cash
Then do not populate Field 2.96
If Business Use Case = NE COLU for SLEB against Net Exposure Collateral and Field 2.73 = TRUE
Then do not populate Field 2.96 (SFTR-116)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.97 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: Yes
Description:
If the transaction is cleared and is included in a portfolio of transactions for which margins are exchanged, this portfolio should be identified by a unique code determined by the reporting counterparty, dependent on Field 2.05 (Cleared) being populated with “TRUE”.
Best Practice:
If the Field 2.05 (Cleared) is populated with "TRUE" a value (x52 alphanumerical characters including up to x4 special characters) shall be provided, else it should be left blank. (SFTR-117)
Status: Best Practice Finalised, Last Updated: 26/04/2021
Field 2.98 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: Yes
Description:
Reportable action types for trade events.
Best Practice:
This field shall contain at least one code pertaining to action type shall be provided, of which there are 8 options (x4 alphabetical characters).
For lifecycle review points please see the "SFTR Guidelines Trade Lifecycle Review 25 February 2020" on the ISLA website: https://www.isla.co.uk/regulation-and-policy/markets-regulation/securities-financing-transactions-regulation-sftr/ (SFTR-118)
Status: Under Review, Last Updated: 03/07/2023
Field 2.99 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: Yes
Description:
Indication whether the report is done at trade or position level. Position level report can be used only as a supplement to trade level reporting to report post-trade events and only if the individual trades in fungible products have been replaced by the position.
Best Practice:
This field shall contain at least one code pertaining to the reporting level shall be provided, of which there are 2 options (x4 alphabetical characters).
It is recommended that "TCTN" is used in all cases for individual transaction reporting to support the agency lending model, as allocations require the notion of different reporting counterparties (Field 1.03).
Bank owned assets such as those in a principal model, will naturally align. (SFTR-119)
Sorry! You need to be logged in to access this document.
This premium content is available to ISLA member firms only. If you do not have a login, please use the ‘Request Login’ within the Member login.
If your firm is not a member of ISLA, find out more information regarding our current members, the types of membership we offer, and the benefits of joining.
Find out moreContent access not allowed
This content is not allowed on this membership level.
Change your membershipContent access not allowed
This content is not allowed on this membership level.
Change your membershipAlready a member? Login to your account
Interested in becoming a member?
ISLA’s members span the breadth and depth of the securities lending industry, and there are many benefits of joining the Association’s network.
Become a member today
SFTR Best Practice 
