ESMA Guidelines on reporting under Articles 4 and 12 SFTR

29/03/2021 | ESMA70-151-2838 EN

Guidelines
Reporting under Articles 4 and 12 SFTR

ESMA REGULAR USE
1

ESMA REGULAR USE
2
Table of Contents
1 Legislative references, abbreviations and definitions.........................................................6
2 Scope................................................................................................................................7
3 Purpose.............................................................................................................................8
4 General Principles .............................................................................................................8
4.1 Reporting start date....................................................................................................8
4.2 Determining the number of reportable SFTs...............................................................9
Market transactions that do not fall under the definition of an SFT ......................9
Aspects related to all types of SFTs ....................................................................9
Aspects related to repos....................................................................................10
Aspects related to BSB/SBB .............................................................................11
Aspects related to securities lending and borrowing..........................................11
Aspects related to SFTs involving commodities.................................................12
Aspects related to margin lending .....................................................................13
4.3 Reporting of CCP-cleared SFTs...............................................................................14
4.4 Allocation of responsibility under Article 4(3) SFTR..................................................15
General case.....................................................................................................15
Third Country - Financial Counterparties (TC-FC).............................................15
Funds................................................................................................................15
4.5 Voluntary delegation of reporting..............................................................................15
4.6 Application of SFTR reporting obligations to SFTs concluded by branches ..............16
Application of SFTR reporting obligations to SFTs concluded by non-EU entities
with EU branches ............................................................................................................16
Determination of reportable SFTs when concluded by branches.......................16
4.7 Reporting by an NFC................................................................................................17
4.8 Action types..............................................................................................................18
Applicable action types......................................................................................18
Full snapshot versus partial reporting of amendments to SFTs .........................18
Sequence between action types for the different types of messages.................19
4.9 Timely reporting of conclusion, modification and termination of an SFT ...................22
Conclusion of an SFT........................................................................................22
Modification and correction of an SFT...............................................................23
Collateral updates .............................................................................................24
Valuation, margin and reuse updates ................................................................24

ESMA REGULAR USE
3
Termination of an SFT.......................................................................................25
Overview of reporting timelines per type of report and action type.....................26
4.10 Mapping business events to action types and levels ................................................26
4.11 Identification of a CSD participant ............................................................................33
4.12 Determining counterparty side..................................................................................33
General case.....................................................................................................33
CCP-cleared SFTs ............................................................................................34
Reporting of unsecured lending/borrowing of securities ....................................34
Reporting of counterparty side in the case of net exposure collateralisation......34
4.13 Price and value fields ...............................................................................................34
Timing of valuations ..........................................................................................34
Calculation method for valuations......................................................................34
4.14 Reporting of CFI for a security used as collateral .....................................................35
4.15 Backloading..............................................................................................................35
4.16 UTI generation and structure....................................................................................36
4.17 Identifying and reporting on beneficiaries .................................................................38
4.18 Identification of issuer of securities and securities ....................................................38
4.19 Procedure when a counterparty undergoes a corporate action.................................39
4.20 Reporting in the phased-in period.............................................................................40
5 SFTR Tables of fields......................................................................................................40
5.1 Counterparty data ....................................................................................................42
Non-cleared SFTs concluded by UCITS fund, and the UCITs management company
delegates reporting to a third party ..................................................................................44
Non-cleared SFTs concluded by AIF...............................................................................44
Non-cleared SFTs where fund portfolio management is outsourced................................44
Non-cleared bilateral SFTs between headquarters............................................44
Non-cleared bilateral SFT between branches....................................................46
Non-cleared bilateral SFT with beneficiaries .....................................................48
Non-cleared SFT with brokers, settled with a custodian bank............................49
Non-cleared SFT with broker, agent lender and tri-party agent .........................51
Non-cleared SFT with broker, agent lender and tri-party agent, settled with a CSD participant different from any of the entities and voluntary delegation of reporting to a thirdparty. 53
Cleared SFT with broker, agent lender, tri-party agent ......................................55

ESMA REGULAR USE
4
Cleared SFT with broker, agent lender, tri-party agent settled with a CSD participant different from any of the entities and voluntary delegation of reporting to a third party 57
Non-cleared SFTs concluded by UCITS fund....................................................59
Non-cleared SFTs concluded by UCITS fund, and the UCITs management
company delegates reporting to a third party...................................................................61
Non-cleared SFTs concluded by AIF.................................................................63
Non-cleared SFTs where fund portfolio management is outsourced..................64
5.2 Loan and Collateral Data..........................................................................................66
Reporting of action types at transaction level and position level. .......................66
5.3 Loan Data ................................................................................................................78
Reporting of event date.....................................................................................78
Reporting of cleared / non-cleared SFT.............................................................78
Trading venue ...................................................................................................85
Master agreement section.................................................................................85
Conclusion and start of the transaction .............................................................88
Term of the SFT................................................................................................89
Termination optionality ......................................................................................91
General and Specific collateral arrangements ...................................................91
Fixed or floating rates........................................................................................94
Repo and BSB/SBB principal amounts..............................................................98
Loan side in securities lending ..........................................................................98
Securities ..........................................................................................................99
SFTs involving commodities – commodities lending........................................104
Cash rebate SLB.............................................................................................106
Fee-based SLB: Non-cash collateral SLB, Cash pool SLB and Uncollateralised SLB 107
Margin loan amount and short market value....................................................108
5.4 Collateral data........................................................................................................111
Reporting of collateralisation of an SLB...........................................................111
Collateralisation...............................................................................................112
Cash collateral ................................................................................................119
Reporting of zero collateral..............................................................................120
Security collateral fields...................................................................................121
Variation margining at transaction level for non-centrally cleared SFTs...........131

ESMA REGULAR USE
5
Variation margining for non-centrally cleared SFTs in the case of collateralisation
on a net exposure basis ................................................................................................140
Prepaid collateral for SLB................................................................................181
Portfolio of cleared transactions ......................................................................183
5.5 Margin data ............................................................................................................183
CCP interposing itself between the two counterparties that are clearing members 184 CCP interposing itself between the two counterparties that are not clearing
members .......................................................................................................................184
Reporting of margin information ......................................................................184
5.6 Reuse data, cash reinvestment and funding sources .............................................186
Collateral reuse...............................................................................................186
Cash collateral reinvestment ...........................................................................193
Zero non-cash collateral reuse and cash reinvestment....................................200
Funding sources..............................................................................................201
6 Rejection feedback........................................................................................................202
7 Reconciliation feedback.................................................................................................204
8 Missing collateral feedback ...........................................................................................206
9 How to provide information to authorities.......................................................................207
9.1 Timelines to setting up data access........................................................................207
9.2 Operational arrangements for data access.............................................................208

ESMA REGULAR USE
6
1 Legislative references, abbreviations and definitions Legislative references AIFMD Directive 2011/61/EU of the European Parliament and of the Council of 8 June 2011 on Alternative Investment Fund Managers (AIFMs) Collateral Directive Directive 2002/47/EC of the European Parliament and of the Council of 6 June 2002 on financial collateral arrangements Consumer Credit Directive Directive 2008/48/EC of the European Parliament and of the Council of 23 April 2008 on credit agreements for consumers and repealing Council Directive 87/102/EEC ITS on reporting Commission Implementing Regulation (EU) 2019/363 of 13 December 2018 laying down implementing technical standards with regard to the format and frequency of reports on the details of securities financing transactions (SFTs) to trade repositories in accordance with Regulation (EU) 2015/2365 of the European Parliament and of the Council and amending Commission Implementing Regulation (EU) No 1247/2012 with regard to the use of reporting codes in the reporting of derivative contracts EMIR European Market Infrastructures Regulation – Regulation (EU) 648/2012 of the European Parliament and Council on OTC derivatives, central counterparties and trade repositories MAR Regulation (EU) No 596/2014 of the European Parliament and of the Council of 16 April 2014 on market abuse (market abuse regulation). MiFIR Regulation (EU) No 600/2014 of the European Parliament and of the Council on markets in financial instruments and amending Regulation (EU) No 648/2012 MMSR Regulation (EU) No 1333/2014 concerning statistics on the money markets Mortgage Credit Directive Directive 2014/17/EU of the European Parliament and of the Council of 4 February 2014 on credit agreements for consumers relating to residential immovable property and amending Directives 2008/48/EC and 2013/36/EU and Regulation (EU) No 1093/2010 REMIT Regulation (EU) No 1227/2011 of the European Parliament and of the Council of 25 October 2011 on wholesale energy market integrity and transparency

ESMA REGULAR USE
7
RTS on reporting Commission Delegated Regulation (EU) 2019/356 of 13 December 2018 supplementing Regulation (EU) 2015/2365 of the European Parliament and of the Council with regard to regulatory technical standards specifying the details of securities financing transactions (SFTs) to be reported to trade repositories RTS on data access Commission Delegated Regulation (EU) 2019/357 of 13 December 2018 supplementing Regulation (EU) 2015/2365 of the European Parliament and of the Council with regard to regulatory technical standards on access to details of securities financing transactions (SFTs) held in trade repositories RTS on data verification Commission Delegated Regulation (EU) 2019/358 of 13 December 2018 supplementing Regulation (EU) 2015/2365 of the European Parliament and of the Council with regard to regulatory technical standards on the collection, verification, aggregation, comparison and publication of data on securities financing transactions (SFTs) by trade repositories SFTR 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 – also referred to as the regulation TS RTS on reporting (Commission Delegated Regulation (EU) 2019/356) and ITS on reporting (Commission Implementing Regulation (EU) 2019/363) UCITS Directive 2009/65/EC of the European Parliament and of the Council of 13 July 2009, on the coordination of laws, regulations and administrative provisions relating to undertakings for collective investment in transferable securities (UCITS) 2 Scope Who? These guidelines apply to counterparties to SFTs as defined in Article 3(2) SFTR, the trade repositories as defined in Article 3(1) SFTR and competent authorities. What? These guidelines apply in relation to the SFT reporting obligation as provided in Article 4 SFTR, the TR obligations under Articles 5(7) and 12 SFTR, as well as the reporting start date as determined in Article 33(2) SFTR When?

ESMA REGULAR USE
8
These guidelines apply from the day following their publication on ESMA website or from the date on which the relevant provisions to the entities as determined by Article 33(2) SFTR apply, whichever date is later. The counterparties, entities responsible for reporting and the report submitting entities are encouraged to use them starting from the first day on which the relevant reporting obligation in accordance with Article 33(2)(a) SFTR becomes applicable. 3 Purpose These Guidelines are based on Article 16(1) of ESMA’s Regulation. These guidelines aim to clarify a number of provisions of SFTR and to provide practical guidance on the implementation of some of those provisions. The Guidelines will contribute to the reduction of costs along the complete reporting chain - the counterparties that report the data, the TRs which put in place the procedures to verify the completeness and correctness of data, and the authorities, defined in Article 12(2) SFTR, which use the data to supervise risks to financial stability. The guidelines provide clarity as to the following aspects:
a. the reporting start date when it falls on a non-working day. b. the number of reportable SFTs;
c. the population of reporting fields for different types of SFTs;
d. the approach used to link SFT collateral with SFT loans; e. the population of reporting fields for margin data; f. the population of reporting fields for reuse, reinvestment and funding sources data; g. the generation of feedback by TRs and its subsequent management by counterparties, namely in the case of (i) rejection of reported data and (ii) reconciliation breaks; and h. the provision of access to data to authorities by TRs. 4 General Principles
4.1 Reporting start date
The reporting obligation under Article 4(1) SFTR applies according to the relevant date of the application specified in Article 33(2)(a)(i) SFTR. The first phase of the obligation becomes applicable on 11 April 2020, which is Saturday. Pursuant to Article 4(1) SFTR the counterparties should comply with their reporting obligation no later than the working day following the conclusion, modification or termination of the transaction. The entities referred under Article 33(2)(a)(i) SFTR, established in EU member states where 13 April is not a public holiday, i.e. it is a working day, should start reporting by 13 April 2020 the SFTs concluded on or after 11 April 2020.

ESMA REGULAR USE
9
The entities referred under Article 33(2)(a)(i) SFTR, established in EU member states where 13 April is a public holiday, i.e. it is not a working day, should start reporting by 14 April 2020 the SFTs concluded on or after 11 April 2020. The same approach should be followed for the rest of the dates of application of the reporting obligation.
4.2 Determining the number of reportable SFTs
Pursuant to Article 1(1) ITS on reporting, counterparties should submit their SFT reports in a common electronic and machine-readable form and in a common XML template in accordance with the ISO 20022 methodology. To facilitate this, these Guidelines include the relevant XSD component applicable to the different use cases. Market transactions that do not fall under the definition of an SFT The following transactions should not fall under the definition of an SFT and should not be reported under SFTR:
a. Retail client lending governed by consumer credit legislation b. Private banking loans and Lombard loans not related to securities financing
c. Syndicated lending and other corporate lending for commercial purposes
d. Overdraft facilities of custodians and CCP daylight lending facilities e. Fails-curing intraday credit / overdraft f. Central bank auto-collateralisation g. Give-ups and take-ups in the execution and clearing chain h. Commodities transactions entered into for operational and/or industrial purposes
i. Transactions involving emission allowances
Aspects related to all types of SFTs
A party to an SFT that acts on a principal basis, by transacting on its own account, should be referred to as a counterparty of an SFT. An entity that facilitates, arranges or otherwise participates, but not on a principal basis nor on its own account, in the conclusion of an SFT, either on the loan or on the collateral side, and acts on behalf of a client, should not be defined as a counterparty but as either broker, agent lender, tri-party agent or CSD participant, as applicable. One entity might have several roles in an SFT. The specific population of the counterparty data is detailed in Section 5.1. Therefore, it is the obligation of the counterparties to identify which type of SFT they have concluded. Similarly, as detailed in Annex 1 of the RTS on reporting and in Section 5.2 of this document, not all the fields are applicable to all SFTs, hence the counterparties should undoubtedly agree on the type of SFT concluded.

ESMA REGULAR USE
10
An SFT is reportable when there are two counterparties to it, or where one of the parties to the SFT is an individual that is not an undertaking and the other is a counterparty as defined in SFTR. There is no SFT with more than a pair of counterparties. In the case of an allocation of loans between two or more collateral takers and two or more collateral providers, an SFT is defined as each collateralized loan of securities, cash or commodities, between two counterparties. In case the conditions in paragraph 12 are fulfilled, regardless of their legal nature, investment funds are deemed to be counterparties to an SFT. Specifically, in the case of sub-funds, similarly to what is done under EMIR, sub-funds usually have LEI. In that case it should be reported as counterparty on a standalone basis. The relevant loan and collateral information should refer to the SFTs concluded by that sub-fund. In case the sub-fund is not a party to the SFT, please refer to Section 4.17. In the case of cleared SFTs, each of the SFTs between the CCP, its clearing members and the clients of those, and so on, constitutes a separate SFT and should be reported with a different UTI. Where the SFT is concluded on a trading venue and cleared on the same day, as provided in Article 2(2) of the RTS on reporting, it shall be reported after it has been cleared, i.e. the intermediate give-ups and take-ups should not be reported. For detailed information on reporting of cleared SFTs, please refer to Section 4.3. Furthermore, in the case of fails-curing SFT, the CSD should report as its counterparties the relevant CSD participants and not the clients of those. This is applicable also when the SFT is executed against an omnibus account, Therefore, except for the transactions included in Article 2(3) of SFTR and those referred to in Section 4.2.1, all other SFTs should be reported as detailed in the subsequent section of these Guidelines. It is worth noting that the SFTs referred to under Article 2(3) are reportable under Regulation 600/2014. Aspects related to repos In the case of collateralised loans in more than one currency, those constitute separate SFTs and should be reported with separate UTIs. The reporting of each repo should be made in accordance with the general principles for reporting of a repo transaction:
a. Report the applicable principal amounts and UTI and the individual collateral components, if such exist, for each separate currency; and b. Report the relevant collateral on a net exposure basis, i.e. the one that covers the repos, but it is not specifically allocated to any of them and ensure that it could be linked through the relevant fields. When the repurchase price is expressed in a currency different from the one in which the purchase price is expressed, but still relates to the same repo, then the currency for the far leg should be converted to the currency of the near one for the purpose of reporting the relevant information on price and principal amounts. Please refer to the guideline on the use of FX rates when reporting market values in Section 4.13.1 to ensure that a consistent figure is submitted for this field.

ESMA REGULAR USE
11
Where the collateral of repo is taking a different form of transfer, which is still part of the collateral arrangements that are defined under the Collateral Directive, the counterparties should still report it as repo. Repos concluded under rules of other jursdictions, such as Gentan repos, should be reported accordingly and by providing complete and accurate details in accordance with the TS on reporting. Repos and reverse repos concluded by CCPs to invest (i) own assets for the purpose of liquidity maintenance, or (ii) clearing members’ assets provided as margin, are covered by the reporting obligation under Article 4 of SFTR. Repos and reverse repos should be reported by using the ISO 20022 XML template applicable to repo. Aspects related to BSB/SBB Certain BSB/SBB are governed by bilateral or master agreements. However, the specific annexes covering these SFTs are different from those pertaining to repos and reverse repos. Undoubtedly, the type of SFT concluded is BSB/SBB. Where the BSB/SBB is governed by a bilateral or master agreement or an annex to a master agreement, this agreement should be reported in the relevant fields, namely fields 9-11 of Table 2 on Loan and collateral data. Counterparties should strive to report the master agreements that are not included in the ITS on reporting in exactly the same way. Also relating to the master agreement, the field Master agreement version should be reported with the version applicable to the SFT that is being concluded. When counterparties find that certain types of BSB/SBBs are better reported by using the repo template, in case both counterparties agree, the counterparties should use the repo template to report those SFTs. BSB/SBB should be reported by using the ISO 20022 XML template applicable to BSB/SBB. Aspects related to securities lending and borrowing Following on the definition, the conclusion of an SLB is connected to the transfer of securities from the lender to the borrower. An SLB cannot have more than one ISIN transferred. If in the process of allocation by third-party entities, such as agent lenders, there is more than one ISIN to be transferred between a given pair of counterparties, then a different SFT for each ISIN should be reported. Given that Article 4(1) of SFTR requires the reporting of conclusions, modification and termination of SFTs no later than the following working day, all SFTs that have been concluded should be reported. This includes all SFTs that were generated even though they might not be settled. Some types of asset managers were not considered in the different scenarios presented. This includes funds that aggregate securities in an asset pool and can lend them. These funds trade through a broker that will act as an agent and lend a security for a given

ESMA REGULAR USE
12 quantity out of the pool of assets of the funds. A direct transaction will be confirmed between the counterparty and the pool. At the end of the day the final allocation is made, and individual confirmations are sent to each fund participating in the pool. The details are also sent to the counterparty and settlement takes place through one single transfer out of the common depositary of all the concerned funds. In this particular case, and following the general principle included in paragraph 15, a separate SFT for each pair of counterparties and ISIN should be reported to the TRs by the counterparties. In the case of securities lending in a CCP setup with an asset pool it is not possible to report intraday lifecycle activity where only net new loan positions are allocated to borrower and lender end of day. Therefore, in a CCP setup, intraday loans should be reported, although there might not be necessary a collateral allocated to those. Collateral should be reported for all other SLBs, where the Field (2.72) “Uncollateralised SL flag” is polulated with “false”, including the settled net new loan needs to be reported in the trade report (on S+1). SLB should be reported by using the ISO 20022 XML template applicable to SLB. Cash-driven SLBs, also known as “reverse securities loans”, have to be reported as a repo. Where a cash-driven SLB is reported using the repo fields, it should be noted that the Master agreement type should reflect the relevant underlying agreement, e.g. GMSLA. Aspects related to SFTs involving commodities The execution of the SFT should be structured in such a way that the beneficial owner neither loses its economic ownership of the commodities, nor takes on new market risk in the commodity. Repo/reverse repo transactions involving commodities are characterised by the presence of a (repurchase) agreement. The commodities can be transferred by way of outright title transfer or pledge. However, when adhering to the scope of SFTs involving commodities, when the sale and repurchase does not qualify as a repo, it shoud be a BSB instead. In a commodities lending and borrowing (SLB) transaction, the collateral taker is the party that lends the commodities and the collateral giver borrows the commodities. Unlike repo/reverse repo and BSB/SBB where the commodity is deemed to be the collateral in the transaction. When reporting SFTs involving commodities, further to the relevant master agreements, the counterparties should assess the extent to which the type of SFT involving commodities that they are reporting could fit into the fields applicable to that SFT. This should help determine whether the transaction needs to be reported as a commodities lending or borrowing transaction, or as a repo/SBB or reverse repo/BSB collateralized with commodities. Furthermore, all SFTs as defined in Articles 3(7) to 3(10) SFTR, except margin lending, include a reference to the possible use of commodities as part of the SFT. BSB/SBB limits the use of
commodities to purchases and subsequent sales between the two counterparties (without market intermediary), whereas the commodities lending and

ESMA REGULAR USE
13 borrowing transactions and repos allow for both title transfer and pledge arrangements. Therefore, the counterparties should populate the type of collateral arrangement in Field
2.20 Method used to provide collateral, as appropriate.
SFTs involving commodities may sometimes be part of more complex structures that may include derivatives, such as futures and options. Only the parts of the overall structure that is the SFT should be reported. Derivatives used in such structures may be reportable under EMIR and/or MIFID and/or REMIT. Regarding the meaning of equivalent commodities and substituted commodities, ESMA clarifies the following:
a. equivalent commodities are the same type of commodities with similar characteristics and/or specifications that can replace the original commodities in the return leg as contractually agreed upon. b. substituted commodities are commodities that are pledged as collateral as substitution for the commodities that were originally pledged as collateral under the same transaction.
4.2.6.1 SFTs involving energy
A transaction (e.g. buy – sell-back of gas across zones with (alternative) financing objectives) can be a a REMIT reportable transaction with T+30 reporting timeframe and, at the same time, an SFT reportable by T+1. Therefore, where these types of transactions are sufficiently clear for unambiguous classification as SFTs used to finance commodities they are reportable as per the relevant reporting template. Aspects related to margin lending It is expected that one and only one margin lending transaction exists between each pair of counterparties at a given point in time, except where the entities agreed contractually to have more than one base currency and the margin loans are determined in relation to each of them, in which case there should be a margin lending transaction per each base currency. This SFT will relate to any margin loan or a short market value in the base currency. UTIs for margin lending should only be generated when the facility has been drawn from at least once. In cases where a prime brokerage agreement has been signed but the facility has not been drawn yet, no report is required since there is no SFT yet. If at any point time both the margin loan and the short market value fall to zero, i.e. no credit in cash or securities is being extended, the client collateral held by the prime broker is no longer collateralising SFT exposure. It is being held for other non-SFT liabilities. The prime broker and the client should (i) report the cash collateral at zero to denote that there is no collateral and (ii) cease to report collateral until such time as a margin loan or SMV exposure again exists.

ESMA REGULAR USE
14
The transaction should not be reported with Action type “ETRM”, but rather with action type “MODI”. In this case, a collateral update message (COLU) indicating zero as a value for cash collateral is also expected to be received so as to avoid any misrepresentation of the collateral being used. For reporting of zero collateral, please refer to section 5.4.4. In the case of margin loans, counterparties should not report collateral components that are different from securities and cash. The reporting of client’s short market value should not be based on the recognition in accounting (that is either trade date or settlement date accounting) by the prime broker (IAS 39.38 Financial Instruments: Recognition and Measurement). The reporting of short market value should be made in the same way in which the settlement of the loan and collateral is reported. Thus, the counterparties should calculate the short market value on the basis of the intended settlement date and securities that are expected to be delivered. Moreover, when the portfolio of the prime brokerage client does not involve securities trading, then the reporting of credit extension to these clients has no value from SFTR perspective and should be avoided in order to prevent the collection of large amounts of irrelevant information.
4.3 Reporting of CCP-cleared SFTs
The reporting at position level is applicable to CCP-cleared SFTs and is optional and complementary to the transaction-level reporting. Reports at position level can be submitted when certain conditions are met1 . a. The legal arrangement is such that the risk is at position level, the trade reports all relate to products that are fungible with each other, and the individual trades have been replaced by the position. This is the case when novation takes place after netting of individual trades, the netted position results in a new contract, and a new UTI is generated for it. This could be the case, for example, between a clearing member and a CCP. b. The original trades, i.e. at transaction level, have been correctly reported. It is not permissible to report only positions.
c. Other events that affect the common fields in the report of the position are separately
reported. d. The original trade reports (point b above) and reports relating to other events (point c above), where applicable, have reached a suitable “end of life state”. This should be achieved by sending early termination messages and then reporting the net position either as a new position or as an update to the existing position. e. The report of the position is made correctly filling in all the applicable fields in the counterparty-specific and transaction data, and, as appropriate, margin and collateral reuse table of fields. 1 Please refer to Paragraph 84 of the CP on Guidelines on reporting under SFTR

ESMA REGULAR USE
15
If these conditions are fulfilled, then the reporting of subsequent updates, including valuation updates, collateral updates and other modifications and lifecycle events can be applied to the report of the position (as modifications etc., and keeping the same value of the UTI on the CCP cleared position) and not to reports of the original trades/events. The position-level report should be identified with its own UTI, which is a persistent identifier of that position, i.e. it does not change following any modifications of the position. It is reinstated that for the position-level reporting to take place, the cleared SFTs should first be reported at transaction level with Action Type “POSC” (even if cleared on the same day), and only subsequently the lifecycle events can be reported at position level. Please refer to Section 5.2.1 for the scenario illustrating the required steps to report at position level.
4.4 Allocation of responsibility under Article 4(3) SFTR
General case
NFC should communicate with FC whether they qualify as small NFC or not, as well as update the FC on any potential changes in their status. Third Country - Financial Counterparties (TC-FC) Once the equivalence of a given TC is declared by the EC, in the case of SFT concluded between a TC-FC, with a branch in the Union, and a SME-NFC, where the TC-FC and the SME-NFC have fulfilled the reporting obligations of that third country, neither the TC-FC nor the SME-NFC should report the SFT under SFTR. Regarding SFTs concluded between an TC-FC outside the scope of application of SFTR (i.e. not covered by Article 2(1)(a)(ii) of SFTR) and an SME NFC, such SFTs should either be reported directly by the SME NFC to a TR, or otherwise make use of the possibility for delegation included in Article 4(2). Funds Where the allocation of responsibility under Article 4(3) SFTR is not applicable to the AIFM, i.e. the AIFM is not subject to SFTR, the responsibility to report SFTs to a TR remains with the fund.
4.5 Voluntary delegation of reporting
In cases of delegation of reporting the delegating counterparty (caught by the reporting obligation) should provide the report submitting entity with all the details of the SFT in a timely manner, and the counterparty is responsible for ensuring that those details are correct. At the same time, the report submitting entity should ensure that the reporting counterparties are informed about the data reported on their behalf, the relevant TR data processing results and relevant reporting or data quality issues if any arise.

ESMA REGULAR USE
16
4.6 Application of SFTR reporting obligations to SFTs concluded by
branches
Application of SFTR reporting obligations to SFTs concluded by non-EU entities with EU branches In line with the purpose of SFTR and in consistency with EMIR, ESMA considers that the term conclusion is to be understood as related to the counterparty to the transaction, i.e. the counterparty where the SFT is booked. Determination of reportable SFTs when concluded by branches
Table 1 explains what should be reported with reference to branches of reporting
counterparties.
The final column entitled “Reportable under SFTR” refers to whether the transaction is subject to the reporting obligation under the SFTR. If not reportable, the transaction should not be reported, regardless of the location of the counterparties/branches. The rows of
Table 1 that are red show scenarios that are never reportable under the SFTR.
It is important to understand that for certain scenarios, the reporting obligation’s existence for the counterparty does not mean that the SFT must be reported, and vice versa, as explained in Table 1. For example, transactions concluded between two branches of the same legal entity, even when the counterparty (identified with LEI 1) is subject to the reporting obligation, are not reportable, as set out in the final column. The reason for this is that there are no two counterparties, but rather two extensions of the same one. Even when a branch has a LEI, Fields 1.3 “Reporting counterparty” and 1.11 “Other counterparty” should be populated with the LEI of the relevant headquarters, whereas the information of the relevant branch should be reported in Fields 1.17 “Branch of the reporting counterparty” and 1.8 “Branch of the other counterparty”. Field 1.12 “Country of the other counterparty” should be populated with the country code of the headquarters, not of the branch.
Table 1 - Reporting by branches
Reporting
Counterparty
Country of the reporting counterparty
Country of the branch of the reporting counterparty Reporting obligation Other Counterparty Country of the other counterparty Country of the branch of the other counterparty Reporting obligation Reportabl e under SFTR SFT1 LEI1 EU YES LEI1 EU AT YES NO SFT2 LEI1 EU YES LEI1 EU US YES NO SFT3 LEI1 EU BE YES LEI1 EU AT YES NO SFT4 LEI1 EU BE YES LEI1 EU US YES NO SFT5 LEI1 EU CH YES LEI1 EU US YES NO SFT6 LEI1 EU YES LEI2 EU YES YES SFT7 LEI1 EU YES LEI2 EU AT YES YES SFT8 LEI1 EU YES LEI2 EU US YES YES

ESMA REGULAR USE
17
Table 1 - Reporting by branches
Reporting
Counterparty
Country of the reporting counterparty
Country of the branch of the reporting counterparty Reporting obligation Other Counterparty Country of the other counterparty Country of the branch of the other counterparty Reporting obligation Reportabl e under SFTR SFT9 LEI1 EU BE YES LEI2 EU YES YES SFT10 LEI1 EU BE YES LEI2 EU AT YES YES SFT11 LEI1 EU BE YES LEI2 EU US YES YES SFT12 LEI1 EU US YES LEI2 EU YES YES SFT13 LEI1 EU US YES LEI2 EU AT YES YES SFT14 LEI1 EU US YES LEI2 EU US YES YES SFT15 LEI1 EU YES LEI3 US NO YES SFT16 LEI1 EU YES LEI3 US CH NO YES SFT17 LEI1 EU YES LEI3 US AT YES YES SFT18 LEI1 EU BE YES LEI3 US NO YES SFT19 LEI1 EU BE YES LEI3 US CH NO YES SFT20 LEI1 EU BE YES LEI3 US AT YES YES SFT21 LEI1 EU US YES LEI3 US NO YES SFT22 LEI1 EU US YES LEI3 US CH NO YES SFT23 LEI1 EU US YES LEI3 US AT YES YES SFT24 LEI4 US NO LEI3 US NO NO SFT25 LEI4 US AT YES LEI3 US NO YES SFT26 LEI4 US CH NO LEI3 US NO NO SFT27 LEI4 US NO LEI3 US AT YES YES SFT28 LEI4 US AT YES LEI3 US AT YES YES SFT29 LEI4 US CH NO LEI3 US AT YES YES SFT30 LEI4 US NO LEI3 US CH NO NO SFT31 LEI4 US AT YES LEI3 US CH NO YES SFT32 LEI4 US CH NO LEI3 US CH NO NO Note: AT and BE are ISO 3166-1 Alpha-2 codes for EU member states, US and CH are ISO 3166-1 Alpha-2 codes for non-EU member states. All codes are included for illustrative purposes. If the country of the branch is not provided, it should be interpreted that the SFT was concluded by the headquarters. The reporting of the data elements in italics might not be required.
4.7 Reporting by an NFC
ESMA recognises that a LEI may be unavailable in some scenarios; however, this scenario does not apply to NFC, established in the EU. All entities subject to SFTR should use LEI for the identification of the entities referred to in the relevant data fields. When the SFT is concluded between two NFCs, both of them should report it to a TR, though they can make use of the possibility to delegate the reporting under Article 4(2) to one of them or to a third party.

ESMA REGULAR USE
18
4.8 Action types
Applicable action types
Counterparties to an SFT should report the conclusion, modification and termination of an SFT. In case none of the details of the SFT, as expressed in the data fields, have changed, the counterparties should not report again details of the SFT. Valuation updates should be reported only when there is a change in the value of the securities on loan or used as collateral. In the case of collateral reporting, the counterparties should not report any intraday changes in the collateral, but only the end of day state. Action types are mutually exclusive. The reporting with each different action type bears different information for authorities both from business and data management perspectives. Therefore, the counterparties should strive to report the correct action type. Full snapshot versus partial reporting of amendments to SFTs In the case of amendments pertaining to the SFTs, both lifecycle events and corrections, counterparties should submit messages containing all applicable fields, including those which have not altered, still allowing for separate reporting between loan and collateral data. Additionally, it should be noted that valuation, collateral, margin and reuse updates are daily snapshot reports, in which case all relevant fields are required. Furthermore, given the daily reporting, it is expected that each of these snapshot reports will reflect the state at the end of the day, taking into consideration all relevant amendments that occurred during that day. Consequently, and having in mind T+1 reporting deadline, a counterparty is not expected to submit a correction report for collateral, valuation, margin or reuse for the current day or the previous working day. On the contrary, the corrections of the collateral, valuation, margin or reuse should be submitted only for the historical data in the case where a mistake in the reported information has been identified after the reporting deadline. In the case of the information concerning the loan side of the transaction, each modification should be reported as such and separately from the corrections of the loan data. In the case of various modifications occurring on the same day, they can be reported in a single report to the extent that this report will accurately reflect all changes The exact fields that are required for each type of report are specified in the validation rules. With respect to certain fields that should not be modified (e.g. Execution timestamp), the TRs are not expected to verify that the content of these fields is not amended when reported with Action Type “MODI” unless specified otherwise in the validation rules for a given field.

ESMA REGULAR USE
19
Sequence between action types for the different types of messages
Table 2, Table 3 and Table 4 provide information on the different combinations of the
sequence of action types that are not prohibited by the validation rules2 . The information presented in Table 2 applies to trade and position3 level reporting, whereas Table 3 and
Table 4 are specifically related to the reporting of margins for CCP-cleared SFTs and the
reporting of reuse.
Table 2 - Counterparty, Loan and Collateral data
Following Steps
New
Error
Termination
Modification
Valuation
Collateral
Correction
Position
Component
Previous steps
New x
Error
Termination x
Modification x
Valuation x
Collateral x
Correction x
Position
Component x x
2 Future changes in the definition of the validation rules may impact the content of the table. 3 Position component does not apply for reporting of the position level reporting

ESMA REGULAR USE
20
Table 3 - Margin update
Following step
New
Error
Margin update
Correction
Previous step
New x
Error
Margin update x
Correction x
Table 4 - Reuse, Cash Reinvestment and Funding Sources Data
Following step
New
Error
Reuse update
Correction
Previous step
New x
Error
Reuse update x
Correction x
When applying Table 2, Table 3 and Table 4, it is important to understand that they represent action types that can be reported at any point in time once another action type was submitted, rather than just the allowable immediate next step. To give an example, after sending a report with action type “Position component” it is allowed to send only a “Correction” or “Error”. However, after sending a “Correction”, any other type of report is allowed. A question may arise if an entity that has sent a report with action type “Position component” and subsequently sent a “Correction” for the same UTI as to whether the

ESMA REGULAR USE
21 entity can continue to send reports with other action types. The response is no. The action type “Correction” does not cancel/disapply the logical restrictions triggered by the previous submission of the report with action type “Position component”. Therefore, that entity can still submit only an “Error” or another “Correction” for the same action type. Similarly, it is not necessary to terminate the SFT with action type “Termination/early termination” again after submitting a correction for a previously terminated SFT (as the “Correction” does not impact the non-outstanding status of the trade). The reason why “Error” and “Correction” are the only acceptable action types after reporting with action type “Position component”, is that once an SFT is included in the position, all subsequent reports (incl. collateral updates) should be done at position level. Therefore, reports should be submitted with a different UTI (the one of the position), and the correct sequencing of these reports for that position should also be validated. The SFT reports should be sent in a chronological sequence in which the events occurred, in line with the requirements set out in the ITS. However, it is recognised that in the cases where an entity fails to report on time or become aware of the past submission of incorrect information, the entity should send the reports with past event dates thus breaking the chronological order. However, the TRs should review the “Event date” only to the extent that they verify that it is not a future date (this is captured explicitly in the validation rules) and:
a. in the case of “past” event dates (i.e. less than reporting date -1), these events do not alter the transactions after their maturity or termination, i.e. the reported event date is earlier than the maturity date and, if populated, the termination date (this is also reflected in the validation rules. TRs should also verify that the modifications sent with a past event date do not alter the previously reported maturity date. Furthermore, the TRs should not apply the reported change to the current Trade State Report (if the transaction is still outstanding) nor the past Trade State Report of the date for which the event was reported. b. in the case of event dates equal to the reporting date or the day preceding the reporting date, the TR should apply changes to the Trade State Report based on the sequence of submissions. The TRs should provide all accepted trade activity reports to the authorities, irrespective of the event date. The TRs should validate the correct sequence of reports based on the order of their submission, irrespectively of the content of the Field “Event date”. Given that some past events may be reported for the trades that matured or have been terminated, it is allowed to send “Modification”, “Valuation update” or “Collateral update” after the “Termination / early termination” (as long as the event date is prior or equal to the maturity/termination date) which is reflected in the Table 2. It should be noted that collateral substitutions after the termination event are not expected to be reported (unless the termination is cancelled). Therefore, the termination should not be reported before the effective date of the termination (please refer to Section 4.9.5) for more details on reporting of the terminations.

ESMA REGULAR USE
22
In the case where multiple past submissions were rejected by a TR, the counterparty should correct and resend them as soon as possible and maintaining the chronological order of the events. In the case where these previous reports concern events that occurred on the reporting date or day before and therefore would be considered by the TR for the purpose of providing Trade State Report (in line with the paragraph 83 above), the counterparty may also need to resubmit last report(s) to bring the record of the transaction to the most up-to-date state. With respect to action type “Error” it is important to note that once reported, it cannot be cancelled or otherwise “undone”. Therefore, if one of the two counterparties sends a report with this action type by mistake, the counterparties should take the following steps to continue reporting correctly:
a. The other counterparty should also send a report with action type “Error” for the same UTI. It will not be possible to use this UTI again. b. Both counterparties should agree on a new UTI for this transaction, report it with the action type “New” and the agreed new UTI and continue reporting of any subsequent lifecycle events using this UTI. One exception where submission of the action type “Error” may not require cancelling of the transaction by the other counterparty is a potential scenario in which one of the counterparties reports the transaction by mistake twice to two different TRs and wants to cancel only one, redundant submission. In this case, this counterparty should send a report with action type “Error” to one TR, while the same transaction remains open in the other TR and both counterparties can continue report with the same UTI. It should also be noted that this restriction is not applicable to the reporting of margins and reuse. For example, a counterparty may report reuse by mistake (when no reuse has taken place) in which case it should submit a reuse report with Action Type “Error”. This should however not prevent this counterparty from reporting reuse at a later stage if needed.
4.9 Timely reporting of conclusion, modification and termination of
an SFT
Conclusion of an SFT
If an SFT that is concluded is subsequently terminated (incl. when it is terminated due to a settlement failure), then the counterparties after reporting it with Action type “New”, should report it with Action Type “Termination/Early Termination). If the original SFT was reported with the Action Type “Position Component” and is subsequently terminated, the counterparties should not send a report with Action Type “Termination/Early Termination” for the original SFT, however the counterparties should send a report with Action Type “Modification” for the position in which the original SFT was included in order to remove this SFT from the position. Action type “Error” should only be used to cancel the transactions that never came into existence or that are out of the scope of the reporting obligation under SFTR. In the specific scenario where the counterparties agree to conclude a transaction which is conditional

ESMA REGULAR USE
23 upon registration with the CCP and the CCP rejects that transaction, the counterparties should terminate the SFT with Action Type “Error” because the agreed condition for the transaction to take place was not fulfilled, therefore the transaction never came into existence. Furthermore, it should be noted that a temporary settlement failure, that does not result in a termination of the SFT, should not be reported. In the specific case of margin lending, the conclusion of the SFT should be reported when there is short market value or net cash debit balance (from the client’s perspective) for the first time, and the execution timestamp should be populated accordingly. Modification and correction of an SFT A modification to an SFT comprises the reporting of the following action types:
“Modification” and “Correction”. The timeline for reporting is the same as for the conclusion of a trade, meaning that from the point in time when a modification is effective, it becomes reportable. Where applicable, e.g. for the changes on the loan side of SLB, this should be understood as the intended settlement date. Counterparties should report only the modifications that have taken place, i.e. they should not report modifications that were agreed but will become effective in the future. To give an example, if the counterparties agree to re-rate a repo on a future date, the re-rating should be reported only once the agreed date (the effective date of re-rating) is reached. Similar to the reporting of conclusions, the temporary settlement fails are not reportable as such unless they result in an amendment to the transaction, which then should be reported accordingly with the action type “Modification”. For example, if a partial return of the SFT was reported as a modification and subsequently it is cancelled due to a settlement failure, the counterparties should report another modification for this SFT in order to revert the changes stemming from the partial return. In the case of back-dated modifications to an SFT (e.g. when the counterparties to an SFT bilaterally agree to re-rate a transaction with an effective date in the past) the counterparties are not expected to resubmit reports for all subsequent activities from the effective date of the back-dated modification. It should be noted that the report with the back-dated modification should be reported with the correct past event date (reflecting the effective date of the modification). In this case, the TRs should not apply the modified data to the trade state report4 . With respect to correction, these should be reported as soon as the incorrectly reported data is identified. It is not necessary to send a correction report if, following a modification of an SFT, a counterparty has introduced incorrect information only in its own internal systems – in such cases the firm should only send the modification report containing final, correct data. 4 Please refer to the section 4.8.3 for further details concerning the impact of the Event date on the treatment of the reports by the TRs.

ESMA REGULAR USE
24
Collateral updates
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. In some other instances, the entities would have agreed already on some changes to the collateral but would have not yet carried them out. Counterparties should report only the collateral updates that have taken place, meaning that they should not report the collateral with the expected settlement date in the future. Collateral updates are daily snapshot reports that should reflect the state of the collateral at the close of a given day. The intraday changes to the collateral should not be reported. In the specific case of the intraday transactions for which the collateral is provided only intraday and goes to zero at the end of the day, the counterparties should report zero collateral. In the case of CCP-cleared on-venue transactions that are included in the position and reported with action type “Position component”, the collateral updates should be sent for the position in which these transactions were included, rather than for the original transactions. Finally, it should be noted that the last collateral update is expected to be submitted for the last day on which the corresponding SFT(s) is outstanding, and it should be submitted by the end of the following day. After submitting a report with action type “Early Termination” for the SFT(s) or after reaching the maturity date by the term SFT(s), the collateral updates should not be submitted for that SFT(s) (except for the missing late reports). In the specific case of margin lending, the collateral updates should be only sent where there is a short market value or net debit balance (from the client’s perspective). In the cases where the margin loan has not yet been drawn by the client, the counterparties should report neither an SFT transaction nor the corresponding collateral. There may also be scenarios where the margin loan has been drawn by the client (hence, the margin lending transaction and corresponding collateral were reported), and subsequently, the margin loan goes to zero. In these cases, if the counterparties do not decide to close the SFT, they should submit a “zero” collateral report for the first day on which the margin loan value is zero. Once the margin loan is used again by the client, the actual values of the collateral should be reported for this SFT. Valuation, margin and reuse updates In the case of valuation updates, the counterparties should send daily valuations by the end of the working day following the date of the valuation and populating
this date in the field “Event date”.

ESMA REGULAR USE
25
Margin updates should be reported when they become effective, i.e. on the expected settlement date, without considering temporary settlement failures. In the specific case of margins pre-paid to a CCP in advance of a portfolio of cleared trades, these should be reported on T+1 of the first applicable SFT in the related portfolio (linked by a portfolio code), rather than on the day following the date on which it was lodged. With respect to reporting of reuse, it is settlement-driven, meaning that counterparties should report only the value of reused collateral settled at the end of a given date. This settlement date should be reported as Event date in the reuse reports, which should be submitted by the end of the following day (i.e. settlement date + 1). The reuse reports are EOD snapshot reports, meaning that they should represent the reused collateral at the end of the day, rather than a change from the previously reported values (“delta report”). Termination of an SFT Counterparties should not send a report with Action Type “Termination/Early termination” when a fixed-term SFT reaches its maturity date and therefore is no longer outstanding. If the counterparties agree to terminate a fixed-term SFT prior to the maturity date or to terminate the open term SFT, they should either:
a. Submit a report with Action Type “Termination/early termination” where the expected settlement of the termination is for the same day as the notice of termination, or b. Submit a report with Action Type “Modification” where the expected settlement of the termination is the following day or later. In this case, the counterparties should modify the maturity date accordingly. Given that under the reporting logic envisaged in SFTR RTS/ITS (and consistent with the current reporting logic under EMIR), there is no possibility to “reopen” a transaction once it is terminated, the counterparties should not report the termination if it does not take place due to a settlement failure. In practice, if on the day following the agreed date of early termination, the counterparties become aware that the termination has not been settled on the expected settlement date they should not send the report with the action type “Termination/Early termination” until the termination is settled. If the termination is cancelled due to the settlement failure, the counterparties should not send the report with the Action Type “Termination/Early termination” as the SFT continues to be outstanding. Similarly, in the case of SFTs that approach their maturity date (either the original contractually agreed Maturity date (Field 2.14) or the Maturity date amended to report an early termination that was agreed in advance), if on the day following the maturity date the counterparties become aware that the back leg of the SFT has not been settled, they should send a modification report to amend the maturity date to a next day or other future day on which it is expected to settle. It should be noted that such amendment of the Maturity date would be possible only until the day following the maturity date, as from this date the SFT will no longer be outstanding and it will not be possible to “reopen” it. When the return settles successfully, the counterparties should not send additional reports, as

ESMA REGULAR USE
26 the SFT will be treated as non-outstanding starting from the day following the Maturity date. Overview of reporting timelines per type of report and action type
Table 5 specifies what should be reported as “Event date” for each type of report and
action type. The event date, by definition, also indicates what is a trigger for reporting, e.g. the expected settlement date in the case of collateral updates or the valuation date in the case of valuation updates. The actual reports should be submitted by the end of the working day following the event date.
Table 5 – Event date
Table Action type Event date
1&2 NEWT Date of conclusion of the contract ("trade date") 1&2 MODI Effective date of modification or, where applicable, the expected settlement date 1&2 CORR Date from which the correction should apply (typically the date for which previous incorrect data was reported) 1&2 ETRM Expected settlement date of the termination 1&2 EROR NA 1&2 COLU Expected settlement date 1&2 VALU Valuation date 3 NEWT Expected settlement date 3 MARU Expected settlement date 3 CORR Date from which the correction should apply (typically the date for which previous incorrect data was reported) 3 EROR NA 4 NEWT Actual settlement date 4 REUU Actual settlement date 4 CORR Date from which the correction should apply (typically the date for which previous incorrect data was reported) 4 EROR NA 4.10Mapping business events to action types and levels
Table 6 shows the mapping between the business events that take place through the
lifecycle of an SFT and the action types that are defined in the TS on reporting. Where the counterparties agree to early terminate and to replace an SFT, this should be reported accordingly. In such cases, the counterparties should first terminate the original SFT (by sending either “Termination/early termination” or “Modification” with amended maturity date) and then submit the report of the new transaction (with action type “New”). Similarly, to simplify the table, all events that result in a termination of an SFT are mapped to action type “Termination/early termination”, except for the event 44 that deals specifically with the reporting of the terminations. However, it is recognised that where the

ESMA REGULAR USE
27 termination of a transaction is agreed for another date in the future, it should generally be reported as a modification of the maturity date (with action type “Modification”), whereas termination on the same day should be reported with action type “Termination/early termination”. No additional action types can be included in the TS on reporting, therefore, the ones included in the TS should be used by counterparties when they report SFTs and the relevant business events pertaining to those. Business lifecycle events for the different types of SFTs should be reported with the following Action Types (Field 2.98) and relevant Levels (Field 2.99)5 .
Table 6 - Mapping business events to action types and levels
New
Event

Business / Trade
Event
Type of
SFT
Applicable
XML
Message6
Acti on
Type
Level Comments/examples
1 Backloading All Table 1 and
Table 2
NEW
T
TCTN
/
PSTN
2 Conclusion All Table 1 and
Table 2
NEW
T or
POS
C
TCTN
/
PSTN
This includes block/pooled/bulk transaction by agent for allocation to clients. This also includes any reportable transactions that are concluded for the purpose of settlement (autocollateralisation by (I)CSD, other credit facilities, intra-day autoborrowing of securities from (I)CSD). The settlement of the opening leg, including a delayed settlement that does not result in a termination or other changes to the SFT, should not be reported separately. In the case of margin lending, the conclusion should be reported when the credit is extended for the first time. 3 Roll-over into new identical transaction REPO Table 1 and
Table 2
NEW
T
TCTN
4 Extension REPO,
SLB
Table 1 and
Table 2
MOD
I
TCTN
This includes, e.g., extension of an extendible repo, ad hoc agreement to change the repurchase date of fixedterm repo or an agreement to defer the repurchase date as part of fails management process 5 Automatic change of purchase and repurchase dates of an evergreen SFT at the end of each business day until termination or maturity REPO, SLB
Table 1 and
Table 2
MOD
I
TCTN
5 The list of business events is not exhaustive 6 The references are to the tables of the RTS and ITS on reporting

ESMA REGULAR USE
28
Table 6 - Mapping business events to action types and levels
New
Event

Business / Trade
Event
Type of
SFT
Applicable
XML
Message6
Acti on
Type
Level Comments/examples
6
Cancellation of disputed transaction
(after external reporting)
All Table 1 and
Table 2
ERO
R

7
New allocation of the
SFTs All Table 1 and
Table 2
NEW
T
TCTN
E.g. disclosure of underlying principals by agent to other party in a "pooled" agency repo 8 Full reallocation with a new UTI All Table 1 and
Table 2
ETR
M +
NEW
T
TCTN
This also includes the scenario where the reallocation takes place before the settlement of the opening leg of the original transaction. 9 Full reallocation to an existing UTI All Table 1 and
Table 2
ETR
M +
MOD
I
TCTN
This also includes the scenario where the reallocation takes place before the settlement of the opening leg of the original transaction. 10 Partial reallocation to a new UTI All Table 1 and
Table 2
MOD
I +
NEW
T
TCTN
This also includes the scenario where the reallocation takes place before the settlement of the opening leg of the original transaction. 11 Partial reallocation to an existing UTI All Table 1 and
Table 2
MOD
I +
MOD
I
TCTN
This also includes the scenario where the reallocation takes place before the settlement of the opening leg of the original transaction. 12 Increase or reduce size of a repo by modifying the terms of the contract (same UTI, no settlement instructions issued) REPO Table 1 and
Table 2
MOD
I TCTN
13
Agreement to accept the partial delivery of the collateral as final implemented by a change in contractual terms REPO Table 1 and
Table 2
MOD
I TCTN
14 Partial termination
REPO,
BSB,
ML
Table 1 and
Table 2
MOD
I
TCTN
/
PSTN
15 Partial return All Table 1 and
Table 2
MOD
I
TCTN
/
PSTN
The settlement of the partial return, including a delayed settlement that does not result in a cancellation of the partial return, should not be reported separately. 16 Cancellation or failure of the partial return SBL Table 1 and
Table 2
MOD
I
TCTN
/
PSTN
A delayed settlement that does not result in a cancellation of the partial return, should not be reported 17 Re-rating (fixed rate, spread or rebate rate) REPO, BSB, SLB
Table 1 and
Table 2
MOD
I
TCTN
18
Agreed cancellation of the re-rate, hence reverting to the previous rate REPO, BSB, SLB
Table 1 and
Table 2
MOD
I
TCTN
If the re-rating was not agreed but was reported unilaterally by mistake, the change to the previous rate should be reported with “CORR”

ESMA REGULAR USE
29
Table 6 - Mapping business events to action types and levels
New
Event

Business / Trade
Event
Type of
SFT
Applicable
XML
Message6
Acti on
Type
Level Comments/examples
19 Change in floating repo rate REPO Table 1 and
Table 2
MOD
I
TCTN
20
Scheduled change in rate on floating-rate collateral or index on index-linked collateral in a BSB BSB Table 1 and
Table 2
MOD
I
TCTN
This event would result in the report of the modification of the repurchase price. 21 Events impacting the collateral value REPO, BSB
Table 1 and
Table 2
COL
U

E.g. Collateral income payment (repo,
BSB), manufactured payment (repo,
BSB), scheduled change in rate on floating-rate collateral or index on index-linked collateral in any type of repo 22 Cash mark SBL Table 1 and
Table 2
MOD
I
TCTN
/
PSTN
23 Fee mark SBL Table 1 and
Table 2
MOD
I
TCTN
/
PSTN
24 Valuation of securities on loan SLB Table 1 and
Table 2
VAL
U

25
Flat margin loan and/or short market value
ML Table 1 and
Table 2
MOD
I

26
Change in outstanding margin loan or short market value ML Table 1 and
Table 2
MOD
I

27
Change of base currency used for margin loan ML Table 1 and
Table 2
MOD
I

28
Additional base currency used for margin loan ML Table 1 and
Table 2
NEW
T

There is only one base currency per margin loan, therefore additional base currency should be reported as a new margin loan with a new UTI 29 Valuation of securities used as collateral All Table 1 and
Table 2
COL
U

30
First allocation of collateral on the day of trade REPO Table 1 and
Table 2
NEW
T or
COL
U
TCTN
Action type NEWT is used when collateral details are reported with other SFT details in the report of new transaction. This could be for example a scenario of a seller's allocation of collateral for a new GC repo or triparty agent's first allocation of collateral on the day of trade 31 First allocation of collateral after the day of trade REPO Table 1 and
Table 2
COL
U
TCTN
This could be for example a scenario of a seller's allocation of collateral for a new GC repo or triparty agent's first allocation of collateral after the day of trade

ESMA REGULAR USE
30
Table 6 - Mapping business events to action types and levels
New
Event

Business / Trade
Event
Type of
SFT
Applicable
XML
Message6
Acti on
Type
Level Comments/examples
32 Substitution of
Collateral All Table 1 and
Table 2
COL
U

This includes, e.g., temporary substitution of securities with cash (typically by triparty agent) in the event of shortage of eligible collateral in seller's account, substitution of temporary cash collateral with securities collateral, temporary cash collateralization of delay in return of securities in response to variation margin call under GMRA 6(h) This also includes any changes to the collateral due to the corporate events 33 Change in collateral quality All Table 1 and
Table 2
COL
U

34
Change in cash collateral amount or currency REPO, SLB
Table 1 and
Table 2
COL
U

35
Buy-in where required by regulation (e.g.
CSDR) or market convention (not under GMRA) All Table 1 and
Table 2
COL
U

36
Cash compensation where required by regulation (e.g.
CSDR) or market convention (not under GMRA) All Table 1 and
Table 2
COL
U

37 Default of the collateral issuer All ALL COL U or ETR M TCTN / PSTN ETRM should only be reported when SFT is terminated following to the default of the collateral issuer. Otherwise, the collateral substitution should be reported with COLU 38 Variation margining REPO, SLB, BSB
Table 1 and
Table 2
COL
U

It's a separate COLU report for net exposure 39 Change in haircut or margins REPO, SLB
Table 1 and
Table 2
COL
U
TCTN
/
PSTN
40 Clearing off-venue All Table 1 and
Table 2
ETR
M +
NEW
T
TCTN
/
PSTN
This includes OTC transactions cleared on same day or after 41 Post-trade clearing of a transaction executed on a trading venue All Table 1 and
Table 2
ETR
M +
NEW
T
TCTN
/
PSTN
This includes transactions executed on a trading venue cleared after the day of trade 42 Same-day clearing of a transaction executed on a trading venue All Table 1 and
Table 2
NEW
T
TCTN
/
PSTN
This includes transactions executed on a trading venue cleared by open offer model and by same-day novation

ESMA REGULAR USE
31
Table 6 - Mapping business events to action types and levels
New
Event

Business / Trade
Event
Type of
SFT
Applicable
XML
Message6
Acti on
Type
Level Comments/examples
43
CCP rejects transaction which is conditional upon registration with the CCP All Table 1 and
Table 2
ERO
R

44
Termination of an open SFT or termination of a term repo (by agreement or unilaterally) REPO, SLB
Table 1 and
Table 2
MOD
I or
ETR
M
TCTN
ETRM should be reported for the termination on the same day, whereas MODI should be used to report a termination on a future date (by amending the maturity date) 45 Termination of an evergreen or puttable SFT REPO, SLB
Table 1 and
Table 2
MOD
I
TCTN This includes elimination of termination optionality 46 Maturity/Expiration All Table 1 and
Table 2
no repor t

Temporary settlement failure of the expiring SFT should not be reported separately 47 Full return of a term SLB prior to the maturity date or of an open term SLB SBL Table 1 and
Table 2
ETR
M

The settlement of the full return, including a delayed settlement that does not result in a cancellation of the full return, should not be reported separately. 48 Cancellation or failure of the full return SBL Table 1 and
Table 2
no repor t or
NEW
T
TCTN
Full return should not be reported if it does not settle, therefore if the full return is cancelled, no additional report is expected. However, if the full return had been reported as ETRM and subsequently the full return is cancelled, the transaction should be re-reported with action type NEWT and new UTI 49 Closure of an SFT due to counterparty default All Table 1 and
Table 2
ETR
M

This includes e.g. placing counterparty into default provided this default option has been agreed under GMRA 10(a)(ii) 50 Termination of transaction under specific GMRA provisions REPO, BSB
Table 1 and
Table 2
ETR
M

This includes:
Termination of transaction under 2000 provision 10(g) or GMRA 2011 provision 10(h) "Mini close-out" under GMRA 2000 10(h) or GMRA 2011 10(i) Repricing or Adjustment under GMRA 2000 4(i)-(k) or GMRA 2011 4(j)-(l) 51 Terminating the relationship between prime broker and the client ML Table 1 and
Table 2
ETR
M

52 Amend trade - bilateral All Table 1 and
Table 2
MOD
I
TCTN
/
PSTN
Counterparties agree to amend a transaction attribute. This is a catch all event for any modifications not listed separately 53 Amend trade - unilateral All Table 1 and
Table 2
COR
R
TCTN
/
PSTN
One counterparty corrects a transaction attribute

ESMA REGULAR USE
32
Table 6 - Mapping business events to action types and levels
New
Event

Business / Trade
Event
Type of
SFT
Applicable
XML
Message6
Acti on
Type
Level Comments/examples
54 Amend collateral - bilateral All Table 1 and
Table 2
COL
U
TCTN
/
PSTN
Counterparties agree to amend a collateral attribute. This is a catch all event for any modifications not listed separately 55 Amend collateral - unilateral All Table 1 and
Table 2
COR
R
TCTN
/
PSTN
One counterparty corrects a collateral attribute 56 Lifecycle event (e.g. change in size or rerating of open repo) incorrectly reported All Table 1 and
Table 2
COR
R
TCTN
/
PSTN
It's not possible to correct the wrongly reported early termination or error. Once a report with these action types is sent, there is no way to bring the transaction back to outstanding status, and therefore it is necessary to rereport the transaction with action type NEWT and new UTI. 57 Transaction not executed or out of scope of SFTR but reported to TR by mistake All Table 1 and
Table 2
ERO
R

58
Initial posting of margin to a CCP for cleared SFTs All Table 3 NEW T - 59 Update of the initial margin posted at the CCP All Table 3 MAR U - 60 Posting variation margin to a CCP for cleared SFTs All Table 3 MAR U - 61 Correction of a previous submitted margin report All Table 3 COR R - 62 Cancellation of a wrongly submitted margin report All Table 3 ERO R - 63 First report of reuse of collateral or reinvestment of cash collateral All Table 4 NEW T - 64 Change in the securities reused or update of the estimated reuse or value of reused collateral All Table 4 REU U - 65 Change in cash collateral reinvestment type, amount or currency SLB Table 4 REU U - 66 Correction of a previously submitted collateral reuse All Table 4 COR R -

ESMA REGULAR USE
33
Table 6 - Mapping business events to action types and levels
New
Event

Business / Trade
Event
Type of
SFT
Applicable
XML
Message6
Acti on
Type
Level Comments/examples report with incorrect data 67 Cancellation of a wrongly submitted collateral reuse report (e.g. for an entity not subject to the reporting obligation) All Table 4 ERO R - 4.11Identification of a CSD participant Except for cases where margin lending is reported, or when a transaction involves commodities, counterparties should always populate the Central Securities Depository (CSD) participant or indirect participant field. The field should be reported even if the SFT settles outside of a CSD. ESMA expects that the reporting counterparty should report this field using the following logic:
a. Report its own LEI if it is settling directly at any CSD, i.e. it is a CSD participant; b. Report its own LEI if it is settling securities at any of the two ICSDs even where the ICSD is not the issuer CSD, i.e. it the counterparty is an ICSD participant;
c. Report the LEI of its custodian bank irrespective of whether the custodian is using
any sub-custodian or not. This includes scenarios when a counterparty uses an Agent Lender. The counterparty should not report the LEI of the CSD in which they are either direct or indirect participants in the “CSD Participant” field. 4.12Determining counterparty side General case In the case of repos or BSBs, the buyer is the collateral taker, while the seller is the collateral provider. In the case of SLB or SFTs involving commodities, the lender is the collateral taker, while the borrower is the collateral provider. In the case of margin loans, the lender is the collateral taker, while the borrower is the collateral provider.

ESMA REGULAR USE
34
CCP-cleared SFTs
In the case of CCP-cleared SFTs, the CCP interposes itself between the two counterparties to the SFT. Therefore, it will be buyer to the seller, borrower to the lender, seller to the buyer and lender to the borrower. Reporting of unsecured lending/borrowing of securities In the case of unsecured lending and borrowing of securities, the counterparty that lends the securities should report itself as the collateral taker, and the counterparty that borrows the securities should report itself in Field 1.9 as the collateral provider. Reporting of counterparty side in the case of net exposure collateralisation In the case of net exposure collateralisation, the counterparties should not report the Field “Counterparty side” for the collateral that is used as variation margining. However, the counterparties should, following the determination of whether they are net collateral provider or net collateral taker, report the collateral pertaing to the variation margining as detailed in section 5.4.7. 4.13Price and value fields Timing of valuations When an SFT is cleared, information related to valuations sourced from the CCP should be used for SFTR reporting. 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. 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. If valuations for two different days are provided, the counterparties should populate Field
2.3 “Event date” accordingly for each different day.
Calculation method for valuations
When reporting under SFTR, counterparties should use the value they use for collateral management and exposure management purposes. When there is no market value available, SFTR does not prescribe any specific method for calculating these valuations. Nevertheless, the data reported under Fields 2.57 and

ESMA REGULAR USE
35
2.88 is reconcilable data, therefore, the counterparties should agree and report values that
are within the accepted limits of tolerance difference, as detailed in the Annex to the RTS on data collection. The market value of the securities should be reported as at close of business of each working day, reflecting the valuation used for collateral management purposes, e.g. to calculate daily variation margin. In the event a market price for the securities being valued is not available, the reporting counterparty should use the most recent market price available as a fall-back option. Counterparties should use as appropriate the currency XML tags for all the price fields to correctly identify the relevant value and amount fields, more importantly, when they are in a different currency. Please also refer to the example in Section 5.2.1.8. 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. 4.14Reporting 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 link http://www.annaweb.org/standards/about-identification-standards/, 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 reconciliable field. 4.15Backloading Counterparties that decide to report on a preceding RSD should report complete and accurate details of the relevant backloaded transactions, including the daily update of the collateral with action type “COLU”. If they report a portion of their SFTs, they should report complete and accurate details of the margin and reuse data in Tables 3 and 4 of the Annex to the TS on reporting. In case both counterparties are covered by the relevant RSD, to minimise reconciliation breaks, they should agree on which day they backload the SFTs. In any case, the reporting of the backloading transactions should be done by RSD+190. If a reporting counterparty for whom the RSD has not yet kicked in decides to report backloading transactions, it should ensure that each SFT that is reported as per paragraph 146.

ESMA REGULAR USE
36
Should the counterparties decide so, full reporting of backloaded SFTs, i.e. reporting of all SFTs that are open at a given point in time after the first RSD before the aforementioned deadline remains possible on a voluntary basis too. The backloaded transaction should be reported with action type (Field 2.98) populated with “NEWT”. The “Execution timestamp” (Field 2.12) should be populated with the original execution timestamp. The “Value date (start date)” (Field 2.13) should be populated with the original value date unless it has been amended due to settlement issues with regards to the SFT. The rest of the data fields should contain the state at the time of reporting. The previous lifecycle events should not be reported separately. 4.16UTI generation and structure The flowchart below illustrates the process for generating a UTI.

ESMA REGULAR USE
37
In the case of cleared SFTs, each of the SFTs between the CCP and its clearing members, and between the clearing members and their clients, should be reported with different UTIs.

ESMA REGULAR USE
38
It is worth noting that the agreement on the UTI between the counterparties is in practice the fall-back option under the framework provided in the technical standards, as most of the entities rely on the waterfall for UTI generation. Nevertheless, the parties may have such an agreement, in which case they should abide by it in all the cases which are covered by the agreement. In the case of open term SFTs, the counterparties should retain the initially generated UTI for that SFT and should not re-generate a new one on each renewal. The non-generating counterparty should be able to ingest in its systems or in the systems of the entity responsible for reporting or the report submitting entity the UTI communicated by the counterparty that generated it. The counterparties should put in place the relevant technical arrangements, adequate to the volume of data to be exchanged, to ensure the timely communication and ingestion of UTI. In case there is an issue with the generation or communication of the UTI, the counterparties should ensure the timely solution of any issue related to the generation and communication of the UTI and report by the timeline for reporting of the SFT. If the UTI itself is wrong, the trade should be cancelled and reported as new with the correct UTI. On the UTI format, the counterparties to an SFT might consider using the CPMI-IOSCO guidance recommending that new UTIs are structured as a concatenated combination of:
a. the LEI of the generating entity as it was valid at the moment of generation, and b. a unique value created by that entity (where this value only needs to be unique within the set of such values generated by that entity since the combination with the LEI will guarantee global uniqueness). 4.17Identifying and reporting on beneficiaries A usual case, but there may be others, are the umbrella and sub-fund structures, where the umbrella fund is the counterparty and the sub-fund or subfunds are the beneficiaries. There may also be cases where the beneficiary is a ring-fenced pool; in such cases, the LEI should be used to identify such ring-fenced pool7 . 4.18Identification of issuer of securities and securities Counterparties should report the LEI of the issuer(s) of the securities lent or borrowed, the LEI of the issuer(s) of the securities used as collateral, as well as the ISINs of the securities. 7 As referred into to the Recommendation n.8 of the 2012 FSB report “A Global Legal Entity Identifier for Financial Markets” asset pools or other segregated parts of a legal entity may carry separate rights and obligations at a sufficient level of independence of that legal entity and be eligible for an LEI. This is also in accordance with ISO standard 17442:2012 for a Legal Identifier.

ESMA REGULAR USE
39
When reporting this information, the counterparties should ensure that there is a correspondence between the ISIN and the LEI of issuer reported in accordance with the validation rules. 4.19Procedure when a counterparty undergoes a corporate action The entity with the new LEI (e.g. merged or acquiring entity– further “new entity”) should notify the TR(s) to which it reported its SFTs about the change and request an update of the identifier in the outstanding SFTs as per paragraph 162 below. If the change of the identifier results from a merger or acquisition, the merged or acquiring entity should also duly update the LEI record of the acquired/merged entity. Where applicable, the counterparty should also provide information about the change of country. In the case of corporate restructuring events affecting all outstanding SFTs, the TR should identify all the outstanding SFTs where the entity is identified with the old LEI in any of the following fields: reporting counterparty ID, ID of the other counterparty, and replace the old LEI with the new one. Other corporate restructuring events, such as, but not limited to, partial acquisitions, spinoffs, may affect only a subset of outstanding SFTs, in which case the new entity should accordingly provide the TR with the UTIs of the SFTs impacted by that event. This is done through the following controlled process:
a. The new entity should submit written documentation to the TR(s) to which it reported its SFTs and requests the change of the LEI due to a corporate event. In the documentation, the following information should be clearly presented (i) the LEI(s) of the entities participating in the merger, acquisition or other corporate event, (ii) the LEI of the new entity, (iii) the date on which the change takes place and (iv) the UTIs of the outstanding SFTs concerned. In case of a merger or acquisition, the documentation should include evidence or proof that the corporate event has taken or will take place and be duly signed. To the extent possible, the entity should provide the required information in advance so that the change is not done retrospectively, but as of the date specified in (iii). It should be noted that failure to update the new LEI on time would result in rejection of the reports submitted by the entity in case where it has been previously identified with the old LEI with an appropriate status (i.e. “Issued”, “Pending transfer” or “Pending archival”) and that status has subsequently been changed to “Merged”. b. The TR should broadcast this information to all the other TRs through a specific file, where the (i) old LEI(s), (ii) the new LEI(s) and (iii) the date as of which the change should be done, are included. To the extent possible, the file should be broadcasted in advance so that the change is not done retrospectively, but as of the date specified in (iii).
c. Each of the counterparties to the SFTs, where any of the merged entities is identified,
should be informed of the modification by the TR to which they report.

ESMA REGULAR USE
40 d. TR(s) should also notify the regulators who have access to the data relating to the SFTs that have been updated. e. Where applicable, the TR should update Field 1.12 “Country of the other counterparty”. f. The changes should be kept in the reporting log maintained by each of the TRs. Subsequent reports should be validated against GLEIF as usual and rejected if the validation fails. Therefore, it is not expected that an entity submits a report as a result of a new LEI. The aforementioned procedure should not be followed when counterparties identify themselves wrongly. In that case, they should submit an SFT report with action type “EROR”, agree on a new UTI with the other counterparty and report complete and accurate details of the SFT. 4.20Reporting in the phased-in period The counterparties for which the reporting obligation has not yet started should provide to the counterparty for which the reporting obligation has commenced with all the relevant information in accordance with the TS on reporting. The information that should be delivered to the reporting counterparty consists of 2 data fields. Those data fields are the “Other counterparty”, “Branch of the other counterparty” and “Country of the other counterparty”. For these data fields, the information should be delivered to the reporting counterparty in a timely manner. Should the counterparties, for which the reporting obligation has not started yet, find it easier, they could start reporting in advance of the relevant reporting start date indicated in Article 33(2)(a) SFTR. If a counterparty for which the reporting obligation has not yet kicked in decides to report transactions, it should follow paragraph 144 in section 4.15 of the Guidelines. 5 SFTR Tables of fields
Article 1(1) RTS on reporting provides that “A report made pursuant to Article 4(1) of
Regulation (EU) 2015/2365 shall include the complete and accurate details set out in Tables 1, 2, 3 and 4 of the Annex that pertain to the SFT concerned.” The use cases included in Sections 5.1 to 5.6 do not necessarily include all the fields that pertain to the SFT concerned, but they focus on specific sections of data fields in order to provide more granular and detailed guidance on the reporting without any unnecessary repetition or inclusion of other data elements. The validation rules contain the complete guidance on applicable fields per SFT type, Action type and Level, as well as the relevant dependencies. The following sections include various scenarios and corresponding tables clarifying how these scenarios should be reported. Each table shows the reporting fields under the SFTR technical standards. The column “Field” shows each field name, and the column

ESMA REGULAR USE
41
“Example” provides an example of what would be included in that field. The final column entitled “XML Message” shows the format of the XML message which should be submitted in the trade report. Unless otherwise stated in the specific scenario, the following background information applies to all scenarios set out in Section 5:
Counterparty A is a financial counterparty identified with LEI 12345678901234500000 Counterparty B is a French financial counterparty identified with LEI ABCDEFGHIJKLMNOPQRST Counterparty C is an SME-NFC identified with LEI 123456789ABCDEFGHIJK Counterparty D identified with LEI 11223344556677889900 Broker E is identified with LEI 88888888888888888888 Agent lender F is identified with LEI BBBBBBBBBBBBBBBBBBBB Triparty agent G is identified with LEI 77777777777777777777 Custodian bank H is identified with LEI AAAAAAAAAAAAAAAAAAAA Third-party I offers reporting services and is identified with LEI 12345123451234512345 Counterparty J also acts as a clearing member and is identified with LEI CCCCCCCCCCCCCCCCCCCC UCITS fund K is identified with LEI UUUUUUUUUU1111111111, whereas UCITS management company L is identified with LEI UUUUUUUUUU2222222222 AIF M is identified with LEI AAAAAAAAAA1111111111 whereas AIF management company N is identified with LEI AAAAAAAAAA2222222222 CCP O is identified with LEI BBBBBBBBBB1111111111 The German securities issuer is identified with LEI NNNNNNNNNNNNNNNNNNNN The Spanish securities issuer is identified with LEI EEEEEEEEEEEEEEEEEEEE The French securities issuer is identified with LEI FFFFFFFFFFFFFFFFFFFF The Dutch securities issuer is identified with LEI DDDDDDDDDDDDDDDDDDDD The Italian securities issuer is identified with LEI IIIIIIIIIIIIIIIIIIII A general securities issuer is identified with GGGGGGGGGGGGGGGGGGGG The French main index equities issuer is identified with LEI 529900S21EQ1BO4ESM68

ESMA REGULAR USE
42
Trading Venue P is identified with MIC XWAR Securities are identified with the following ISINs:
a. German bonds (Vanilla): DE0010877643 b. Spanish perpetual bonds: ES0010877643
c. French bonds: FR0010877643
d. Dutch bonds: NL0010877643 e. French main index equities: FR0000120271 f. Other French securities: FR0010877000 g. Collateral basket: GB00BH4HKS39 h. Collateral component 1: IT00BH4HKS39
i. Collateral component 2: FR00BH4HKS39
Securities are classified with the following CFIs:
a. Government vanilla bond: DBFTFR b. Government perpetual bond: DBFTPR
c. Equities: ESVUFN
Fields in the tables that are empty and grey-shaded are not applicable for those specific examples but shown for clarification purpose. The applicability of the use cases to the different types of SFTs is included. The actual reporting in accordance with the ISO 20022 XML schemas is provided too.
5.1 Counterparty data
When an SFT is cleared, each counterparty should report in the clearing member field its clearing member. When a voluntary delegation of reporting or allocation of responsibility exists, the report submitting entity or entity responsible for reporting should submit the counterparty data separately, and the loan and collateral data for each of the two sides reported. When there are use cases that cover two or more of the use cases included below, the reporting counterparties or the entities responsible for reporting should include all the relevant details based on the below guidance.

ESMA REGULAR USE
43
Table 7 – Use cases
Repo and reverse repo
BSB /
SBB
Securities and commodities lending
Margin lending
Non-cleared bilateral SFT between headquarters Y Non-cleared bilateral SFT between branches Y Non-cleared bilateral SFT with beneficiaries Y N Non-cleared SFT with brokers, settled with a custodian bank Y N Non-cleared SFT with broker, agent lender and tri-party agent Y N Non-cleared SFT with broker, agent lender and tri-party agent, settled with a CSD participant different from any of the entities and voluntary delegation of reporting to a third party Y N Cleared SFT with broker, agent lender, tri-party agent Y N Cleared SFT with broker, agent lender, tri-party agent settled with a CSD participant different from any of the entities and voluntary delegation of reporting to a third party Y N Non-cleared SFTs concluded by UCITS fund Y

ESMA REGULAR USE
44
Table 7 – Use cases
Repo and reverse repo
BSB /
SBB
Securities and commodities lending
Margin lending
Non-cleared SFTs concluded by
UCITS fund, and the UCITs management company delegates reporting to a third party Y Non-cleared SFTs concluded by AIF Y Non-cleared SFTs where fund portfolio management is outsourced Y Non-cleared bilateral SFTs between headquarters
Table 8 shows which types of securities financing transactions can be conducted purely
bilaterally between two headquarters.
Table 8 – SFTs to which the use case applies
Repo and reverse repo
Buy sell back/sell buy-back
Securities and commodities lending
Margin lending
Y
Table 9 illustrates reporting for a bilateral transaction where the reporting counterparty
(counterparty A) is also submitting its reports (i.e. there is not a separate report submitting entity). The counterparty A is also the beneficiary to this transaction and the CSD participant.

ESMA REGULAR USE
45
Table 9 - Non-cleared bilateral SFTs between headquarters
No Field Example XML Message
1 Reporting timestamp
2021-02-
01T15:15:15
Z
<SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<New>
...
<CtrPtyData>
<RptgDtTm>2020-01-
01T15:15:15Z</RptgDtTm>
<RptSubmitgNtty>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
<CtryCd>FR</CtryCd>
</OthrCtrPty>
<NttyRspnsblForRpt>

<LEI>12345678901234500000</LEI>
</CntrlSctiesDpstryPtcpt>
</SttlmPties>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
...
2 Report submitting entity
{LEI} of counterparty
A
3 Reporting counterparty
{LEI} of counterparty
A
4
Nature of the reporting counterparty F
5
Sector of the reporting counterparty CDTI
6
Additional sector classification
7
Branch of the reporting counterparty
8
Branch of the other counterparty
9 Counterparty side GIVE
10 Entity responsible for the report
{LEI} of counterparty
A
11 Other counterparty
{LEI} of counterparty
B
12 Country of the other
Counterparty FR
13 Beneficiary
14 Tri-party agent
15 Broker
16 Clearing member
17
Central Securities
Depository (‘CSD’) participant or indirect participant {LEI} of counterparty A 18 Agent lender

ESMA REGULAR USE
46
Table 9 - Non-cleared bilateral SFTs between headquarters
No Field Example XML Message
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
Non-cleared bilateral SFT between branches
Table 10 – SFTs to which the use case applies
Repo and reverse repo
Buy sell back/sell buy-back
Securities and commodities lending
Margin lending
Y
Table 11 shows an example of reporting of a bilateral transaction concluded between
branches of two counterparties. The legal entities (headquarters) are identified with respective LEIs, whereas the countries of the branches are identified with ISO country codes. Counterparty A is also the CSD participant.
Table 11 - Non-cleared bilateral SFT between branches
No Field Example XML Message
1 Reporting timestamp 2020-01-
01T15:15:15Z <SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<New>
...
<CtrPtyData>
<RptgDtTm>2020-01-
01T15:15:15Z</RptgDtTm>
<RptSubmitgNtty>

<LEI>12345678901234500000</LEI>
</RptSubmitgNtty>
<CtrPtyData>
<RptgCtrPty>
<Id>
2
Report submitting entity
{LEI} of counterparty
A
3
Reporting counterparty
{LEI} of counterparty
A
4
Nature of the reporting counterparty F
5
Sector of the reporting counterparty CDTI
6
Additional sector classification

ESMA REGULAR USE
47
Table 11 - Non-cleared bilateral SFT between branches
No Field Example XML Message
7
Branch of the reporting counterparty FR

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
<Brnch>
<Ctry>DE</Ctry>
</Brnch>
<CtryCd>FR</CtryCd>
</OthrCtrPty>
<NttyRspnsblForRpt>

<LEI>12345678901234500000</LEI>
</CntrlSctiesDpstryPtcpt>
</SttlmPties>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
...
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
8
Branch of the other counterparty DE
9 Counterparty side GIVE
10 Entity responsible for the report
{LEI} of counterparty
A
11 Other counterparty
{LEI} of counterparty
B
12 Country of the other
Counterparty FR
13 Beneficiary
14 Tri-party agent
15 Broker
16 Clearing member
17
Central Securities
Depository (‘CSD’) participant or indirect participant {LEI} of counterparty A 18 Agent lender

ESMA REGULAR USE
48
Non-cleared bilateral SFT with beneficiaries
Table 12 – SFTs to which the use case applies
Repo and reverse repo
Buy sell back/sell buy-back
Securities and commodities lending
Margin lending
Y N
Table 13 shows an example of a bilateral non-cleared transaction where counterparty A
is not a beneficiary to the transaction. The beneficiary is the counterparty D. Counterparty A is also the CSD participant.
Table 13 - Non-cleared bilateral SFT with beneficiaries
No Field Example XML Message
1 Reporting timestamp
2020-01-
01T15:15:15
Z
<SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<New>
...
<CtrPtyData>
<RptgDtTm>2020-01-
01T15:15:15Z</RptgDtTm>
<RptSubmitgNtty>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
<CtryCd>FR</CtryCd>
2 Report submitting entity
{LEI} of counterparty
A
3 Reporting counterparty
{LEI} of counterparty
A
4
Nature of the reporting counterparty F
5
Sector of the reporting counterparty CDTI
6
Additional sector classification
7
Branch of the reporting counterparty
8
Branch of the other counterparty
9 Counterparty side GIVE
10 Entity responsible for the report
{LEI} of counterparty
A
11 Other counterparty
{LEI} of counterparty
B
12 Country of the other
Counterparty FR

ESMA REGULAR USE
49
Table 13 - Non-cleared bilateral SFT with beneficiaries
No Field Example XML Message
13 Beneficiary
{LEI} of counterparty
D
</OthrCtrPty>
<NttyRspnsblForRpt>

<LEI>12345678901234500000</LEI>
</CntrlSctiesDpstryPtcpt>
</SttlmPties>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
...
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
14 Tri-party agent
15 Broker
16 Clearing member
17
Central Securities
Depository (‘CSD’) participant or indirect participant {LEI} of counterparty A 18 Agent lender Non-cleared SFT with brokers, settled with a custodian bank
Table 14 – SFTs to which the use case applies
Repo and reverse repo
Buy sell back/sell buy-back
Securities and commodities lending
Margin lending
Y N
In the scenario illustrated by Table 15, the counterparty A enters a transaction with counterparty B. Counterparty A uses a custodian bank H, which is therefore identified in the Field 1.17. Furthermore, the counterparty A uses services of the broker E.

ESMA REGULAR USE
50
Table 15 - Non-cleared SFT with brokers, settled with a custodian bank
No Field Example XML Message
1 Reporting timestamp 2020-01-
0115:15:15Z
<SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<New>
...
<CtrPtyData>
<RptgDtTm>2020-01-
01T15:15:15Z</RptgDtTm>
<RptSubmitgNtty>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
<CtryCd>FR</CtryCd>
</OthrCtrPty>
<NttyRspnsblForRpt>

<Brkr>

<LEI>88888888888888888888</LEI>
</Brkr>
<SttlmPties>
<CntrlSctiesDpstryPtcpt>
<LEI>
AAAAAAAAAAAAAAAAAAAA</LEI>
</CntrlSctiesDpstryPtcpt>
</SttlmPties>
</OthrPtyData>
</CtrPtyData>
2 Report submitting entity
{LEI} of counterparty
A
3 Reporting counterparty
{LEI} of counterparty
A
4
Nature of the reporting counterparty F
5
Sector of the reporting counterparty CDTI
6
Additional sector classification
7
Branch of the reporting counterparty
8
Branch of the other counterparty
9 Counterparty side GIVE
10 Entity responsible for the report
{LEI} of counterparty
A
11 Other counterparty
{LEI} of counterparty
B
12 Country of the other
Counterparty FR
13 Beneficiary
14 Tri-party agent
15 Broker {LEI} of broker E
16 Clearing member
17
Central Securities
Depository (‘CSD’) participant or indirect participant {LEI} of custodian bank H 18 Agent lender

ESMA REGULAR USE
51
Table 15 - Non-cleared SFT with brokers, settled with a custodian bank
No Field Example XML Message
</CtrPtyData>
<LnData>
...
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
Non-cleared SFT with broker, agent lender and tri-party agent
Table 16 – SFTs to which the use case applies
Repo and reverse repo
Buy sell back/sell buy-back
Securities and commodities lending
Margin lending
Y N
In the scenario illustrated by the Table 17, the counterparty A enters a transaction with counterparty B. Counterparty A uses an agent lender F and tri-party agent G. Furthermore, the counterparty A uses services of the broker E. Counterparty A is the CSD participant.
Table 17 - Non-cleared SFT with broker, agent lender and tri-party agent
No Field Example XML Message
1 Reporting timestamp
2020-01-
01T15:15:15
Z
<SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<New>
...
<CtrPtyData>
<RptgDtTm>2020-01-
01T15:15:15Z</RptgDtTm>
<RptSubmitgNtty>

<LEI>12345678901234500000</LEI>
2 Report submitting entity
{LEI} of counterparty
A
3 Reporting counterparty
{LEI} of counterparty
A
4
Nature of the reporting counterparty F

ESMA REGULAR USE
52
Table 17 - Non-cleared SFT with broker, agent lender and tri-party agent
No Field Example XML Message
5
Sector of the reporting counterparty CDTI
</RptSubmitgNtty>
<CtrPtyData>
<RptgCtrPty>
<Id>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
<CtryCd>FR</CtryCd>
</OthrCtrPty>
<NttyRspnsblForRpt>

<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
</AgtLndr>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
...
</LnData>
6
Additional sector classification
7
Branch of the reporting counterparty
8
Branch of the other counterparty
9 Counterparty side GIVE
10 Entity responsible for the report
{LEI} of counterparty
A
11 Other counterparty
{LEI} of counterparty
B
12 Country of the other counterparty FR
13 Beneficiary
14 Tri-party agent
{LEI} of triparty agent
G
15 Broker {LEI} of broker E
16 Clearing member
17
Central Securities
Depository (‘CSD’) participant or indirect participant {LEI} of counterparty A 18 Agent lender {LEI} of agent lender F

ESMA REGULAR USE
53
Table 17 - Non-cleared SFT with broker, agent lender and tri-party agent
No Field Example XML Message
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
Non-cleared SFT with broker, agent lender and tri-party agent, settled with a CSD participant different from any of the entities and voluntary delegation of reporting to a third-party.
Table 18 – SFTs to which the use case applies
Repo and reverse repo
Buy sell back/sell buy-back
Securities and commodities lending
Margin lending
Y N
In the scenario illustrated by the Table 19, the counterparty A enters a transaction with counterparty B. Counterparty A uses an agent lender F and tri-party agent G. Furthermore, the counterparty A uses services of the broker E and custodian bank H. Finally, Counterparty A delegates the reporting to a third-party I.
Table 19 - Non-cleared SFT with broker, agent lender and tri-party agent, settled with
a CSD participant different from any of the entities and voluntary delegation of reporting to a third party No Field Example XML Message 1 Reporting timestamp 2020-01- 0115:15:15Z <SctiesFincgRptgTxRpt> <TradData> <Rpt> <New> ... <CtrPtyData> <RptgDtTm>2020-01- 01T15:15:15Z</RptgDtTm> <RptSubmitgNtty>

<LEI>12345123451234512345</LEI>
</RptSubmitgNtty>
2 Report submitting entity {LEI} of third party I 3 Reporting counterparty {LEI} of counterparty A 4 Nature of the reporting counterparty F 5 Sector of the reporting counterparty CDTI

ESMA REGULAR USE
54
Table 19 - Non-cleared SFT with broker, agent lender and tri-party agent, settled with
a CSD participant different from any of the entities and voluntary delegation of reporting to a third party No Field Example XML Message 6 Additional sector classification <CtrPtyData> <RptgCtrPty> <Id>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
<CtryCd>FR</CtryCd>
</OthrCtrPty>
<NttyRspnsblForRpt>

<LEI>AAAAAAAAAAAAAAAAAAAA</LEI>
</CntrlSctiesDpstryPtcpt>
</SttlmPties>
<AgtLndr>

<LEI>BBBBBBBBBBBBBBBBBBBB </LEI>
</AgtLndr>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
7
Branch of the reporting counterparty
8
Branch of the other counterparty
9 Counterparty side GIVE
10 Entity responsible for the report
{LEI} of counterparty
A
11 Other counterparty
{LEI} of counterparty
B
12 Country of the other counterparty FR
13 Beneficiary
14 Tri-party agent
{LEI} of triparty agent
G
15 Broker {LEI} of
Broker E
16 Clearing member
17
Central Securities
Depository (‘CSD’) participant or indirect participant {LEI} of custodian bank H 18 Agent lender {LEI} of agent lender F

ESMA REGULAR USE
55
Table 19 - Non-cleared SFT with broker, agent lender and tri-party agent, settled with
a CSD participant different from any of the entities and voluntary delegation of reporting to a third party No Field Example XML Message ... </LnData> <CollData> ... </CollData> ... </New> </Rpt> </TradData> </SctiesFincgRptgTxRpt> Cleared SFT with broker, agent lender, tri-party agent
Table 20 – SFTs to which the use case applies
Repo and reverse repo
Buy sell back/sell buy-back
Securities and commodities lending
Margin lending
Y N
Table 21 illustrates the population of the reporting fields in case of a cleared SFT. The
population of the fields is irrespective of the type of CCP access that the counterparty has. It should always identify the entity acting as clearing member. Counterparty A accesses the CCP via clearing member J. It also uses services of broker E, agent lender F and tri-party agent G. Counterparty A is also the CSD participant. It should be noted that CCP field pertains to Table 2 (Loan and collateral data), and hence its population is covered in Section 5.2.
Table 21 - Cleared SFT with broker, agent lender, tri-party agent
No Field Example XML Message
1 Reporting timestamp 2020-01-
01T15:15:15Z <SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<New>
...
<CtrPtyData>
<RptgDtTm>2020-01-
01T15:15:15Z</RptgDtTm>
<RptSubmitgNtty>
2
Report submitting entity
{LEI} of counterparty
A
3
Reporting counterparty
{LEI} of counterparty
A
4
Nature of the reporting counterparty F

ESMA REGULAR USE
56
Table 21 - Cleared SFT with broker, agent lender, tri-party agent
No Field Example XML Message
5
Sector of the reporting counterparty CDTI

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
<CtryCd>FR</CtryCd>
</OthrCtrPty>
<NttyRspnsblForRpt>

<LEI>CCCCCCCCCCCCCCCCCCCC
</LEI>
</ClrMmb>
<SttlmPties>
<CntrlSctiesDpstryPtcpt>

<LEI>12345678901234512345</LEI>
</CntrlSctiesDpstryPtcpt>
</SttlmPties>
<AgtLndr>
6
Additional sector classification
7
Branch of the reporting counterparty
8
Branch of the other counterparty
9 Counterparty side GIVE
10 Entity responsible for the report
{LEI} of counterparty
A
11 Other counterparty
{LEI} of counterparty
B
12 Country of the other counterparty FR
13 Beneficiary
14 Tri-party agent {LEI} of triparty agent G 15 Broker {LEI} of broker E 16 Clearing member {LEI} of counterparty J 17 Central Securities Depository (‘CSD’) participant or indirect participant {LEI} of counterparty A 18 Agent lender {LEI} of agent lender F

ESMA REGULAR USE
57
Table 21 - Cleared SFT with broker, agent lender, tri-party agent
No Field Example XML Message

<LEI>BBBBBBBBBBBBBBBBBBBB </LEI>
</AgtLndr>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
...
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
Cleared SFT with broker, agent lender, tri-party agent settled with a CSD participant different from any of the entities and voluntary delegation of reporting to a third party
Table 22 – SFTs to which the use case applies
Repo and reverse repo
Buy sell back/sell buy-back
Securities and commodities lending
Margin lending
Y N
Similarly to the previous example, Table 23 illustrates population of the reporting fields in case of a cleared SFT and Counterparty A accesses the CCP via clearing member J. It also uses services of broker E, agent lender F and tri-party agent G. Furthermore, in this example the transaction is settled with an entity H different from any of the counterparties and the reporting counterparty delegates the reporting to a third-party I. It should be noted that the population of the fields is irrespective of the type of CCP access that the counterparty has. It should always identify the entity acting as clearing member.
Table 23 - Cleared SFT with broker, agent lender, tri-party agent settled with a CSD
participant different from any of the entities and voluntary delegation of reporting to a third party No Field Example XML Message 1 Reporting timestamp 2020-01- 0115:15:15Z <SctiesFincgRptgTxRpt> <TradData>

ESMA REGULAR USE
58
Table 23 - Cleared SFT with broker, agent lender, tri-party agent settled with a CSD
participant different from any of the entities and voluntary delegation of reporting to a third party No Field Example XML Message 2 Report submitting entity {LEI} of third party I <Rpt> <New> ... <CtrPtyData> <RptgDtTm>2020-01- 01T15:15:15Z</RptgDtTm> <RptSubmitgNtty>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
<CtryCd>FR</CtryCd>
</OthrCtrPty>
<NttyRspnsblForRpt>

<LEI>CCCCCCCCCCCCCCCCCCCC
</LEI>
</ClrMmb>
3 Reporting counterparty
{LEI} of counterparty
A
4
Nature of the reporting counterparty F
5
Sector of the reporting counterparty CDTI
6
Additional sector classification
7
Branch of the reporting counterparty
8
Branch of the other counterparty
9 Counterparty side GIVE
10 Entity responsible for the report
{LEI} of counterparty
A
11 Other counterparty
{LEI} of counterparty
B
12 Country of the other counterparty FR
13 Beneficiary
14 Tri-party agent
{LEI} of triparty agent
G
15 Broker {LEI} of broker E
16 Clearing member
{LEI} of counterparty
J
17
Central Securities
Depository (‘CSD’) participant or indirect participant {LEI} of custodian bank H 18 Agent lender {LEI} of agent lender F

ESMA REGULAR USE
59
Table 23 - Cleared SFT with broker, agent lender, tri-party agent settled with a CSD
participant different from any of the entities and voluntary delegation of reporting to a third party No Field Example XML Message <SttlmPties> <CntrlSctiesDpstryPtcpt>

<LEI>AAAAAAAAAAAAAAAAAAAA</LEI>
</CntrlSctiesDpstryPtcpt>
</SttlmPties>
<AgtLndr>

<LEI>BBBBBBBBBBBBBBBBBBBB </LEI>
</AgtLndr>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
...
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
Non-cleared SFTs concluded by UCITS fund
Table 24 – SFTs to which the use case applies
Repo and reverse repo
Buy sell back/sell buy-back
Securities and commodities lending
Margin lending
Y
Table 25 shows the reporting of an SFT concluded by UCITS fund K. In accordance with
the Article 4(3) of SFTR the UCITS management company L is responsible for reporting on behalf of the UCITS, therefore it is identified in both fields “2.2” Report submitting entity and “2.10” Entity responsible for reporting. The transaction is settled with custodian bank H.

ESMA REGULAR USE
60
Table 25 - Non-cleared SFTs concluded by UCITS fund
No Field Example XML Message
1 Reporting timestamp
2020-01-
01T15:15:15
Z
<SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<New>
...
<CtrPtyData>
<RptgDtTm>2020-01-
01T15:15:15Z</RptgDtTm>
<RptSubmitgNtty>

<LEI>UUUUUUUUUU2222222222</LEI>
</RptSubmitgNtty>
<CtrPtyData>
<RptgCtrPty>
<Id>

<LEI>UUUUUUUUUU1111111111</LEI>
</Id>
<Ntr>
<FI>
<Clssfctn>UCIT</Clssfctn>
</FI>
</Ntr>
<Sd>GIVE</Sd>
</RptgCtrPty>
<OthrCtrPty>
<Id>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
<CtryCd>FR</CtryCd>
</OthrCtrPty>
<NttyRspnsblForRpt>

<LEI>UUUUUUUUUU2222222222</LEI>
</NttyRspnsblForRpt>
<OthrPtyData>
<SttlmPties>
<CntrlSctiesDpstryPtcpt>

<LEI>AAAAAAAAAAAAAAAAAAAA</LEI>
</CntrlSctiesDpstryPtcpt>
</SttlmPties>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
...
</LnData>
<CollData>
2 Report submitting entity
{LEI} of
UCITS managemen t company L
3 Reporting counterparty {LEI} of
UCITS K
4
Nature of the reporting counterparty F
5
Sector of the reporting counterparty UCIT
6
Additional sector classification
7
Branch of the reporting counterparty
8
Branch of the other counterparty
9 Counterparty side GIVE
10 Entity responsible for the report
{LEI} of
UCITS managemen t company L
11 Other counterparty
{LEI} of counterparty
B
12 Country of the other counterparty FR
13 Beneficiary
14 Tri-party agent
15 Broker
16 Clearing member
17
Central Securities
Depository (‘CSD’) participant or indirect participant {LEI} of custodian bank H 18 Agent lender

ESMA REGULAR USE
61
Table 25 - Non-cleared SFTs concluded by UCITS fund
No Field Example XML Message
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
Non-cleared SFTs concluded by UCITS fund, and the UCITs management company delegates reporting to a third party
Table 26 – SFTs to which the use case applies
Repo and reverse repo
Buy sell back/sell buy-back
Securities and commodities lending
Margin lending
Y
Table 27 shows the reporting of an SFT concluded by UCITS fund K. In accordance with
the article 4.3 of SFTR the UCITS management company L is responsible for reporting on behalf of the UCITS, therefore, it is identified in Field 2.10 “Entity responsible for reporting”, however, decides to delegate to the third party I which is included in Field 2.2 “Report submitting entity”. The transaction is settled with custodian bank H.
Table 27 - Non-cleared SFTs concluded by UCITS fund
No Field Example XML Message
1 Reporting timestamp
2020-01-
01T15:15:15
Z
<SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<New>
...
<CtrPtyData>
<RptgDtTm>2020-01-
01T15:15:15Z</RptgDtTm>
<RptSubmitgNtty>

<LEI>UUUUUUUUUU1111111111</LEI>
2 Report submitting entity {LEI} of third party I 3 Reporting counterparty {LEI} of UCITS K 4 Nature of the reporting counterparty F 5 Sector of the reporting counterparty UCIT 6 Additional sector classification 7 Branch of the reporting counterparty

ESMA REGULAR USE
62
Table 27 - Non-cleared SFTs concluded by UCITS fund
No Field Example XML Message
8
Branch of the other counterparty
</Id>
<Ntr>
<FI>
<Clssfctn>UCIT</Clssfctn>
</FI>
</Ntr>
<Sd>GIVE</Sd>
</RptgCtrPty>
<OthrCtrPty>
<Id>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
<CtryCd>FR</CtryCd>
</OthrCtrPty>
<NttyRspnsblForRpt>

<LEI>UUUUUUUUUU2222222222</LEI>
</NttyRspnsblForRpt>
<OthrPtyData>
<SttlmPties>
<CntrlSctiesDpstryPtcpt>

<LEI>AAAAAAAAAAAAAAAAAAAA</LEI>
</CntrlSctiesDpstryPtcpt>
</SttlmPties>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
...
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
9 Counterparty side GIVE
10 Entity responsible for the report
{LEI} of
UCITS managemen t company L
11 Other counterparty
{LEI} of counterparty
B
12 Country of the other counterparty FR
13 Beneficiary
14 Tri-party agent
15 Broker
16 Clearing member
17
Central Securities
Depository (‘CSD’) participant or indirect participant {LEI} of custodian bank H 18 Agent lender

ESMA REGULAR USE
63
Non-cleared SFTs concluded by AIF
Table 28 – SFTs to which the use case applies
Repo and reverse repo
Buy sell back/sell buy-back
Securities and commodities lending
Margin lending
Y
Table 29 shows reporting of an SFT concluded by AIF fund M. In accordance with the
article 4.3 of SFTR the AIF management company N is responsible for reporting on behalf
of the AIF, therefore it is identified in both Fields 2.2 “Report submitting entity” and 2.10 “Entity responsible for reporting”. The transaction is settled with custodian bank H.
Table 29 - Non-cleared SFTs concluded by AIF
N o
Field Example XML Message
1 Reporting timestamp 2020-01-
01T15:15:15Z
<SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<New>
...
<CtrPtyData>
<RptgDtTm>2020-01-
01T15:15:15Z</RptgDtTm>
<RptSubmitgNtty>

<LEI>AAAAAAAAAA2222222222</LEI>
</RptSubmitgNtty>
<CtrPtyData>
<RptgCtrPty>
<Id>

<LEI>AAAAAAAAAA1111111111</LEI>
</Id>
<Ntr>
<FI>
<Clssfctn>AIFD</Clssfctn>
</FI>
</Ntr>
<Sd>GIVE</Sd>
</RptgCtrPty>
<OthrCtrPty>
<Id>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
<CtryCd>FR</CtryCd>
</OthrCtrPty>
2 Report submitting entity
{LEI} of AIF management company N
3 Reporting counterparty {LEI} of AIF M
4
Nature of the reporting counterparty F
5
Sector of the reporting counterparty AIFD
6
Additional sector classification
7
Branch of the reporting counterparty
8
Branch of the other counterparty
9 Counterparty side GIVE
10 Entity responsible for the report
{LEI} of AIF management company N
11 Other counterparty
{LEI} of counterparty
B
12 Country of the other counterparty FR
13 Beneficiary
14 Tri-party agent

ESMA REGULAR USE
64
Table 29 - Non-cleared SFTs concluded by AIF
N o
Field Example XML Message
15 Broker <NttyRspnsblForRpt>

<LEI>AAAAAAAAAA2222222222</LEI>
</NttyRspnsblForRpt>
<OthrPtyData>
<SttlmPties>
<CntrlSctiesDpstryPtcpt>

<LEI>AAAAAAAAAAAAAAAAAAAA</LEI>
</CntrlSctiesDpstryPtcpt>
</SttlmPties>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
...
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
16 Clearing member
17
Central Securities
Depository (‘CSD’) participant or indirect participant {LEI} of custodian bank H 18 Agent lender Non-cleared SFTs where fund portfolio management is outsourced In the case of outsourcing of the portfolio management to a different entity from the fund management company, that entity should only be reported as broker, in case it acts as such. Otherwise this entity, similarly to other entities which might participate directly or indirectly in the SFT, should not be reported in any field In the scenario illustrated in Table 31, portfolio management of the AIF M is delegated to another entity which does not act as a broker. The transaction is settled with custodian bank H.
Table 30 – SFTs to which the use case applies
Repo and reverse repo
Buy sell back/sell buy-back
Securities and commodities lending
Margin lending
Y

ESMA REGULAR USE
65
Table 31 - Non-cleared SFTs where fund portfolio management is outsourced
No Field Example XML Message
1 Reporting timestamp
2020-01-
01T15:15:15
Z
<SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<New>
...
<CtrPtyData>
<RptgDtTm>2020-01-
01T15:15:15Z</RptgDtTm>
<RptSubmitgNtty>

<LEI>AAAAAAAAAA2222222222</LEI>
</RptSubmitgNtty>
<CtrPtyData>
<RptgCtrPty>
<Id>

<LEI>AAAAAAAAAA1111111111</LEI>
</Id>
<Ntr>
<FI>
<Clssfctn>AIFD</Clssfctn>
</FI>
</Ntr>
<Sd>GIVE</Sd>
</RptgCtrPty>
<OthrCtrPty>
<Id>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
<CtryCd>FR</CtryCd>
</OthrCtrPty>
<NttyRspnsblForRpt>

<LEI>AAAAAAAAAA2222222222</LEI>
</NttyRspnsblForRpt>
<OthrPtyData>
<Brkr>
<LEI>
AAAAAAAAAA2222222222</LEI>
</Brkr>
<SttlmPties>
<CntrlSctiesDpstryPtcpt>

<LEI>AAAAAAAAAAAAAAAAAAAA</LEI>
</CntrlSctiesDpstryPtcpt>
</SttlmPties>
2 Report submitting entity
{LEI} of AIF managemen t company N
3 Reporting counterparty {LEI} of AIF
M
4
Nature of the reporting counterparty F
5
Sector of the reporting counterparty AIFD
6
Additional sector classification
7
Branch of the reporting counterparty
8
Branch of the other counterparty
9 Counterparty side GIVE
10 Entity responsible for the report
{LEI} of AIF managemen t company N
11 Other counterparty
{LEI} of counterparty
B
12 Country of the other counterparty FR
13 Beneficiary
14 Tri-party agent
15 Broker
16 Clearing member
17
Central Securities
Depository (‘CSD’) participant or indirect participant {LEI} of custodian bank H 18 Agent lender

ESMA REGULAR USE
66
Table 31 - Non-cleared SFTs where fund portfolio management is outsourced
No Field Example XML Message
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
...
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
5.2 Loan and Collateral Data
Following the population of the counterparty data fields, the population of the loan and collateral fields for different use cases is included. The reporting in accordance with the ISO 20002 XML schemas is provided too. This will facilitate the population of fields by the counterparties. Each of the subsections will include a short description of the reporting logic for the fields that are being discussed. Reporting of action types at transaction level and position level.
5.2.1.1 New bilateral SFT at transaction level that is not cleared
Table 32 illustrates the population of the reporting fields in case of a new SFT, which is
not cleared. This is how the SFTs that are bilateral should be reported, at transaction level.
Table 32- New SFT at transaction level that is not cleared
No Field Example XML Message
1
Unique Trade
Identifier (UTI) UTI1 <SctiesFincgRptgTxRpt> <TradData> <Rpt> <New> ... <CtrPtyData> ... </CtrPtyData> <LnData> <RpTrad> 5 Cleared false 98 Action type NEWT 99 Level TCTN

ESMA REGULAR USE
67
Table 32- New SFT at transaction level that is not cleared
No Field Example XML Message

<UnqTradIdr>UTI1</UnqTradIdr>
<ClrSts>
<NonClrd>NORE</NonClrd>
</ClrSts>
</RpTrad>
</LnData>
<CollData>
...
</CollData>
<LvlTp>TCTN</LvlTp>
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
5.2.1.2 New bilateral SFT at transaction level that is i) cleared on the same day ii) or after.
Table 33, Table 34, and Table 35 illustrate the population of the reporting fields by a CP
(not the CCP) in case of a new SFT where the transaction is i) executed bilaterally and cleared afterwards on the same day or ii) cleared on a day following the one of its conclusion on a venue. Counterparties should submit an SFT report with action type “ETRM”, which does not allow for population of Field “Cleared” to indicate the early termination of the trade reported as uncleared. Afterwards the counterparty should submit an SFT report with action type “NEWT” to indicate that the SFT has been cleared. The sequence of the submissions are illustrated by Table 33, Table 34, and Table 35 respectively.
Table 33 - New bilateral SFT at transaction level that is cleared on the same day or
after.
No Field Example XML Message
1
Unique Trade
Identifier (UTI) UTI1 <SctiesFincgRptgTxRpt> <TradData> <Rpt> <New> ... <CtrPtyData> ... </CtrPtyData> <LnData> <RpTrad>

<UnqTradIdr>UTI1</UnqTradIdr>
</RpTrad>
<ClrSts>
<NonClrd>NORE</NonClrd>
5 Cleared false
98 Action type NEWT
99 Level TCTN

ESMA REGULAR USE
68
Table 33 - New bilateral SFT at transaction level that is cleared on the same day or
after.
No Field Example XML Message
</ClrSts>
</LnData>
<CollData>
...
</CollData>
<LvlTp>TCTN</LvlTp>
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
Table 34 – Termination of the bilateral SFT at transaction level due to clearing on the
same day or after.
No Field Example XML Message
1
Unique Trade
Identifier (UTI) UTI1 <SctiesFincgRptgTxRpt> <TradData> <Rpt> <EarlyTermntn> ... <CtrPtyData> ... </CtrPtyData> <LnData> <UnqTradIdr>UTI1</UnqTradIdr> </LnData> <CollData> ... </CollData> ... </EarlyTermntn> </Rpt> </TradData> </SctiesFincgRptgTxRpt> 98 Action type ETRM 99 Level
Table 35 – New cleared SFT at transaction level resulting from clearing of a bilateral
SFT on the same day or after.
No Field Example XML Message
1
Unique Trade
Identifier (UTI) UTI2 <SctiesFincgRptgTxRpt> <TradData>

ESMA REGULAR USE
69
Table 35 – New cleared SFT at transaction level resulting from clearing of a bilateral
SFT on the same day or after.
No Field Example XML Message
2
Report tracking number UTI18
<Rpt>
<New>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
<RpTrad>

<RptTrckgNb>UTI1</RptTrckgNb>
</Clrd>
</ClrSts>
</RpTrad>
</LnData>
<CollData>
...
</CollData>
<LvlTp>TCTN</LvlTp>
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
5 Cleared true
98 Action type NEWT
99 Level TCTN
Note that Table 33 and Table 34 report is not expected if the trade is concluded on a trading venue by counterparties that are also the clearing members and cleared by a central counterparty on the same day, only Table 35 report is expected. Furthermore,
Table 35 illustrates the reporting in the case where a cleared SFT is not included
immediately in a position (in which case it would be reported with action type POSC as clarified in the subsequent examples).
5.2.1.3 New SFT reported as position component
Table 36 and Table 37 illustrate the population of the reporting fields in case of a new SFT9
is reported as a position component. This is how the SFTs that are comprised in a CCPcleared position can be reported. See that the sequences showed by Table 36 and Table 37 have been developed taking into account that the SFT is concluded on a trading venue and cleared by a central counterparty on the same day, and therefore only the SFT in its 8 From CM client perspective, not applicable to the CCP´s report. 9 Cleared SFTs scenarios are marked as applicable to repos, although in practice, these scenarios are not expected. Position level is not possible for Margin Lending.

ESMA REGULAR USE
70 cleared form shall be reported. In the context of the examples for CCP-cleared SFTs, these are identified with Unique Trade Identifier (UTI) “PUTI1”. Since this option is a supplement reporting to transaction level, the reports are as follows. Counterparties should not report Report tracking number (Field 2.2) for CCP-cleared SFTs:
Table 36 - New SFT concluded on a trading venue and cleared by a central
counterparty on the same day and reported with position component at transaction level No Field Example XML Message 1 Unique Trade Identifier (UTI) UTI1 <SctiesFincgRptgTxRpt> <TradData> <Rpt> <PosCmpnt> ... <CtrPtyData> ... </CtrPtyData> <LnData> <RpTrad>

<UnqTradIdr>UTI2</UnqTradIdr>
<ClrSts>
<Clrd>
...
</Clrd>
</ClrSts>
</RpTrad>
</LnData>
<CollData>
...
</CollData>
<LvlTp>TCTN</LvlTp>
</PosCmpnt>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
5 Cleared true
98 Action type POSC10
99 Level TCTN
Table 37 - New CCP-cleared SFT reported at position level
No Field Example XML Message
1
Unique Trade
Identifier (UTI) PUTI1 <SctiesFincgRptgTxRpt> <TradData> 10 Note that the original trades at transaction level have to be reported with position component as an action type.

ESMA REGULAR USE
71
Table 37 - New CCP-cleared SFT reported at position level
No Field Example XML Message
5 Cleared true11 <Rpt>
<New>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
<RpTrad>

<UnqTradIdr>PUTI1</UnqTradIdr>
<ClrSts>
<Clrd>
...
</Clrd>
</ClrSts>
</RpTrad>
</LnData>
<CollData>
...
</CollData>
<LvlTp>PSTN</LvlTp>
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
98 Action type NEWT12
99 Level PSTN13
5.2.1.4 Modification of an SFT at transaction level
Table 38 illustrates the population of the reporting fields in case a previously reported SFT
at transaction level is modified.
Table 38 - Modification of an SFT at transaction level
No Field Example XML Message
1
Unique Trade Identifier
(UTI) UTI1 <SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<Mod>
...
<CtrPtyData>
98 Action type MODI
99 Level TCTN
11 Despite of the optionality, bilaterally agreed SFTs cannot be replaced by a single trade, so therefore all the reports made as position level shall be cleared. 12 In this example a new position is created. In the case where a cleared transaction is included in an existing position, it would be reported as modification of that position (with action type MODI) 13 Note that the resulting cleared SFT should be reported at position level, and position level repoting can be used only as a supplement to the trade level reporting and therefore the reporting of Tables Table 36 and Table 37 is expected.

ESMA REGULAR USE
72
Table 38 - Modification of an SFT at transaction level
No Field Example XML Message
...
</CtrPtyData>
<LnData>
<RpTrad>

<UnqTradIdr>UTI1</UnqTradIdr>
</RpTrad>
</LnData>
<CollData>
...
</CollData>
<LvlTp>TCTN</LvlTp>
</Mod>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
5.2.1.5 Modification of a CCP-cleared SFT at position level
Table 39 illustrates the population of the reporting fields in case of a modification of a CCP
cleared SFT previously reported at a position level. This is the result of the inclusion of additional SFTs concluded at transaction level and cleared on the same or on a different day by a CCP. There is no possibility to modify the original transaction level report once the transaction is included in the position, however, if any information was wrongly reported, that SFT might be corrected.
Table 39 - Modification of a CCP-cleared SFT at position level
No Field Example XML Message
1
Unique Trade
Identifier (UTI) PUTI1 <SctiesFincgRptgTxRpt> <TradData> <Rpt> <Mod> ... <CtrPtyData> ... </CtrPtyData> <LnData> <RpTrad>

<UnqTradIdr>PUTI1</UnqTradIdr>
<ClrSts>
<Clrd>
...
</Clrd>
</ClrSts>
5 Cleared true
98 Action type MODI
99 Level PSTN

ESMA REGULAR USE
73
Table 39 - Modification of a CCP-cleared SFT at position level
No Field Example XML Message
</RpTrad>
</LnData>
<CollData>
...
</CollData>
<LvlTp>PSTN</LvlTp>
</Mod>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
5.2.1.6 Correction of an SFT at transaction level
Table 40 illustrates the population of the reporting fields when there is a correction of data
fields that were submitted wrongly in a previous report of an SFT at transaction level.
Table 40 - Correction of an SFT at transaction level
No Field Example XML Message
1
Unique Trade Identifier
(UTI) UTI1
<SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<Crrctn>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
<RpTrad>

<UnqTradIdr>UTI1</UnqTradIdr>
</RpTrad>
</LnData>
<CollData>
...
</CollData>
<LvlTp>TCTN</LvlTp>
</Crrctn>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
98 Action type CORR
99 Level TCTN

ESMA REGULAR USE
74
5.2.1.7 Correction of a CCP-cleared SFT at position level
Table 41 illustrates the population of the reporting fields when there is a correction of data
fields that were submitted wrongly in a previous report at position level of a CCP-cleared SFT. There is no need to correct the original transaction level report if it was correctly reported.
Table 41 - Correction of a CCP-cleared SFT at position level
No Field Example XML Message
1
Unique Trade
Identifier (UTI) PUTI1
<SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<Crrctn>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
<RpTrad>

<UnqTradIdr>PUTI1</UnqTradIdr>
<ClrSts>
<Clrd>
...
</Clrd>
</ClrSts>
</RpTrad>
</LnData>
<CollData>
...
</CollData>
<LvlTp>PSTN</LvlTp>
</Crrctn>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
5 Cleared true
98 Action type CORR
99 Level PSTN
5.2.1.8 Valuation of SFT (only for SLB)
Table 42 illustrates the population of reporting fields when there is a valuation update of
the securities in an SLB transaction. The counterparty values the securities on loan at 1,000,000 EUR which in this case coincides with the loan value (Field 2.56), which is not applicable for Action type “VALU”. In this case, the counterparty report valuation of the securities on loan (Field 2.57) in the currency in which the loan is made. The currency of the market value is indicated in the xml tag.

ESMA REGULAR USE
75
Table 42 - Valuation of SFT (only for SLB)
No Field Example XML Message
1
Unique Trade Identifier
(UTI) UTI1 <SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<ValtnUpd>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
<UnqTradIdr>UTI1</UnqTradIdr>
<MktVal Ccy="EUR">1000000</MktVal>
</LnData>
<CollData>
...
</CollData>
...
</ValtnUpd>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
57 Market value 1000000
98 Action type VALU
5.2.1.9 Reporting of collateral update for SFTs collateralised at transaction level
The reporting of any information on collateral should be carried out only with action type COLU and, for SFTs collateralised at transaction level, the UTI of the collateralised transaction should be reported too as shown in Table 43. The specificities of collateral reporting are covered in Section 5.4. This example can be also applied to the reporting of collateral for SFTs reported at position level, in the case where collateral is assigned to the position.
Table 43 - Reporting of collateral update for SFTs collateralised at transaction level
No Field Example XML Message
1
Unique Trade Identifier
(UTI) UTI1 <SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<CollUpd>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
<RpTrad>

<UnqTradIdr>UTI1</UnqTradIdr>
</RpTrad>
</LnData>
<CollData>
98 Action type COLU
99 Level

ESMA REGULAR USE
76
Table 43 - Reporting of collateral update for SFTs collateralised at transaction level
No Field Example XML Message
...
</CollData>
...
</CollUpd>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
Moreover, once an SFT is included into a position, any collateral update should be reported for that position rather than for an original SFT.
5.2.1.10 Reporting of collateral update for SFTs collateralised at net exposure level
The reporting of any information on collateral should be carried out only with Action type COLU and, for SFTs collateralised at net exposure level, no UTI is required as showed in
Table 44. The specificities of collateral reporting are covered in Section 5.4.
Table 44 - Reporting of collateral update for SFTs collateralised at net exposure level
No Field Example XML Message
1
Unique Trade Identifier
(UTI)
< SctiesFincgRptgTxRpt>
<TradData>
<CollUpd>
…
<CtrPtyData>
...
</CtrPtyData>
<LnData>
…
</LnData>
<CollData>
...
</CollData>
…
</CollUpd>
</TradData>
…
</SctiesFincgRptgTxRpt>
98 Action type COLU
99 Level
5.2.1.11 Early termination of an SFT
Table 45 illustrates the population of reporting fields when termination of an open term
SFT or an early termination of a fixed-term SFT occurs. The level, i.e. transaction or position, at which the SFT is reported is irrelevant for this use case, as Field 2.99 “Level” is not applicable for this action type.

ESMA REGULAR USE
77
Table 45 - Early termination of an SFT
No Field Example XML Message
1
Unique Trade Identifier
(UTI) UTI1 <SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<EarlyTermntn>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
<UnqTradIdr>UTI1</UnqTradIdr>
</LnData>
<CollData>
...
</CollData>
...
</EarlyTermntn>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
98 Action type ETRM
99 Level
5.2.1.12 Erroring an SFT
Table 46 illustrates the population of reporting fields in case of a cancellation of a wrongly
submitted entire report where the SFT never came into existence or was not subject to SFT reporting requirements, but which was reported to a TR by mistake. The level, i.e. transaction or position, at which the SFT is reported is irrelevant for this use case, as Field
2.99 “Level” is not applicable for this action type.
Table 46 - Erroring SFTs at transaction level
No Field Example XML Message
1
Unique Trade Identifier
(UTI) UTI1 <SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<Err>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
<UnqTradIdr>UTI1</UnqTradIdr>
</LnData>
<CollData>
...
</CollData>
...
</Err>
</Rpt>
</TradData>
98 Action type EROR
99 Level

ESMA REGULAR USE
78
Table 46 - Erroring SFTs at transaction level
No Field Example XML Message
</SctiesFincgRptgTxRpt>
5.3 Loan Data
The subsequent sections emphasise the population of a given set of fields that share specific characteristics of the loan side of a transaction. These will allow the reporting counterparties to directly assess the information that they should report for each specific data section where applicable. The validation rules contain the complete guidance on applicable fields per SFT type, Action type and Level, as well as the relevant dependencies. All the examples and use cases below contain randomly generated codes, none of them pertaining to a security or an entity. Reporting of event date Counterparties should be mindful that the information reported with regards to a given event date should allow authorities to have a clear view on the exposures arising from a given (set of) SFTs as of the close of the day for which the SFT refers to. Counterparties should report the event date in accordance with section 4.9.6. Reporting of cleared / non-cleared SFT
5.3.2.1 Cleared SFTs open offer
When a trade is cleared in an open offer model, the clearing takes place at the time of conclusion of the SFT.
Table 47 illustrates the population of fields of the above-mentioned situation from the CCP
O and CM-client perspective, as in this case, it is identical.
The following group of reporting fields should be reported:
a. “Cleared” (Field 2.5) is populated with “true”; b. “Clearing Timestamp” (Field 2.6) is equal to Field 2.12 “Execution timestamp”;
c. “CCP” (Field 2.7) is populated with the LEI of the CCP O.
Table 47 - From CCP and CM perspective
No Field Example XML Message
2
Report tracking number RTN1 <SctiesFincgRptgTxRpt> <TradData> <Rpt> <New> ... <CtrPtyData> 5 Cleared true 6 Clearing timestamp 2020-04- 22T16:41:07Z

ESMA REGULAR USE
79
Table 47 - From CCP and CM perspective
No Field Example XML Message
7 CCP {LEI} of CCP
O
...
</CtrPtyData>
<LnData>
<RpTrad>

<LEI>BBBBBBBBBB1111111111</LEI>
</CCP>
<ClrDtTm>2020-04-
22T16:41:07Z</ClrDtTm>
</Clrd>
</ClrSts>
<MstrAgrmt>
<Tp>
<Tp>OTHR</Tp>
</Tp>

<OthrMstrAgrmtDtls>CCPClearingCondition s</OthrMstrAgrmtDtls> </MstrAgrmt> </RpTrad> </LnData> <CollData> ... </CollData> ... </New> </Rpt> </TradData> </SctiesFincgRptgTxRpt> 9 Master agreement Type OTHR 10 Other master agreement type CCPClearing Conditions 12 Execution timestamp 2020-04- 22T16:41:07Z
5.3.2.2 Cleared SFT in a novation model
When a trade is cleared in a novation model, the clearing takes place after the time of conclusion of the SFT.
Table 48 and Table 49 illustrate the population of fields, from the CCP O and the CM
perspective respectively, in case of an SFT cleared by CCP O in a novation model. In this respect, the following group of reporting fields should be reported:

ESMA REGULAR USE
80 a. “Report tracking number” (Field 2.2) should be reported with the prior UTI (that of the bilateral transaction in the case of CCP-cleared SFTs) but only to be reported by the CM and its client (not by the CCP); b. “Cleared” (Field 2.5) is populated with “true”;
c. “Clearing Timestamp” (Field 2.6) is after Field 2.12 Execution timestamp;
d. “CCP” (Field 2.7) is populated with the LEI of the CCP O.
Table 48 – Cleared SFT in a novation model from CCP perspective
No Field Example XML Message
1
Unique Trade
Identifier (UTI) UTI2 <SctiesFincgRptgTxRpt> <TradData> <Rpt> <New> <CtrPtyData> ... </CtrPtyData> <LnData> <RpTrad> <UnqTradIdr>UTI2</UnqTradIdr> <ExctnDtTm>2020-04- 22T14:41:07Z</ExctnDtTm> <ClrSts> <Clrd> <CCP>

<LEI>BBBBBBBBBB1111111111</LEI>
</CCP>
<ClrDtTm>2020-04-
22T16:41:07Z</ClrDtTm>
</Clrd>
</ClrSts>
<MstrAgrmt>
<Tp>
<Tp>OTHR</Tp>
</Tp>

<OthrMstrAgrmtDtls>CCPClearingCondition s</OthrMstrAgrmtDtls> </MstrAgrmt> </RpTrad> </LnData> <CollData> ... </CollData> ... </New> </Rpt> </TradData> 2 Report tracking number 5 Cleared true 6 Clearing timestamp 2020-04- 22T16:41:07Z 7 CCP {LEI} of CCP O 9 Master agreement Type OTHR 10 Other master agreement type CCPClearing Conditions 12 Execution timestamp 2020-04- 22T14:41:07Z

ESMA REGULAR USE
81
Table 48 – Cleared SFT in a novation model from CCP perspective
No Field Example XML Message
</SctiesFincgRptgTxRpt>
Table 49 shows the example from CM perspective. The population of the fields should be
the same for the client perspective.
Table 49 - Cleared SFT in a novation model from CM perspective
No Field Example XML Message
1
Unique Trade
Identifier (UTI) UTI2 <SctiesFincgRptgTxRpt> <TradData> <Rpt> <New> ... <CtrPtyData> ... </CtrPtyData> <LnData> <RpTrad> <UnqTradIdr>UTI2</UnqTradIdr> <ExctnDtTm>2020-04- 22T14:41:07Z</ExctnDtTm> <ClrSts> <Clrd> <CCP>

<LEI>BBBBBBBBBB1111111111</LEI>
</CCP>
<ClrDtTm>2020-04-
22T16:41:07Z</ClrDtTm>

<OthrMstrAgrmtDtls>CCPClearingCondition s</OthrMstrAgrmtDtls> </MstrAgrmt> </RpTrad> </LnData> <CollData> ... </CollData> ... </New> 2 Report tracking number UTI1 5 Cleared true 6 Clearing timestamp 2020-04- 22T16:41:07Z 7 CCP {LEI} of CCP O 9 Master agreement Type OTHR 10 Other master agreement type CCPClearing Conditions 12 Execution timestamp 2020-04- 22T14:41:07Z

ESMA REGULAR USE
82
Table 49 - Cleared SFT in a novation model from CM perspective
No Field Example XML Message
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
5.3.2.3 CCP-cleared SFT in a DBV model
When a trade is cleared in DBV model, the clearing takes place after the time of conclusion if the SFT. Field 2.19 indicates whether the transaction was settled using the Delivery by Value mechanism.
Table 50 illustrates the population of fields from the CCP O perspective. On this regard
the following group of reporting fields should be reported:
a. “Cleared” (Field 2.5) is populated with “true”; b. “Clearing Timestamp” (Field 2.6) is after Field 2.12 Execution timestamp;
c. “CCP” (Field 2.7) is populated with the LEI of the CCP O.
Table 50 - CCP perspective
No Field Example XML Message
1
Unique Trade
Identifier (UTI) UTI2 <SctiesFincgRptgTxRpt> <TradData> <Rpt> <New> ... <CtrPtyData> ... </CtrPtyData> <LnData> <RpTrad> <UnqTradIdr>UTI2</UnqTradIdr> <ExctnDtTm>2020-04- 22T14:41:07Z</ExctnDtTm> <ClrSts> <Clrd> <CCP>

<LEI>BBBBBBBBBB1111111111</LEI>
</CCP>
<ClrDtTm>2020-04-
22T16:41:07Z</ClrDtTm>
</Clrd>
</ClrSts>
<MstrAgrmt>
<Tp>
<Tp>OTHR</Tp>
2
Report tracking number
5 Cleared true
6 Clearing timestamp 2020-04-
22T16:41:07Z
7 CCP {LEI} of CCP
O
9
Master agreement
Type OTHR
10 Other master agreement type
CCPClearing
Conditions
12 Execution timestamp 2020-04-
22T14:41:07Z
19 Delivery by Value
(“DBV”) indicator true

ESMA REGULAR USE
83
Table 50 - CCP perspective
No Field Example XML Message
</Tp>

<OthrMstrAgrmtDtls>CCPClearingCondition s</OthrMstrAgrmtDtls> </MstrAgrmt> <DlvryByVal>true</DlvryByVal> </RpTrad> </LnData> <CollData> ... </CollData> ... </New> </Rpt> </TradData> </SctiesFincgRptgTxRpt>
Table 51 - CM perspective
No Field Example XML Message
1
Unique Trade
Identifier (UTI) UTI2
2
Report tracking number UTI1
<SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<New>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
<RpTrad>
<UnqTradIdr>UTI2</UnqTradIdr>
<ExctnDtTm>2020-04-
22T14:41:07Z</ExctnDtTm>
<ClrSts>
<Clrd>
<CCP>

<LEI>BBBBBBBBBB1111111111</LEI>
</CCP>
<ClrDtTm>2020-04-
22T16:41:07Z</ClrDtTm>

<RptTrckgNb>UTI1</RptTrckgNb>
</Clrd>
</ClrSts>
<MstrAgrmt>
<Tp>
5 Cleared true
6 Clearing timestamp 2020-04-
22T16:41:07Z
7 CCP {LEI} of CCP
O
9
Master agreement
Type OTHR
10 Other master agreement type
CCPClearing
Conditions
12 Execution timestamp 2020-04-
22T14:41:07Z
19 Delivery by Value
(“DBV”) indicator true

ESMA REGULAR USE
84
Table 51 - CM perspective
No Field Example XML Message
<Tp>OTHR</Tp>
</Tp>

<OthrMstrAgrmtDtls>CCPClearingCondition s</OthrMstrAgrmtDtls> </MstrAgrmt> <DlvryByVal>true</DlvryByVal> </RpTrad> </LnData> <CollData> ... </CollData> ... </New> </Rpt> </TradData> </SctiesFincgRptgTxRpt>
5.3.2.4 Non-cleared SFT
“Cleared” (Field 2.5) is populated with “false” as showed in Table 52. The rest of the fields related to clearing are not populated. Execution timestamp is populated.
Table 52 - Non-cleared SFT
N o
Field Example XML Message
1
Unique Trade
Identifier (UTI) UTI1
2
Report tracking number
<SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<New>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
<RpTrad>
<UnqTradIdr>UTI1</UnqTradIdr>
<ExctnDtTm>2020-04-
22T14:41:07Z</ExctnDtTm>
</RpTrad>
</LnData>
<CollData>
...
</CollData>
...
</New>
5 Cleared false
6 Clearing timestamp
7 CCP
12 Execution timestamp 2020-04-
22T14:41:07Z

ESMA REGULAR USE
85
Table 52 - Non-cleared SFT
N o
Field Example XML Message
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
Trading venue
The field “Trading venue” (Field 2.8) should be populated in accordance with the type of conclusion of the SFT. The counterparties should always use the segment MIC. In case an SFT is concluded on an automated trading systems (ATS) or broker matching platform, the MIC of the platform should be populated. This field does not allow population with LEI. Master agreement section
5.3.4.1 Documented SFT with master agreement from the list
When a master agreement is used, the following fields should be reported:
a. “Master agreement type” (Field 2.9); b. “Master agreement version” (Field 2.11), when Field 2.9 is populated with value other than “BIAG”. “CSDA” or “OTHR”. If the master agreement (other than "BIAG", "CSDA" or "OTHR") does not have a version, the counterparties should populate the field “Master agreement version” with the year in which they signed the agreement. SFTs under CSDs' fails-curing programmes should be reported with Master agreement type "CSDA".
Table 53 illustrates the population of fields in case the SFT is concluded under the GMRA
2011 master agreement.
Table 53 - Documented SFT with master agreement from the list
No Field Example XML Message
9
Master agreement type GMRA <SctiesFincgRptgTxRpt> <TradData> <Rpt> <New> ... <CtrPtyData> ... </CtrPtyData> <LnData> <RpTrad> <MstrAgrmt> <Tp> <Tp>GMRA</Tp> 10 Other master agreement type 11 Master agreement version 2011

ESMA REGULAR USE
86
Table 53 - Documented SFT with master agreement from the list
No Field Example XML Message
</Tp>
<Vrsn>2011</Vrsn>
</MstrAgrmt>
</RpTrad>
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
5.3.4.2 Documented SFT with agreement that is not in the list
When a master agreement not in the list (e.g. CCP clearing conditions for novated transactions, or prime brokerage bilateral agreements in margin lending) is used the following fields should be reported:
a. “Master agreement type” (Field 2.9). b. “Other master agreement type” (Field 2.10), when “OTHR” reported in Field 2.9.
Table 54 illustrates the population of fields in case the SFT is concluded under a master
agreement that is not in the list and refers to the CCP O Repo Rulebook.
Table 54 - Documented SFT with agreement that Is not in the list
No Field Example XML Message
9
Master agreement type OTHR <SctiesFincgRptgTxRpt> <TradData> <Rpt> <New> <LnData> ... <CtrPtyData> ... </CtrPtyData> <RpTrad> <MstrAgrmt> <Tp> <Tp>OTHR</Tp> </Tp> <OthrMstrAgrmtDtls>CCP O Repo Rulebook</OthrMstrAgrmtDtls> </MstrAgrmt> </RpTrad> </LnData> <CollData> 10 Other master agreement type CCP O Repo Rulebook 11 Master agreement version

ESMA REGULAR USE
87
Table 54 - Documented SFT with agreement that Is not in the list
No Field Example XML Message
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
5.3.4.3 Undocumented SFT
In the case of the undocumented SFT, the following fields should be reported (see Table 55):
a. “Master agreement type” (Field 2.9), which should be populated with “OTHR”. b. “Other master agreement type” (Field 2.10), which should be populated with “Undocumented”.
Table 55 - Undocumented SFT
No Field Example XML Message
9
Master agreement type OTHR <SctiesFincgRptgTxRpt> <TradData> <Rpt> <New> ... <CtrPtyData> ... </CtrPtyData> <LnData> <RpTrad> <MstrAgrmt> <Tp> <Tp>OTHR</Tp> </Tp>

<OthrMstrAgrmtDtls>Undocumented</Oth rMstrAgrmtDtls> </MstrAgrmt> </RpTrad> </LnData> <CollData> ... </CollData> ... </New> </Rpt> </TradData> </SctiesFincgRptgTxRpt> 10 Other master agreement type Undocumented 11 Master agreement version

ESMA REGULAR USE
88
Conclusion and start of the transaction
The following two examples illustrate reporting of a conclusion of the SFT (a) starting immediately and (b) with a forward value date. The value date should be understood as the agreed settlement date in line with the definition of Field 2.13 in the RTS. A temporary settlement fail on the expected Value date does not require any additional report (e.g. a “Modification”), unless the counterparties agree to amend or terminate the transaction because of the settlement failure (in which case the modification or the termination event needs to be reported accordingly).
5.3.5.1 Immediate
Table 56 illustrates the population of fields in case the transaction is executed and starts
in two days, i.e. the settlement cycle in the EU. This is an immediate SFT.
Table 56 - Immediate
No Field Example XML Message
12 Execution timestamp 2020-04-
22T16:41:07Z
<SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<New>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
<RpTrad>
<ExctnDtTm>2020-04-
22T16:41:07Z</ExctnDtTm>
<ValDt>2020-04-24</ValDt>
</RpTrad>
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
13 Value date (Start date) 2020-04-24
5.3.5.2 Forward
Table 57 illustrates the population of fields in case the transaction starts one month after
it is executed; this means that this is a forward SFT.

ESMA REGULAR USE
89
Table 57 - Forward
No Field Example XML Message
12 Execution timestamp 2020-04-
22T16:41:07Z
<SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<New>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
<RpTrad>
<ExctnDtTm>2020-04-
22T16:41:07Z</ExctnDtTm>
<ValDt>2020-05-22</ValDt>
</RpTrad>
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
13 Value date (Start date) 2020-05-22
Term of the SFT
When reporting the Minimum notice period (Field 2.16), counterparties should provide the information regarding the business days in accordance with the definition of business day in the relevant master agreement or bilateral agreement that governs the SFT. When this field is applicable to SFTs whose optionality is not included in the TS on reporting, such as puttable repos, the counterparties should report the information about the Earliest call-back date (Field 2.17) if it is available. Counterparties should report the Minimum notice period (Field 2.16) for open term repos i.e. Field 2.21 is populated with “true”, as well as for evergreen and extendable repos, i.e. Field 2.22 is populated with ETSB and EGRN. Counterparties should populate Field 2.17 “Earliest call back date” for those SFTs that have termination optionality. Unless the counterparties have agreed to have a new earliest call-back date, they should report the original earliest call-back date applicable to the SFT.
5.3.6.1 Open term
Table 58 illustrates the population of fields in case the counterparties agree on an open
term transaction with a minimum notice period for the termination of the transaction of 1 day.

ESMA REGULAR USE
90
Table 58 - Open term
No Field Example XML Message
14 Maturity date (End date)
<SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<New>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
<RpTrad>
<MinNtcePrd>1</MinNtcePrd>
<Term>
<Opn>NOAP</Opn>
</Term>
</RpTrad>
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
16 Minimum notice period 1
17 Earliest call-back date
21 Open term true
5.3.6.2 Fixed-term
Table 59 illustrates the population of fields in case the counterparties agreed to exchange
cash, securities, or commodities versus collateral for the closing leg (forward leg) of the SFT on 22 May 2020. The minimum number of business days, in the example, that one of the counterparties has to inform the other counterparty of the termination of this SFT is 5. The earliest date that the cash lender has the right to call back a portion of the funds or to terminate the transaction is the 7 May 2020. While this scenario is not standard practice, it is still possible to happen.
Table 59 - Fixed term
No Field Example XML Message
14 Maturity date (End date) 2020-05-22 <SctiesFincgRptgTxRpt> <TradData> <Rpt> <New> ... <CtrPtyData> ... </CtrPtyData> <LnData> 16 Minimum notice period 5 17 Earliest call-back date 2020-05-07 21 Open term false

ESMA REGULAR USE
91
Table 59 - Fixed term
No Field Example XML Message
<RpTrad>
<MinNtcePrd>5</MinNtcePrd>
<EarlstCallBckDt>2020-05-
07</EarlstCallBckDt>
</RpTrad>
</LnData>
</New>
<Mod>
<LnData>
<RpTrad>
<Term>
<Fxd>
<MtrtyDt>2020-05-
22</MtrtyDt>
</Fxd>
</Term>
</RpTrad>
</LnData>
<CollData>
...
</CollData>
...
</Mod>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
Termination optionality
ESMA points out that the counterparties should report Field 2.22 with one of the following values: "EGRN”, “ETSB” or “NOAP”. Field 2.21 shall contain one of the values: “true” or “false”. If Field 2.22 Termination optionality is populated with ”ETSB”, this field shall be populated with ”false”. In case the SFT is callable or puttable, the counterparties should report this information in “Earliest call-back date” (Field 2.17). General and Specific collateral arrangements The field “General Collateral Indicator” (Field 2.18) only applies to the securities provided as collateral, and not to the securities on loan. In line with the RTS, and for consistency with the reporting instructions used in MMSR, “GENE” should be reported in all cases where the collateral provider can choose the security to provide as collateral amongst a range of securities meeting predefined criteria. This also includes, but is not limited to, GC facilities provided by an Automatic Trading System such as those run by CCPs, and transactions in which the collateral is managed

ESMA REGULAR USE
92 by a triparty agent. “GENE” should also be the default case in most SLB arrangements. “SPEC” should only be reported in cases in which the collateral taker requests a specific ISIN to be provided as collateral. The reporting of collateralisation on a net exposure basis (Field 2.73) is a separate question, which is not directly linked to the type of collateral arrangement. Transactions taking place on a GC platform may be collateralised either on a single transaction basis or on a net exposure basis. The counterparties should report them as appropriate. The reporting of collateral baskets is explained in Section 5.4.2 on collateralisation. When an SFT was originally concluded as GC, but has specific securities chosen by the collateral taker allocated after execution, it becomes specific collateral transaction immediately. An SFT report with action type “MODI” should be reported with the revised value for Field 2.18, and the relevant collateral should be reported with action type “COLU”. Unless otherwise agreed by the counterparties, the triparty repos should be reported with Field 2.18 “General collateral indicator” populated as “GENE”.
Table 60, Table 61 and Table 62 provide three examples of how to populate the “General
Collateral indicator” (Field 2.18). Please note that these may not cover all existing cases.
5.3.8.1 Specific collateral in title transfer
Table 60 illustrates the population of fields in case the SFT is subject to a specific collateral
arrangement (Field 2.18 populated with SPEC), and such collateral is subject to a title transfer (Field 2.20 populated with TTCA).
Table 60 - Specific collateral in title transfer
No Field Example XML Message
18 General collateral indicator SPEC <SctiesFincgRptgTxRpt> <TradData> <Rpt> <New> ... <CtrPtyData> ... </CtrPtyData> <LnData> <RpTrad> <GnlColl>SPEC</GnlColl> <DlvryByVal>false</DlvryByVal>

<CollDlvryMtd>TTCA</CollDlvryMtd>
</RpTrad>
</LnData>
<CollData>
...
</CollData>
...
</New>
19 Delivery By Value
(‘DBV’) indicator false
20 Method used to provide collateral TTCA

ESMA REGULAR USE
93
Table 60 - Specific collateral in title transfer
No Field Example XML Message
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
5.3.8.2 General collateral in pledge
Table 61 illustrates the population of fields in case the SFT is subject to a general collateral
arrangement (Field 2.18 populated with GENE), and such collateral is subject to a Securities financial collateral arrangement (Field 2.20) populated with SICA.
Table 61 - General collateral in pledge
No Field Example XML Message
18 General collateral indicator GENE <SctiesFincgRptgTxRpt> <TradData> <Rpt> <New> ... <CtrPtyData> ... </CtrPtyData> <LnData> <RpTrad> <GnlColl>GENE</GnlColl> <DlvryByVal>false</DlvryByVal>

<CollDlvryMtd>SICA</CollDlvryMtd>
</RpTrad>
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
19 Delivery By Value
(‘DBV’) indicator false
20 Method used to provide collateral SICA
5.3.8.3 DBV general collateral in title transfer
Table 62 illustrates the population of fields in case the SFT is subject to a general collateral
arrangement (Field 2.18 populated with GENE), and such collateral is subject to a title transfer (Field 2.20 populated with TTCA). The transaction is settled using the DBV mechanism (Field 2.19) populated with TRUE.

ESMA REGULAR USE
94
Table 62 - DBV general collateral in title transfer
No Field Example XML Message
18 General collateral indicator GENE <SctiesFincgRptgTxRpt> <TradData> <Rpt> <New> ... <CtrPtyData> ... </CtrPtyData> <LnData> <RpTrad> <GnlColl>GENE</GnlColl> <DlvryByVal>true</DlvryByVal>

<CollDlvryMtd>TTCA</CollDlvryMtd>
</RpTrad>
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
19 Delivery By Value
(‘DBV’) indicator true
20 Method used to provide collateral TTCA
Fixed or floating rates
When concluding SFTs, counterparties might agree to use fixed interest rate or floating rate for the loan side of the SFT. Negative values are allowed for the “Fixed rate” (Field 2.23) and the “Adjusted floating rate” (Field 2.35). 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. Certain floating rates, such as ESTER, SOFR, etc. have been established after the publication of the RTS and ITS on reporting. They have an ISO code. Counterparties should use the already agreed codes to report the information in a more consistent way. When there are other floating rates which do not have an ISO code, the counterparties should report a consistent alphanumeric code. Counterparties should report Fields 2.35 “Adjusted rate” and 2.36 “Rate date” only for preagreed future rate changes captured as part of the conclusion of the transaction. The rest of the changes to the fixed or floating rates should be reported in Fields 2.23 and 2.25, respectively. Counterparties should not report in Fields 2.23 or Field 2.25 any rate related to the short market value (Field 2.71).

ESMA REGULAR USE
95
5.3.9.1 Fixed rate - Initial report
When counterparties conclude SFTs with fixed rates, they should to populate Fields 2.23 and 2.24 as shown in Table 63. In this case, the annualised interest rate is “-0.23455” with the day count convention as Actual360 (“A004”).
Table 63 - Fixed rate - Initial report
No Field Example XML Message
1 UTI UTI1 <SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<New>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
<UnqTradIdr>UTI1</UnqTradIdr>
<RpTrad>
<IntrstRate>
<Fxd>
<Rate>-0.23455</Rate>
<DayCntBsis>
<Cd>A004</Cd>
</DayCntBsis>
</Fxd>
</IntrstRate>
</RpTrad>
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
23 Fixed rate -0.23455
24 Day count convention A004
98 Action type NEWT
5.3.9.2 Fixed rate – modification
When counterparties agree to modify the fixed rate, i.e. to re-rate the SFT, they should report the modification in Field 2.23 and in Field 2.24, as shown in Table 64. In this case, the new annualised interest rate is “0.12345” with the new day count convention as Actual365Fixed (“A005”).
Table 64 - Fixed rate – modification
No Field Example XML Message
1 UTI UTI1 <SctiesFincgRptgTxRpt>

ESMA REGULAR USE
96
Table 64 - Fixed rate – modification
No Field Example XML Message
23 Fixed rate 0.12345 <TradData>
<Rpt>
<Mod>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>

<RpTrad><UnqTradIdr>UTI1</UnqTradIdr>
<IntrstRate>
<Fxd>
<Rate>0.12345</Rate>
<DayCntBsis>
<Cd>A005</Cd>
</DayCntBsis>
</Fxd>
</IntrstRate>
</RpTrad>
</LnData>
<CollData>
...
</CollData>
...
</Mod>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
24 Day count convention A005
98 Action type MODI
5.3.9.3 Floating rate – Initial report
In Table 65 it is illustrated the population of fields when the counterparties concluded an SFT by choosing as reference rate EONIA (Field 25) with a floating rate reference period expressed in days (Field 2.26) with an integer multiplier of the time period of 1 day (Field 2.27). The counterparties also agreed on a week time period in the floating rate payment frequency (Field 2.28) with an integer multiplier of the time period of 1 week (Field 2.29) describing how often the counterparties exchange payments. In this case, the floating rate will reset with a time period of days (Field 2.30) with a multiplier of 1 day (Field 2.31). In this case, the number of basis points to be added (or subtracted in case of negative value which is allowed for this field) as spread to the floating interest rate in order to determine the interest rate of the loan are is “5” (Field 2.32).

ESMA REGULAR USE
97
Table 65 - Floating rate – Initial report
No Field Example XML Message
25 Floating rate EONA <SctiesFincgRptgTxRpt> <TradData> <Rpt> <New> ... <CtrPtyData> ... </CtrPtyData> <LnData> <RpTrad> <IntrstRate> <Fltg> <RefRate> <Indx>EONA</Indx> </RefRate> <Term> <Unit>DAYS</Unit> <Val>1</Val> </Term> <PmtFrqcy> <Unit>WEEK</Unit> <Val>1</Val> </PmtFrqcy> <RstFrqcy> <Unit>DAYS</Unit> <Val>1</Val> </RstFrqcy> <BsisPtSprd>5</BsisPtSprd> </Fltg> </IntrstRate> </RpTrad> </LnData> <CollData> ... </CollData> ... </New> </Rpt> </TradData> </SctiesFincgRptgTxRpt> 26 Floating rate reference period - time period DAYS 27 Floating rate reference period - multiplier 1 28 Floating rate payment frequency - time period WEEK 29 Floating rate payment frequency - multiplier 1 30 Floating rate reset frequency - time period DAYS 31 Floating rate reset frequency - multiplier 1 32 Spread 5
5.3.9.4 Floating rate adjustment fields
Floating rate adjustment should be reported as it was agreed by the counterparties. Negative values are allowed.

ESMA REGULAR USE
98
Repo and BSB/SBB principal amounts
Table 66 illustrates the population of fields in case the principal amount on the value date
is 10,162,756.90 EUR, and the principal amount on the maturity date is 10,161,551.48 EUR. Where the principal amount on the maturity date (Field 2.38) value is not yet known, the validation rules allow this field to remain blank. This field should later be updated when the value is known. In the case of benchmarks, the expected principal amount at maturity date should be reported at the time of reporting and updated once the variance is known.
Table 66 - Repo and BSB/SBB principal amounts
No Field Example XML Message
37 Principal amount on the value date 10162756.90 <SctiesFincgRptgTxRpt> <TradData> <Rpt> <New> ... <CtrPtyData> ... </CtrPtyData> <LnData> <RpTrad> <PrncplAmt> <ValDtAmt Ccy="EUR">10162756.9</ValDtAmt> <MtrtyDtAmt Ccy="EUR">10161551.48</MtrtyDtAmt> </PrncplAmt> </RpTrad> </LnData> <CollData> ... </CollData> ... </New> </Rpt> </TradData> </SctiesFincgRptgTxRpt> 38 Principal amount on the maturity date 10161551.48 39 Principal amount currency EUR Loan side in securities lending In SLB transactions, the loan side of the trade involves a security which needs to be valued consistently by the reporting counterparties. The “Security or commodity price” (Field 2.49) should be reported in the currency in which the security or commodity price is denominated. This currency should be specified in “Price currency” (Field 2.50). Moreover, the security price should not include any margining requirement, discount, mark-up, addon, etc. which should instead be reported as part of the Collateral market value (Field 2.88), even if they are calculated from the loan side of the transaction.

ESMA REGULAR USE
99
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 “Currency of nominal amount” (Field 2.48). Other securities should be reported as a quantity, in which case “Unit of measure” (Field 2.47) has to be populated whereas “Currency of nominal amount” (Field 2.48) is left empty. “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. “Market value” however represents the valuation of the securities on loan by the counterparties. This valuation may be in a different currency from the one in which the security on loan is denominated. Please also refer to the example in Section 5.2.1.8. Loan value is calculated as follows:
𝑳𝒐𝒂𝒏 𝒗𝒂𝒍𝒖𝒆 (𝒇𝒊𝒆𝒍𝒅 𝟐. 𝟓𝟔) = 𝑄𝑢𝑎𝑛𝑡𝑖𝑡𝑦 𝑜𝑟 𝑛𝑜𝑚𝑖𝑛𝑎𝑙 𝑎𝑚𝑜𝑢𝑛𝑡 (𝑓𝑖𝑒𝑙𝑑 2.46) ∗ 𝑆𝑒𝑐𝑢𝑟𝑖𝑡𝑦 𝑜𝑟 𝑐𝑜𝑚𝑚𝑜𝑑𝑖𝑡𝑦 𝑝𝑟𝑖𝑐𝑒 (𝑓𝑖𝑒𝑙𝑑 2.49) 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 “Market value” (Field 2.57). Securities
5.3.12.1 Security / collateral quality
The fields Security quality (Field 2.51) and Collateral quality (Field 2.90) should be populated by the reporting entities with one of the values specified in the ITS on reporting. The value “NOAP” should be used for the following collateral types (Field 2.94): Main index equities (MEQU), Other equities (OEQU), and Other assets (OTHR) for which credit ratings within the meaning of the Regulation (EG) No 1060/2009 (CRAR) are not applicable14. The value “NOTR” should only be used for instruments that can be rated but do not have a credit rating. To report this information, and in order to avoid mechanistic reliance on credit ratings in accordance with Article 5a of the CRA Regulation, the counterparties should rely on their internal assessment of the credit quality of the securities, which may include external ratings from one or several CRAs. The value reported should reflect as closely as possible the characteristics of the security. Where external ratings have been used as an input to populate Field 2.51, counterparties 14 Under CRAR Article 3, “Credit rating” means an opinion regarding the creditworthiness of an entity, a debt or financial obligation, debt security, preferred share or other financial instrument, or of an issuer of such a debt or financial obligation, debt security, preferred share or other financial instrument, issued using an established and defined ranking system of rating categories.”

ESMA REGULAR USE
100 should ideally base their assessment on the instrument rating rather than the issuer rating if it is available. The currency denomination (local vs foreign currency) and the maturity (short-term vs long-term) should reflect the specific characteristics of the security. 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.
5.3.12.2 Bonds
The price in the case of bonds should be reported as a percentage, but not as a decimal fraction of 1.
Table 67 illustrates the population of fields in case of the SFT involving investment-grade
government securities and classified as debt instrument (bonds) with a nominal amount of 100,000,000 EUR. The securities, in this example, were issued by a German issuer (Field 2.53) identified by its LEI (Field 2.54). The price of a security is expressed in percentage as 99.5% (Field 2.49), its currency is euro (Field 2.50), and the securities maturity date is the 22 April 2030 (Field 2.50). The loan value of the SFT is 99,500,000 EUR (Field 2.56) and the borrower has not exclusive access to borrow from the lender’s securities portfolio (Field 2.68).
Table 67 - Bonds
No Field Example XML Message
40 Type of asset SECU <SctiesFincgRptgTxRpt> <TradData> <Rpt> <New> ... <CtrPtyData> ... </CtrPtyData> <LnData> <SctiesLndg> <AsstTp> <Scty> <Id>DE0010877643</Id>

<ClssfctnTp>DBFTFR</ClssfctnTp>
<QtyOrNmnlVal>
<NmnlVal>
<Amt Ccy="EUR">100000000</Amt>
</NmnlVal>
41 Security identifier {ISIN}
42 Classification of a security {CFI}
46 Quantity or nominal amount 100000000
48 Currency of nominal amount EUR
49 Security or commodity price 99.5
50 Price currency
51 Security quality INVG
52 Maturity of the security 2030-04-22
53 Jurisdiction of the issuer DE

ESMA REGULAR USE
101
Table 67 - Bonds
No Field Example XML Message
54 LEI of the issuer {LEI} of the issuer
</QtyOrNmnlVal>
<UnitPric>
<Ptrg>99.5</Ptrg>
</UnitPric>
<Qlty>INVG</Qlty>
<Mtrty>2030-04-22</Mtrty>
<Issr>
<Id>
<LEI>
NNNNNNNNNNNNNNNNNNNN </LEI>
</Id>

<ExclsvArrgmnt>false</ExclsvArrgmnt>
</Scty>
</AsstTp>
<LnVal Ccy="EUR">99500000</LnVal>
</SctiesLndg>
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>DBFTFR</
55 Security type GOVS
56 Loan value 99500000
68 Exclusive arrangements FALSE
5.3.12.3 Main index equities
Table 68 illustrates the population of fields in case of the SFT involving an equity that is
part of a main index, i.e. main index equities (Field 2.55) with a quantity of 100,000 (Field
2.46). Field 2.48 is not applicable since Field 2.46 is populated with a quantity and not with a nominal amount. Counterparties should report equities as MEQU where these are considered as such pursuant to Commission Implementing Regulation 2016/1646. The type of asset is again a security (Field 2.40) as equities (Field 2.42). The security quality is not applicable for this type of securities (Field 2.51). The securities, in this example, were issued by a French issuer (Field 2.53) identified by its LEI (Field 2.54).

ESMA REGULAR USE
102
The security price is expressed in units and is 9.95 EUR (Field 2.49 and Field 2.50). Since the underlying is an equity there is no securities maturity date, therefore, Field 2.52 should be populated with the ISO 8601 standard “9999-12-31”. The loan value of the SFT is 995,000 EUR (Field 2.56) and the borrower has not exclusive access to borrow from the lender’s securities portfolio (Field 2.68).
Table 68 – Main index equities
No Field Example XML Message
40 Type of asset SECU <SctiesFincgRptgTxRpt> <TradData> <Rpt> <New> ... <CtrPtyData> ... </CtrPtyData> <LnData> <SctiesLndg> <AsstTp> <Scty> <Id>FR0000120271</Id>

<ClssfctnTp>ESVUFN</ClssfctnTp>
<QtyOrNmnlVal>
<Qty>100000</Qty>
</QtyOrNmnlVal>
<UnitPric>
<MntryVal>
<Amt Ccy="EUR">9.95</Amt>
</MntryVal>
</UnitPric>
<Qlty>NOAP</Qlty>
<Mtrty>9999-12-31</Mtrty>
<Issr>
<Id>
<LEI>
529900S21EQ1BO4ESM68 </LEI>
</Id>

<ExclsvArrgmnt>false</ExclsvArrgmnt>
</Scty>
</AsstTp>
<LnVal Ccy="EUR">995000</LnVal>
41 Security identifier {ISIN}
42 Classification of a security {CFI}
46 Quantity or nominal amount 100000
49 Security or commodity price 9.95
50 Price currency EUR
51 Security quality NOAP
52 Maturity of the security 9999-12-31
53 Jurisdiction of the issuer FR
54 LEI of the issuer {LEI} of the issuer
55 Security type MEQU
56 Loan value 995000
68 Exclusive arrangements FALSE

ESMA REGULAR USE
103
Table 68 – Main index equities
No Field Example XML Message
</SctiesLndg>
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
5.3.12.4 Other securities without maturity
Table 69 illustrates the population of fields in case of the SFT involving securities that are
not in the list provided by Field 2.55 of Annex I of the ITS. In this case, Field 2.55 should be populated with “other assets”. The quantity of the securities is 100,000 (Field 2.46). Field 2.48 is not applicable since Field 2.46 is populated with a quantity and not with a nominal amount. The type of asset is again a security (Field 2.40) classified as ESVUFN (Field 2.42). The security quality is not applicable to this kind of securities (Field 2.51). The securities, in this example, were issued by a French issuer (Field 2.53) identified by its LEI (Field 2.54) The security price is expressed in units and is, in this example, 99.5 EUR (Field 2.49 and Field 2.50). The securities have no securities maturity date; therefore, Field 2.52 should be populated with the ISO 8601 standard “9999-12-31”. The loan value of the SFT is 9,950,000 EUR (Field 2.56), and the borrower has not exclusive access to borrow from the lender’s securities portfolio (Field 2.68).
Table 69 – Other securities without maturity
No Field Example XML Message
40 Type of asset SECU <SctiesFincgRptgTxRpt> <TradData> <Rpt> <New> ... <CtrPtyData> ... </CtrPtyData> <LnData> <SctiesLndg> <AsstTp> <Scty> <Id>FR0010877000</Id> 41 Security identifier {ISIN} 42 Classification of a security {CFI} 46 Quantity or nominal amount 100000 49 Security or commodity price 99.5 50 Price currency EUR 51 Security quality NOAP

ESMA REGULAR USE
104
Table 69 – Other securities without maturity
No Field Example XML Message
52 Maturity of the security 9999-12-31 <ClssfctnTp> ESVUFN </ClssfctnTp> <QtyOrNmnlVal> <Qty>100000</Qty> </QtyOrNmnlVal> <UnitPric> <MntryVal> <Amt Ccy="EUR">99.5</Amt> </MntryVal> </UnitPric> <Qlty>NOAP</Qlty> <Mtrty>9999-12-31</Mtrty> <Issr> <Id>

<LEI>GGGGGGGGGGGGGGGGGGGG
</LEI>
</Id>

<ExclsvArrgmnt>false</ExclsvArrgmnt>
</Scty>
</AsstTp>
<LnVal Ccy="EUR">9950000</LnVal>
</SctiesLndg>
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
53 Jurisdiction of the issuer FR
54 LEI of the issuer {LEI} of the issuer
55 Security type OTHR
56 Loan value 9950000
68 Exclusive arrangements FALSE
SFTs involving commodities – commodities lending
Table 70 illustrates the population of fields in case of the SFT involving commodities (Field
2.40) with energy as base product (Field 2.43), oil as sub-product (Field 2.44), and Brent oil as further sub-product (Field 2.45).

ESMA REGULAR USE
105
In the example, the quantity of 100,000 (Field 2.46) is measured in Barrels (Field 47) with a price per BARL of 60 USD (Field 49, and Field 50). The loan value is 6,000,000 (Field 56).
Table 70 - SFTs involving commodities
No Field Example XML Message
40 Type of asset COMM <SctiesFincgRptgTxRpt> <TradData> <Rpt> <New> ... <CtrPtyData> ... </CtrPtyData> <LnData> <SctiesLndg> <AsstTp> <Cmmdty> <Clssfctn> <Nrgy> <Oil> <BasePdct>NRGY</Base Pdct> <SubPdct>OILP</SubPdc t> <AddtlSubPdct>BRNT</A ddtlSubPdct> </Oil> </Nrgy> </Clssfctn> <Qty> <Val>100000</Val> <UnitOfMeasr>BARL</UnitO fMeasr> </Qty> <UnitPric> <MntryVal> <Amt Ccy="USD">60</Amt> </MntryVal> </UnitPric> </Cmmdty> </AsstTp> <LnVal Ccy="USD">6000000</LnVal> </SctiesLndg> 43 Base product NRGY 44 Sub - product OIL 45 Further sub - product BRNT 46 Quantity or nominal amount 100000 47 Unit of measure BARL 49 Securities or commodities price 60 50 Price currency USD 56 Loan value 6000000

ESMA REGULAR USE
106
Table 70 - SFTs involving commodities
No Field Example XML Message
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
Cash rebate SLB
Table 71 illustrates the population of fields in case the counterparties agree on a floating
rebate rate based on EONIA index (Field 2.59) with a floating rebate rate reference time period of days (Field 2.60) with an integer multiplier of the time period of 1 day (Field 2.61). The counterparties also agreed on a one-week basis frequency for the floating rebate rate payment (Field 2.62) and (Field 2.63). Please note that both fields are optional to facilitate transactions that do not define a floating rebate rate payment frequency. The floating rate will reset with a time period of days (Field 2.64) with a multiplier of 1 day (Field 2.65) The number of basis points to be added (or subtracted in case of negative value which is allowed for this field) as spread to the floating interest rate in order to determine the interest rate of the loan are is “5” (Field 2.66).
Table 71 - Cash rebate SLB
No Field Example XML Message
58 Fixed rebate rate <SctiesFincgRptgTxRpt> <TradData> <New> … <CtrPtyData> ... </CtrPtyData> <LnData> ... <TxLnData> <SctiesLndg> ... <RbtRate> 59 Floating rebate rate EONA 60 Floating rebate rate reference period - time period DAYS 61 Floating rebate rate reference period - multiplier 1 62 Floating rebate rate payment frequency - time period WEEK

ESMA REGULAR USE
107
Table 71 - Cash rebate SLB
No Field Example XML Message
63
Floating rebate rate payment frequency - multiplier 1 <Fltg> <RefRate> <Indx>EONA</Indx> </RefRate> <Term> <Unit>DAYS</Unit> <Val>1</Val> </Term> <PmtFrqcy> <Unit>WEEK</Unit> <Val>1</Val> </PmtFrqcy> <RstFrqcy> <Unit>DAYS</Unit> <Val>1</Val> </RstFrqcy> <BsisPtSprd>5</BsisPtSprd> </Fltg> </RbtRate> </SctiesLndg> </TxLnData> </LnData> <CollData> ... </CollData> ... </New> </TradData> ... </SctiesFincgRptgTxRpt> 64 Floating rebate rate reset frequency - time period DAYS 65 Floating rebate rate reset frequency - multiplier 1 66 Spread of the rebate rate 5 Fee-based SLB: Non-cash collateral SLB, Cash pool SLB and Uncollateralised SLB Fee-based SLB covers three types of SLBs: Non-cash collateral SLB, Cash pool SLB and Uncollateralised SLB. All three types have the same reporting logic.
Table 72 contains the value that is to be reported by counterparties in the Field 67 “Lending
fee” when they conclude non-cash collateral, cash pool or uncollateralised SLB (nonrebate SLB). The lending fee, in this case, is 1.23456% and is populated without percentage sign which is reserved for xml tags.
Table 72 - Non-cash collateral
No Field Example XML Message
67 Lending fee 1.23456
<SctiesFincgRptgTxRpt>
<TradData>
<Rpt>

ESMA REGULAR USE
108
Table 72 - Non-cash collateral
No Field Example XML Message
<New>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
<SctiesLndg>
<LndgFee>1.23456</LndgFee>
</SctiesLndg>
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
Margin loan amount and short market value
The overall outstanding margin loan amount (Field 2.69) should either be reported as 0 (when the client has an overall cash credit/is long cash) or as a positive value (when the client has an overall cash debit/is short cash in base currency). The base currency should always be reported, as defined in the bilateral agreement between a prime broker and its client. The overall margin loan value is calculated on the basis of individual margin loan constituents by currency (Fields 2.33 and 2.34). These fields should be repeated as many times as necessary to include all currencies used in the account. This will allow authorities to monitor client cash debit (i.e. margin loans) in individual currencies, as opposed to only a net debit in base currency, as well as cash credit in individual currencies used as collateral. In line with the overall margin lending amount, a net client debit in a given currency should be reported as a positive value together with the currency, while a net client credit should be reported as a negative value. Short market value should always be populated with a value denominated in the margin loan base currency, as defined in the bilateral agreement (Field 2.70). One single monetary amount per UTI is expected, therefore, short market value should be reported on a net basis, at the end of the day. With regards to outstanding margin loan, any net cash credit used to collateralise the short market value should be reported as a negative value (Field 2.33) together with its currency (Field 2.34). When the margin loan amount is 0, i.e. when the client has a net cash credit in base currency, and the short market value is also 0, Fields 2.33, 2.69 and 2.71 should all be populated with 0. A “zero” collateral update should also be reported..

ESMA REGULAR USE
109
5.3.16.1 Positive and negative balances in some currencies and net debit in base currency
Table 73 illustrates the population of reporting fields in the case of a net debit in base
currency, reflecting in this particular example a credit in USD and debits in GBP and EUR. For simplicity, the USD-EUR and GBP-EUR exchange rates in this example are set equal to 1.
Table 73 - Positive and negative balances in some currencies and debit in base
currency
No Field Example XML Message
33 Margin lending currency amount -100000 <SctiesFincgRptgTxRpt> <TradData> <Rpt> <New> ... <CtrPtyData> ... </CtrPtyData> <LnData> <MrgnLndg> <OutsdngMrgnLnAmt Ccy="EUR">150000</OutsdngMrgnLnAmt> <ShrtMktValAmt Ccy="EUR">0</ShrtMktValAmt> <MrgnLnAttr> <Amt> <Amt Ccy="USD">- 100000</Amt> <Amt Ccy="GBP">50000</Amt> <Amt Ccy="EUR">100000</Amt> </Amt> </MrgnLnAttr> </MrgnLndg> </LnData> <CollData> ... </CollData> ... </New> </Rpt> </TradData> </SctiesFincgRptgTxRpt> 34 Margin lending currency USD 33 Margin lending currency amount 50000 34 Margin lending currency GBP 33 Margin lending currency amount 150000 34 Margin lending currency EUR 69 Outstanding margin loan 100000 70 Base currency of outstanding margin loan EUR 71 Short market value 0
5.3.16.2 Net credit in base currency and short market value
Table 74 illustrates the population of reporting fields in case of net cash credit in base
currency (GBP), therefore, the outstanding margin loan is reported as 0, with cash credit

ESMA REGULAR USE
110 in non-base currency (USD) used as collateral by the client to cover part of the short market value.
Table 74 - Credit in base currency and positive short market value
No Field Example XML Message
33 Margin lending currency amount -100000 <SctiesFincgRptgTxRpt> <TradData> <Rpt> <New> ... <CtrPtyData> ... </CtrPtyData> <LnData> <MrgnLndg> <OutsdngMrgnLnAmt Ccy="GBP">0</OutsdngMrgnLnAmt> <ShrtMktValAmt Ccy="GBP">500000</ShrtMktValAmt> <MrgnLnAttr> <Amt> <Amt Ccy="USD">- 100000</Amt> </Amt> </MrgnLnAttr> </MrgnLndg> </LnData> <CollData> ... </CollData> ... </New> </Rpt> </TradData> </SctiesFincgRptgTxRpt> 34 Margin lending currency USD 69 Outstanding margin loan 0 70 Base currency of outstanding margin loan GBP 71 Short market value 500000
5.3.16.3 Net credit in base currency and no short market value
Table 75 illustrates the population of reporting fields in case of cash credit in base currency
(EUR) and no short market value. Since there is no margin loan outstanding or short market value, the cash credit is not reportable (since it is not used as collateral in a margin loan or short market value). A report is required nonetheless to notify authorities of the zero balance. The base currency, as originally agreed in the original contract, should be populated.
Table 75 - Credit in base currency and no short market value
No Field Example XML Message
33 Margin lending currency amount 0
<SctiesFincgRptgTxRpt>
<TradData>

ESMA REGULAR USE
111
Table 75 - Credit in base currency and no short market value
No Field Example XML Message
34 Margin lending currency
USD <Rpt>
<New>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
<MrgnLndg>
<OutsdngMrgnLnAmt Ccy="EUR">0</OutsdngMrgnLnAmt>
<ShrtMktValAmt Ccy="EUR">0</ShrtMktValAmt>
<MrgnLnAttr>
<Amt>
<Amt Ccy="USD">0</Amt>
</Amt>
</MrgnLnAttr>
</MrgnLndg>
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
69 Outstanding margin loan 0
70
Base currency of outstanding margin loan
EUR
71 Short market value 0
5.4 Collateral data
The sub-sequent sections emphasise the population of a given set of fields that share specific characteristics of the collateral of an SFT. This would allow the reporting counterparties to directly assess the information that they should report for each specific data section when it is applicable. The validation rules contain the complete guidance on applicable fields per SFT type and action type, as well as the relevant dependencies. Reporting of collateralisation of an SLB Depending on whether the SLB is collateralised or uncollateralised, the counterparties should report this information in Field 2.72 “Uncollateralised Securities Lending ('SL') flag”.

ESMA REGULAR USE
112
5.4.1.1 Uncollateralised SLB
Counterparties should report “true” in Field 2.72 “Uncollateralised Securities Lending ('SL') flag” when there is an uncollateralised lending of securities but still organised as an SLB transaction.
5.4.1.2 Collateralised SLB
Counterparties should report “false” in “Uncollateralised Securities Lending ('SL') flag” (Field 2.72) when the SLB transaction is collateralised or when the counterparties agree to collateralise the trade, but the specific allocation of collateral is not yet known. Collateralisation When the collateral basket is not known at the time of reporting, Field 2.96 should be populated with “NTAV”. The same is applicable to repos taking place on GC platforms. In that case, the counterparties should update the information on identification of collateral basket as soon as they know it and then update the information on the collateral components no later than the working day following the value date. When collateralisation does not take place against a collateral basket, ESMA expects that the counterparties should report the relevant collateral elements.
5.4.2.1 Single transaction with collateral basket
Table 76 illustrates the population of fields in case two separate SFTs are traded against
a collateral basket (Field 2.96) identified by the ISIN “GB00BH4HKS39”. There might be several SFTs traded against a collateral basket, without then having collateralisation on a net exposure basis. The SFTs are collateralised at transaction level (Field 2.73 populated with “FALSE”).
Table 76 - Single transaction with collateral basket
No Field Example XML Message
1.3 Reporting
counterparty
LEI of counterparty
A
<SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<New>
<CtrPtyData>
<CtrPtyData>
<RptgCtrPty>
<Id>

<LEI>12345678901234500000</LEI>
</Id>
<Sd>GIVE</Sd>
</RptgCtrPty>
<OthrCtrPty>
<Id>
1.11 Other counterparty
LEI of counterparty
B
1.9 Counterparty side GIVE
1.18 Agent lender
{LEI} of agent lender
F
1
Unique Transaction
Identifier ('UTI') UTI1
3 Event date 24/04/2020

ESMA REGULAR USE
113
Table 76 - Single transaction with collateral basket
No Field Example XML Message
9 Master agreement GMRA
<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
</OthrCtrPty>
<OthrPtyData>
<AgtLndr>

<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
</AgtLndr>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
<RpTrad>

<NetXpsrCollstnInd>false</NetXpsrCollstnI nd> <BsktIdr> <Id>GB00BH4HKS39</Id> </BsktIdr> </RpTrad> </CollData> ... </New> </Rpt> <Rpt> <New> <CtrPtyData> <CtrPtyData> <RptgCtrPty> <Id>

<LEI>12345678901234500000</LEI>
</Id>
<Sd>GIVE</Sd>
</RptgCtrPty>
<OthrCtrPty>
<Id>
73 Collateralisation of net exposure FALSE
96 Collateral basket identifier {ISIN}
98 Action type NEWT
1.3 Reporting
counterparty
LEI of counterparty
A
1.11 Other counterparty
LEI of counterparty
B
1.9 Counterparty side GIVE
1.18 Agent lender
{LEI} of agent lender
F
1
Unique Transaction
Identifier ('UTI') UTI2
3 Event date 24/04/2020
9 Master agreement GMRA
73 Collateralisation of net exposure FALSE
96 Collateral basket identifier {ISIN}
98 Action type NEWT

ESMA REGULAR USE
114
Table 76 - Single transaction with collateral basket
No Field Example XML Message

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
</OthrCtrPty>
<OthrPtyData>
<AgtLndr>

<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
</AgtLndr>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
<RpTrad>

<NetXpsrCollstnInd>false</NetXpsrCollstnI nd> <BsktIdr> <Id>GB00BH4HKS39</Id> </BsktIdr> </RpTrad> </CollData> ... </New> </Rpt> </TradData> </SctiesFincgRptgTxRpt>
5.4.2.2 Single transaction with basket identification not known at the time of reporting
Table 77 illustrates the population of fields in case of a single transaction that is
collateralised by a collateral basket but where the identification of the basket is not available at time of reporting (Field 2.96 populated with “NTAV”). The SFT is collateralised at single transaction level (Field 2.73). The SFT is collateralised at transaction basis (Field 2.73 populated with “FALSE”).

ESMA REGULAR USE
115
Table 77 - Single transaction without basket at time of reporting
No Field Example XML Message
1.3 Reporting
counterparty
LEI of counterparty
A
<SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<New>
<CtrPtyData>
<CtrPtyData>
<RptgCtrPty>
<Id>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
</OthrCtrPty>
<OthrPtyData>
<AgtLndr>

<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
</AgtLndr>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
<RpTrad>

<NetXpsrCollstnInd>false</NetXpsrCollstnI nd> <BsktIdr> <Id>NTAV</Id> </BsktIdr> </RpTrad> </CollData> ...
1.11 Other counterparty
LEI of counterparty
B
1.9 Counterparty side GIVE
1.18 Agent lender
{LEI} of agent lender
F
1
Unique Transaction
Identifier ('UTI') UTI1
3 Event date 24/04/2020
9 Master agreement GMRA
73 Collateralisation of net exposure FALSE
96 Collateral basket identifier NTAV
98 Action type NEWT

ESMA REGULAR USE
116
Table 77 - Single transaction without basket at time of reporting
No Field Example XML Message
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
5.4.2.3 Collateralisation on a net exposure basis with basket
Table 78 illustrates the population of fields in the case of two transactions collateralised
by a collateral basket (Field 2.96) on a net exposure basis (Field 2.73 populated with “TRUE”) and identified by the ISIN “GB00BH4HKS39”. This example does not mean that all GC deals are on a net exposure basis. Counterparties should report the SFTs as they are concluded. It is worth mentioning that when SFTs are collateralised on a net exposure basis with a basket, the COLU messages should include the individual collateral components. The reporting of the basket ISIN is only until the allocation of securities is defined. The collateral components should be reported as they stand at the end of the day.
Table 78 - Net exposure basis with basket
No Field Example XML Message
1.3 Reporting
counterparty
LEI of counterparty
A
<SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<New>
<CtrPtyData>
<CtrPtyData>
<RptgCtrPty>
<Id>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
</OthrCtrPty>
<OthrPtyData>
<AgtLndr>

<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
</AgtLndr>
</OthrPtyData>
</CtrPtyData>
1.11 Other counterparty
LEI of counterparty
B
1.9 Counterparty side GIVE
1.18 Agent lender {LEI} of
agent lender
1
Unique Transaction
Identifier ('UTI') UTI1
3 Event date 24/04/2020
9 Master agreement GMRA
73 Collateralisation of net exposure TRUE
96 Collateral basket identifier {ISIN}
98 Action type NEWT
1.3 Reporting
counterparty
LEI of counterparty
A

ESMA REGULAR USE
117
Table 78 - Net exposure basis with basket
No Field Example XML Message
1.11 Other counterparty
LEI of counterparty
B
</CtrPtyData>
<LnData>
<RpTrad>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
</OthrCtrPty>
<OthrPtyData>
<AgtLndr>

<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
</AgtLndr>
</OthrPtyData>
</CtrPtyData>
1.9 Counterparty side GIVE
1.18 Agent lender {LEI} of
agent lender
1
Unique Transaction
Identifier ('UTI') UTI2
3 Event date 24/04/2020
9 Master agreement GMRA
73 Collateralisation of net exposure TRUE
96 Collateral basket identifier {ISIN}
98 Action type NEWT

ESMA REGULAR USE
118
Table 78 - Net exposure basis with basket
No Field Example XML Message
</CtrPtyData>
<LnData>
<RpTrad>

<NetXpsrCollstnInd>true</NetXpsrCollstnIn d> <BsktIdr> <Id>GB00BH4HKS39</Id> </BsktIdr> </RpTrad> </CollData> ... </New> </Rpt> </TradData> </SctiesFincgRptgTxRpt>
5.4.2.4 Collateralisation on a net exposure basis with basket identification not known at
the time of reporting
Table 79 illustrates the population of fields when a transaction is collateralised on a net
exposure basis (Field 2.73 populated with “TRUE”) by a collateral basket whose identifier is either not an ISIN or the ISIN is not known yet (Field 2.96 populated with “NTAV”). The collateralisation of the transaction is on a net exposure basis (Field 2.73).
Table 79 - Net exposure basis without basket at time of reporting
No Field Example XML Message
73 Collateralisation of net exposure true <SctiesFincgRptgTxRpt> <TradData> <Rpt> <New> ... <CtrPtyData> ... </CtrPtyData> 96 Collateral basket identifier NTAV 98 Action type NEWT

ESMA REGULAR USE
119
Table 79 - Net exposure basis without basket at time of reporting
No Field Example XML Message
<LnData>
...
</LnData>
<CollData>
<RpTrad>

<NetXpsrCollstnInd>true</NetXpsrCollstnIn d> <BsktIdr> <Id>NTAV</Id> </BsktIdr> </RpTrad> </CollData> ... </New> </Rpt> </TradData> </SctiesFincgRptgTxRpt> Cash collateral
Table 80 illustrates the reporting of fields in case of cash rebate and cash pool SLB
transaction. In the example, it is collateralised by cash collateral of 1,000,000 EUR (Field
2.76 and Field 2.77). The reporting scenario for this case is the same for the action type
“NEWT” and “COLU”.
Table 80 - Cash collateral
No Field Example XML Message
76 Cash collateral amount 1000000 <SctiesFincgRptgTxRpt> <TradData> <Rpt> <New> ... <CtrPtyData> ... </CtrPtyData> <LnData> ... </LnData> <CollData> <RpTrad> <AsstTp> <Csh> <Amt Ccy="EUR">1000000</Amt> </Csh> </AsstTp> 77 Cash collateral currency EUR

ESMA REGULAR USE
120
Table 80 - Cash collateral
No Field Example XML Message
</RpTrad>
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
Reporting of zero collateral
In order to simplify the reporting when the collateral is equal to 0, except for margin loans, the collateral should always be reported as cash collateral, with the cash collateral amount being equal to 0 and the type of collateral component being “CASH” regardless on whether the type of collateral previously used for that SFT was securities, commodities or cash.
Table 81 illustrates the reporting of fields in case the collateral is equal to 0 and the type
of collateral component is either securities, commodities (only for repos and BSB/SBBs), or cash.
Table 81 – Reporting of zero collateral for securities, commodities and cash
No Field Example XML Message
75 Type of collateral component CASH <SctiesFincgRptgTxRpt> <TradData> <Rpt> <CollUpd> ... <CtrPtyData> ... </CtrPtyData> <LnData> ... </LnData> <CollData> <RpTrad> <AsstTp> <Csh> <Amt Ccy="EUR">0</Amt> </Csh> </AsstTp> </RpTrad> </CollData> ... </CollUpd> </Rpt> </TradData> </SctiesFincgRptgTxRpt> 76 Cash collateral amount 0 77 Cash collateral currency EUR

ESMA REGULAR USE
121
Security collateral fields
Regarding securities for which details are not available, reporting is mandatory by value date +1 day. For issues related to settlement, please refer to Section 5.4.8 of the Guidelines. In the case of collateral baskets, whereby the details are reported only once the collateral allocation has taken place, please refer to Section 5.4.2 of the Guidelines.
5.4.5.1 Haircut
Counterparties should report collateral data in line with Table 2 of the Annex to the RTS on Reporting. Collateral market value (Field 2.88) 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. Haircut or margin (Field 2.89) should be reported at ISIN level as a %, for all SFT types. For repos, the haircut is contractually agreed and should be fixed for the duration of the SFT, unless the counterparties renegotiate haircut. The haircut is calculated as 1 minus the ratio between cash and collateral value, multiplied by 100. For example, a repo with 100 in cash and 105 in collateral yields a haircut of 100*[1-(100/105)]=4.7619 and should be reported as “4.7619”. In the case of a portfolio-level repo haircut (i.e. where upon agreement between the counterparties a single haircut is applied to the entire repo collateral portfolio), the same principles apply. As specified in the RTS on reporting, portfolio-level haircuts should also be reported at ISIN-level, i.e. it should be repeated for each ISIN in the portfolio (and for cash if it is part of the portfolio):
For SLB, the “Haircut or margin” (Field 2.89) should only include haircuts that apply to the collateral side. Margin requirements will instead be captured through the collateral market value (Field 2.88) and the cash collateral amount (Field 2.76). Thus, the collateral market value and cash collateral amount should also be updated with any add-ons (such as loan mark-ups) that start applying in the course of the transaction.
Table 82 shows collateral data from an SLB where securities worth 100.000 EUR are
borrowed against 100.000 EUR in cash collateral (Field 2.76 and Field 2.77), i.e. no haircut, meaning that the haircut should be reported as 0 (Field 2.89).
Table 82 – Cash collateral with no haircut
No Field Example XML Message
76 Cash collateral amount 100000 <SctiesFincgRptgTxRpt> <TradData> <Rpt> <New> ... <CtrPtyData> ... </CtrPtyData> 77 Cash collateral currency EUR 89 Haircut or margin 0

ESMA REGULAR USE
122
Table 82 – Cash collateral with no haircut
No Field Example XML Message
<LnData>
...
</LnData>
<CollData>
<RpTrad>
<AsstTp>
<Csh>
<Amt Ccy="EUR">100000</Amt>

<HrcutOrMrgn>0</HrcutOrMrgn>
</Csh>
</AsstTp>
</RpTrad>
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
Table 83 shows a security on loan worth 100,000 EUR collateralised with 105,000 USD in
cash (Field 2.76 and Field 2.77), reflecting a margin of 105% on the loan side.
Table 83 – Cash collateral in foreign currency with margin
No Field Example XML Message
76 Cash collateral amount 105000 <SctiesFincgRptgTxRpt> <TradData> <Rpt> <New> ... <CtrPtyData> ... </CtrPtyData> <LnData> ... </LnData> <CollData> <RpTrad> <AsstTp> <Csh> <Amt Ccy="USD">105000</Amt>

<HrcutOrMrgn>0</HrcutOrMrgn>
</Csh>
</AsstTp>
</RpTrad>
77 Cash collateral currency
USD
89 Haircut or margin 0

ESMA REGULAR USE
123
Table 83 – Cash collateral in foreign currency with margin
No Field Example XML Message
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
In the “Mixed” collateral example (Table 84), securities on loan worth 100,000 EUR are collateralised with 55,000 EUR in cash collateral (Field 2.76) and 60,000 EUR in non-cash collateral (Field 2.88). This includes a margin requirement (unspecified) on the loan side, which applies to both cash and non-cash collateral, on top of which comes a 5% haircut on the value of the securities used as collateral. Field 2.89 is populated with “0” for the cash collateral, and “5” for the securities used as collateral.
Table 84 – “Mixed” collateral with haircut and margin
No Field Example XML Message
76 Cash collateral amount 55000 <SctiesFincgRptgTxRpt> <TradData> <Rpt> <New> ... <CtrPtyData> ... </CtrPtyData> <LnData> ... </LnData> <CollData> <RpTrad> <AsstTp> <Scty> <MktVal Ccy="EUR">60000</MktVal>

<HrcutOrMrgn>0</HrcutOrMrgn>
</Csh>
</AsstTp>
</RpTrad>
</CollData>
...
</New>
</Rpt>
77 Cash collateral currency
EUR
89 Haircut or margin 0
88 Collateral market value 60000
89 Haircut or margin 5

ESMA REGULAR USE
124
Table 84 – “Mixed” collateral with haircut and margin
No Field Example XML Message
</TradData>
</SctiesFincgRptgTxRpt>
Negative haircuts can be reported to the extent that the value of the collateral is smaller than the loan value. The sign of the haircut should not vary with the counterparty side.
Table 85 shows a repo in which a transaction is collateralised with a basket of securities
(this time without cash) and a portfolio-level haircut applies to all the collateral securities. The same haircut should be reported for each collateral component in the portfolio (including cash if it is part of the portfolio). A loan worth 150,000 EUR is collateralised with two securities, 110,000 EUR in security A and 50,000 in security B. The total collateral market value posted is 160,000 EUR, which corresponds to a portfolio-level haircut of 100*[1-(150/160)]=6.25%. This is the value that should be reported in Field 2.89 for each ISIN. Similarly, for collateralisation on a net exposure basis (Field 2.73), the same haircut should be reported for each individual security.
Table 85 – Collateral portfolio with portfolio-level haircut
No Field Example XML Message
88 Collateral market value 110000 <SctiesFincgRptgTxRpt> <TradData> <Rpt> <New> ... <CtrPtyData> ... </CtrPtyData> <LnData> ... </LnData> <CollData> <RpTrad> <AsstTp> <Scty> <MktVal Ccy="EUR">110000</MktVal>

<HrcutOrMrgn>6.25</HrcutOrMrgn>
</Scty>
</AsstTp>
</RpTrad>
</CollData>
89 Haircut or margin 6.25
88 Collateral market value 50000
89 Haircut or margin 6.25

ESMA REGULAR USE
125
Table 85 – Collateral portfolio with portfolio-level haircut
No Field Example XML Message
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
For margin lending, where a haircut or margin requirement applies to the entire collateral portfolio, the value reported in Field 2.89 should be repeated across all ISINs and cash elements. If this is not the case and haircuts apply instead on a security-by-security basis, ISIN-specific haircuts or margins should be reported (in the same format as for other SFTs, i.e. in %).
5.4.5.2 Collateral Type
Collateral type (Field 2.94) should be reported by counterparties with one of the following values:
a. ‘GOVS' - Government securities; b. 'SUNS' - Supra-nationals and agencies securities;
c. 'FIDE' - Debt securities (including covered bonds) issued by banks and other financial
institutions; d. 'NFID' - Corporate debt securities (including covered bonds) issued by non-financial institutions; e. 'SEPR' - Securitized products (including ABS, CDO, CMBS, RMBS, ABCP); f. 'MEQU' - Main index equities (including convertible bonds); g. 'OEQU' - Other equities (including convertible bonds); h. 'OTHR'- Other assets (including shares in mutual funds). For other securities, counterparties may rely on other official sources in order to minimise the risk of inconsistencies and reconciliation issues. For the definition of government securities, reporting entities should use as reference footnote 19 of FSB standards on SFT data collection and rely on Basel III standardised approach. If one of the counterparties is not concerned by the Basel III requirements, then the counterparties should agree on the value to be reported for this field. The distinction between “Main index equities” and “Other equities” is in line with the FSB standards. However, it is left to FSB members to decide which indices should qualify as “Main”, provided that these are defined in accordance with the implementation of the FSB/BCBS framework on haircuts in non-centrally cleared SFTs.

ESMA REGULAR USE
126
The ESMA ITS on main indices and recognised exchanges under the Capital Requirements Regulation (CRR)15 include a list of main indices (Annex I, Tables 1 and 2). The list includes equity and convertible bonds indices covering assets inside and outside the EU. This list should be used as the reference to classify equities and convertible bonds as “Main index” or “Other”.
5.4.5.3 Availability for collateral reuse
Counterparties should populate the field only taking into account contractual ability to reuse collateral. When “Method used to provide collateral” (Field 2.20) is reported as “TTCA” or “SIUR”, “Availability for collateral reuse” (Field 2.95) should always be populated with “TRUE”. Operational constraints or regulatory requirements that may prevent reuse from taking place should not be considered here. The contractual ability to reuse should be determined by the Master Agreement, which defines the type of collateral arrangement used in the SFT. For example, a CCP that passes on the SFT collateral from one CM to the other under “TTCA” should report that the collateral is available for reuse, even if it is prevented from doing so under the CCP’s clearing conditions. The same goes for UCITS: non-cash collateral received that is available for reuse should be reported as such, even though it cannot be reused under the ESMA Guidelines on ETFs and other UCITS issues. Finally, note that “Availability for collateral reuse” does not consider whether the collateral has been or will be reused. Only when collateral is reused -- which includes the use of borrowed securities under SLB arrangements -- a reuse report should be sent in addition (see Section 5.6.1).
5.4.5.4 Plain vanilla Bonds
Table 86 illustrates the reporting of plain-vanilla bonds used as collateral the 24 April 2020.
In this case, 102,000,000 EUR in German government debt securities identified by ISIN “DE0010877643” and classified as “DBFTFR” with a 2% haircut and maturity date on 22 April 2030 were used as a collateral in a repo transaction. The securities are known and reported by the reporting timeline together with the rest of the information on the loan side. The quality of the securities is investment grade – “INVG” and the collateral is available for subsequent reuse. The table focuses only on the fields relevant for collateral reporting. Currency of the collateral nominal amount or quantity is optional but should be reported when a nominal amount is reported. In cases where a quantity is reported (e.g. equity), this field should not be populated. Regarding the value date of the collateral, this field is only applicable to SLB in the context of prepaid collateral. The definition of Price per unit (Field 2.87) specifies that the value reported should include the accrued interest for interest-bearing securities, i.e. the dirty price. 15 Commission implementing regulation (EU) 2016/1646 of 13 September 2016.

ESMA REGULAR USE
127
Table 86 - Plain vanilla Bonds
No Field Example XML Message
3 Event date 2020-04-24 <SctiesFincgRptgTxRpt> <TradData> <Rpt> <New> ... <CtrPtyData> ... </CtrPtyData> <LnData> <RpTrad> <EvtDt>2020-04-24</EvtDt> </RpTrad> </LnData> <CollData> <RpTrad> <AsstTp> <Scty> <Id>DE0010877643</Id>

<ClssfctnTp>DBFTFR</ClssfctnTp>
<NmnlVal>
<Amt Ccy="EUR">100000000</Amt>
</NmnlVal>
</QtyOrNmnlVal>
<UnitPric>
<Ptrg>102</Ptrg>
</UnitPric>
<MktVal Ccy="EUR">102000000</MktVal>

<LEI>NNNNNNNNNNNNNNNNNNNN
</LEI>
</Id>

<AvlblForCollReuse>true</AvlblForCollReu se> </Scty> 75 Type of the collateral component SECU 78 Identification of a security used as collateral {ISIN} 79 Classification of a security used as collateral {CFI} 83 Collateral quantity or nominal amount 100000000 85 Currency of collateral nominal amount EUR 86 Price currency 87 Price per unit 102 88 Collateral market value 102000000 89 Haircut or margin 2 90 Collateral quality INVG 91 Maturity date of the security 2030-04-22 92 Jurisdiction of the issuer DE 93 LEI of the issuer {LEI} of the issuer 94 Collateral type GOVS 95 Availability for collateral reuse true 98 Action type NEWT

ESMA REGULAR USE
128
Table 86 - Plain vanilla Bonds
No Field Example XML Message
</AsstTp>
</RpTrad>
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
5.4.5.5 Perpetual bonds
Table 87 illustrates the reporting of 102,000,000 EUR of Spanish government perpetual
bonds used as collateral. A haircut of 2% is applied. The securities are known and reported by the reporting timeline together with the rest of the information on the loan side. The quality of the securities is investment grade – “INVG” and the collateral is available for reuse. The table focuses only on the fields relevant for collateral reporting. Currency of the collateral nominal amount or quantity is optional but should be reported when a nominal amount is reported. In cases where a quantity is reported (e.g. equity), this field should not be populated. Regarding the value date of the collateral, this field is only applicable to SLB in the context of prepaid collateral. The definition of Price per unit (Field 2.87) specifies that the value reported should include the accrued interest for interest-bearing securities, i.e. the dirty price.
Table 87 - Perpetual bonds
No Field Example XML Message
3 Event date 2020-04-24 <SctiesFincgRptgTxRpt> <TradData> <Rpt> <New> ... <CtrPtyData> ... </CtrPtyData> <LnData> <RpTrad> <EvtDt>2020-04-24</EvtDt> </RpTrad> </LnData> <CollData> <RpTrad> <AsstTp> <Scty> <Id>ES0010877643</Id> 75 Type of the collateral component SECU 78 Identification of a security used as collateral {ISIN} 79 Classification of a security used as collateral {CFI} 83 Collateral quantity or nominal amount 100000000 85 Currency of collateral nominal amount EUR 86 Price currency 87 Price per unit 102

ESMA REGULAR USE
129
Table 87 - Perpetual bonds
No Field Example XML Message
88 Collateral market value 102000000
<ClssfctnTp>DBFTPR</ClssfctnTp>
<QtyOrNmnlVal>
<NmnlVal>
<Amt Ccy="EUR">100000000</Amt>
</NmnlVal>
</QtyOrNmnlVal>
<UnitPric>
<Ptrg>102</Ptrg>
</UnitPric>
<MktVal Ccy="EUR">102000000</MktVal>

<LEI>EEEEEEEEEEEEEEEEEEEE </LEI>
</Id>

<AvlblForCollReuse>true</AvlblForCollReu se> </Scty> </AsstTp> </RpTrad> </CollData> ... </New> </Rpt> </TradData> </SctiesFincgRptgTxRpt> 89 Haircut or margin 2 90 Collateral quality INVG 91 Maturity date of the security 9999-12-31 92 Jurisdiction of the issuer ES 93 LEI of the issuer {LEI} of the issuer 94 Collateral type GOVS 95 Availability for collateral reuse true 98 Action type NEWT
5.4.5.6 Main Index Equities
Table 88 illustrates the reporting of main index equities “MEQU” used as collateral, in this
case, 105,000,000 EUR in the French CAC40 equities Total, with CFI code ESVUFN with a 5% haircut. The securities are known and reported by the reporting timeline together with the rest of the information on the loan side. The field “Collateral quality” is populated

ESMA REGULAR USE
130 with “NOAP”, as the rating is not applicable for these securities. They are available for subsequent reuse. Currency of the collateral nominal amount or quantity is optional but should be reported when a nominal amount is reported. In cases where a quantity is reported (e.g. equity), this field should not be populated. Regarding the value date of the collateral, this field is only applicable to SLB in the context of prepaid collateral. The definition of Price per unit (Field 2.87) specifies that the value reported should include the accrued interest for interest-bearing securities, i.e. the dirty price.
Table 88 - Main Index Equities
No Field Example XML Message
3 Event date 2020-04-24 <SctiesFincgRptgTxRpt> <TradData> <Rpt> <New> ... <CtrPtyData> ... </CtrPtyData> <LnData> <RpTrad> <EvtDt>2020-04-24</EvtDt> </RpTrad> </LnData> <CollData> <RpTrad> <AsstTp> <Scty> <Id> FR0000120271</Id> <ClssfctnTp> ESVUFN </ClssfctnTp> <QtyOrNmnlVal> <Qty>100000000</Qty> </QtyOrNmnlVal> <UnitPric> <MntryVal> <Amt Ccy="EUR">10.5</Amt> </MntryVal> </UnitPric> <MktVal Ccy="EUR">105000000</MktVal>

<HrcutOrMrgn>5</HrcutOrMrgn>
<Qlty>NOAP</Qlty>
<Mtrty>9999-12-31</Mtrty>
<Issr>
<Id>
75 Type of the collateral component SECU
78
Identification of a security used as collateral {ISIN} 79 Classification of a security used as collateral {CFI} 83 Collateral quantity or nominal amount 10000000 86 Price currency EUR 87 Price per unit 10.5 88 Collateral market value 105000000 89 Haircut or margin 5 90 Collateral quality NOAP 91 Maturity date of the security 9999-12-31 92 Jurisdiction of the issuer FR 93 LEI of the issuer {LEI} of the issuer 94 Collateral type MEQU 95 Availability for collateral reuse true 98 Action type NEWT

ESMA REGULAR USE
131
Table 88 - Main Index Equities
No Field Example XML Message

<AvlblForCollReuse>true</AvlblForCollReu se> </Scty> </AsstTp> </RpTrad> </CollData> ... </Rpt> </TradData> </SctiesFincgRptgTxRpt> Variation margining at transaction level for non-centrally cleared SFTs The references in this subsection to SLB or repo are only meant to provide examples with different master agreements. However, other types of SFTs, such as BSB/SBB or SFTs involving commodities, should be reported based on the same principles. Furthermore, the examples in this subsection refer to variation margining at the level of individual SFTs. The examples in the following section will illustrate instead the reporting of variation margining with collateralisation on a net exposure basis. The negative signs for collateral components when part of variation margining on a net exposure basis indicate the state at the end of the day, not the flow for that given day. While numerically these can coincide, the difference is fundamental. Thus, counterparties should report the state of each collateral component accordingly at the end of the day. Further guidance is included in paragraph 373. For simplicity, in the examples below, haircut is reported as 0. The counterparties should report the haircut as calculated in accordance with section 5.4.5.1.
5.4.6.1 Variation margining of an SLB with additional provision of the same securities by
the collateral provider
Table 89 illustrates a variation margin update in the case of SLB to the plain-vanilla bond
example in Table 86: a 1,000,099 increase in the nominal amount of collateral provided to compensate for a decline in the price of the bond price from 102 to 100.99, as reported by the collateral provider. Collateral giver and collateral taker should both report in exactly the same way the information on collateral, as detailed in Table 89.

ESMA REGULAR USE
132
Table 89 - Variation margin update to SLB
No Field Example XML Message
1.3 Reporting
counterparty
LEI of counterparty
A
<SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<CollUpd>
...
<CtrPtyData>
<CtrPtyData>
<RptgCtrPty>
<Id>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
</OthrCtrPty>
<OthrPtyData>
<AgtLndr>

<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
</AgtLndr>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
<SctiesLndg>

<UnqTradIdr>UTI1</UnqTradIdr>
<EvtDt>2020-04-24</EvtDt>
<MstrAgrmt>
<Tp>
<Tp>GMSLA</Tp>
</Tp>
</MstrAgrmt>
</SctiesLndg>
</LnData>
<CollData>
<SctiesLndg>
<Collsd>
<AsstTp>
<Scty>
<Id>DE0010877643</Id>

<ClssfctnTp>DBFTFR</ClssfctnTp>
<QtyOrNmnlVal>
1.11 Other counterparty
LEI of counterparty
B
1.18 Agent lender
{LEI} of the agent lender
F
1
Unique Transaction
Identifier ('UTI') UTI1
3 Event date 24/04/2020
9 Master agreement GMSLA
73 Collateralisation of net exposure FALSE
75 Type of the collateral component SECU
78
Identification of a security used as collateral {ISIN} 79 Classification of a security used as collateral {CFI} 83 Collateral quantity or nominal amount 101000099 85 Currency of collateral nominal amount EUR 86 Price currency 87 Price per unit 100.99 88 Collateral market value 102000000 89 Haircut or margin 0 90 Collateral quality INVG 91 Maturity date of the security 22/04/2030 92 Jurisdiction of the issuer DE 93 LEI of the issuer {LEI} of the issuer 94 Collateral type GOVS

ESMA REGULAR USE
133
Table 89 - Variation margin update to SLB
No Field Example XML Message
95 Availability for collateral reuse TRUE <NmnlVal> <Amt Ccy="EUR">101000099</Amt> </NmnlVal> </QtyOrNmnlVal> <UnitPric> <Ptrg>100.99</Ptrg> </UnitPric> <MktVal Ccy="EUR">102000000</MktVal> <HrcutOrMrgn>0</HrcutOrMrgn> <Qlty>INVG</Qlty> <Mtrty>2030-04-22</Mtrty> <Issr> <Id>

<LEI>NNNNNNNNNNNNNNNNNNNN
</LEI>
</Id>

<NetXpsrCollstnInd>false</NetXpsrCollstnI nd> </Collsd> </SctiesLndg> </CollData> ... </CollUpd> </Rpt> </TradData> </SctiesFincgRptgTxRpt> 98 Action type COLU
5.4.6.2 Variation margining of a repo with additional provision of the same securities by
the collateral provider
Table 90 illustrates a variation margin update in the case of a repo to the plain-vanilla bond
example in Table 86: a 1,000,099 increase in the nominal amount of collateral provided to compensate for a decline in the price of the bond price from 102 to 100.99, as reported by

ESMA REGULAR USE
134 the collateral provider. Collateral giver and collateral taker should both report in exactly the same way the information on collateral, as detailed in Table 90.
Table 90 - Variation margin update to a repo
No Field Example XML Message
1.3 Reporting
counterparty
LEI of counterparty
A
<SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<CollUpd>
...
<CtrPtyData>
<CtrPtyData>
<RptgCtrPty>
<Id>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
</OthrCtrPty>
<OthrPtyData>
<AgtLndr>

<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
</AgtLndr>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
<RpTrad>
<EvtDt>2020-04-24</EvtDt>

<UnqTradIdr>UTI1</UnqTradIdr>
<MstrAgrmt>
<Tp>
<Tp>GMRA</Tp>
</Tp>
</MstrAgrmt>
</RpTrad>
</LnData>
<CollData>
<RpTrad>
<AsstTp>
<Scty>
<Id>DE0010877643</Id>
1.11 Other counterparty
LEI of counterparty
B
1.18 Agent lender
{LEI} of the agent lender
F
1
Unique Transaction
Identifier ('UTI') UTI1
3 Event date 24/04/2020
9 Master agreement GMRA
73 Collateralisation of net exposure FALSE
75 Type of the collateral component SECU
78
Identification of a security used as collateral {ISIN} 79 Classification of a security used as collateral {CFI} 83 Collateral quantity or nominal amount 101000099 85 Currency of collateral nominal amount EUR 86 Price currency 87 Price per unit 100.99 88 Collateral market value 102000000 89 Haircut or margin 0 90 Collateral quality INVG 91 Maturity date of the security 22/04/2030 92 Jurisdiction of the issuer DE

ESMA REGULAR USE
135
Table 90 - Variation margin update to a repo
No Field Example XML Message
93 LEI of the issuer {LEI} of the issuer

<ClssfctnTp>DBFTFR</ClssfctnTp>
<QtyOrNmnlVal>
<NmnlVal>
<Amt Ccy="EUR">101000099</Amt>
</NmnlVal>
</QtyOrNmnlVal>
<UnitPric>
<Ptrg>100.99</Ptrg>
</UnitPric>
<MktVal Ccy="EUR">102000000</MktVal>

<LEI>NNNNNNNNNNNNNNNNNNNN
</LEI>
</Id>

<NetXpsrCollstnInd>false</NetXpsrCollstnI nd> </RpTrad> </CollData> ... </CollUpd> </Rpt> </TradData> </SctiesFincgRptgTxRpt> 94 Collateral type GOVS 95 Availability for collateral reuse TRUE 98 Action type COLU

ESMA REGULAR USE
136
5.4.6.3 Variation margining of an SLB with return of the same securities to the collateral
provider
Table 91 illustrates a different collateral update to the example in Table 86 - a 999,709
EUR decrease in the nominal amount of collateral to compensate for an increase in the price of the bond price from 102 to 103.03, as reported by the collateral provider. Collateral provider and collateral taker should both report in exactly the same way the information on collateral, as detailed in Table 91.
Table 91 - Variation margining of an SLB with return of the same securities to the
collateral provider
No Field Example XML Message
1.3 Reporting
counterparty
LEI of counterparty
A
<SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<CollUpd>
...
<CtrPtyData>
<CtrPtyData>
<RptgCtrPty>
<Id>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
</OthrCtrPty>
<OthrPtyData>
<AgtLndr>

<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
</AgtLndr>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
<SctiesLndg>
<EvtDt>2020-04-24</EvtDt>

<UnqTradIdr>UTI1</UnqTradIdr>
<MstrAgrmt>
<Tp>
<Tp>GMSLA</Tp>
</Tp>
</MstrAgrmt>
</SctiesLndg>
</LnData>
1.11 Other counterparty
LEI of counterparty
B
1.18 Agent lender {LEI} of the
agent lender F
1
Unique Transaction
Identifier ('UTI') UTI1
3 Event date 24/04/2020
9 Master agreement GMSLA
73 Collateralisation of net exposure FALSE
75
Type of the collateral component
SECU
78
Identification of a security used as collateral {ISIN} 79 Classification of a security used as collateral {CFI} 83 Collateral quantity or nominal amount 99000291 85 Currency of collateral nominal amount EUR 86 Price currency 87 Price per unit 103.03 88 Collateral market value 102000000 89 Haircut or margin 0

ESMA REGULAR USE
137
Table 91 - Variation margining of an SLB with return of the same securities to the
collateral provider
No Field Example XML Message
90 Collateral quality INVG <CollData>
<SctiesLndg>
<Collsd>
<AsstTp>
<Scty>
<Id>DE0010877643</Id>

<ClssfctnTp>DBFTFR</ClssfctnTp>
<QtyOrNmnlVal>
<NmnlVal>
<Amt Ccy="EUR">99000291</Amt>
</NmnlVal>
</QtyOrNmnlVal>
<UnitPric>
<Ptrg>103.03</Ptrg>
</UnitPric>
<MktVal Ccy="EUR">102000000</MktVal>
<HrcutOrMrgn>0</HrcutOrMrgn>
<Qlty>INVG</Qlty>
<Mtrty>2030-04-22</Mtrty>
<Issr>
<Id>

<LEI>NNNNNNNNNNNNNNNNNNNN
</LEI>
</Id>

<NetXpsrCollstnInd>false</NetXpsrCollstnI nd> </Collsd> </SctiesLndg> </CollData> ... </CollUpd> 91 Maturity date of the security 22/04/2030 92 Jurisdiction of the issuer DE 93 LEI of the issuer {LEI} of the issuer 94 Collateral type GOVS 95 Availability for collateral reuse TRUE 98 Action type COLU

ESMA REGULAR USE
138
Table 91 - Variation margining of an SLB with return of the same securities to the
collateral provider
No Field Example XML Message
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>
5.4.6.4 Variation margining of a repo with return of the same securities to the collateral
provider
Table 92 illustrates a different collateral update to the example in Table 86 - a 999,709
EUR decrease in the nominal amount of collateral to compensate for an increase in the price of the bond price from 102 to 103.03, as reported by the collateral provider. Collateral provider and collateral taker should both report in exactly the same way the information on collateral, as detailed in Table 92.
Table 92 - Variation margining of a repo with return of the same securities to the
collateral provider
No Field Example XML Message
1.3 Reporting
counterparty
LEI of counterparty
A
<SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<CollUpd>
...
<CtrPtyData>
<CtrPtyData>
<RptgCtrPty>
<Id>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
</OthrCtrPty>
<OthrPtyData>
<AgtLndr>

<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
</AgtLndr>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
1.11 Other counterparty
LEI of counterparty
B
1.18 Agent lender {LEI} of the
agent lender F
1
Unique Transaction
Identifier ('UTI') UTI1
3 Event date 24/04/2020
9 Master agreement GMRA
73 Collateralisation of net exposure FALSE
75
Type of the collateral component
SECU
78
Identification of a security used as collateral {ISIN} 79 Classification of a security used as collateral {CFI} 83 Collateral quantity or nominal amount 99000291

ESMA REGULAR USE
139
Table 92 - Variation margining of a repo with return of the same securities to the
collateral provider
No Field Example XML Message
85
Currency of collateral nominal amount
EUR
<RpTrad>
<EvtDt>2020-04-24</EvtDt>

<ClssfctnTp>DBFTFR</ClssfctnTp>
<QtyOrNmnlVal>
<NmnlVal>
<Amt Ccy="EUR">99000291</Amt>
</NmnlVal>
</QtyOrNmnlVal>
<UnitPric>
<Ptrg>103.03</Ptrg>
</UnitPric>
<MktVal Ccy="EUR">102000000</MktVal>

<LEI>NNNNNNNNNNNNNNNNNNNN
</LEI>
</Id>

<AvlblForCollReuse>true</AvlblForCollReu se> </Scty> 86 Price currency 87 Price per unit 103.03 88 Collateral market value 102000000 89 Haircut or margin 0 90 Collateral quality INVG 91 Maturity date of the security 22/04/2030 92 Jurisdiction of the issuer DE 93 LEI of the issuer {LEI} of the issuer 94 Collateral type GOVS 95 Availability for collateral reuse TRUE 98 Action type COLU

ESMA REGULAR USE
140
Table 92 - Variation margining of a repo with return of the same securities to the
collateral provider
No Field Example XML Message
</AsstTp>

<NetXpsrCollstnInd>false</NetXpsrCollstnI nd> </RpTrad> </CollData> ... </CollUpd> </Rpt> </TradData> </SctiesFincgRptgTxRpt> Variation margining for non-centrally cleared SFTs in the case of collateralisation on a net exposure basis In the case of collateralisation on a net exposure basis, in addition to the collateral exchanged as part of the transaction, the counterparties might agree to collateralise the loans that were concluded under the same type of master agreement on a net basis. Therefore, there are instances in which some of the collateral components that have been provided on a net basis by the collateral provider might be returned by the collateral taker. This is either to ensure that there is no excess collateral for the set of collateralised transactions, or that the collateral does not cross any haircut or margin threshold that might have been agreed between the counterparties. There are also instances where the securities that are returned by the collateral taker are not exactly the same as the securities that were originally posted by the collateral provider. In that case, it becomes necessary to identify the direction of the transfer to allow for a correct computation of exposures and level of collateralisation. Therefore, to ensure consistent reporting of collateral when collateralisation on a net exposure basis exists:
a. When collateral is exchanged in non-centrally cleared SFTs as part of variation margining on a net exposure basis between the two counterparties, they should report in the XML schema the amount of securities and the market value of those with a sign that reflects the state of each security from their own perspective. b. If the collateral provider is adding extra collateral as variation margin, it should report the new collateral market value on a net exposure basis with a negative sign.
c. If the collateral taker is returning part of the same extra collateral that it was already
provided as variation margin, it should report the new net collateral market value on a net exposure basis with a positive sign, whereas the collateral provider should report the new net collateral market value with a negative sign.

ESMA REGULAR USE
141 d. If the collateral provider receives collateral components which are different from the collateral components provided in the first place, it should report the collateral market value for those new collateral components with a positive sign. e. Conversely, the collateral taker should report with a positive sign the collateral components received as part of variation margining and with a negative sign the collateral components given to the collateral provider, which are different from the collateral components taken in the first place. This type of reporting is only applicable for COLU messages where (i) collateralisation is on a net exposure basis and (ii) there is no UTI reported for the collateral component(s). This reporting is not applicable to the allocations of collateral on a per transaction basis. Whenever there is collateralisation on a net exposure basis, the counterparties should send COLU messages for each of the SFTs that are collateralised at transaction level, and a single COLU message for the collateral that is used as variation margin.
5.4.7.1 Net exposure – Variation margining against a cash pool for SLB that are
collateralised with cash collateral at transaction level In the example in Table 93, the SLBs are initially collateralised with cash collateral (cash rebate SLB), and then the counterparties carry variation margining against a cash pool. The cash usually has no haircut and, in this case, the margin on the loan side is also considered to be zero. Specifically, with regards to haircuts and margins, the counterparties should refer to the guidelines in subsection 5.4.5.1 of section 5.4.4.
Table 93 - Net exposure - Variation margining against a cash pool for SLB that are
collateralised with cash collateral at transaction level No Field Example XML Message
1.3 Reporting
counterparty
LEI of counterparty
A
<SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<CollUpd>
…
<CtrPtyData>
<CtrPtyData>
<RptgCtrPty>
<Id>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
</OthrCtrPty>
1.11 Other counterparty
LEI of counterparty
B
1.18 Agent lender
{LEI} of agent lender
F
1
Unique Transaction
Identifier ('UTI') UTI1
3 Event date 24/04/2020
9 Master agreement GMSLA
73 Collateralisation of net exposure TRUE
75 Type of the collateral component CASH

ESMA REGULAR USE
142
Table 93 - Net exposure - Variation margining against a cash pool for SLB that are
collateralised with cash collateral at transaction level No Field Example XML Message 76 Cash collateral amount

100000000
<OthrPtyData>
<AgtLndr>

<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
</AgtLndr>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
<SctiesLndg>
<EvtDt>2020-04-24</EvtDt>

<UnqTradIdr>UTI1</UnqTradIdr>
<MstrAgrmt>
<Tp>
<Tp>GMSLA</Tp>
</Tp>
</MstrAgrmt>
</SctiesLndg>
</LnData>
<CollData>
<SctiesLndg>
<Collsd>
<AsstTp>
<Scty>
</Scty>
<Csh>
<Amt Ccy="EUR">100000000</Amt>
</Csh>
</AsstTp>
<NetXpsrCollstnInd>true</NetXpsrCollstnIn d> </Collsd> </SctiesLndg> </CollData> ... </CollUpd> </Rpt> <Rpt> <CollUpd> <CtrPtyData> <CtrPtyData> <RptgCtrPty> <Id>

<LEI>12345678901234500000</LEI>
</Id>
77 Cash collateral currency
EUR
98 Action type COLU
1.3 Reporting
counterparty
LEI of counterparty
A
1.11 Other counterparty
LEI of counterparty
B
1.18 Agent lender
{LEI} of agent lender
F
1
Unique Transaction
Identifier ('UTI') UTI2
3 Event date 24/04/2020
9 Master agreement GMSLA
73 Collateralisation of net exposure TRUE
75 Type of the collateral component CASH
76 Cash collateral amount

100000000
77 Cash collateral currency
EUR
98 Action type COLU
1.3 Reporting
counterparty
LEI of counterparty
A
1.11 Other counterparty
LEI of counterparty
B
1.18 Agent lender
{LEI} of agent lender
F
3 Event date 24/04/2020
9 Master agreement GMSLA
75 Type of the collateral component CASH

ESMA REGULAR USE
143
Table 93 - Net exposure - Variation margining against a cash pool for SLB that are
collateralised with cash collateral at transaction level No Field Example XML Message 76 Cash collateral amount

5000000
</RptgCtrPty>
<OthrCtrPty>
<Id>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
</OthrCtrPty>
<OthrPtyData>
<AgtLndr>

<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
</AgtLndr>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
<SctiesLndg>
<EvtDt>2020-04-24</EvtDt>

<UnqTradIdr>UTI2</UnqTradIdr>
<MstrAgrmt>
<Tp>
<Tp>GMSLA</Tp>
</Tp>
</MstrAgrmt>
</SctiesLndg>
</LnData>
<CollData>
<SctiesLndg>
<Collsd>
<AsstTp>
<Scty>
</Scty>
<Csh>
<Amt Ccy="EUR">100000000</Amt>
</Csh>
</AsstTp>
</Collsd>
</SctiesLndg>
</CollData>
...
</CollUpd>
</Rpt>
<Rpt>
<CollUpd>
<CtrPtyData>
<CtrPtyData>
<RptgCtrPty>
77 Cash collateral currency
EUR
98 Action type COLU

ESMA REGULAR USE
144
Table 93 - Net exposure - Variation margining against a cash pool for SLB that are
collateralised with cash collateral at transaction level No Field Example XML Message <Id>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
</OthrCtrPty>
<OthrPtyData>
<AgtLndr>

<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
</AgtLndr>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
<SctiesLndg>
<EvtDt>2020-04-24</EvtDt>

<MstrAgrmt> <Tp> <Tp>GMSLA</Tp> </Tp> </MstrAgrmt> </SctiesLndg> </LnData> <CollData> <SctiesLndg> <Collsd> <AsstTp> <Scty> </Scty> <Csh> <Amt Ccy="EUR">5000000</Amt> </Csh> </AsstTp> <NetXpsrCollstnInd>true</NetXpsrCollstnIn d> </Collsd> </SctiesLndg> </CollData> ... </CollUpd> </Rpt>

ESMA REGULAR USE
145
Table 93 - Net exposure - Variation margining against a cash pool for SLB that are
collateralised with cash collateral at transaction level No Field Example XML Message </TradData> </SctiesFincgRptgTxRpt>
5.4.7.2 Net exposure – Variation margining of repos collateralised initially at transaction
level and then included in a netting set
Table 94 shows the collateral pertaining to three UTIs, which were initially collateralised
on a per transaction basis. However, these three repos were included in a netting set, and the subsequent collateral reporting contains the collateral elements relating to the individual SFTs identified with their UTI and the collateral used for the collateralisation on a net exposure basis.
Table 94 - Net exposure - Variation margining of repos collateralised initially at
transaction level and then included in a netting set.
No Field Example XML Message
1.3 Reporting
counterparty
LEI of counterparty
A
<SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<CollUpd>
…
<CtrPtyData>
<CtrPtyData>
<RptgCtrPty>
<Id>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
</OthrCtrPty>
<OthrPtyData>
<AgtLndr>

<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
</AgtLndr>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
<RpTrad>
<EvtDt>2020-04-24</EvtDt>
1.11 Other counterparty
LEI of counterparty
B
1.18 Agent lender
{LEI} of agent lender
F
1
Unique Transaction
Identifier ('UTI') UTI1
3 Event date 24/04/2020
9 Master agreement GMRA
73 Collateralisation of net exposure TRUE
75 Type of the collateral component SECU
78
Identification of a security used as collateral {ISIN} 79 Classification of a security used as collateral {CFI} 83 Collateral quantity or nominal amount

100000000
85 Currency of collateral nominal amount EUR

ESMA REGULAR USE
146
Table 94 - Net exposure - Variation margining of repos collateralised initially at
transaction level and then included in a netting set.
No Field Example XML Message
86 Price currency

<ClssfctnTp>DBFTFR</ClssfctnTp>
<QtyOrNmnlVal>
<NmnlVal>
<Amt Ccy="EUR">100000000</Amt>
</NmnlVal>
</QtyOrNmnlVal>
<UnitPric>
<Ptrg>100</Ptrg>
</UnitPric>
<MktVal Ccy="EUR">100000000</MktVal>

<LEI>NNNNNNNNNNNNNNNNNNNN</LEI

</Id>

<AvlblForCollReuse>true</AvlblForCollReu se> </Scty> <Scty> <Id>FR0010877643</Id> 87 Price per unit 100 88 Collateral market value

100000000
89 Haircut or margin 0
90 Collateral quality INVG
91 Maturity date of the security 22/04/2030 92 Jurisdiction of the issuer DE 93 LEI of the issuer {LEI} of the issuer 94 Collateral type GOVS 95 Availability for collateral reuse TRUE 75 Type of the collateral component SECU 78 Identification of a security used as collateral {ISIN} 79 Classification of a security used as collateral {CFI} 83 Collateral quantity or nominal amount 50000000 85 Currency of collateral nominal amount EUR 86 Price currency 87 Price per unit 100 88 Collateral market value 50000000 89 Haircut or margin 0 90 Collateral quality INVG 91 Maturity date of the security 22/04/2030 92 Jurisdiction of the issuer FR

ESMA REGULAR USE
147
Table 94 - Net exposure - Variation margining of repos collateralised initially at
transaction level and then included in a netting set.
No Field Example XML Message
93 LEI of the issuer {LEI} of the issuer
<ClssfctnTp>DBFTFR
</ClssfctnTp>
<QtyOrNmnlVal>
<NmnlVal>
<Amt Ccy="EUR">50000000</Amt>
</NmnlVal>
</QtyOrNmnlVal>
<UnitPric>
<Ptrg>100</Ptrg>
</UnitPric>
<MktVal>50000000</MktVal>

<LEI>FFFFFFFFFFFFFFFFFFFF</LEI>
</Id>

<NetXpsrCollstnInd>true</NetXpsrCollstnIn d> </RpTrad> </CollData> ... </CollUpd> </Rpt> <Rpt> <CollUpd> <CtrPtyData> <CtrPtyData> <RptgCtrPty> <Id> 94 Collateral type GOVS 95 Availability for collateral reuse TRUE 98 Action type COLU
1.3 Reporting
counterparty
LEI of counterparty
A
1.11 Other counterparty
LEI of counterparty
B
1.18 Agent lender
{LEI} of agent lender
F
1
Unique Transaction
Identifier ('UTI') UTI2
3 Event date 24/04/2020
9 Master agreement GMRA
73 Collateralisation of net exposure
TRUE
75 Type of the collateral component SECU
78
Identification of a security used as collateral {ISIN} 79 Classification of a security used as collateral {CFI} 83 Collateral quantity or nominal amount

50000000
84 Collateral unit of measure
85 Currency of collateral nominal amount EUR 86 Price currency 87 Price per unit 100 88 Collateral market value

50000000

ESMA REGULAR USE
148
Table 94 - Net exposure - Variation margining of repos collateralised initially at
transaction level and then included in a netting set.
No Field Example XML Message
89 Haircut or margin 0

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
</OthrCtrPty>
<OthrPtyData>
<AgtLndr>

<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
</AgtLndr>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
<RpTrad>
<EvtDt>2020-04-24</EvtDt>
<UnqTradIdr>UTI2/UnqTradIdr>
<MstrAgrmt>
<Tp>
<Tp>GMRA</Tp>
</Tp>
</MstrAgrmt>
</RpTrad>
</LnData>
<CollData>
<RpTrad>
<AsstTp>
<Scty>
<Id>FR0010877643</Id>

<ClssfctnTp>DBFTFR</ClssfctnTp>
<QtyOrNmnlVal>
<NmnlVal>
<Amt Ccy="EUR">50000000</Amt>
</NmnlVal>
</QtyOrNmnlVal>
<UnitPric>
<Ptrg>100</Ptrg>
</UnitPric>
<MktVal Ccy="EUR">50000000</MktVal>
90 Collateral quality INVG
91 Maturity date of the security 22/04/2030 92 Jurisdiction of the issuer FR 93 LEI of the issuer {LEI} of the issuer 94 Collateral type GOVS 95 Availability for collateral reuse TRUE 98 Action type COLU
1.3 Reporting
counterparty
LEI of counterparty
A
1.11 Other counterparty
LEI of counterparty
B
1.18 Agent lender
{LEI} of agent lender
F
1
Unique Transaction
Identifier ('UTI') UTI3
3 Event date 24/04/2020
9 Master agreement GMRA
73 Collateralisation of net exposure TRUE
75 Type of the collateral component SECU
78
Identification of a security used as collateral {ISIN} 79 Classification of a security used as collateral {CFI} 83 Collateral quantity or nominal amount

5000000
84 Collateral unit of measure

ESMA REGULAR USE
149
Table 94 - Net exposure - Variation margining of repos collateralised initially at
transaction level and then included in a netting set.
No Field Example XML Message
85 Currency of collateral nominal amount EUR <HrcutOrMrgn>0</HrcutOrMrgn> <Qlty>INVG</Qlty> <Mtrty>2030-04-22</Mtrty> <Issr> <Id>

<LEI>FFFFFFFFFFFFFFFFFFFF</LEI>
</Id>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
</OthrCtrPty>
<OthrPtyData>
<AgtLndr>
86 Price currency
87 Price per unit 100
88 Collateral market value

5000000
89 Haircut or margin 0
90 Collateral quality INVG
91 Maturity date of the security 22/04/2040 92 Jurisdiction of the issuer NL 93 LEI of the issuer {LEI} of the issuer 94 Collateral type GOVS 95 Availability for collateral reuse TRUE 98 Action type COLU
1.3 Reporting
counterparty
LEI of counterparty
A
1.11 Other counterparty
LEI of counterparty
B
1.18 Agent lender
{LEI} of agent lender
F
3 Event date 24/04/2020
9 Master agreement GMRA
73 Collateralisation of net exposure TRUE
75 Type of the collateral component SECU
78
Identification of a security used as collateral {ISIN}

ESMA REGULAR USE
150
Table 94 - Net exposure - Variation margining of repos collateralised initially at
transaction level and then included in a netting set.
No Field Example XML Message
79
Classification of a security used as collateral {CFI}

<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
</AgtLndr>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
<RpTrad>
<EvtDt>2020-04-24</EvtDt>

<UnqTradIdr>UTI3</UnqTradIdr>
<MstrAgrmt>
<Tp>
<Tp>GMRA</Tp>
</Tp>
</MstrAgrmt>
</RpTrad>
</LnData>
<CollData>
<RpTrad>
<AsstTp>
<Scty>
<Id>NL0010877643</Id>
<ClssfctnTp>DBFTFR
</ClssfctnTp>
<QtyOrNmnlVal>
<NmnlVal>
<Amt Ccy="EUR">5000000</Amt>
</NmnlVal>
</QtyOrNmnlVal>
<UnitPric>
<Ptrg>100</Ptrg>
</UnitPric>
<MktVal Ccy="EUR">5000000</MktVal>

<LEI>DDDDDDDDDDDDDDDDDDDD
</LEI>
</Id>

<JursdctnCtry>NL</JursdctnCtry>
83 Collateral quantity or nominal amount

2000000
84 Collateral unit of measure
85 Currency of collateral nominal amount EUR 86 Price currency 87 Price per unit 100 88 Collateral market value

2000000
89 Haircut or margin 0
90 Collateral quality INVG
91 Maturity date of the security 22/04/2040 92 Jurisdiction of the issuer IT 93 LEI of the issuer {LEI} of the issuer 94 Collateral type GOVS 95 Availability for collateral reuse TRUE 75 Type of the collateral component SECU 78 Identification of a security used as collateral {ISIN} 79 Classification of a security used as collateral {CFI} 83 Collateral quantity or nominal amount

2000000
84 Collateral unit of measure
85 Currency of collateral nominal amount EUR 86 Price currency

ESMA REGULAR USE
151
Table 94 - Net exposure - Variation margining of repos collateralised initially at
transaction level and then included in a netting set.
No Field Example XML Message
87 Price per unit 100 </Issr>
<Tp>
<Cd>GOVS</Cd>
</Tp>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
</OthrCtrPty>
<OthrPtyData>
<AgtLndr>

2000000
89 Haircut or margin 0
90 Collateral quality INVG
91 Maturity date of the security 22/04/2040 92 Jurisdiction of the issuer ES 93 LEI of the issuer {LEI} of the issuer 94 Collateral type GOVS 95 Availability for collateral reuse TRUE 98 Action type COLU

ESMA REGULAR USE
152
Table 94 - Net exposure - Variation margining of repos collateralised initially at
transaction level and then included in a netting set.
No Field Example XML Message
</RpTrad>
</LnData>
<CollData>
<RpTrad>
<AsstTp>
<Scty>
<Id>IT00BH4HKS39</Id>
<ClssfctnTp>DBFTFR
</ClssfctnTp>
<QtyOrNmnlVal>
<NmnlVal>
<Amt Ccy="EUR">2000000</Amt>
</NmnlVal>
</QtyOrNmnlVal>
<UnitPric>
<Ptrg>100</Ptrg>
</UnitPric>
<MktVal Ccy="EUR">2000000</MktVal>

<HrcutOrMrgn>0</HrcutOrMrgn>
<Qlty>INVG</Qlty>
<Mtrty>2030-04-22</Mtrty>
<Issr>
<Id>
<LEI>IIIIIIIIIIIIIIIIIIII</LEI>
</Id>

<ClssfctnTp>DBFTPR</ClssfctnTp>
<QtyOrNmnlVal>
<NmnlVal>
<Amt Ccy="EUR">2000000</Amt>
</NmnlVal>
</QtyOrNmnlVal>
<UnitPric>

ESMA REGULAR USE
153
Table 94 - Net exposure - Variation margining of repos collateralised initially at
transaction level and then included in a netting set.
No Field Example XML Message
<Ptrg>100</Ptrg>
</UnitPric>
<MktVal>2000000</MktVal>

<LEI>EEEEEEEEEEEEEEEEEEEE</LEI>
</Id>

<NetXpsrCollstnInd>true</NetXpsrCollstnIn d> </RpTrad> </CollData> ... </CollUpd> </Rpt> </TradData> </SctiesFincgRptgTxRpt>
5.4.7.3 Net exposure - Variation margining of SLBs collateralised against a non-cash
collateral pool with a return of equivalent, but not the same securities to collateral provider
Table 95 illustrates a more complex update to the collateral. There is no collateral on a
per transaction basis; the original conclusion is against a collateral pool. In this example, following an increase in the price of one of the securities used to collateralise the exposure, that is the German government bond price increased from 102 to 103.3, but the collateral taker needs German government bonds while the collateral provider accepts to receive French government bonds. The two counterparties agree to the following substitution: the collateral taker returns 2,000,000 EUR in nominal amount of French government bond collateral. Thus the 2,060,000 EUR excess German bond collateral market value is

ESMA REGULAR USE
154 compensated by 2,060,000 EUR in the French bond collateral market value that is in possession of the collateral provider (i.e. with a negative sign from the perspective of the collateral taker), restoring the initial net collateral balance. It should be noted that the fields applicable to securities in the repeatable section of the collateral data are repeated twice in order to report all the relevant details. Both securities are available for subsequent reuse. Collateral provider and collateral taker should report the information on collateral, as detailed in Table 95 and including the relevant signs for the collateral components that are
part of the variation margining on a net exposure basis, as indicated in paragraph 373.
Table 95 - Net exposure - Variation margining of SLBs collateralised against a
collateral pool with return of equivalent, but not the same securities to collateral provider No Field Example XML Message 1. 3 Reporting counterparty LEI of counterparty A <SctiesFincgRptgTxRpt> <TradData> <Rpt> <CollUpd> ... <CtrPtyData> <CtrPtyData> <RptgCtrPty> <Id>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
</OthrCtrPty>
<OthrPtyData>
<AgtLndr>

<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
</AgtLndr>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
<SctiesLndg>
<EvtDt>2020-04-24</EvtDt>

<MstrAgrmt> <Tp> <Tp>GMSLA</Tp> 1. 11 Other counterparty LEI of counterparty B 1. 18 Agent lender {LEI} of the agent lender F 3 Event date 24/04/2020 9 Master agreement GMSLA 73 Collateralisation of net exposure TRUE 75 Type of the collateral component SECU 78 Identification of a security used as collateral {ISIN} 79 Classification of a security used as collateral {CFI} 83 Collateral quantity or nominal amount 101000000 85 Currency of collateral nominal amount EUR 86 Price currency 87 Price per unit 103.03 88 Collateral market value 104060300

ESMA REGULAR USE
155
Table 95 - Net exposure - Variation margining of SLBs collateralised against a
collateral pool with return of equivalent, but not the same securities to collateral provider No Field Example XML Message 89 Haircut or margin 0 </Tp> </MstrAgrmt> </SctiesLndg> </LnData> <CollData> <SctiesLndg> <Collsd> <AsstTp> <Scty> <Id>DE0010877643</Id>

<ClssfctnTp>DBFTPR</ClssfctnTp>
<QtyOrNmnlVal>
<NmnlVal>
<Amt Ccy="EUR">101000000</Amt>
</NmnlVal>
</QtyOrNmnlVal>
<UnitPric>
<Ptrg>103.03</Ptrg>
</UnitPric>
<MktVal Ccy="EUR">104060300</MktVal>
<HrcutOrMrgn>0</HrcutOrMrgn>
<Qlty>INVG</Qlty>
<Mtrty>2030-04-22</Mtrty>
<Issr>
<Id>

<LEI>NNNNNNNNNNNNNNNNNNNN
</LEI>
</Id>

<ClssfctnTp>DBFTPR</ClssfctnTp>
90 Collateral quality INVG
91 Maturity date of the security 22/04/2030 92 Jurisdiction of the issuer DE 93 LEI of the issuer {LEI} of the issuer 94 Collateral type GOVS 95 Availability for collateral reuse TRUE 75 Type of the collateral component SECU 78 Identification of a security used as collateral {ISIN} 79 Classification of a security used as collateral {CFI} 83 Collateral quantity or nominal amount -2000000 85 Currency of collateral nominal amount EUR 86 Price currency 87 Price per unit 103.015 88 Collateral market value -2060300 89 Haircut or margin 0 90 Collateral quality INVG 91 Maturity date of the security 22/04/2030 92 Jurisdiction of the issuer FR 93 LEI of the issuer {LEI} of the issuer 94 Collateral type GOVS

ESMA REGULAR USE
156
Table 95 - Net exposure - Variation margining of SLBs collateralised against a
collateral pool with return of equivalent, but not the same securities to collateral provider No Field Example XML Message 95 Availability for collateral reuse TRUE <QtyOrNmnlVal> <NmnlVal> <Amt Ccy="EUR">- 2000000</Amt> <Sgn>true</Sgn> </NmnlVal> </QtyOrNmnlVal> <UnitPric> <Ptrg>103.015</Ptrg> </UnitPric> <MktVal Ccy="EUR">- 2060300</MktVal> <HrcutOrMrgn>0</HrcutOrMrgn> <Qlty>INVG</Qlty> <Mtrty>2030-04-22</Mtrty> <Issr> <Id>

<LEI>FFFFFFFFFFFFFFFFFFFF </LEI>
</Id>

<NetXpsrCollstnInd>true</NetXpsrCollstnIn d> </Collsd> </SctiesLndg> </CollData> ... </CollUpd> </Rpt> </TradData> </SctiesFincgRptgTxRpt> 98 Action type COLU

ESMA REGULAR USE
157
5.4.7.4 Net exposure - Variation margining of repos collateralised initially at transaction
level and then included in a netting set with return of equivalent but not the same securities to collateral provider The example in Table 96 is a continuation of the example in Table 94. In this case, there is a return of one of the provided securities as VM, but greater than the initial quantity provided as variation margin.
Table 96 - Net exposure - Variation margining of repos collateralised initially at
transaction level and then included in a netting set with return of equivalent but not the same securities to collateral provider No Field Example XML Message
1.3 Reporting
counterparty
LEI of counterparty
A
<SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<CollUpd>
…
<CtrPtyData>
<CtrPtyData>
<RptgCtrPty>
<Id>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
</OthrCtrPty>
<OthrPtyData>
<AgtLndr>

<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
</AgtLndr>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
<RpTrad>
<EvtDt>2020-04-24</EvtDt>

<UnqTradIdr>UTI1</UnqTradIdr>
<MstrAgrmt>
<Tp>
<Tp>GMRA</Tp>
</Tp>
1.11 Other counterparty
LEI of counterparty
B
1.18 Agent lender
{LEI} of agent lender
F
1
Unique Transaction
Identifier ('UTI') UTI1
3 Event date 24/04/2020
9 Master agreement GMRA
73 Collateralisation of net exposure TRUE
75 Type of the collateral component SECU
78
Identification of a security used as collateral {ISIN} 79 Classification of a security used as collateral {CFI} 83 Collateral quantity or nominal amount 100000000 85 Currency of collateral nominal amount EUR 86 Price currency 87 Price per unit 100 88 Collateral market value 100000000

ESMA REGULAR USE
158
Table 96 - Net exposure - Variation margining of repos collateralised initially at
transaction level and then included in a netting set with return of equivalent but not the same securities to collateral provider No Field Example XML Message 89 Haircut or margin 0 </MstrAgrmt> </RpTrad> </LnData> <CollData> <RpTrad> <AsstTp> <Scty> <Id>DE0010877643</Id>

<ClssfctnTp>DBFTFR</ClssfctnTp>
<QtyOrNmnlVal>
<NmnlVal>
<Amt Ccy="EUR">100000000</Amt>
</NmnlVal>
</QtyOrNmnlVal>
<UnitPric>
<Ptrg>100</Ptrg>
</UnitPric>
<MktVal Ccy="EUR">100000000</MktVal>

<LEI>NNNNNNNNNNNNNNNNNNNN</LEI

</Id>

<ClssfctnTp>DBFTFR</ClssfctnTp>
<QtyOrNmnlVal>
<NmnlVal>
90 Collateral quality INVG
91 Maturity date of the security 22/04/2030 92 Jurisdiction of the issuer DE 93 LEI of the issuer {LEI} of the issuer 94 Collateral type GOVS 95 Availability for collateral reuse TRUE 78 Identification of a security used as collateral {ISIN} 79 Classification of a security used as collateral {CFI} 83 Collateral quantity or nominal amount 50000000 85 Currency of collateral nominal amount EUR 86 Price currency 87 Price per unit 100 88 Collateral market value 50000000 89 Haircut or margin 0 90 Collateral quality INVG 91 Maturity date of the security 22/04/2030 92 Jurisdiction of the issuer DE 93 LEI of the issuer {LEI} of the issuer 94 Collateral type GOVS 95 Availability for collateral reuse TRUE

ESMA REGULAR USE
159
Table 96 - Net exposure - Variation margining of repos collateralised initially at
transaction level and then included in a netting set with return of equivalent but not the same securities to collateral provider No Field Example XML Message 98 Action type COLU <Amt Ccy="EUR">50000000</Amt> </NmnlVal> </QtyOrNmnlVal> <UnitPric> <Ptrg>100</Ptrg> </UnitPric> <MktVal>50000000</MktVal>

<LEI>NNNNNNNNNNNNNNNNNNNN</LEI

</Id>

<LEI>12345678901234500000</LEI>
</Id>
</RptgCtrPty>
1.3 Reporting
counterparty
LEI of counterparty
A
1.11 Other counterparty
LEI of counterparty
B
1.18 Agent lender
{LEI} of agent lender
F
1
Unique Transaction
Identifier ('UTI') UTI2
3 Event date 24/04/2020
9 Master agreement GMRA
73 Collateralisation of net exposure TRUE
78
Identification of a security used as collateral {ISIN} 79 Classification of a security used as collateral {CFI} 83 Collateral quantity or nominal amount 50000000 84 Collateral unit of measure 85 Currency of collateral nominal amount EUR 86 Price currency 87 Price per unit 100 88 Collateral market value 50000000 89 Haircut or margin 0 90 Collateral quality INVG 91 Maturity date of the security 22/04/2030 92 Jurisdiction of the issuer FR

ESMA REGULAR USE
160
Table 96 - Net exposure - Variation margining of repos collateralised initially at
transaction level and then included in a netting set with return of equivalent but not the same securities to collateral provider No Field Example XML Message 93 LEI of the issuer {LEI} of the issuer <OthrCtrPty> <Id>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
</OthrCtrPty>
<OthrPtyData>
<AgtLndr>

<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
</AgtLndr>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
<RpTrad>
<EvtDt>2020-04-24</EvtDt>

<HrcutOrMrgn>0</HrcutOrMrgn>
<Qlty>INVG</Qlty>
94 Collateral type GOVS
95 Availability for collateral reuse TRUE
98 Action type COLU
1.3 Reporting
counterparty
LEI of counterparty
A
1.11 Other counterparty
LEI of counterparty
B
1.18 Agent lender
{LEI} of agent lender
F
1
Unique Transaction
Identifier (‘UTI’)
UTI3
3 Event date 24/04/2020
9 Master agreement GMRA
73 Collateralisation of net exposure TRUE
78
Identification of a security used as collateral {ISIN} 79 Classification of a security used as collateral {CFI} 83 Collateral quantity or nominal amount 50000000 84 Collateral unit of measure 85 Currency of collateral nominal amount EUR 86 Price currency 87 Price per unit 100 88 Collateral market value 50000000 89 Haircut or margin 0

ESMA REGULAR USE
161
Table 96 - Net exposure - Variation margining of repos collateralised initially at
transaction level and then included in a netting set with return of equivalent but not the same securities to collateral provider No Field Example XML Message 90 Collateral quality INVG <Mtrty>2030-04-22</Mtrty> <Issr> <Id>

<LEI>FFFFFFFFFFFFFFFFFFFF</LEI>
</Id>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
</OthrCtrPty>
<OthrPtyData>
<AgtLndr>

<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
</AgtLndr>
</OthrPtyData>
91 Maturity date of the security 22/04/2040 92 Jurisdiction of the issuer NL 93 LEI of the issuer {LEI} of the issuer 94 Collateral type GOVS 95 Availability for collateral reuse TRUE 98 Action type COLU
1.3 Reporting
counterparty
LEI of counterparty
A
1.11 Other counterparty
LEI of counterparty
B
1.18 Agent lender
{LEI} of agent lender
F
3 Event date 24/04/2020
9 Master agreement GMRA
73 Collateralisation of net exposure TRUE
78
Identification of a security used as collateral {ISIN} 79 Classification of a security used as collateral {CFI} 83 Collateral quantity or nominal amount 2000000 84 Collateral unit of measure 85 Currency of collateral nominal amount EUR 86 Price currency 87 Price per unit 100

ESMA REGULAR USE
162
Table 96 - Net exposure - Variation margining of repos collateralised initially at
transaction level and then included in a netting set with return of equivalent but not the same securities to collateral provider No Field Example XML Message 88 Collateral market value 2000000 </CtrPtyData> </CtrPtyData> <LnData> <RpTrad> <EvtDt>2020-04-24</EvtDt>

<UnqTradIdr>UTI3</UnqTradIdr>
<MstrAgrmt>
<Tp>
<Tp>GMRA</Tp>
</Tp>
</MstrAgrmt>
</RpTrad>
</LnData>
<CollData>
<RpTrad>
<AsstTp>
<Scty>
<Id>NL0010877000</Id>
<ClssfctnTp>DBFTFR
</ClssfctnTp>
<QtyOrNmnlVal>
<NmnlVal>
<Amt Ccy="EUR">50000000</Amt>
</NmnlVal>
</QtyOrNmnlVal>
<UnitPric>
<Ptrg>100</Ptrg>
</UnitPric>
<MktVal Ccy="EUR">50000000</MktVal>

<LEI>DDDDDDDDDDDDDDDDDDDD
</LEI>
</Id>

<JursdctnCtry>NL</JursdctnCtry>
</Issr>
<Tp>
<Cd>GOVS</Cd>
89 Haircut or margin 0
90 Collateral quality INVG
91 Maturity date of the security 22/04/2040 92 Jurisdiction of the issuer IT 93 LEI of the issuer {LEI} of the issuer 94 Collateral type GOVS 95 Availability for collateral reuse TRUE 98 Action type COLU
1.3 Reporting
counterparty
LEI of counterparty
A
1.11 Other counterparty
LEI of counterparty
B
1.18 Agent lender
{LEI} of agent lender
F
3 Event date 24/04/2020
9 Master agreement GMRA
73 Collateralisation of net exposure TRUE
78
Identification of a security used as collateral {ISIN} 79 Classification of a security used as collateral {CFI} 83 Collateral quantity or nominal amount -2000000 84 Collateral unit of measure 85 Currency of collateral nominal amount EUR

ESMA REGULAR USE
163
Table 96 - Net exposure - Variation margining of repos collateralised initially at
transaction level and then included in a netting set with return of equivalent but not the same securities to collateral provider No Field Example XML Message 86 Price currency </Tp>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
</OthrCtrPty>
<OthrPtyData>
<AgtLndr>

<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
</AgtLndr>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
<RpTrad>
<EvtDt>2020-04-24</EvtDt>
<MstrAgrmt>
<Tp>
<Tp>GMRA</Tp>
</Tp>
</MstrAgrmt>
</RpTrad>
</LnData>
87 Price per unit 100
88 Collateral market value -2000000
89 Haircut or margin 0
90 Collateral quality INVG
91 Maturity date of the security 22/04/2040 92 Jurisdiction of the issuer ES 93 LEI of the issuer {LEI} of the issuer 94 Collateral type GOVS 95 Availability for collateral reuse TRUE 98 Action type COLU

ESMA REGULAR USE
164
Table 96 - Net exposure - Variation margining of repos collateralised initially at
transaction level and then included in a netting set with return of equivalent but not the same securities to collateral provider No Field Example XML Message <CollData> <RpTrad> <AsstTp> <Scty> <Id>IT00BH4HKS39</Id> <ClssfctnTp> DBFTFR </ClssfctnTp> <QtyOrNmnlVal> <NmnlVal> <Amt Ccy="EUR">2000000</Amt> <Sgn>true</Sgn> </NmnlVal> </QtyOrNmnlVal> <UnitPric> <Ptrg>100</Ptrg> </UnitPric> <MktVal Ccy="EUR">2000000</MktVal>

<HrcutOrMrgn>0</HrcutOrMrgn>
<Qlty>INVG</Qlty>
<Mtrty>2030-04-22</Mtrty>
<Issr>
<Id>
<LEI>IIIIIIIIIIIIIIIIIIII</LEI>
</Id>

ESMA REGULAR USE
165
Table 96 - Net exposure - Variation margining of repos collateralised initially at
transaction level and then included in a netting set with return of equivalent but not the same securities to collateral provider No Field Example XML Message <CtrPtyData> <CtrPtyData> <RptgCtrPty> <Id>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
</OthrCtrPty>
<OthrPtyData>
<AgtLndr>

<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
</AgtLndr>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
<RpTrad>
<EvtDt>2020-04-24</EvtDt>
<MstrAgrmt>
<Tp>
<Tp>GMRA</Tp>
</Tp>
</MstrAgrmt>
</RpTrad>
</LnData>
<CollData>
<RpTrad>
<AsstTp>
<Scty>
<Id>ES0010877643</Id>
<ClssfctnTp>DBFTPR
</ClssfctnTp>
<QtyOrNmnlVal>
<NmnlVal>
<Amt Ccy="EUR">101000000</Amt>
</NmnlVal>
</QtyOrNmnlVal>
<UnitPric>
<Ptrg>103.03</Ptrg>
</UnitPric>

ESMA REGULAR USE
166
Table 96 - Net exposure - Variation margining of repos collateralised initially at
transaction level and then included in a netting set with return of equivalent but not the same securities to collateral provider No Field Example XML Message <MktVal Ccy="EUR">- 2000000</MktVal>

<LEI>EEEEEEEEEEEEEEEEEEEE </LEI>
</Id>

<NetXpsrCollstnInd>true</NetXpsrCollstnIn d> </RpTrad> </CollData> ... </CollUpd> </Rpt> </TradData> </SctiesFincgRptgTxRpt>
5.4.7.5 Net exposure – Variation margining with cash of repos collateralised initially at
transaction level and then included in a netting set (Table 97) This example is a variation of the previous examples of variation margining at net exposure with securities. The three SFTs identified with UTI1, UTI2 and UTI3 are collateralised at transaction level with securities and then for the variation margining the counterparties have agreed to provide cash. The collateral provider is the one giving additional cash to cover the exposure.

ESMA REGULAR USE
167
Table 97 – Net exposure – Variation margining with cash of repos collateralised
initially at transaction level and then included in a netting set No Field Example XML Message
1.3 Reporting
counterparty
LEI of counterparty
A
<SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<CollUpd>
…
<CtrPtyData>
<CtrPtyData>
<RptgCtrPty>
<Id>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
</OthrCtrPty>
<OthrPtyData>
<AgtLndr>

<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
</AgtLndr>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
<RpTrad>
<EvtDt>2020-04-24</EvtDt>

<ClssfctnTp>DBFTFR</ClssfctnTp>
<QtyOrNmnlVal>
1.11 Other counterparty
LEI of counterparty
B
1.18 Agent lender
{LEI} of agent lender
F
1
Unique Transaction
Identifier (‘UTI’)
UTI1
3 Event date 24/04/2020
9 Master agreement GMRA
73 Collateralisation of net exposure TRUE
75 Type of the collateral component SECU
78
Identification of a security used as collateral {ISIN} 79 Classification of a security used as collateral {CFI} 83 Collateral quantity or nominal amount

100000000
85 Currency of collateral nominal amount EUR 86 Price currency 87 Price per unit 100 88 Collateral market value

100000000
89 Haircut or margin 0
90 Collateral quality INVG
91 Maturity date of the security 22/04/2030 92 Jurisdiction of the issuer DE 93 LEI of the issuer {LEI} of the issuer

ESMA REGULAR USE
168
Table 97 – Net exposure – Variation margining with cash of repos collateralised
initially at transaction level and then included in a netting set No Field Example XML Message 94 Collateral type GOVS <NmnlVal> <Amt Ccy="EUR">100000000</Amt> </NmnlVal> </QtyOrNmnlVal> <UnitPric> <Ptrg>100</Ptrg> </UnitPric> <MktVal Ccy="EUR">100000000</MktVal>

<LEI>NNNNNNNNNNNNNNNNNNNN</LEI

</Id>

<AvlblForCollReuse>true</AvlblForCollReu se> </Scty> <Scty> <Id>FR0010877643</Id> <ClssfctnTp>DBFTFR </ClssfctnTp> <QtyOrNmnlVal> <NmnlVal> <Amt Ccy="EUR">50000000</Amt> </NmnlVal> </QtyOrNmnlVal> <UnitPric> <Ptrg>100</Ptrg> </UnitPric> <MktVal>50000000</MktVal> 95 Availability for collateral reuse TRUE 75 Type of the collateral component SECU 78 Identification of a security used as collateral {ISIN} 79 Classification of a security used as collateral {CFI} 83 Collateral quantity or nominal amount

50000000
85 Currency of collateral nominal amount EUR 86 Price currency 87 Price per unit 100 88 Collateral market value

50000000
89 Haircut or margin 0
90 Collateral quality INVG
91 Maturity date of the security 22/04/2030 92 Jurisdiction of the issuer FR 93 LEI of the issuer {LEI} of the issuer 94 Collateral type GOVS 95 Availability for collateral reuse TRUE 98 Action type COLU
1.3 Reporting
counterparty
LEI of counterparty
A
1.11 Other counterparty
LEI of counterparty
B

ESMA REGULAR USE
169
Table 97 – Net exposure – Variation margining with cash of repos collateralised
initially at transaction level and then included in a netting set No Field Example XML Message
1.18 Agent lender
{LEI} of agent lender
F

<LEI>FFFFFFFFFFFFFFFFFFFF</LEI>
</Id>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
</OthrCtrPty>
<OthrPtyData>
<AgtLndr>

<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
1
Unique Transaction
Identifier (‘UTI’)
UTI2
3 Event date 24/04/2020
9 Master agreement GMRA
73 Collateralisation of net exposure TRUE
75 Type of the collateral component SECU
78
Identification of a security used as collateral {ISIN} 79 Classification of a security used as collateral {CFI} 83 Collateral quantity or nominal amount

50000000
84 Collateral unit of measure
85 Currency of collateral nominal amount EUR 86 Price currency 87 Price per unit 100 88 Collateral market value

ESMA REGULAR USE
170
Table 97 – Net exposure – Variation margining with cash of repos collateralised
initially at transaction level and then included in a netting set No Field Example XML Message 98 Action type COLU </AgtLndr> </OthrPtyData> </CtrPtyData> </CtrPtyData> <LnData> <RpTrad> <EvtDt>2020-04-24</EvtDt>

<LEI>FFFFFFFFFFFFFFFFFFFF</LEI>
</Id>

<JursdctnCtry>FR</JursdctnCtry>
</Issr>
<Tp>
1.3 Reporting
counterparty
LEI of counterparty
A
1.11 Other counterparty
LEI of counterparty
B
1.18 Agent lender
{LEI} of agent lender
B
1
Unique Transaction
Identifier ('UTI') UTI3
3 Event date 24/04/2020
9 Master agreement GMRA
73 Collateralisation of net exposure TRUE
75 Type of the collateral component SECU
78
Identification of a security used as collateral {ISIN} 79 Classification of a security used as collateral {CFI} 83 Collateral quantity or nominal amount

50000000
84 Collateral unit of measure
85 Currency of collateral nominal amount EUR 86 Price currency 87 Price per unit 100 88 Collateral market value

50000000
89 Haircut or margin 0
90 Collateral quality INVG
91 Maturity date of the security 22/04/2040

ESMA REGULAR USE
171
Table 97 – Net exposure – Variation margining with cash of repos collateralised
initially at transaction level and then included in a netting set No Field Example XML Message 92 Jurisdiction of the issuer NL <Cd>GOVS</Cd> </Tp>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
</OthrCtrPty>
<OthrPtyData>
<AgtLndr>

<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
</AgtLndr>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
<RpTrad>
<EvtDt>2020-04-24</EvtDt>

<UnqTradIdr>UTI3</UnqTradIdr>
<MstrAgrmt>
<Tp>
<Tp>GMRA</Tp>
</Tp>
</MstrAgrmt>
93 LEI of the issuer {LEI} of the issuer
94 Collateral type MEQU
95 Availability for collateral reuse TRUE
98 Action type GOVS
1.3 Reporting
counterparty
LEI of counterparty
A
1.11 Other counterparty
LEI of counterparty
B
1.18 Agent lender
{LEI} of agent lender
F
3 Event date 24/04/2020
9 Master agreement GMRA
73 Collateralisation of net exposure TRUE
75 Type of the collateral component CASH
76 Cash collateral amount

2000000
77 Cash collateral currency
EUR
98 Action type COLU

ESMA REGULAR USE
172
Table 97 – Net exposure – Variation margining with cash of repos collateralised
initially at transaction level and then included in a netting set No Field Example XML Message </RpTrad> </LnData> <CollData> <RpTrad> <AsstTp> <Scty> <Id>NL0010877643</Id> <ClssfctnTp>DBFTFR </ClssfctnTp> <QtyOrNmnlVal> <Qty>50000000</Qty> </QtyOrNmnlVal> <UnitPric> <MntryVal> <Amt Ccy="EUR">10</Amt> </MntryVal> </UnitPric> <MktVal Ccy="EUR">50000000</MktVal>

<LEI>DDDDDDDDDDDDDDDDDDDD
</LEI>
</Id>

ESMA REGULAR USE
173
Table 97 – Net exposure – Variation margining with cash of repos collateralised
initially at transaction level and then included in a netting set No Field Example XML Message <Rpt> <CollUpd> <CtrPtyData> <CtrPtyData> <RptgCtrPty> <Id>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
</OthrCtrPty>
<OthrPtyData>
<AgtLndr>

ESMA REGULAR USE
174
Table 97 – Net exposure – Variation margining with cash of repos collateralised
initially at transaction level and then included in a netting set No Field Example XML Message </Rpt> </TradData> </SctiesFincgRptgTxRpt>
5.4.7.6 Variation margining of repos collateralised initially at transaction level and then
included in a netting set. On that given day the position is flat and no VM is needed
Table 98 further elaborates on the example included in Table 97, but in this case, the
important element that is shown is that at the end of the day there is no further collateral exchanged as variation margin for the collateralisation on a net exposure basis. The reporting logic is similar to the reporting of zero collateral in section 5.4.4.
Table 98 – Net exposure – Variation margining of repos collateralised initially at
transaction level and then included in a netting set. On that given day the position is flat and no VM is needed No Field Example XML Message
1.3 Reporting
counterparty
LEI of counterparty
A
<SctiesFincgRptgTxRpt>
<TradData>
<Rpt>
<CollUpd>
…
<CtrPtyData>
<CtrPtyData>
<RptgCtrPty>
<Id>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
</OthrCtrPty>
<OthrPtyData>
<AgtLndr>

100000000
85 Currency of collateral nominal amount EUR

ESMA REGULAR USE
175
Table 98 – Net exposure – Variation margining of repos collateralised initially at
transaction level and then included in a netting set. On that given day the position is flat and no VM is needed No Field Example XML Message 86 Price currency <UnqTradIdr>UTI1</UnqTradIdr> <MstrAgrmt> <Tp> <Tp>GMRA</Tp> </Tp> </MstrAgrmt> </RpTrad> </LnData> <CollData> <RpTrad> <AsstTp> <Scty> <Id>DE0010877643</Id>

<ClssfctnTp>DBFTFR</ClssfctnTp>
<QtyOrNmnlVal>
<NmnlVal>
<Amt Ccy="EUR">100000000</Amt>
</NmnlVal>
</QtyOrNmnlVal>
<UnitPric>
<Ptrg>100</Ptrg>
</UnitPric>
<MktVal Ccy="EUR">100000000</MktVal>

<LEI>NNNNNNNNNNNNNNNNNNNN</LEI

</Id>

<AvlblForCollReuse>true</AvlblForCollReu se> 87 Price per unit 100 88 Collateral market value

50000000
85 Currency of collateral nominal amount EUR 86 Price currency 87 Price per unit 100 88 Collateral market value

50000000
89 Haircut or margin 0
90 Collateral quality INVG
91 Maturity date of the security 22/04/2030

ESMA REGULAR USE
176
Table 98 – Net exposure – Variation margining of repos collateralised initially at
transaction level and then included in a netting set. On that given day the position is flat and no VM is needed No Field Example XML Message 92 Jurisdiction of the issuer FR </Scty> <Scty> <Id>FR0010877643</Id> <ClssfctnTp>DBFTFR </ClssfctnTp> <QtyOrNmnlVal> <NmnlVal> <Amt Ccy="EUR">50000000</Amt> </NmnlVal> </QtyOrNmnlVal> <UnitPric> <Ptrg>100</Ptrg> </UnitPric> <MktVal>50000000</MktVal>

<LEI>FFFFFFFFFFFFFFFFFFFF</LEI>
</Id>

<NetXpsrCollstnInd>true</NetXpsrCollstnIn d> </RpTrad> </CollData> ... </CollUpd> </Rpt> <Rpt> <CollUpd> <CtrPtyData> 93 LEI of the issuer {LEI} of the issuer 94 Collateral type GOVS 95 Availability for collateral reuse TRUE 98 Action type COLU
1.3 Reporting
counterparty
LEI of counterparty
A
1.11 Other counterparty
LEI of counterparty
B
1.18 Agent lender
{LEI} of agent lender
F
1
Unique Transaction
Identifier ('UTI') UTI2
3 Event date 24/04/2020
9 Master agreement GMRA
73 Collateralisation of net exposure TRUE
75 Type of the collateral component SECU
78
Identification of a security used as collateral {ISIN} 79 Classification of a security used as collateral {CFI} 83 Collateral quantity or V nominal amount

50000000
84 Collateral unit of measure
85 Currency of collateral nominal amount EUR 86 Price currency 87 Price per unit 100

ESMA REGULAR USE
177
Table 98 – Net exposure – Variation margining of repos collateralised initially at
transaction level and then included in a netting set. On that given day the position is flat and no VM is needed No Field Example XML Message 88 Collateral market value

50000000
<CtrPtyData>
<RptgCtrPty>
<Id>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
</OthrCtrPty>
<OthrPtyData>
<AgtLndr>

<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
</AgtLndr>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
<RpTrad>
<EvtDt>2020-04-24</EvtDt>

<UnqTradIdr>UTI2</UnqTradIdr>
<MstrAgrmt>
<Tp>
<Tp>GMRA</Tp>
</Tp>
</MstrAgrmt>
</RpTrad>
</LnData>
<CollData>
<RpTrad>
<AsstTp>
<Scty>
<Id>FR0010877643</Id>
<ClssfctnTp>DBFTFR
</ClssfctnTp>
<QtyOrNmnlVal>
<NmnlVal>
<Amt Ccy="EUR">50000000</Amt>
</NmnlVal>
</QtyOrNmnlVal>
<UnitPric>
89 Haircut or margin 0
90 Collateral quality INVG
91 Maturity date of the security 22/04/2030 92 Jurisdiction of the issuer FR 93 LEI of the issuer {LEI} of the issuer 94 Collateral type GOVS 95 Availability for collateral reuse TRUE 98 Action type COLU
1.3 Reporting
counterparty
LEI of counterparty
A
1.11 Other counterparty
LEI of counterparty
B
1.18 Agent lender
{LEI} of agent lender
F
1
Unique Transaction
Identifier ('UTI') UTI3
3 Event date 24/04/2020
9 Master agreement GMRA
73 Collateralisation of net exposure TRUE
75 Type of the collateral component SECU
78
Identification of a security used as collateral {ISIN} 79 Classification of a security used as collateral {CFI} 83 Collateral quantity or nominal amount

50000000

ESMA REGULAR USE
178
Table 98 – Net exposure – Variation margining of repos collateralised initially at
transaction level and then included in a netting set. On that given day the position is flat and no VM is needed No Field Example XML Message 84 Collateral unit of measure <Ptrg>100</Ptrg> </UnitPric> <MktVal Ccy="EUR">50000000</MktVal>

<LEI>FFFFFFFFFFFFFFFFFFFF</LEI>
</Id>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
</OthrCtrPty>
85 Currency of collateral nominal amount EUR 86 Price currency 87 Price per unit 100 88 Collateral market value

50000000
89 Haircut or margin 0
90 Collateral quality INVG
91 Maturity date of the security 22/04/2040 92 Jurisdiction of the issuer NL 93 LEI of the issuer {LEI} of the issuer 94 Collateral type GOVS 95 Availability for collateral reuse TRUE 98 Action type COLU
1.3 Reporting
counterparty
LEI of counterparty
A
1.11 Other counterparty
LEI of counterparty
B
1.18 Agent lender
{LEI} of agent lender
F
3 Event date 24/04/2020
9 Master agreement GMRA
73 Collateralisation of net exposure TRUE
75 Type of the collateral component CASH
76 Cash collateral amount 0

ESMA REGULAR USE
179
Table 98 – Net exposure – Variation margining of repos collateralised initially at
transaction level and then included in a netting set. On that given day the position is flat and no VM is needed No Field Example XML Message 77 Cash collateral currency EUR <OthrPtyData> <AgtLndr>

<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
</AgtLndr>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
<RpTrad>
<EvtDt>2020-04-24</EvtDt>

<ClssfctnTp>DBFTFR</ClssfctnTp>
<QtyOrNmnlVal>
<NmnlVal>
<Amt Ccy="EUR">50000000</Amt>
</NmnlVal>
</QtyOrNmnlVal>
<UnitPric>
<Ptrg>100</Ptrg>
</UnitPric>
<MktVal Ccy="EUR">50000000</MktVal>

<LEI>DDDDDDDDDDDDDDDDDDDD
</LEI>
98 Action type COLU

ESMA REGULAR USE
180
Table 98 – Net exposure – Variation margining of repos collateralised initially at
transaction level and then included in a netting set. On that given day the position is flat and no VM is needed No Field Example XML Message </Id>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
</OthrCtrPty>
<OthrPtyData>
<AgtLndr>

<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
</AgtLndr>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
<RpTrad>

ESMA REGULAR USE
181
Table 98 – Net exposure – Variation margining of repos collateralised initially at
transaction level and then included in a netting set. On that given day the position is flat and no VM is needed No Field Example XML Message <EvtDt>2020-04-24</EvtDt> <MstrAgrmt> <Tp> <Tp>GMRA</Tp> </Tp> </MstrAgrmt> </RpTrad> </LnData> <CollData> <RpTrad> <AsstTp> <Csh> <Amt Ccy="EUR">0</Amt> </Csh> </AsstTp>

<NetXpsrCollstnInd>true</NetXpsrCollstnIn d> </RpTrad> </CollData> ... </CollUpd> </Rpt> </TradData> </SctiesFincgRptgTxRpt> Prepaid collateral for SLB When reporting the explicit collateral allocation for a net exposure, the collateral update should specify the LEIs of the counterparties, the master agreement, the value date of the collateral and the specific collateral allocation, so that the collateral update can be linked to the existing SFTs. The field “Value date of the collateral” (Field 2.74) is applicable in the context of Repos, BSB/SBB and SLB. The event date specifies the expected settlement date of the collateral. By comparing the LEIs of the counterparties, the master agreement, and the date fields of the original trade report and provided in the collateral update, it is possible to identify to which trades the collateral update for a net outstanding amount applies. In the example shown by Table 99, the collateral should be reported based on the expected settlement that occurred on 23/04/2020, specified as “Event Date” (Field 2.3). The “Value date of collateral” (Field 2.74) specifies the date as of which the collateral update applies to the outstanding loans (i.e. the collateral is not “pre-paid” anymore from 24/04/2020). Therefore, to determine to which SFTs the collateral update applies, the value date of collateral would be related to the value date and the maturity date of the SFTs that have the same LEIs of the counterparties and the same master agreement.

ESMA REGULAR USE
182
Table 99 - Prepaid collateral
No Field Example XML Message
3 Event date 2020-04-23 <SctiesFincgRptgTxRpt> <TradData> <Rpt> <CollUpd> ... <CtrPtyData> ... </CtrPtyData> <LnData> <SctiesLndg> <EvtDt>2020-04-23</EvtDt> </SctiesLndg> </LnData> <CollData> <SctiesLndg> <Collsd> <CollValDt>2020-04- 24</CollValDt> <AsstTp> <Scty> <Id>DE0010877643</Id>

<ClssfctnTp>DBFTFR</ClssfctnTp>
<QtyOrNmnlVal>
<NmnlVal>
<Amt Ccy="EUR">100000000</Amt>
</NmnlVal>
</QtyOrNmnlVal>
<UnitPric>
<Ptrg>102</Ptrg>
</UnitPric>
<MktVal Ccy="EUR">102000000</MktVal>
<HrcutOrMrgn>2</HrcutOrMrgn>
<Qlty>INVG</Qlty>
<Mtrty>2030-04-22</Mtrty>
<Issr>
<Id>

<LEI>NNNNNNNNNNNNNNNNNNNN
</LEI>
</Id>

<JursdctnCtry>DE</JursdctnCtry>
</Issr>
<Tp>
<Cd>GOVS</Cd>
</Tp>
73 Collateralisation of net exposure true
74 Value date of the collateral 2020-04-24
78
Identification of a security used as collateral {ISIN} 79 Classification of a security used as collateral {CFI} 83 Collateral quantity or nominal amount 100000000 84 Collateral unit of measure 85 Currency of collateral nominal amount EUR 86 Price currency 87 Price per unit 102 88 Collateral market value 102000000 89 Haircut or margin 2 90 Collateral quality INVG 91 Maturity date of the security 2030-04-22 92 Jurisdiction of the issuer DE 93 LEI of the issuer {LEI} of the issuer 94 Collateral type GOVS 95 Availability for collateral reuse true

ESMA REGULAR USE
183
Table 99 - Prepaid collateral
No Field Example XML Message

<AvlblForCollReuse>true</AvlblForCollReu se> </Scty> </AsstTp> </Collsd> </SctiesLndg> </CollData> ... </CollUpd> </Rpt> </TradData> </SctiesFincgRptgTxRpt> Portfolio of cleared transactions When reporting Field 2.97 (Portfolio code), the counterparties should ensure that they use the code consistently in their reports. If a code identifies a portfolio that collateralises transactions also comprising derivatives, the counterparties should use the same code used when reporting under EMIR. Also, the Portfolio code value does not need to be universally unique but needs to be used consistently. Since the Field 2.97 contains a non-matching value, the value does not have to to be agreed upon by both counterparties in the transaction.
5.5 Margin data
The data included in this section should be reported by all the counterparties whose SFTs have been centrally cleared unless these counterparties are subject to the mandatory delegation under Article 4(2) in which case it should be the entity specified in that Article the one that reports. In order to be able to use the services of a CCP, both CM 1 and CM 2 post margin to the CCP. The margin is composed of initial margin and variation margin16. The margin that clearing members post with the CCP has no direct relationship to the collateral of the SFT. The CCP uses the margin to cover all the risks arising from the transactions that it clears for the respective clearing members. The margin that the clearing members post to the CCP may also cover risks arising from transactions other than SFTs, such as trades in derivatives. 16 There might also be excess margin, which would be the part of the collateral in excess of the required level.

ESMA REGULAR USE
184
CCP interposing itself between the two counterparties that are clearing members Where a counterparty is not a clearing member itself, the margin it provides to the clearing member (see “margin*” in the case 2 below) may be different from the margin provided by the clearing member to the CCP. CCP interposing itself between the two counterparties that are not clearing members • Reporting of margin information In case there is a third type of margin exchange, counterparties should agree and consistently report it as either Initial Margin or Variation Margin. Initial Margin, Variation Margin and excess collateral are each reported in a single figure, composed of the gross (pre-haircut) value of all received/posted/pledged asset classes. In case there are no derivatives in the portfolio that is cleared, it is recommended to follow Counterparty 1 (Clearing member 1) Counterparty 2 (Clearing member 2) SFT collateral SFT loan CCP Margin Margin Case 1. CCP interposing itself between the two counterparties that are clearing members CM 1 CM 2 SFT collateral SFT loan CCP Margin Margin Counterparty 1 Counterparty 2 Margin* Margin* Case 2. CCP interposing itself between the two counterparties that are not clearing members

ESMA REGULAR USE
185 the base currency of the CCP, however, if there are derivatives reportable under EMIR, the same currency should be used. Margin information is applicable only to CCP-cleared SFTs. In the case shown in Table 100, the entity uses the same portfolio for collateralisation as under EMIR. The reporting counterparty, Counterparty J which is also a clearing member uses delegated reporting services provided by Counterparty D. It reports the amount of 1,000,000 EUR posted as initial margin and the amount of 300,000 EUR as variation margin posted to CCP O. The counterparty also reports excess collateral of 100,000 EUR.
Table 100 – Margin data
No Field Example XML Message
1 Reporting timestamp 2020-04-
22T16:41:07Z
<SctiesFincgRptgTxMrgnDataRpt>
<TradData>
<Rpt>
<TradUpd>

<LEI>CCCCCCCCCCCCCCCCCCCC
</LEI>
</RptgCtrPty>
<OthrCtrPty>

<LEI>BBBBBBBBBB1111111111</LEI>
</OthrCtrPty>
<NttyRspnsblForRpt>

<LEI>CCCCCCCCCCCCCCCCCCCC
</LEI>
</NttyRspnsblForRpt>
<RptSubmitgNtty>

<CollPrtflId>EMIRSFTRCODE1</CollPrtflId

<PstdMrgnOrColl> <InitlMrgnPstd Ccy="EUR">1000000</InitlMrgnPstd> <VartnMrgnPstd Ccy="EUR">300000</VartnMrgnPstd> 2 Event date 2020-04-23 3 Report submitting entity {LEI} of counterparty D 4 Reporting Counterparty {LEI} of counterparty J 5 Entity responsible for the report {LEI} of counterparty J 6 Other counterparty {LEI} of CCP O 7 Portfolio code EMIRSFTRC ODE1 8 Initial margin posted 1000000 9 Currency of the initial margin posted EUR 10 Variation margin posted 300000 11 Currency of the variation margins posted EUR 12 Initial margin received 13 Currency of the initial margin received 14 Variation margin received 15 Currency of the variation margins received 16 Excess collateral posted 100000

ESMA REGULAR USE
186
Table 100 – Margin data
No Field Example XML Message
17
Currency of the excess collateral posted
EUR
<XcssCollPstd Ccy="EUR">100000</XcssCollPstd>
</PstdMrgnOrColl>
<RcvdMrgnOrColl>
...
</RcvdMrgnOrColl>
</TradUpd>
</Rpt>
</TradData>
</SctiesFincgRptgTxMrgnDataRpt>
18 Excess collateral received
19
Currency of the excess collateral received
20 Action type MARU
5.6 Reuse data, cash reinvestment and funding sources
As highlighted in the RTS, the logic that underpins Table 4 of the Annex to the TS on reporting is different from the other tables, and will not be used for reconciliation, as this information cannot be linked to individual transactions. Instead, non-cash collateral reuse, cash collateral reinvestment and funding sources shall be reported as aggregates at reporting-entity level. Moreover, if data on collateral reuse, cash reinvestment or funding sources is reported at different points in time, only the first report should be reported with action type “NEWT” for a given combination of reporting counterparty and entity responsible for reporting, irrespective of which fields it includes. The subsequent reports for that combination should be made with the relevant action type. Collateral reuse Collateral reuse shall be reported using the formula agreed in the FSB framework17 and included in the RTS. Market participants do not usually distinguish between their own assets and the collateral they have received from counterparties (provided that the collateral securities are eligible for reuse). Therefore, the intuition behind the FSB formula is that entities should provide an estimate of the amount of collateral they are re-using, based on the share of collateral they have received compared with their own assets. The reporting obligation only applies to SFTs, which means that the collateral securities posted or received from other transactions are out of scope. In other words, collateral posted for margining purposes in derivatives transactions or any other transactions that are outside the scope of SFTR, as discussed in Section 4.2.1, should not be included in the formula. 17 FSB Non-cash collateral re-use: Measure and metrics. http://www.fsb.org/wp-content/uploads/Non-cash-Collateral-Re-UseMeasures-and-Metrics.pdf

ESMA REGULAR USE
187
This also means that the components of the reuse formula should not be reported separately to ESMA. Instead, reporting entities should only provide the estimate that results from the application of the formula at ISIN level. When no actual reuse has taken place, the reporting field should be left blank. When collateral is no longer reused, it shall be reported as “reuse Update” (REUU) with “0”. If reporting has been delegated, the counterparty to which reporting has been delegated is not responsible for the reporting of the estimated reuse of the collateral. NFCs are responsible for calculating the estimated reuse themselves and provide the estimate to the counterparty in charge of reporting in a timely manner. If counterparties prefer to report the actual reuse instead of the estimated reuse, they can do so. In the FSB framework, the term “collateral” is broadly defined by its economic function, i.e. to be understood as securities, regardless of the legal structure of the transaction. In terms of scope, this means that the collateral received, eligible for reuse captures:
a. securities received as collateral in reverse repos and BSB; b. securities borrowed in securities borrowing transactions;
c. securities received as collateral in securities lending transactions;
d. securities received as additional collateral to meet variation margin requirements originating from SFTs. Pledged initial margins that are isolated and immobilised (e.g. in the context of derivatives), and therefore not eligible for reuse, should not be included in the estimation. In margin lending, the eligibility of collateral for reuse does not only depend on the type of collateral arrangement used for the transaction but also on contractual limits (“rehypothecation limit”) agreed between the prime broker and its client. This limit calculated as a fixed percentage of the daily margin loan amount outstanding. For collateral to be reused, securities that have a right to rehypothecation need to be transferred first from the client account to the prime broker’s own account within the limit. ESMA proposes that for the calculation of the reuse formula, collateral received, eligible for reuse should exclude collateral securities that cannot be transferred to the prime broker’s own account due to the contractual limit on rehypothecation. The deposited but not assigned securities should not be included. Including such securities would lead to an overestimation of the amount of collateral that is actually being reused. In a similar way, collateral posted captures:
a. securities posted as collateral in repos and SBB b. securities on loan
c. securities posted as collateral in securities borrowing transactions
d. securities posted as collateral to meet variation margin requirements originating from SFTs.

ESMA REGULAR USE
188
Any security received or posted as part of transactions that are outside of the SFTR scope, including SFTs that are executed with ESCB counterparties, should be excluded from the reuse formula. CCPs should exclude from their reuse estimates the collateral securities that are transferred between clearing members as part of their central clearing activities. This concerns both the “Collateral received” and “Collateral reused” components of the formula. These collateral securities are not reused by the CCP per se, as the transfer of securities reflects rather the novation process that takes place when a central counterparty interposes itself between the two original counterparties. The collateral securities received as margin should be included in the estimates, as applicable, and CCPs are expected to report any reuse that takes place as part of their other activities. This includes treasury operations and any other type of facility or mechanism (e.g. reverse securities loans) that CCPs might have in place. Regarding the collateral reuse metrics18 included in the FSB framework, these will be computed directly by national or global authorities on the basis of the collateral reuse reported by entities. For the reuse rate, authorities will need to compute the denominator on the basis of data reported by entities in Table 2.
5.6.1.1 Reuse of securities by FC or non-SME NFC without delegation of reporting
Table 101 shows a case in which counterparty B reports value of reused securities with
ISIN IT00BH4HKS39 of the amount of 10,000,000 EUR.
Table 101 – Reuse of securities by FC or non-SME NFC without delegation of
reporting
No Field Example XML Message
1 Reporting timestamp 2020-04-
22T16:41:07Z <SctiesFincgRptgTxReusdCollDataRpt> <TradData> <Rpt> <CollReuseUpd> ... <RptgDtTm>2020-04- 22T16:41:07Z</RptgDtTm> <CtrPtyData> <RptSubmitgNtty>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</RptSubmitgNtty>
<RptgCtrPty>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</RptgCtrPty>
<NttyRspnsblForRpt>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
2 Event date 2020-04-23
3
Report submitting entity
{LEI} of counterparty
B
4
Reporting counterparty
{LEI} of counterparty
B
5
Entity responsible for the report
{LEI} of counterparty
B
6
Type of collateral component SECU
7 Collateral component {ISIN}
8
Value of reused collateral
189 See section 4 of the FSB framework on non-cash collateral re-use.

ESMA REGULAR USE
189
Table 101 – Reuse of securities by FC or non-SME NFC without delegation of
reporting
No Field Example XML Message
9
Estimated reuse of collateral 10000000 </NttyRspnsblForRpt> </CtrPtyData> <CollCmpnt> <Scty> <ISIN>IT00BH4HKS39</ISIN> <ReuseVal> <Estmtd Ccy="EUR">10000000</Estmtd> </ReuseVal> </Scty> </CollCmpnt> <EvtDt>2020-04-23</EvtDt> ... </CollReuseUpd> </Rpt> </TradData>

</SctiesFincgRptgTxReusdCollDataRpt> 10 Reused collateral currency EUR 18 Action type REUU 5.6.1.2 Reuse of securities by FC or non-SME NFC with delegation of reporting Table 102 shows the case in which counterparty A delegates the reporting to counterparty B. It reports the value of reused securities with ISIN IT00BH4HKS39 of the amount of 10,000,000 EUR. Table 102 – Reuse of securities by FC or non-SME NFC with delegation of reporting No Field Example XML Message 1 Reporting timestamp 2020-04- 22T16:41:07Z <SctiesFincgRptgTxReusdCollDataRpt> <TradData> <Rpt> <CollReuseUpd> ... <RptgDtTm>2020-04- 22T16:41:07Z</RptgDtTm> <CtrPtyData> <RptSubmitgNtty>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</RptSubmitgNtty>
<RptgCtrPty>

<LEI>12345678901234500000</LEI>
</RptgCtrPty>
<NttyRspnsblForRpt>
2 Event date 2020-04-23
3
Report submitting entity
{LEI} of counterparty
B
4
Reporting counterparty
{LEI} of counterparty
A
5
Entity responsible for the report
{LEI} of counterparty
A
6
Type of collateral component SECU
7 Collateral component {ISIN}

ESMA REGULAR USE
190
Table 102 – Reuse of securities by FC or non-SME NFC with delegation of reporting
No Field Example XML Message
8
Value of reused collateral

</SctiesFincgRptgTxReusdCollDataRpt> 9 Estimated reuse of collateral 10000000 10 Reused collateral currency EUR 18 Action type REUU 5.6.1.3 Reuse of securities by SME NFC with one counterparty Table 103 shows the case in which counterparty C is SME-NFC and it has concluded SFTs with only one entity - counterparty B (FC). Counterparty B reports the value of reused securities with ISIN IT00BH4HKS39 of the amount of 10,000,000 EUR. Table 103 – Reuse of securities by SME NFC with one counterparty No Field Example XML Message 1 Reporting timestamp 2020-04- 22T16:41:07Z <SctiesFincgRptgTxReusdCollDataRpt> <TradData> <Rpt> <CollReuseUpd> ... <RptgDtTm>2020-04- 22T16:41:07Z</RptgDtTm> <CtrPtyData> <RptSubmitgNtty>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</RptSubmitgNtty>
<RptgCtrPty>

<LEI>123456789ABCDEFGHIJK</LEI>
2 Event date 2020-04-23
3
Report submitting entity
{LEI} of counterparty
B
4
Reporting counterparty
{LEI} of counterparty
C
5
Entity responsible for the report
{LEI} of counterparty
B
6
Type of collateral component SECU

ESMA REGULAR USE
191
Table 103 – Reuse of securities by SME NFC with one counterparty
No Field Example XML Message
7 Collateral component {ISIN} </RptgCtrPty> <NttyRspnsblForRpt> <LEI> ABCDEFGHIJKLMNOPQRST</LEI> </NttyRspnsblForRpt> </CtrPtyData> <CollCmpnt> <Scty> <ISIN>IT00BH4HKS39</ISIN> <ReuseVal> <Estmtd Ccy="EUR">10000000</Estmtd> </ReuseVal> </Scty> </CollCmpnt> <EvtDt>2020-04-23</EvtDt> ... </CollReuseUpd> </Rpt> </TradData>

</SctiesFincgRptgTxReusdCollDataRpt> 8 Value of reused collateral 9 Estimated reuse of collateral 10000000 10 Reused collateral currency EUR 18 Action type REUU 5.6.1.4 Reuse of securities by SME NFC with several counterparties Table 104 and Table 105 contain the information that should be reported regarding the reuse by SME NFC with several counterparties. In this example, there are two tables. However, there can be as many tables as counterparties with which the SME NFC has entered into SFTs and has subsequently reused the collateral. In this case, counterparty C is SME-NFC, and it has concluded SFTs with two entities - counterparty B and counterparty D. Counterparty B reports the value of reused securities with ISIN IT00BH4HKS39 of the amount of 10,000,000 EUR in Table 104. Counterparty D reports the value of reused securities with ISIN FR00BH4HKS3 of the amount of 2,000,000 EUR in Table 105. Table 104 – Reuse of securities by SME NFC with several counterparties (1) No Field Example XML Message 1 Reporting timestamp 2020-04- 22T16:41:07Z <SctiesFincgRptgTxReusdCollDataRpt> <TradData> <Rpt> <CollReuseUpd> ... <RptgDtTm>2020-04- 22T16:41:07Z</RptgDtTm> 2 Event date 2020-04-23 3 Report submitting entity {LEI} of counterparty B

ESMA REGULAR USE
192
Table 104 – Reuse of securities by SME NFC with several counterparties (1)
No Field Example XML Message
4
Reporting counterparty
{LEI} of counterparty
C
<CtrPtyData>
<RptSubmitgNtty>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</RptSubmitgNtty>
<RptgCtrPty>

<LEI>123456789ABCDEFGHIJK</LEI>
</RptgCtrPty>
<NttyRspnsblForRpt>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</NttyRspnsblForRpt>
</CtrPtyData>
<CollCmpnt>
<Scty>
<ISIN> IT00BH4HKS39</ISIN>
<ReuseVal>
<Estmtd Ccy="EUR">10000000</Estmtd>
</ReuseVal>
</Scty>
</CollCmpnt>
<EvtDt>2020-04-23</EvtDt>
...
</CollReuseUpd>
</Rpt>
</TradData>

</SctiesFincgRptgTxReusdCollDataRpt> 5 Entity responsible for the report {LEI} of counterparty B 6 Type of collateral component SECU 7 Collateral component {ISIN} 8 Value of reused collateral 9 Estimated reuse of collateral 10000000 10 Reused collateral currency EUR 18 Action type REUU Table 105 – Reuse of securities by SME NFC with several counterparties (2) No Field Example XML Message 1 Reporting timestamp 2020-04- 22T18:41:07Z <SctiesFincgRptgTxReusdCollDataRpt> <TradData> <Rpt> <CollReuseUpd> ... <RptgDtTm>2020-04- 22T16:41:07Z</RptgDtTm> <CtrPtyData> <RptSubmitgNtty>

<LEI>11223344556677889900</LEI>
</RptSubmitgNtty>
<RptgCtrPty>
2 Event date 2020-04-23
3
Report submitting entity
{LEI} of counterparty
D
4
Reporting counterparty
{LEI} of counterparty
C
5
Entity responsible for the report
{LEI} of counterparty
D

ESMA REGULAR USE
193
Table 105 – Reuse of securities by SME NFC with several counterparties (2)
No Field Example XML Message
6
Type of collateral component SECU
<LEI>123456789ABCDEFGHIJK</LEI>
</RptgCtrPty>
<NttyRspnsblForRpt>

</SctiesFincgRptgTxReusdCollDataRpt> 7 Collateral component {ISIN} 8 Value of reused collateral 9 Estimated reuse of collateral 2000000 10 Reused collateral currency EUR 18 Action type REUU Cash collateral reinvestment Counterparties should report cash collateral reinvestment when cash is used as collateral in SLB transactions and reinvested, either directly by the lender (collateral taker) or on behalf of the lender by an agent. The reporting of reinvestment is irrespective of the type of financial counterparty involved, e.g. broker, dealer, investment firm, etc. It is related to its position in the relevant SFTs. The type of reinvestment (Field 4.12) and reinvested cash amount (Field 4.13) should be broken down by currency of the cash collateral reinvested (Field 4.14). Since counterparties are expected to report a single reinvestment rate without a breakdown by currency, the reinvestment rate (Field 4.11) should be calculated as the weighted-average rate based on the reinvested cash amount (Field 4.13) following conversion into the reinvested cash currency (Field 4.14). Cash received for margining purposes in non-centrally cleared SFTs and subsequently reinvested is also within scope. Cash received from margin lending and subsequently reinvested should not be reported as cash collateral reinvestment. For the reporting of cash collateral in the context of margin lending, see Section 5.3.16.

ESMA REGULAR USE
194
In the case where the reporting counterparty cannot distinguish between its own cash and the cash received as cash collateral, the cash reinvestment amount should be calculated using the same methodology as for non-cash collateral. The cash collateral received by CCPs (as part of their margining requirements) and the cash collateral reinvestments are already publicly available from the CPMI-IOSCO Public Quantitative Disclosures.19 Although reporting under SFTR takes place on a daily basis (rather than on a quarterly basis as it is the case for the Public Quantitative Disclosures), the comparable level of granularity and type of information collected does not warrant additional reporting. CCP cash collateral reinvestment is, therefore, excluded. Finally, with regards to the reporting of cash collateral reinvestment, the counterparties should also take into account any subsequent guidance or clarification provided in this context by the FSB.
5.6.2.1 Reinvestment of cash by FC or non-SME NFC without delegation of reporting
Table 106 shows the case in which counterparty B reports its own cash reinvestment of
100,000 EUR at 1.5% rate in the repo market.
Table 106 - Reinvestment of cash by FC or non-SME NFC without delegation of
reporting
No Field Example XML Message
1 Reporting timestamp 2020-04-
22T16:41:07Z
<SctiesFincgRptgTxReusdCollDataRpt>
<TradData>
<Rpt>
<CollReuseUpd>
...
<RptgDtTm>2020-04-
22T16:41:07Z</RptgDtTm>
<CtrPtyData>
<RptSubmitgNtty>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</RptSubmitgNtty>
<RptgCtrPty>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</RptgCtrPty>
<NttyRspnsblForRpt>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</NttyRspnsblForRpt>
</CtrPtyData>
<CollCmpnt>
2 Event date 2020-04-23
3
Report submitting entity
{LEI} of counterparty
B
4
Reporting counterparty
{LEI} of counterparty
B
5
Entity responsible for the report
{LEI} of counterparty
B
11 Reinvestment Rate 1.5
12 Type of re-invested cash investment REPM 13 Re-invested cash amount 100000 14 Re-invested cash currency EUR 19 CPMI-IOSCO, February 2015, “Public quantitative disclosure standards for central counterparties”:
https://www.bis.org/cpmi/publ/d125.pdf

ESMA REGULAR USE
195
Table 106 - Reinvestment of cash by FC or non-SME NFC without delegation of
reporting
No Field Example XML Message
18 Action type REUU
<Csh>
<RinvstdCsh>
<Tp>REPM</Tp>
<RinvstdCshAmt Ccy="EUR">100000</RinvstdCshAmt>
</RinvstdCsh>

</SctiesFincgRptgTxReusdCollDataRpt> 5.6.2.2 Reinvestment of cash by FC or non-SME NFC with delegation of reporting Table 107 shows the case in which, counterparty A delagates the reporting of its cash reinvestment to counterparty B. Counterparty B reports cash reinvestment of 100,000 EUR at 1% rate in the repo market. Table 107 - Reinvestment of cash by FC or non-SME NFC with delegation of reporting No Field Example XML Message 1 Reporting timestamp 2020-04- 22T16:41:07Z <SctiesFincgRptgTxReusdCollDataRpt> <TradData> <Rpt> <CollReuseUpd> ... <RptgDtTm>2020-04- 22T16:41:07Z</RptgDtTm> <CtrPtyData> <RptSubmitgNtty>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</RptSubmitgNtty>
<RptgCtrPty>

<LEI>12345678901234500000</LEI>
2 Event date 2020-04-23
3
Report submitting entity
{LEI} of counterparty
B
4
Reporting counterparty
{LEI} of counterparty
A
5
Entity responsible for the report
{LEI} of counterparty
A
11 Reinvestment Rate 1

ESMA REGULAR USE
196
Table 107 - Reinvestment of cash by FC or non-SME NFC with delegation of
reporting
No Field Example XML Message
12 Type of re-invested cash investment REPM </RptgCtrPty> <NttyRspnsblForRpt>

</SctiesFincgRptgTxReusdCollDataRpt> 13 Re-invested cash amount 100000 14 Re-invested cash currency EUR 18 Action type REUU 5.6.2.3 Reinvestment of cash by SME NFC with one counterparty Table 108 shows the case in which counterparty C is SME-NFC, and it has concluded SFTs with only one entity - counterparty B. Counterparty B reports cash collateral reinvestment of 100,000 EUR at 1% rate in the repo market. Table 108 - Reinvestment of cash by SME NFC with one counterparty No Field Example XML Message 1 Reporting timestamp 2020-04- 22T16:41:07Z <SctiesFincgRptgTxReusdCollDataRpt> <TradData> <Rpt> <CollReuseUpd> 2 Event date 2020-04-23

ESMA REGULAR USE
197
Table 108 - Reinvestment of cash by SME NFC with one counterparty
No Field Example XML Message
3
Report submitting entity
{LEI} OF counterparty
B
...
<RptgDtTm>2020-04-
22T16:41:07Z</RptgDtTm>
<CtrPtyData>
<RptSubmitgNtty>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</RptSubmitgNtty>
<RptgCtrPty>

<LEI>123456789ABCDEFGHIJK</LEI>
</RptgCtrPty>
<NttyRspnsblForRpt>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</NttyRspnsblForRpt>
</CtrPtyData>
<CollCmpnt>
<Csh>
<RinvstdCsh>
<Tp>REPM</Tp>
<RinvstdCshAmt Ccy="EUR">100000</RinvstdCshAmt>
</RinvstdCsh>

</SctiesFincgRptgTxReusdCollDataRpt> 4 Reporting counterparty {LEI} of counterparty C 5 Entity responsible for the report {LEI} of counterparty B 11 Reinvestment Rate 1 12 Type of re-invested cash investment REPM 13 Re-invested cash amount 100000 14 Re-invested cash currency EUR 18 Action type REUU 5.6.2.4 Reinvestment of cash by SME NFC with several counterparties Table 109 and Table 110 contain the information that should be reported regarding the collateral reinvestment by SME NFC with several counterparties. In this example, there are two tables. However, there can be as many tables as counterparties with which the SME NFC has entered into SFTs and has subsequently reinvested the cash collateral.

ESMA REGULAR USE
198
In this case, counterparty C is SME-NFC, and it has concluded SFTs with two entities - counterparty B and counterparty D. Counterparty B reports the amount of 100,000 EUR as reinvested cash collateral in Table 109. Counterparty D reports the amount of 100,000 EUR as reinvested cash collateral in Table 110.
Table 109 - Reinvestment of cash by SME NFC with several counterparties (1)
No Field Example XML Message
1 Reporting timestamp 2020-04-
22T16:41:07Z
<SctiesFincgRptgTxReusdCollDataRpt>
<TradData>
<Rpt>
<CollReuseUpd>
...
<RptgDtTm>2020-04-
22T16:41:07Z</RptgDtTm>
<CtrPtyData>
<RptSubmitgNtty>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</RptSubmitgNtty>
<RptgCtrPty>

<LEI>123456789ABCDEFGHIJK</LEI>
</RptgCtrPty>
<NttyRspnsblForRpt>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</NttyRspnsblForRpt>
</CtrPtyData>
<CollCmpnt>
<Csh>
<RinvstdCsh>
<Tp>REPM</Tp>
<RinvstdCshAmt Ccy="EUR">100000</RinvstdCshAmt>
</RinvstdCsh>

</SctiesFincgRptgTxReusdCollDataRpt> 2 Event date 2020-04-23 3 Report submitting entity {LEI} of counterparty B 4 Reporting counterparty {LEI} of counterparty C 5 Entity responsible for the report {LEI} of counterparty B 11 Reinvestment Rate 1 12 Type of re-invested cash investment REPM 13 Re-invested cash amount 100000 14 Re-invested cash currency EUR 18 Action type REUU

ESMA REGULAR USE
199
Table 110 - Reinvestment of cash by SME NFC with several counterparties (2)
No Field Example XML Message
1 Reporting timestamp 2020-04-
22T16:41:07Z
<SctiesFincgRptgTxReusdCollDataRpt>
<TradData>
<Rpt>
<CollReuseUpd>
...
<RptgDtTm>2020-04-
22T16:41:07Z</RptgDtTm>
<CtrPtyData>
<RptSubmitgNtty>

<LEI>123456789ABCDEFGHIJK</LEI>
</RptgCtrPty>
<NttyRspnsblForRpt>

</SctiesFincgRptgTxReusdCollDataRpt> 2 Event date 2020-04-23 3 Report submitting entity {LEI} of counterparty D 4 Reporting counterparty {LEI} of counterparty C 5 Entity responsible for the report {LEI2} of counterparty D 11 Reinvestment Rate 1 12 Type of re-invested cash investment REPM 13 Re-invested cash amount 100000 14 Re-invested cash currency EUR 18 Action type REUU

ESMA REGULAR USE
200
Zero non-cash collateral reuse and cash reinvestment
Table 111 illustrates the reporting of fields in case there is neither reuse of non-cash
collateral nor reinvestment of cash collateral. Counterparties should, therefore, report as in Table 111. In this case, Field 12 of Table 4 of the RTS “Type of re-invested cash investment” should be reported as “other”.
Table 111 – Zero cash collateral reuse
No Field Example XML Message
1 Reporting timestamp 2020-04-
22T16:41:07Z
<SctiesFincgRptgTxReusdCollDataRpt>
<TradData>
<Rpt>
<CollReuseUpd>
...
<RptgDtTm>2020-04-
22T16:41:07Z</RptgDtTm>
<CtrPtyData>
<RptSubmitgNtty>

<LEI>123456789ABCDEFGHIJK</LEI>
</RptgCtrPty>
<NttyRspnsblForRpt>

</SctiesFincgRptgTxReusdCollDataRpt> 2 Event date 2020-04-23 3 Report submitting entity {LEI} of counterparty D 4 Reporting counterparty {LEI} of counterparty C 5 Entity responsible for the report {LEI2} of counterparty D 6 Type of collateral component CASH 12 Type of re-invested cash investment OTHR 13 Re-invested cash amount 0 14 Re-invested cash currency EUR

ESMA REGULAR USE
201
Funding sources
The fields pertaining to funding sources only should be reported when there is a margin loan or short market value outstanding. The reporting counterparties or entities responsible for reporting should provide this information at reporting-counterparty level, not at individual transaction level.
Table 112 shows the case in which counterparty B reports an amount of 5,000,000 EUR
as funding sources from the repo market to finance margin loans.
Table 112 - Funding sources
No Field Example XML Message
1 Reporting timestamp 2020-04-
22T16:41:07Z
<SctiesFincgRptgTxReusdCollDataRpt>
<TradData>
<Rpt>
<Crrctn>
<RptgDtTm>2020-04-
22T16:41:07Z</RptgDtTm>
<CtrPtyData>
<RptSubmitgNtty>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</RptSubmitgNtty>
<RptgCtrPty>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</RptgCtrPty>
<NttyRspnsblForRpt>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</NttyRspnsblForRpt>
</CtrPtyData>
<CollCmpnt>
...
</CollCmpnt>
<EvtDt>
2020-04-23
</EvtDt>
<FndgSrc>
<Tp>REPO</Tp>
<MktVal Ccy="EUR">5000000</MktVal>
</FndgSrc>
</Crrctn>
</Rpt>
</TradData>

</SctiesFincgRptgTxReusdCollDataRpt> 2 Event date 2020-04-23 3 Report submitting entity {LEI} of counterparty B 4 Reporting counterparty {LEI} of counterparty B 5 Entity responsible for the report {LEI} of counterparty B 15 Funding sources REPO 16 Market value of the funding sources 5000000 17 Funding sources currency EUR 18 Action type REUU

ESMA REGULAR USE
202
6 Rejection feedback
Article 1(1) RTS on data collection provides the different checks that a TR needs to carry
out to ensure the correctness and completeness of SFT data reported pursuant to Article 4 SFTR. The TR should provide rejection feedback in accordance with the following rejection categories:
a. Schema validation of a submission as per Article 1(1)(b) RTS on data collection b. Authorization/permission of a report submitting entity as per Article 1(1)(c) RTS on data collection
c. Logical validation of a submission as per Articles 1(1)(d) to 1(1)(j) RTS on data
collection d. Business rules or content validation of a submission in accordance with Article 1(1)(k) RTS on data collection and included in the validation rules and as provided in these Guidelines It is worth noting that the authentication of an entity will be performed by the TR at the time of connection to the TR system; Hence no specific rejection feedback will be provided. The TR should verify compliance of the file with the XML schema (syntax of the whole file and specific SFT reports). If the file is not compliant, the whole file (all transactions included in the file) is rejected, and the reason will be that the file is “corrupted”. As Article 1(c) of the RTS on data collection states that this check should take place as
part of the verification of reports made to the TR and whilst the permissioning relationship
can be established at onboarding, the authorization to report should also be checked at a submission level and a TR should reject any submission failing this check with an appropriate feedback message. The TRs should use the relevant ISO 20022 XML message to provide the validation feedback to the entities that are onboarded to that TR. The TRs should use the codes included in the reporting fields when communication rejections to the counterparties. Following receipt of a rejection, the reporting counterparties or ERR should, either directly or through a RSE, submit correct and complete reports by the reporting timeline as defined under Article 4(1) SFTR. Where a file contains 3 transactions, but the transactions fail validations the statistics show the file as accepted with 3 rejected transactions. Where a data file submitted by the reporting counterparty, the entity responsible for reporting, or the report submitting entity contains a serious schema error and the transactions cannot be validated, this will be reported as 1 file rejection. Further to the above information, TRs will provide to each reporting counterparty, entity responsible for reporting or report submitting entity, as applicable, with an end of day report (auth.084.001.01) containing the following information:

ESMA REGULAR USE
203
Table 113 – Rejection feedback
No. Field
Details to be reported
XML Message
1 Number of files received Numeric values <SctiesFincgRptgTxStsAdvc> <TxRptStsAndRsn> <Rpt> <RptSttstcs> <TtlNbOfRpts>2</TtlNbOfRpts>

<TtlNbOfRptsRjctd>1</TtlNbOfRptsRjctd>
<NbOfRptsRjctdPerErr>
<DtldNb>1</DtldNb>
<RptSts>
<MsgRptId>ReportID</MsgRptId>
<Sts>RJCT</Sts>
<DtldVldtnRule>
<Id>RuleID</Id>
<Desc>Rule description</Desc>
<SchmeNm>
<Cd>1</Cd>
</SchmeNm>
</DtldVldtnRule>
</RptSts>
</NbOfRptsRjctdPerErr>
</RptSttstcs>
<TxSttstcs>
<TtlNbOfTxs>2</TtlNbOfTxs>

<UnqTradIdr>UTI1</UnqTradIdr>
<MstrAgrmt>
<Tp>
<Tp>OTHR</Tp>
</Tp>
<Vrsn>2019</Vrsn>
</MstrAgrmt>
2 No. of files accepted Numeric values
3 No. of files rejected Numeric values
4 File identification Textual value
5 Rejection reason Error code
6 Rejection description Error description
7 Number of SFTs received Numeric values
8 Number of SFTs accepted Numeric values
9 Number of SFT s rejected Numeric values
10 Identification of the SFT
11 Reporting counterparty Table A Field 3
12 UTI Table B Field 1
13 Other counterparty Table A Field 11
14 Master agreement type Table B Field 9
15 Rejection reason Error codes
16
Rejection description Error description

ESMA REGULAR USE
204
This will ensure that in case the reporting counterparty or the entity responsible for reporting are not reporting directly to the TR, but they have a view-only account, they should be able to have a detailed understanding on their compliance with the reporting obligation under SFTR. 7 Reconciliation feedback When performing the inter-TR reconciliation process the TRs pair loans, then (i) reconcile the loans on the loan reconcilable fields and in parallel (ii) reconcile the collateral on the collateral reconcilable fields. The collateral thus will not be paired regardless of whether it is trade based collateral or net exposure collateral. Only loans should be paired, and the collateral associated with the loans for both trade-based collateral or net exposure-based collateral will be matched. The TRs should not pair collateral and, in that case, if one side does not provide net exposure collateral, then every collateral asset will be reported in the Reconciliation Results Status report under “Not Matched”, and the Collateral Reconciliation Status will be “Not Reconciled”.
Table 114 - Reconciliation categories
Reconciliation categories Allowable values
Reporting type Single-sided/dual-sided
Reporting requirement for both counterparties Yes/No Pairing Status Paired/unpaired Loan reconciliation status Reconciled/not reconciled Collateral reconciliation status Reconciled/not reconciled Further modifications: Yes/No Following the receipt and acceptance, following verification, of a message with action type “EROR”, the TR should remove a given SFT from the reconciliation with immediate effect, i.e. from the immediately following reconciliation cycle. Furthermore, no SFT can be revived, hence an SFT should be excluded from reconciliation 30 days following the maturity date or early termination of it, i.e. reporting with action type “Termination/Early termination”, or “Position component” in accordance </Tx> </TxId> <Sts>RJCT</Sts> <DtldVldtnRule> <Id>RuleID</Id> <Desc>Rule description</Desc> </DtldVldtnRule> </NbOfTxsRjctd> </TxSttstcs> </Rpt> </TxRptStsAndRsn> </SctiesFincgRptgTxStsAdvc>

ESMA REGULAR USE
205 with the conditions under Article 2(2)(h) of the RTS on verification. Furthermore, in the case of the reconciliation of the details of collateral, these messages differ from loan messages in that there are no maturity dates. For net exposure-based collateral this means that the date of it is related to the date of the loan side of the SFT. Hence a TR should seek to reconcile this information until thirty days after the termination or maturity of the last loan that is included in the net exposure collateralisation. Moreover, the collateral reconciliation status for net exposure collateral will be repeated for all SFTs included in the net-exposure collateralisation. When there is reporting requirement for both counterparties, they should ensure that the SFTs reported have pairing status as “Paired”, loan reconciliation status as “Reconciled” and “Collateral reconciliation status as “Reconciled”. To facilitate this, the TRs will be providing them with the following report containing detailed information on the reconciliation status of each SFTs that they have reported and that is subject to reconciliation:

Reconciliation data
Table 115 - Reconciliation Feedback
No. Field
Details to be reported
XML Message
1
Reporting counterparty
Unique key
Table A Field 3 <SctiesFincgRptgRcncltnStsAdvc>

<LEI>ABCDEFGHIJKLMNOPQRST</
LEI>
</OthrCtrPty>

<UnqTradIdr>UTI10</UnqTradIdr>
</TxId>
<Modfd>true</Modfd>
<RcncltnSts>
<RptgData>
<NotMtchd>
<CtrPty1>
2 UTI Table B Field 1
3
Other counterparty
Table A Field
11
4
Master agreement type
Table B Field 9
Report status
Paired/Reconcil ed
Reporting timestamp
Information on the last reporting timestamp pertaining to the SFT that is reconciled
Table A Field 1
Modification status
Information if the transaction subject of reconciliati on was modified True/False No Reconciliati on required Indication that the transaction is not True/False

ESMA REGULAR USE
206
Table 115 - Reconciliation Feedback
No. Field
Details to be reported
XML Message subject of reconciliati on

<LEI>AAAAAAAAAAAAAAAAAAAA</
LEI>
</CtrPty1>
<CtrPty2>

<LEI>EEEEEEEEEEEEEEEEEEEE</
LEI>
</CtrPty2>
<MtchgCrit>
<LnMtchgCrit>
<TermntnDt>
<Val1>2019-04-20
</Val1>
<Val2>2019-04-21
</Val2>
</TermntnDt>
</LnMtchgCrit>
<CollMtchgCrit>
<CmpntTp>
<Scty>
<Qty>

</SctiesFincgRptgRcncltnStsAdvc> Matching status True/False Loan reconciliatio n status reconciled/not reconciled Reportable loan fields subject of reconciliatio n Only not reconciled fields are to be reported, both values subject of reconciliati on shall be reported Loan fields of Table 1 of RTS on data verification Collateral reconciliatio n status reconciled/not reconciled Reportable collateral fields subject of reconciliatio n Only not reconciled fields are to be reported, both values subject of reconciliati on shall be reported Collateral fields of Table 1 of RTS on data verification Following the removal of SFTs from reconciliation, these SFTs should also be removed from the reconciliation reports provided to counterparties and authorities. The TRs should retain in their systems the latest reconciliation status of these SFTs. 8 Missing collateral feedback It should be indicated whether the SFT is collateralised or not. When the SFT is collateralised, collateral information needs to be provided as soon as it is known.

ESMA REGULAR USE
207
When collateral information is not known yet at the time of reporting, the specific collateral details, i.e. Fields 2.75 to 2.94, are not populated. Instead, Field 2.96 is populated, either with a valid ISIN of the collateral basket or with a “NTAV”. The SFT report will be accepted. At the end of the day, pursuant to Article 3(c) of the RTS of data collection the TR shall generate a report containing “the Unique Transaction Identifiers (UTIs) of the SFTs for which Field 72 of Table 2 of Annex I to Implementing Regulation (EU) 2019/363 is reported as “false”, and information about the collateral in Fields 73 to 96 of the same Table has not yet been reported”. Given that the information about individual collateral components is contained in Fields 2.75 to 2.94, to remind entities to provide specific collateral information, the TR should generate the “Missing Collateral Report” containing the UTIs of SFTs that the counterparty has reported as collateralised and for which only Field 2.96 is reported. Stemming from the expectation that for intraday SFTs collateral would not be allocated, to ensure efficiency and usability of this data by counterparties, the TRs should include in this report the SFTs that fulfil all the below conditions:
a. SFTs where the Field 2.72 is populated with “false” and only Field 2.96 is reported; b. SFTs where the date part of the execution timestamp and the maturity date or the termination date are different;
c. SFTs that are subject to reconciliation.
9 How to provide information to authorities
9.1 Timelines to setting up data access
With regards to the timeliness of the access to data, TRs should establish their internal processes in such a way that, in accordance with Article 4(1)(f), an authority has direct and immediate access to details of SFTs within thirty days after it submitted its request for setting up access. The TRs should use the information provided by the authorities in the relevant form provided in the RTS on data access. The SFT data on branches and subsidiaries should be provided to the authorities also by taking into account the existing LEI relationship data. Furthermore, when providing access to data reported by counterparties under Article 4 of SFTR, the TRs should include in the activity and state files SFTs reported at transaction and at position level. With regards to the requirements on Article 4(2)(k) RTS on data access, the access should be provided to commodities, in case the relevant member states of those are identifiable. With regards to the requirements on Article 4(2)(n) RTS on data access, where the access should be provided to SFTs in the currency issued by the central bank, the data access should cover all the non-valuation fields where the currency is being used. If several authorities issue the same currency, as it is the case of the euro, they all should have access to those SFTs.

ESMA REGULAR USE
208
With regards to the requirements on Article 4(2)(o) RTS on data access, where the access should be provided to SFTs relating to the benchmarks that are provided by an administrator for which the entity in Article 12(2) SFTR has a mandate, the TR should ensure receiving the information attesting the capacity relevant administrators for those benchmarks.
9.2 Operational arrangements for data access
With regards to the details of SFTs reported in accordance with Tables 1 to 4 of the Annex to RTS on reporting, including the latest trade states of SFTs that have not matured or which have not been the subject of reports with action types “Error”, “Termination/Early termination”, or “Position component” as referred to in Field 98 of Table 2 of Annex I to ITS on reporting, the TRs should use the following XML templates. The relevant trade activity messages are auth.052.001.01 (counterparty, loan and collateral), auth.070.001.01 (margin), auth.071.001.01 (collateral reuse). The relevant state messages are 079.001.01 (counterparty, loan and collateral), auth.085.001.01 (margin), auth.086.001.01 (collateral reuse). These templates have been updated with regards to update and clarification on the templates relating to (i) Reporting of Repo Collateral and BSB Collateral, (ii) Reporting of Margin Lending Collateral, (iii) Net Exposure Collateral Reporting, (iv) Multiple Collateral Assets. Moreover, the same templates are to be used when the TRs prepare the response to both recurrent queries and ad-hoc ones for loan and collateral data. The TRs are not required to provide access to margin and reuse data through ad-hoc queries, as there are no queryable fields for either of the two reports.
Table 116 – SFT report – counterparty, loan and collateral data
No. Field
Details to be reported XML schema
1 Reportable field
Table 1 Field 1 to
Field 18
Table 2 Field 1 to
Field 99
<SctiesFincgRptgTxStatRpt>
<Stat>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
...
</LnData>
<CollData>
...
</CollData>
<RcncltnFlg>
...
</RcncltnFlg>
<CtrctMod>
...
</CtrctMod>

ESMA REGULAR USE
209
Table 116 – SFT report – counterparty, loan and collateral data
No. Field
Details to be reported XML schema
...
</Stat>
...
</SctiesFincgRptgTxStatRpt>
In addition, margin and reuse data are reported at end-of-data state level by counterparties, ERR or RSE. This does not preclude a reporting counterparty an ERR or a RSE to report this information in several batches. The TR should provide to the authorities in the activity report auth.070.001.01 (margin), all the SFT margin reports that were submitted in a given day and in the state report auth.085.001.01 the latest state of all SFT margins that were reported for the relevant event date or in case no information was reported for a given date, the latest reported information.
Table 117 – SFT report – margin data
No. Field
Details to be reported XML schema
1 Reportable field
Table 3
Field 1 to
Field 20
<SctiesFincgRptgMrgnDataTxStatRpt>
<Stat>
...
<CtrPty>
...
</CtrPty>
<CollPrtflId>...</CollPrtflId>
<PstdMrgnOrColl>
...
</PstdMrgnOrColl>
<RcvdMrgnOrColl>
...
</RcvdMrgnOrColl>
<RcncltnFlg>
...
</RcncltnFlg>
<CtrctMod>
...
</CtrctMod>
...
</Stat>
...
</SctiesFincgRptgMrgnDataTxStatRpt>
When providing access to reuse data with regards to SME NFC, the TRs should provide the authorities with all the information reported with action types “NEWT” and “REUU” for

ESMA REGULAR USE
210 the reporting counterparty for the given event date. TRs should use the fields “Entity responsible for reporting” and “Report submitting entity” to determine the applicable instances. When for a given reporting counterparty there are more than one entity responsible for reporting, and these use the same report submitting entity, the TRs should provide all the collateral reuse reports for that event date that were submitted for the reporting counterparty. The TR should provide to the authorities in the activity report auth.071.001.01, all the SFT collateral reuse reports that were submitted in a given day and in the state report auth.086.001.01 the latest state of all SFT collateral reuse reports that were reported for the relevant event date or in case no information was reported for a given date, the latest reported information.
Table 118 – SFT report – reuse data
No. Field
Details to be reported XML schema
1 Reportable field
Table 4
Field 1 to Field
18
<SctiesFincgRptgReusdCollDataTxStatRpt>
<Stat>
...
<CtrPtyData>
...
</CtrPtyData>
<CollCmpnt>
...
</CollCmpnt>
...
<FndgSrc>
...
</FndgSrc>
<RcncltnFlg>
...
</RcncltnFlg>
<CtrctMod>
...
</CtrctMod>
...
</Stat>
...
</SctiesFincgRptgReusdCollDataTxStatRpt>
With regards to the relevant details of SFT reports rejected by the TR, including any SFT reports rejected during the previous working day and the reasons for their rejection, as specified in accordance with Table 2 of Annex I to RTS on data verification, the TRs should use the same XML template as in Table 113 – Rejection feedback.

ESMA REGULAR USE
211
Table 119 – Rejections report
No. Field
Additional information
Details to be reported
XML schema
1 Number of files received Numeric values
2 No. of files accepted Numeric values
3 No. of files rejected Numeric values
4 File identification Textual value
5 Rejection reason Error code
6 Rejection description Error description
7 Number of SFT received Numeric values
8 No. of SFT accepted Numeric values
9 No. of SFT s rejected Numeric values
10
Identification of the
SFT
11
Reporting counterparty
Unique key of the SFT
Table 1 Field 3
12 UTI Table 2 Field 1
13 Other counterparty Table 1 Field 11
14
Master agreement type Table 2 Field 9
15 Rejection reason Error codes
16 Rejection description Error description
With regards to the reconciliation status of all reported SFTs for which the TR has carried out the reconciliation process in accordance with RTS on data verification (except those SFTs that have expired or for which SFT reports with action types “Error”, “Termination/Early termination”, or “Position component” were received more than a month before the date on which the reconciliation process takes place), the TR should use the same XML template as in Table 115 - Reconciliation Feedback. The XSD has been updated to allow for the provision of reconciliation values for multiple collateral elements to both counterparties, ERR, report submitting entity and authorities. The collateral reconciliation results should be reported only once for all trades that fall under the same master agreement type, and net exposure of collateralization is TRUE.
Table 120 – SFT reconciliation status report
No. Field Additional information
Details to be reported
XML schema
1 Reporting counterparty
Unique key
Table 1 Field 3
2 UTI Table 2 Field 1
3 Other counterparty Table 1 Field 11
4 Master agreement type Table 2 Field 9
5 Report status Paired/Reconciled
7 Modification status
Information if the transaction subject of reconciliation was modified True/False

ESMA REGULAR USE
212
Table 120 – SFT reconciliation status report
No. Field Additional information
Details to be reported
XML schema
8
No Reconciliation required
Indication that the transaction is not subject of reconciliation True/False 9 Matching status True/False 10 Loan reconciliation status reconciled/not reconciled 11 Reportable loan fields subject of reconciliation Only not reconciled fields are to be reported, both values subject of reconciliation shall be reported 12 Collateral reconciliation status reconciled/not reconciled 13 Reportable collateral fields subject of reconciliation Only not reconciled fields are to be reported, both values subject of reconciliation shall be reported Once a query is received, TRs should validate whether the query is correct and can be processed by their systems. In case of invalid data queries (e.g. the query is not compliant), the TR sends a feedback message to the authority stating that the query is invalid, including the description of the type of error. <FinInstrmRptgStsAdvc> <MsgStsAdvc> <MsgSts> <RptSts>RJCT</RptSts> <VldtnRule> <Id>EXE-003</Id> <Desc>Descrition of the rule</Desc> </VldtnRule> <RefDt>2017-11-15T10:35:55Z</RefDt> </MsgSts> </MsgStsAdvc> </FinInstrmRptgStsAdvc>

ESMA REGULAR USE
213
TRs shall execute ad-hoc data queries as soon as possible after its submission and validation, also on non-working days. The time for the provision of responses to ad hoc queries is specified in Article 5(4) RTS on data access:
a. where access is requested to details of outstanding SFTs, or of SFTs which have either matured or for which reports with action types “Error”, “Termination/Early termination”, or “Position component” as referred to in Field 98 of Table 2 of Annex I to ITS on reporting were made not more than one year before the date on which the request was submitted: no later than 12:00 Universal Coordinated Time on the first calendar day following the day on which the request to access is submitted. b. where access is requested to SFT details which have either matured or for which reports with action types “Error”, “Termination/Early termination”, or “Position component” as referred to in Field 98 of Table 2 of Annex I to ITS on reporting were made more than one year before the date on which the request was submitted: no later than three working days after the request to access has been submitted.
c. where access is requested to SFT details falling under both points (a) and (b): no
later than three working days after the request to access is submitted. If the time of data query submission is shorter than one day before the first execution date, then the first execution can be postponed until the following execution day according to the parameters specified in the query. If the execution of a query fails due to technical reasons, an error message shall be sent by TRs to the ESMA System. The error message should describe which type of error occurred. As a response to each data query, a TR prepares a response file containing data on all securities financing transactions fulfilling the search criteria defined by the authority:
a) For an ad-hoc query a one-off response file is prepared (one response file per one query); b) For a recurrent query, response files are prepared on a regular basis according to the frequency defined by the authority. The TRs should allow the entities included in Article 12(2) SFTR to establish a frequency for data access different from the daily. When establishing the maximum duration of the execution of a recurrent query, the TRs should take into account the needs of the entities listed in Article 12(2) SFTR and limit the risks to the functioning of their systems.
Article 5 of RTS on data access does not refer to the timelines that TRs should follow in
the event of carrying out scheduled maintenance that impacts TR services related to authorities’ access to data, irrespective of the channel or format used. TRs should plan carefully the scheduled maintenance that impacts TR services related to authorities’ access to data so that it does not coincide with working days determined in accordance with a calendar consistently agreed in the Union such as the Target2 calendar. Where under exceptional circumstances it coincides with such a working day, the scheduled maintenance should be carried out outside normal working hours, i.e. very early in the morning or very late at night. The TRs should make sure that the aforementioned

ESMA REGULAR USE
214 scheduled maintenance is not performed in a way that circumvents the timely availability of SFTs information to authorities. TRs should use electronic means to notify all authorities of the start and end dates and times of their scheduled maintenance windows. Where annual planning of scheduled maintenance windows that impact TR services related to authorities’ access to data exists at the TR, the TR could notify all authorities of that planning on an annual basis and with at least three working days’ notice. Furthermore, any additional specific notifications on scheduled maintenance that impact TR services related to authorities’ access to data, that are not notified on an annual basis, should be made at the earliest opportunity and at least three working days before the starting date of the scheduled maintenance that impacts TR services related to authorities’ access to data. TRs should keep a record of the relevant notifications that can be made available to ESMA upon request. The records related to scheduled maintenance notifications should contain, at least, the following information: the timestamp of the notification, of the start and of the end of the scheduled maintenance that impacts TR services related to authorities’ access to data and the relevant list of users notified. In the case of verification of requests under Article 5(5) of the RTS on data access, TRs should confirm receipt and verify the correctness and completeness of any request to access data, at the earliest opportunity and no later than sixty minutes after the finalisation of the relevant scheduled maintenance that impacts TR services related to authorities’ access to data. In the case of access to data under point a) of Article 5(4) of RTS on data access TRs should seek to complete the request at the earliest opportunity and no later than 12:00 Universal Coordinated Time on the first calendar day following the day on which the scheduled maintenance that impacts TR services related to authorities’ access to data was completed. The timelines in points b) and c) of Article 5(4) remain unaffected. In the case of non-scheduled maintenance, the TRs should meet the timelines included in Articles 5(4) and 5(5) of RTS on data access and these timelines will be taken as the reference when assessing the compliance of the TR. TRs should notify ESMA of the nonscheduled maintenance in accordance with their procedures. The output files are prepared by TRs in ISO 20022 XML format. The output files should contain the subset of SFT data that is limited to the legal mandate of the authority, pursuant to Articles 1 and 2 RTS on data access. The output files shall contain the subset of transaction data according to the criteria defined in the data query. When the number of records in the response to a query is large, the response shall be split into many files. For each trade the output file shall include all the fields as specified in the RTS and ITS and reported to TRs by
counterparties. The data query criteria should limit only the number of the query parameters (queryable fields) and in consequence the number of records included in the output file, not the scope of information delivered per each trade (i.e. the number of fields per trade).

ESMA REGULAR USE
215
If the execution of a query returns no transactions, a relevant feedback message should be sent by the TR.

ESMA Guidelines on reporting under Articles 4 and 12 SFTR

Business / Trade Event Type of SFT Applicable XML Message6 Acti on Type Level Comments/examples 6 Cancellation of disputed transaction (after external reporting) All Table 1 and Table 2 ERO R

25 Flat margin loan and/or short market value ML Table 1 and Table 2 MOD I

26 Change in outstanding margin loan or short market value ML Table 1 and Table 2 MOD I

27 Change of base currency used for margin loan ML Table 1 and Table 2 MOD I

28 Additional base currency used for margin loan ML Table 1 and Table 2 NEW T

There is only one base currency per margin loan, therefore additional base currency should be reported as a new margin loan with a new UTI 29 Valuation of securities used as collateral All Table 1 and Table 2 COL U

Business / Trade Event Type of SFT Applicable XML Message6 Acti on Type Level Comments/examples 32 Substitution of Collateral All Table 1 and Table 2 COL U

34 Change in cash collateral amount or currency REPO, SLB Table 1 and Table 2 COL U

35 Buy-in where required by regulation (e.g. CSDR) or market convention (not under GMRA) All Table 1 and Table 2 COL U

36 Cash compensation where required by regulation (e.g. CSDR) or market convention (not under GMRA) All Table 1 and Table 2 COL U

Business / Trade Event Type of SFT Applicable XML Message6 Acti on Type Level Comments/examples 43 CCP rejects transaction which is conditional upon registration with the CCP All Table 1 and Table 2 ERO R

Temporary settlement failure of the expiring SFT should not be reported separately 47 Full return of a term SLB prior to the maturity date or of an open term SLB SBL Table 1 and Table 2 ETR M

This includes e.g. placing counterparty into default provided this default option has been agreed under GMRA 10(a)(ii) 50 Termination of transaction under specific GMRA provisions REPO, BSB Table 1 and Table 2 ETR M

Lineage: In force

Business / Trade
Event
Type of
SFT
Applicable
XML
Message6
Acti on
Type
Level Comments/examples
6
Cancellation of disputed transaction
(after external reporting)
All Table 1 and
Table 2
ERO
R

25
Flat margin loan and/or short market value
ML Table 1 and
Table 2
MOD
I

26
Change in outstanding margin loan or short market value ML Table 1 and
Table 2
MOD
I

27
Change of base currency used for margin loan ML Table 1 and
Table 2
MOD
I

28
Additional base currency used for margin loan ML Table 1 and
Table 2
NEW
T

There is only one base currency per margin loan, therefore additional base currency should be reported as a new margin loan with a new UTI 29 Valuation of securities used as collateral All Table 1 and
Table 2
COL
U

Business / Trade
Event
Type of
SFT
Applicable
XML
Message6
Acti on
Type
Level Comments/examples
32 Substitution of
Collateral All Table 1 and
Table 2
COL
U

34
Change in cash collateral amount or currency REPO, SLB
Table 1 and
Table 2
COL
U

35
Buy-in where required by regulation (e.g.
CSDR) or market convention (not under GMRA) All Table 1 and
Table 2
COL
U

36
Cash compensation where required by regulation (e.g.
CSDR) or market convention (not under GMRA) All Table 1 and
Table 2
COL
U

Business / Trade
Event
Type of
SFT
Applicable
XML
Message6
Acti on
Type
Level Comments/examples
43
CCP rejects transaction which is conditional upon registration with the CCP All Table 1 and
Table 2
ERO
R

Temporary settlement failure of the expiring SFT should not be reported separately 47 Full return of a term SLB prior to the maturity date or of an open term SLB SBL Table 1 and
Table 2
ETR
M

This includes e.g. placing counterparty into default provided this default option has been agreed under GMRA 10(a)(ii) 50 Termination of transaction under specific GMRA provisions REPO, BSB
Table 1 and
Table 2
ETR
M