Guidelines

Reporting under Articles 4 and 12 SFTR

29/03/2021 | ESMA70-151-2838 EN
1
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

2
 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 third-
party. 53
Cleared SFT with broker, agent lender, tri-party agent ...................................... 55

3
 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

4
 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

5
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

6
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?

7
 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.

8
 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.

9
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.

10
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

11
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

12
 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.

13
 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

14
 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.

15
 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

Country of Country of
Country of Country of Reportabl
Reporting the branch of Reporting Other the branch of Reporting
the reporting the other e under
Counterparty the reporting obligation Counterparty the other obligation
counterparty counterparty SFTR
counterparty counterparty

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

16
Table 1 - Reporting by branches
Country of Country of
Country of Country of Reportabl
Reporting the branch of Reporting Other the branch of Reporting
the reporting the other e under
Counterparty the reporting obligation Counterparty the other obligation
counterparty counterparty SFTR
counterparty counterparty

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.

17
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.

18
 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

Modification
Termination

Component
Correction
Collateral
Valuation

Position
Error
New

New
x x x x x x

Error

Termination x x x x x
Previous steps

Modification x x x x x x

Valuation x x x x x x

Collateral x x x x x x

Correction x x x x x x

Position
x x
Component

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

19
 Table 3 - Margin update
Following step

Margin update

Correction
Error
New
New x x x
Previous step

Error

Margin update x x x

Correction x x x

Table 4 - Reuse, Cash Reinvestment and Funding Sources Data

Following step
Reuse update

Correction
Error
New

New x x x
Previous step

Error

Reuse update x x x

Correction x x 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

20
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.

21
 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

22
 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.

23
 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”.

24
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

25
 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.10 Mapping 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

26
 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 Applicable Acti
Business / Trade Type of
Event XML on Level Comments/examples
Event SFT
# Message6 Type
TCTN
Table 1 and NEW
1 Backloading All /
Table 2 T
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 (auto-
collateralisation by (I)CSD, other credit
NEW
TCTN facilities, intra-day autoborrowing of
Table 1 and T or
2 Conclusion All / securities from (I)CSD).
Table 2 POS
PSTN The settlement of the opening leg,
C
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.
Roll-over into new Table 1 and NEW
3 REPO TCTN
identical transaction Table 2 T
This includes, e.g., extension of an
extendible repo, ad hoc agreement to
REPO, Table 1 and MOD change the repurchase date of fixed-
4 Extension TCTN
SLB Table 2 I term repo or an agreement to defer the
repurchase date as part of fails
management process
Automatic change of
purchase and
repurchase dates of
an evergreen SFT at REPO, Table 1 and MOD
5 TCTN
the end of each SLB Table 2 I
business day until
termination or
maturity

5
The list of business events is not exhaustive
6
The references are to the tables of the RTS and ITS on reporting

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

28
Table 6 - Mapping business events to action types and levels
New Applicable Acti
Business / Trade Type of
Event XML on Level Comments/examples
Event SFT
# Message6 Type
Change in floating Table 1 and MOD
19 REPO TCTN
repo rate Table 2 I
Scheduled change in
rate on floating-rate This event would result in the report of
Table 1 and MOD
20 collateral or index on BSB TCTN the modification of the repurchase
Table 2 I
index-linked collateral price.
in a BSB
E.g. Collateral income payment (repo,
BSB), manufactured payment (repo,
Events impacting the REPO, Table 1 and COL BSB), scheduled change in rate on
21 -
collateral value BSB Table 2 U floating-rate collateral or index on
index-linked collateral in any type of
repo
TCTN
Table 1 and MOD
22 Cash mark SBL /
Table 2 I
PSTN
TCTN
Table 1 and MOD
23 Fee mark SBL /
Table 2 I
PSTN
Valuation of Table 1 and VAL
24 SLB -
securities on loan Table 2 U
Flat margin loan
Table 1 and MOD
25 and/or short market ML -
Table 2 I
value
Change in
outstanding margin Table 1 and MOD
26 ML -
loan or short market Table 2 I
value
Change of base
Table 1 and MOD
27 currency used for ML -
Table 2 I
margin loan
There is only one base currency per
Additional base
Table 1 and NEW margin loan, therefore additional base
28 currency used for ML -
Table 2 T currency should be reported as a new
margin loan
margin loan with a new UTI
Valuation of
Table 1 and COL
29 securities used as All -
Table 2 U
collateral
Action type NEWT is used when
collateral details are reported with
other SFT details in the report of new
NEW
First allocation of transaction.
Table 1 and T or
30 collateral on the day REPO TCTN This could be for example a scenario
Table 2 COL
of trade of a seller's allocation of collateral for a
U
new GC repo or triparty agent's first
allocation of collateral on the day of
trade
This could be for example a scenario
First allocation of of a seller's allocation of collateral for a
Table 1 and COL
31 collateral after the REPO TCTN new GC repo or triparty agent's first
Table 2 U
day of trade allocation of collateral after the day of
trade

29
Table 6 - Mapping business events to action types and levels
New Applicable Acti
Business / Trade Type of
Event XML on Level Comments/examples
Event SFT
# Message6 Type
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
Substitution of Table 1 and COL temporary cash collateral with
32 All -
Collateral Table 2 U 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
Change in collateral Table 1 and COL
33 All -
quality Table 2 U
Change in cash
REPO, Table 1 and COL
34 collateral amount or -
SLB Table 2 U
currency
Buy-in where
required by
regulation (e.g. Table 1 and COL
35 All -
CSDR) or market Table 2 U
convention (not
under GMRA)
Cash compensation
where required by
regulation (e.g. Table 1 and COL
36 All -
CSDR) or market Table 2 U
convention (not
under GMRA)
ETRM should only be reported when
COL
TCTN SFT is terminated following to the
Default of the U or
37 All ALL / default of the collateral issuer.
collateral issuer ETR
PSTN Otherwise, the collateral substitution
M
should be reported with COLU
REPO,
Table 1 and COL It's a separate COLU report for net
38 Variation margining SLB, -
Table 2 U exposure
BSB
TCTN
Change in haircut or REPO, Table 1 and COL
39 /
margins SLB Table 2 U
PSTN
ETR
TCTN
Table 1 and M+ This includes OTC transactions
40 Clearing off-venue All /
Table 2 NEW cleared on same day or after
PSTN
T
Post-trade clearing of ETR
TCTN This includes transactions executed on
a transaction Table 1 and M+
41 All / a trading venue cleared after the day
executed on a trading Table 2 NEW
PSTN of trade
venue T
Same-day clearing of
TCTN This includes transactions executed on
a transaction Table 1 and NEW
42 All / a trading venue cleared by open offer
executed on a trading Table 2 T
PSTN model and by same-day novation
venue

30
Table 6 - Mapping business events to action types and levels
New Applicable Acti
Business / Trade Type of
Event XML on Level Comments/examples
Event SFT
# Message6 Type
CCP rejects
transaction which is
Table 1 and ERO
43 conditional upon All -
Table 2 R
registration with the
CCP
Termination of an ETRM should be reported for the
MOD
open SFT or termination on the same day, whereas
REPO, Table 1 and I or
44 termination of a term TCTN MODI should be used to report a
SLB Table 2 ETR
repo (by agreement termination on a future date (by
M
or unilaterally) amending the maturity date)
Termination of an
REPO, Table 1 and MOD This includes elimination of termination
45 evergreen or puttable TCTN
SLB Table 2 I optionality
SFT
no Temporary settlement failure of the
Table 1 and
46 Maturity/Expiration All repor - expiring SFT should not be reported
Table 2
t separately
The settlement of the full return,
Full return of a term
including a delayed settlement that
SLB prior to the Table 1 and ETR
47 SBL - does not result in a cancellation of the
maturity date or of an Table 2 M
full return, should not be reported
open term SLB
separately.
Full return should not be reported if it
does not settle, therefore if the full
no return is cancelled, no additional report
Cancellation or repor is expected. However, if the full return
Table 1 and
48 failure of the full SBL t or TCTN had been reported as ETRM and
Table 2
return NEW subsequently the full return is
T cancelled, the transaction should be
re-reported with action type NEWT and
new UTI
This includes e.g. placing counterparty
Closure of an SFT
Table 1 and ETR into default provided this default option
49 due to counterparty All -
Table 2 M has been agreed under GMRA
default
10(a)(ii)
This includes:
Termination of transaction under 2000
Termination of provision 10(g) or GMRA 2011
transaction under REPO, Table 1 and ETR provision 10(h)
50 -
specific GMRA BSB Table 2 M "Mini close-out" under GMRA 2000
provisions 10(h) or GMRA 2011 10(i)
Repricing or Adjustment under GMRA
2000 4(i)-(k) or GMRA 2011 4(j)-(l)
Terminating the
relationship between Table 1 and ETR
51 ML -
prime broker and the Table 2 M
client
Counterparties agree to amend a
TCTN
Amend trade - Table 1 and MOD transaction attribute. This is a catch all
52 All /
bilateral Table 2 I event for any modifications not listed
PSTN
separately
TCTN
Amend trade - Table 1 and COR One counterparty corrects a
53 All /
unilateral Table 2 R transaction attribute
PSTN

31
Table 6 - Mapping business events to action types and levels
New Applicable Acti
Business / Trade Type of
Event XML on Level Comments/examples
Event SFT
# Message6 Type
Counterparties agree to amend a
TCTN
Amend collateral - Table 1 and COL collateral attribute. This is a catch all
54 All /
bilateral Table 2 U event for any modifications not listed
PSTN
separately
TCTN
Amend collateral - Table 1 and COR One counterparty corrects a collateral
55 All /
unilateral Table 2 R attribute
PSTN
It's not possible to correct the wrongly
reported early termination or error.
Lifecycle event (e.g. Once a report with these action types
TCTN
change in size or re- Table 1 and COR is sent, there is no way to bring the
56 All /
rating of open repo) Table 2 R transaction back to outstanding status,
PSTN
incorrectly reported and therefore it is necessary to
rereport the transaction with action
type NEWT and new UTI.
Transaction not
executed or out of
Table 1 and ERO
57 scope of SFTR but All -
Table 2 R
reported to TR by
mistake
Initial posting of
NEW
58 margin to a CCP for All Table 3 -
T
cleared SFTs
Update of the initial
MAR
59 margin posted at the All Table 3 -
U
CCP
Posting variation
MAR
60 margin to a CCP for All Table 3 -
U
cleared SFTs
Correction of a
COR
61 previous submitted All Table 3 -
R
margin report
Cancellation of a
ERO
62 wrongly submitted All Table 3 -
R
margin report
First report of reuse
of collateral or NEW
63 All Table 4 -
reinvestment of cash T
collateral
Change in the
securities reused or
update of the REU
64 All Table 4 -
estimated reuse or U
value of reused
collateral
Change in cash
collateral REU
65 SLB Table 4 -
reinvestment type, U
amount or currency
Correction of a
COR
66 previously submitted All Table 4 -
R
collateral reuse

32
Table 6 - Mapping business events to action types and levels
New Applicable Acti
Business / Trade Type of
Event XML on Level Comments/examples
Event SFT
# Message6 Type
report with incorrect
data
Cancellation of a
wrongly submitted
collateral reuse
ERO
67 report (e.g. for an All Table 4 -
R
entity not subject to
the reporting
obligation)

4.11 Identification 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.12 Determining 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.

33
 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.13 Price 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

34
 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.14 Reporting of CFI for a security used as collateral

When a security is used as collateral, the CFI code of that security should be reported in
fields 42 and 79 of the table on Loan and Collateral data. This field does not apply to
commodities.
Counterparties should always use official sources for the CFI. For this purpose, the data
issued by the relevant National Numbering Agency (NNA) should be used. Further
information is provided by ANNA in the following link http://www.anna-
web.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.15 Backloading

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.

35
 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.16 UTI generation and structure

The flowchart below illustrates the process for generating a UTI.

36
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.

37
 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.17 Identifying 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.18 Identification 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.

38
 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.19 Procedure 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, spin-
offs, 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.

39
 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.20 Reporting 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

40
 “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

41
 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.

42
Table 7 – Use cases
Repo and Securities and
BSB / Margin
reverse commodities
SBB lending
repo lending

Non-cleared bilateral SFT between

Y Y Y Y
headquarters

Non-cleared bilateral SFT between

Y Y Y Y
branches

Non-cleared bilateral SFT with

Y Y Y N
beneficiaries

Non-cleared SFT with brokers, settled

Y Y Y N
with a custodian bank

Non-cleared SFT with broker, agent

Y Y Y N
lender and tri-party agent

Non-cleared SFT with broker, agent

lender and tri-party agent, settled with
a CSD participant different from any of Y Y Y N
the entities and voluntary delegation of
reporting to a third party

Cleared SFT with broker, agent lender,

Y Y Y N
tri-party agent

Cleared SFT with broker, agent lender,

tri-party agent settled with a CSD
participant different from any of the Y Y Y N
entities and voluntary delegation of
reporting to a third party

Non-cleared SFTs concluded by

Y Y Y Y
UCITS fund

43
Table 7 – Use cases
Repo and Securities and
BSB / Margin
reverse commodities
SBB lending
repo lending

Non-cleared SFTs concluded by

UCITS fund, and the UCITs Y Y Y Y
management company delegates
reporting to a third party

Y Y Y Y
Non-cleared SFTs concluded by AIF

Non-cleared SFTs where fund portfolio Y Y Y Y

management is outsourced

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 Buy sell back/sell Securities and
Margin lending
repo buy-back commodities
lending
Y Y Y 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.

44
Table 9 - Non-cleared bilateral SFTs between headquarters
No Field Example XML Message
2021-02- <SctiesFincgRptgTxRpt>
1 Reporting timestamp 01T15:15:15 <TradData>
Z <Rpt>
{LEI} of <New>
2 Report submitting entity counterparty ...
A <CtrPtyData>
{LEI} of <RptgDtTm>2020-01-
3 Reporting counterparty counterparty 01T15:15:15Z</RptgDtTm>
A <RptSubmitgNtty>
Nature of the reporting
4 F <LEI>12345678901234500000</LEI>
counterparty
</RptSubmitgNtty>
Sector of the reporting <CtrPtyData>
5 CDTI
counterparty <RptgCtrPty>
<Id>
Additional sector
6
classification <LEI>12345678901234500000</LEI>
Branch of the reporting </Id>
7
counterparty <Ntr>
Branch of the other <FI>
8 <Clssfctn>CDTI</Clssfctn>
counterparty
</FI>
9 Counterparty side GIVE </Ntr>
{LEI} of <Sd>GIVE</Sd>
Entity responsible for
10 counterparty </RptgCtrPty>
the report
A <OthrCtrPty>
{LEI} of <Id>
11 Other counterparty counterparty
B <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
Country of the other </Id>
12 FR <CtryCd>FR</CtryCd>
Counterparty
</OthrCtrPty>
13 Beneficiary <NttyRspnsblForRpt>
14 Tri-party agent <LEI>12345678901234500000</LEI>
15 Broker </NttyRspnsblForRpt>
<OthrPtyData>
16 Clearing member
<SttlmPties>
Central Securities <CntrlSctiesDpstryPtcpt>
{LEI} of
Depository (‘CSD’)
17 counterparty
participant or indirect <LEI>12345678901234500000</LEI>
A
participant </CntrlSctiesDpstryPtcpt>
</SttlmPties>
</OthrPtyData>
</CtrPtyData>
18 Agent lender
</CtrPtyData>
<LnData>
...

45
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

Securities and
Repo and reverse Buy sell back/sell
commodities Margin lending
repo buy-back
lending

Y Y Y 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
2020-01- <SctiesFincgRptgTxRpt>
1 Reporting timestamp
01T15:15:15Z <TradData>
{LEI} of <Rpt>
Report submitting
2 counterparty <New>
entity
A ...
{LEI} of <CtrPtyData>
Reporting
3 counterparty <RptgDtTm>2020-01-
counterparty
A 01T15:15:15Z</RptgDtTm>
Nature of the <RptSubmitgNtty>
4
reporting counterparty F
<LEI>12345678901234500000</LEI>
Sector of the </RptSubmitgNtty>
5
reporting counterparty CDTI <CtrPtyData>
Additional sector <RptgCtrPty>
6 <Id>
classification

46
Table 11 - Non-cleared bilateral SFT between branches
No Field Example XML Message
Branch of the
7 <LEI>12345678901234500000</LEI>
reporting counterparty FR
Branch of the other </Id>
8 <Ntr>
counterparty DE
<FI>
9 Counterparty side GIVE <Clssfctn>CDTI</Clssfctn>
{LEI} of </FI>
Entity responsible for
10 counterparty </Ntr>
the report <Brnch>
A
{LEI} of <Ctry>FR</Ctry>
11 Other counterparty counterparty </Brnch>
B <Sd>GIVE</Sd>
Country of the other </RptgCtrPty>
12 <OthrCtrPty>
Counterparty FR <Id>
13 Beneficiary
<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
14 Tri-party agent </Id>
15 Broker <Brnch>
<Ctry>DE</Ctry>
16 Clearing member </Brnch>
Central Securities <CtryCd>FR</CtryCd>
Depository (‘CSD’) {LEI} of </OthrCtrPty>
17
participant or indirect counterparty <NttyRspnsblForRpt>
participant A
<LEI>12345678901234500000</LEI>
</NttyRspnsblForRpt>
<OthrPtyData>
<SttlmPties>
<CntrlSctiesDpstryPtcpt>

<LEI>12345678901234500000</LEI>
</CntrlSctiesDpstryPtcpt>
</SttlmPties>
</OthrPtyData>
</CtrPtyData>
18 Agent lender </CtrPtyData>
<LnData>
...
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>

47
 Non-cleared bilateral SFT with beneficiaries

Table 12 – SFTs to which the use case applies

Securities and
Repo and reverse Buy sell back/sell
commodities Margin lending
repo buy-back
lending

Y Y 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
2020-01-
<SctiesFincgRptgTxRpt>
1 Reporting timestamp 01T15:15:15
<TradData>
Z
<Rpt>
{LEI} of <New>
2 Report submitting entity counterparty ...
A <CtrPtyData>
{LEI} of <RptgDtTm>2020-01-
3 Reporting counterparty counterparty 01T15:15:15Z</RptgDtTm>
A <RptSubmitgNtty>
Nature of the reporting
4
counterparty F <LEI>12345678901234500000</LEI>
</RptSubmitgNtty>
Sector of the reporting <CtrPtyData>
5
counterparty CDTI <RptgCtrPty>
Additional sector <Id>
6
classification
<LEI>12345678901234500000</LEI>
Branch of the reporting
7 </Id>
counterparty
<Ntr>
Branch of the other <FI>
8
counterparty <Clssfctn>CDTI</Clssfctn>
9 Counterparty side GIVE </FI>
</Ntr>
{LEI} of
Entity responsible for <Sd>GIVE</Sd>
10 counterparty
the report </RptgCtrPty>
A
<OthrCtrPty>
{LEI} of
<Id>
11 Other counterparty counterparty
B
<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
Country of the other </Id>
12
Counterparty FR <CtryCd>FR</CtryCd>

48
Table 13 - Non-cleared bilateral SFT with beneficiaries
No Field Example XML Message
{LEI} of </OthrCtrPty>
13 Beneficiary counterparty <NttyRspnsblForRpt>
D
14 Tri-party agent <LEI>12345678901234500000</LEI>
</NttyRspnsblForRpt>
15 Broker
<OthrPtyData>
16 Clearing member <Bnfcry>
Central Securities
Depository (‘CSD’) {LEI} of <LEI>11223344556677889900</LEI>
17 </Bnfcry>
participant or indirect counterparty
participant A <SttlmPties>
<CntrlSctiesDpstryPtcpt>

<LEI>12345678901234500000</LEI>
</CntrlSctiesDpstryPtcpt>
</SttlmPties>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
...
18 Agent lender </LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>

Non-cleared SFT with brokers, settled with a custodian bank

Table 14 – SFTs to which the use case applies

Securities and
Repo and reverse Buy sell back/sell
commodities Margin lending
repo buy-back
lending

Y Y 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.

49
Table 15 - Non-cleared SFT with brokers, settled with a custodian bank
No Field Example XML Message
2020-01- <SctiesFincgRptgTxRpt>
1 Reporting timestamp
0115:15:15Z <TradData>
{LEI} of <Rpt>
2 Report submitting entity counterparty <New>
A ...
{LEI} of <CtrPtyData>
3 Reporting counterparty counterparty <RptgDtTm>2020-01-
A 01T15:15:15Z</RptgDtTm>
<RptSubmitgNtty>
Nature of the reporting
4
counterparty F <LEI>12345678901234500000</LEI>
Sector of the reporting </RptSubmitgNtty>
5
counterparty CDTI <CtrPtyData>
<RptgCtrPty>
Additional sector <Id>
6
classification
Branch of the reporting <LEI>12345678901234500000</LEI>
7
counterparty </Id>
Branch of the other <Ntr>
8 <FI>
counterparty
<Clssfctn>CDTI</Clssfctn>
9 Counterparty side GIVE </FI>
{LEI} of </Ntr>
Entity responsible for
10 counterparty <Sd>GIVE</Sd>
the report
A </RptgCtrPty>
{LEI} of <OthrCtrPty>
11 Other counterparty counterparty <Id>
B
Country of the other <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
12 </Id>
Counterparty FR
<CtryCd>FR</CtryCd>
13 Beneficiary </OthrCtrPty>
<NttyRspnsblForRpt>
14 Tri-party agent
{LEI} of <LEI>12345678901234500000</LEI>
15 Broker
broker E </NttyRspnsblForRpt>
16 Clearing member <OthrPtyData>
Central Securities
<Brkr>
Depository (‘CSD’) {LEI} of
17
participant or indirect custodian
<LEI>88888888888888888888</LEI>
participant bank H
</Brkr>
<SttlmPties>
<CntrlSctiesDpstryPtcpt>
<LEI>
18 Agent lender AAAAAAAAAAAAAAAAAAAA</LEI>
</CntrlSctiesDpstryPtcpt>
</SttlmPties>
</OthrPtyData>
</CtrPtyData>

50
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

Securities and
Repo and reverse Buy sell back/sell
commodities Margin lending
repo buy-back
lending

Y Y 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
2020-01- <SctiesFincgRptgTxRpt>
1 Reporting timestamp 01T15:15:15 <TradData>
Z <Rpt>
{LEI} of <New>
2 Report submitting entity counterparty ...
A <CtrPtyData>
{LEI} of <RptgDtTm>2020-01-
3 Reporting counterparty counterparty 01T15:15:15Z</RptgDtTm>
A <RptSubmitgNtty>
Nature of the reporting
4 F
counterparty <LEI>12345678901234500000</LEI>

51
Table 17 - Non-cleared SFT with broker, agent lender and tri-party agent
No Field Example XML Message
Sector of the reporting </RptSubmitgNtty>
5 CDTI <CtrPtyData>
counterparty
<RptgCtrPty>
Additional sector <Id>
6
classification
Branch of the reporting <LEI>12345678901234500000</LEI>
7 </Id>
counterparty
Branch of the other <Ntr>
8 <FI>
counterparty
<Clssfctn>CDTI</Clssfctn>
9 Counterparty side GIVE </FI>
{LEI} of </Ntr>
Entity responsible for
10 counterparty <Sd>GIVE</Sd>
the report
A </RptgCtrPty>
{LEI} of <OthrCtrPty>
11 Other counterparty counterparty <Id>
B
Country of the other <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
12 FR </Id>
counterparty
<CtryCd>FR</CtryCd>
13 Beneficiary </OthrCtrPty>
<NttyRspnsblForRpt>
{LEI} of tri-
14 Tri-party agent party agent
<LEI>12345678901234500000</LEI>
G
</NttyRspnsblForRpt>
{LEI} of
15 Broker <OthrPtyData>
broker E
<TrptyAgt>
16 Clearing member
Central Securities <LEI>77777777777777777777</LEI>
{LEI} of </TrptyAgt>
Depository (‘CSD’)
17 counterparty <Brkr>
participant or indirect
A
participant
<LEI>88888888888888888888</LEI>
</Brkr>
<SttlmPties>
<CntrlSctiesDpstryPtcpt>

<LEI>12345678901234500000</LEI>
</CntrlSctiesDpstryPtcpt>
</SttlmPties>
{LEI} of <AgtLndr>
18 Agent lender agent lender
F <LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
</AgtLndr>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
...
</LnData>

52
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

Securities and
Repo and reverse Buy sell back/sell
commodities Margin lending
repo buy-back
lending

Y Y 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
2020-01- <SctiesFincgRptgTxRpt>
1 Reporting timestamp
0115:15:15Z <TradData>
{LEI} of third <Rpt>
2 Report submitting entity
party I <New>
{LEI} of ...
3 Reporting counterparty counterparty <CtrPtyData>
A <RptgDtTm>2020-01-
Nature of the reporting 01T15:15:15Z</RptgDtTm>
4 F <RptSubmitgNtty>
counterparty
Sector of the reporting <LEI>12345123451234512345</LEI>
5 CDTI
counterparty </RptSubmitgNtty>

53
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
Additional sector <CtrPtyData>
6 <RptgCtrPty>
classification
<Id>
Branch of the reporting
7
counterparty <LEI>12345678901234500000</LEI>
Branch of the other </Id>
8
counterparty <Ntr>
9 Counterparty side GIVE <FI>
<Clssfctn>CDTI</Clssfctn>
{LEI} of
Entity responsible for </FI>
10 counterparty
the report </Ntr>
A
<Sd>GIVE</Sd>
{LEI} of
</RptgCtrPty>
11 Other counterparty counterparty
<OthrCtrPty>
B
<Id>
Country of the other
12 FR
counterparty <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
13 Beneficiary
<CtryCd>FR</CtryCd>
{LEI} of tri- </OthrCtrPty>
14 Tri-party agent party agent <NttyRspnsblForRpt>
G
{LEI} of <LEI>12345678901234500000</LEI>
15 Broker </NttyRspnsblForRpt>
Broker E
<OthrPtyData>
16 Clearing member
Central Securities <TrptyAgt>
{LEI} of
Depository (‘CSD’)
17 custodian
participant or indirect <LEI>77777777777777777777</LEI>
bank H
participant </TrptyAgt>
<Brkr>

<LEI>88888888888888888888</LEI>
</Brkr>
<SttlmPties>
<CntrlSctiesDpstryPtcpt>

{LEI} of <LEI>AAAAAAAAAAAAAAAAAAAA</LEI>
18 Agent lender agent lender </CntrlSctiesDpstryPtcpt>
F </SttlmPties>
<AgtLndr>

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

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
...
</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

Securities and
Repo and reverse Buy sell back/sell
commodities Margin lending
repo buy-back
lending

Y Y 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
2020-01-
1 Reporting timestamp <SctiesFincgRptgTxRpt>
01T15:15:15Z
{LEI} of <TradData>
Report submitting <Rpt>
2 counterparty
entity <New>
A
{LEI} of ...
Reporting <CtrPtyData>
3 counterparty
counterparty <RptgDtTm>2020-01-
A
01T15:15:15Z</RptgDtTm>
Nature of the <RptSubmitgNtty>
4 F
reporting counterparty

55
Table 21 - Cleared SFT with broker, agent lender, tri-party agent
No Field Example XML Message
Sector of the
5 CDTI <LEI>12345678901234500000</LEI>
reporting counterparty
</RptSubmitgNtty>
Additional sector <CtrPtyData>
6
classification <RptgCtrPty>
Branch of the <Id>
7
reporting counterparty
Branch of the other <LEI>12345678901234500000</LEI>
8 </Id>
counterparty
<Ntr>
9 Counterparty side GIVE <FI>
{LEI} of <Clssfctn>CDTI</Clssfctn>
Entity responsible for
10 counterparty </FI>
the report
A </Ntr>
{LEI} of <Sd>GIVE</Sd>
11 Other counterparty counterparty </RptgCtrPty>
B <OthrCtrPty>
Country of the other <Id>
12 FR
counterparty
<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
13 Beneficiary </Id>
<CtryCd>FR</CtryCd>
{LEI} of tri-
14 Tri-party agent </OthrCtrPty>
party agent G
<NttyRspnsblForRpt>
{LEI} of broker
15 Broker
E
<LEI>12345678901234500000</LEI>
{LEI} of </NttyRspnsblForRpt>
16 Clearing member
counterparty J <OthrPtyData>
Central Securities
{LEI} of
Depository (‘CSD’) <TrptyAgt>
17 counterparty
participant or indirect
A
participant <LEI>77777777777777777777</LEI>
</TrptyAgt>
<Brkr>

<LEI>88888888888888888888</LEI>
</Brkr>
<ClrMmb>

{LEI} of agent <LEI>CCCCCCCCCCCCCCCCCCCC

18 Agent lender </LEI>
lender F
</ClrMmb>
<SttlmPties>
<CntrlSctiesDpstryPtcpt>

<LEI>12345678901234512345</LEI>
</CntrlSctiesDpstryPtcpt>
</SttlmPties>
<AgtLndr>

56
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 Buy sell back/sell Securities and Margin lending
repo buy-back commodities
lending

Y Y 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
2020-01- <SctiesFincgRptgTxRpt>
1 Reporting timestamp
0115:15:15Z <TradData>

57
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
{LEI} of third <Rpt>
2 Report submitting entity
party I <New>
{LEI} of ...
3 Reporting counterparty counterparty <CtrPtyData>
A <RptgDtTm>2020-01-
Nature of the reporting 01T15:15:15Z</RptgDtTm>
4 F <RptSubmitgNtty>
counterparty
Sector of the reporting <LEI>12345123451234512345</LEI>
5 CDTI
counterparty </RptSubmitgNtty>
<CtrPtyData>
Additional sector
6 <RptgCtrPty>
classification
<Id>
Branch of the reporting
7
counterparty <LEI>12345678901234500000</LEI>
Branch of the other </Id>
8 <Ntr>
counterparty
<FI>
9 Counterparty side GIVE
<Clssfctn>CDTI</Clssfctn>
{LEI} of </FI>
Entity responsible for
10 counterparty </Ntr>
the report
A <Sd>GIVE</Sd>
{LEI} of </RptgCtrPty>
11 Other counterparty counterparty <OthrCtrPty>
B <Id>
Country of the other
12 FR <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
counterparty
</Id>
13 Beneficiary <CtryCd>FR</CtryCd>
{LEI} of tri- </OthrCtrPty>
14 Tri-party agent party agent <NttyRspnsblForRpt>
G
{LEI} of <LEI>12345678901234500000</LEI>
15 Broker </NttyRspnsblForRpt>
broker E
{LEI} of <OthrPtyData>
16 Clearing member counterparty <TrptyAgt>
J
Central Securities <LEI>77777777777777777777</LEI>
{LEI} of </TrptyAgt>
Depository (‘CSD’)
17 custodian <Brkr>
participant or indirect
bank H
participant
<LEI>88888888888888888888</LEI>
</Brkr>
{LEI} of <ClrMmb>
18 Agent lender agent lender
F <LEI>CCCCCCCCCCCCCCCCCCCC
</LEI>
</ClrMmb>

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
<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 Buy sell back/sell Securities and Margin lending
repo buy-back commodities
lending

Y Y Y 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.

59
Table 25 - Non-cleared SFTs concluded by UCITS fund
No Field Example XML Message
2020-01- <SctiesFincgRptgTxRpt>
1 Reporting timestamp 01T15:15:15 <TradData>
Z <Rpt>
{LEI} of <New>
UCITS ...
2 Report submitting entity
managemen <CtrPtyData>
t company L <RptgDtTm>2020-01-
{LEI} of 01T15:15:15Z</RptgDtTm>
3 Reporting counterparty <RptSubmitgNtty>
UCITS K
Nature of the reporting
4 <LEI>UUUUUUUUUU2222222222</LEI>
counterparty F </RptSubmitgNtty>
Sector of the reporting <CtrPtyData>
5
counterparty UCIT <RptgCtrPty>
<Id>
Additional sector
6
classification <LEI>UUUUUUUUUU1111111111</LEI>
Branch of the reporting </Id>
7
counterparty <Ntr>
Branch of the other <FI>
8 <Clssfctn>UCIT</Clssfctn>
counterparty
</FI>
9 Counterparty side GIVE </Ntr>
{LEI} of <Sd>GIVE</Sd>
Entity responsible for UCITS </RptgCtrPty>
10
the report managemen <OthrCtrPty>
t company L <Id>
{LEI} of
11 Other counterparty counterparty <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
B </Id>
Country of the other <CtryCd>FR</CtryCd>
12 </OthrCtrPty>
counterparty FR
<NttyRspnsblForRpt>
13 Beneficiary
<LEI>UUUUUUUUUU2222222222</LEI>
14 Tri-party agent
</NttyRspnsblForRpt>
15 Broker <OthrPtyData>
16 Clearing member <SttlmPties>
<CntrlSctiesDpstryPtcpt>
Central Securities
Depository (‘CSD’) {LEI} of <LEI>AAAAAAAAAAAAAAAAAAAA</LEI>
17
participant or indirect custodian </CntrlSctiesDpstryPtcpt>
participant bank H </SttlmPties>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
18 Agent lender <LnData>
...
</LnData>
<CollData>

60
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 Buy sell back/sell Securities and Margin lending
repo buy-back commodities
lending

Y Y Y 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
2020-01- <SctiesFincgRptgTxRpt>
1 Reporting timestamp 01T15:15:15 <TradData>
Z <Rpt>
{LEI} of third <New>
2 Report submitting entity
party I ...
{LEI} of <CtrPtyData>
3 Reporting counterparty
UCITS K <RptgDtTm>2020-01-
Nature of the reporting 01T15:15:15Z</RptgDtTm>
4 <RptSubmitgNtty>
counterparty F
Sector of the reporting <LEI>12345123451234512345</LEI>
5
counterparty UCIT </RptSubmitgNtty>
Additional sector <CtrPtyData>
6 <RptgCtrPty>
classification
<Id>
Branch of the reporting
7
counterparty <LEI>UUUUUUUUUU1111111111</LEI>

61
Table 27 - Non-cleared SFTs concluded by UCITS fund
No Field Example XML Message
Branch of the other </Id>
8
counterparty <Ntr>
9 Counterparty side <FI>
GIVE <Clssfctn>UCIT</Clssfctn>
{LEI} of </FI>
Entity responsible for UCITS </Ntr>
10
the report managemen <Sd>GIVE</Sd>
t company L </RptgCtrPty>
{LEI} of <OthrCtrPty>
11 Other counterparty counterparty <Id>
B
Country of the other <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
12
counterparty FR </Id>
<CtryCd>FR</CtryCd>
13 Beneficiary </OthrCtrPty>
14 Tri-party agent <NttyRspnsblForRpt>
15 Broker <LEI>UUUUUUUUUU2222222222</LEI>
16 Clearing member </NttyRspnsblForRpt>
<OthrPtyData>
Central Securities
<SttlmPties>
Depository (‘CSD’) {LEI} of
17 <CntrlSctiesDpstryPtcpt>
participant or indirect custodian
participant bank H
<LEI>AAAAAAAAAAAAAAAAAAAA</LEI>
</CntrlSctiesDpstryPtcpt>
</SttlmPties>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
...
18 Agent lender </LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>

62
 Non-cleared SFTs concluded by AIF

Table 28 – SFTs to which the use case applies

Repo and reverse Buy sell back/sell Securities and Margin lending
repo buy-back commodities
lending

Y Y Y 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
Field Example XML Message
o
2020-01- <SctiesFincgRptgTxRpt>
1 Reporting timestamp
01T15:15:15Z <TradData>
{LEI} of AIF <Rpt>
2 Report submitting entity management <New>
company N ...
3 Reporting counterparty {LEI} of AIF M <CtrPtyData>
<RptgDtTm>2020-01-
Nature of the reporting 01T15:15:15Z</RptgDtTm>
4
counterparty F <RptSubmitgNtty>
Sector of the reporting
5 <LEI>AAAAAAAAAA2222222222</LEI>
counterparty AIFD
</RptSubmitgNtty>
Additional sector <CtrPtyData>
6
classification <RptgCtrPty>
Branch of the reporting <Id>
7
counterparty
<LEI>AAAAAAAAAA1111111111</LEI>
Branch of the other
8 </Id>
counterparty
<Ntr>
9 Counterparty side GIVE <FI>
{LEI} of AIF <Clssfctn>AIFD</Clssfctn>
Entity responsible for </FI>
10 management
the report </Ntr>
company N
{LEI} of <Sd>GIVE</Sd>
11 Other counterparty counterparty </RptgCtrPty>
B <OthrCtrPty>
Country of the other <Id>
12
counterparty FR <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
13 Beneficiary </Id>
<CtryCd>FR</CtryCd>
14 Tri-party agent </OthrCtrPty>

63
Table 29 - Non-cleared SFTs concluded by AIF
N
Field Example XML Message
o
15 Broker <NttyRspnsblForRpt>
16 Clearing member
<LEI>AAAAAAAAAA2222222222</LEI>
Central Securities </NttyRspnsblForRpt>
Depository (‘CSD’) {LEI} of <OthrPtyData>
17
participant or indirect custodian <SttlmPties>
participant bank H <CntrlSctiesDpstryPtcpt>

<LEI>AAAAAAAAAAAAAAAAAAAA</LEI>
</CntrlSctiesDpstryPtcpt>
</SttlmPties>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
...
18 Agent lender
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>

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 Buy sell back/sell Securities and Margin lending
repo buy-back commodities
lending

Y Y Y Y

64
Table 31 - Non-cleared SFTs where fund portfolio management is outsourced
No Field Example XML Message
2020-01- <SctiesFincgRptgTxRpt>
1 Reporting timestamp 01T15:15:15 <TradData>
Z <Rpt>
{LEI} of AIF <New>
2 Report submitting entity managemen ...
t company N <CtrPtyData>
{LEI} of AIF <RptgDtTm>2020-01-
3 Reporting counterparty 01T15:15:15Z</RptgDtTm>
M
<RptSubmitgNtty>
Nature of the reporting
4
counterparty F <LEI>AAAAAAAAAA2222222222</LEI>
Sector of the reporting </RptSubmitgNtty>
5
counterparty AIFD <CtrPtyData>
<RptgCtrPty>
Additional sector <Id>
6
classification
Branch of the reporting <LEI>AAAAAAAAAA1111111111</LEI>
7
counterparty </Id>
Branch of the other <Ntr>
8 <FI>
counterparty
<Clssfctn>AIFD</Clssfctn>
9 Counterparty side GIVE </FI>
{LEI} of AIF </Ntr>
Entity responsible for
10 managemen <Sd>GIVE</Sd>
the report
t company N </RptgCtrPty>
{LEI} of <OthrCtrPty>
11 Other counterparty counterparty <Id>
B
Country of the other <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
12 </Id>
counterparty FR
<CtryCd>FR</CtryCd>
13 Beneficiary </OthrCtrPty>
<NttyRspnsblForRpt>
14 Tri-party agent
15 Broker <LEI>AAAAAAAAAA2222222222</LEI>
16 Clearing member </NttyRspnsblForRpt>
<OthrPtyData>
Central Securities <Brkr>
Depository (‘CSD’) {LEI} of <LEI>
17
participant or indirect custodian AAAAAAAAAA2222222222</LEI>
participant bank H </Brkr>

<SttlmPties>
<CntrlSctiesDpstryPtcpt>
18 Agent lender
<LEI>AAAAAAAAAAAAAAAAAAAA</LEI>
</CntrlSctiesDpstryPtcpt>
</SttlmPties>

65
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
Unique Trade <SctiesFincgRptgTxRpt>
1 UTI1
Identifier (UTI) <TradData>
<Rpt>
5 Cleared false <New>
...
98 Action type NEWT <CtrPtyData>
...
</CtrPtyData>
99 Level TCTN
<LnData>
<RpTrad>

66
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
Unique Trade <SctiesFincgRptgTxRpt>
1 UTI1
Identifier (UTI) <TradData>
<Rpt>
5 Cleared false <New>
...
98 Action type NEWT <CtrPtyData>
...
</CtrPtyData>
<LnData>
<RpTrad>
99 Level TCTN
<UnqTradIdr>UTI1</UnqTradIdr>
</RpTrad>
<ClrSts>
<NonClrd>NORE</NonClrd>

67
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

Unique Trade <SctiesFincgRptgTxRpt>
1 UTI1
Identifier (UTI) <TradData>
<Rpt>
98 Action type ETRM <EarlyTermntn>
...
99 Level <CtrPtyData>
...
</CtrPtyData>
<LnData>
<UnqTradIdr>UTI1</UnqTradIdr>
</LnData>
<CollData>
...
</CollData>
...
</EarlyTermntn>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>

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

Unique Trade <SctiesFincgRptgTxRpt>
1 UTI2
Identifier (UTI) <TradData>

68
 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

Report tracking <Rpt>
2 UTI18
number <New>
...
5 Cleared true
<CtrPtyData>
...
98 Action type NEWT
</CtrPtyData>
<LnData>
<RpTrad>

<UnqTradIdr>UTI2</UnqTradIdr>
<ClrSts>
<Clrd>

<RptTrckgNb>UTI1</RptTrckgNb>
</Clrd>
</ClrSts>
99 Level TCTN
</RpTrad>
</LnData>
<CollData>
...
</CollData>
<LvlTp>TCTN</LvlTp>
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>

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 CCP-
cleared 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.

69
 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

Unique Trade <SctiesFincgRptgTxRpt>
1 UTI1
Identifier (UTI) <TradData>
<Rpt>
5 Cleared true <PosCmpnt>
...
98 Action type POSC10 <CtrPtyData>
...
</CtrPtyData>
<LnData>
<RpTrad>

<UnqTradIdr>UTI2</UnqTradIdr>
<ClrSts>
<Clrd>
...
</Clrd>
</ClrSts>
99 Level TCTN
</RpTrad>
</LnData>
<CollData>
...
</CollData>
<LvlTp>TCTN</LvlTp>
</PosCmpnt>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>

Table 37 - New CCP-cleared SFT reported at position level

No Field Example XML Message

Unique Trade <SctiesFincgRptgTxRpt>
1 PUTI1
Identifier (UTI) <TradData>

10
Note that the original trades at transaction level have to be reported with position component as an action type.

70
 Table 37 - New CCP-cleared SFT reported at position level

No Field Example XML Message

<Rpt>
5 Cleared true11
<New>
...
98 Action type NEWT12
<CtrPtyData>
...
</CtrPtyData>
<LnData>
<RpTrad>

<UnqTradIdr>PUTI1</UnqTradIdr>
<ClrSts>
<Clrd>
...
</Clrd>
</ClrSts>
99 Level PSTN13
</RpTrad>
</LnData>
<CollData>
...
</CollData>
<LvlTp>PSTN</LvlTp>
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>

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
Unique Trade Identifier <SctiesFincgRptgTxRpt>
1 UTI1
(UTI) <TradData>
<Rpt>
98 Action type MODI
<Mod>
...
99 Level TCTN
<CtrPtyData>

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.

71
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

Unique Trade <SctiesFincgRptgTxRpt>
1 PUTI1
Identifier (UTI) <TradData>
<Rpt>
5 Cleared true <Mod>
...
98 Action type MODI <CtrPtyData>
...
</CtrPtyData>
<LnData>
<RpTrad>

<UnqTradIdr>PUTI1</UnqTradIdr>
99 Level PSTN
<ClrSts>
<Clrd>
...
</Clrd>
</ClrSts>

72
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
Unique Trade Identifier
1 UTI1
(UTI) <SctiesFincgRptgTxRpt>
<TradData>
98 Action type CORR
<Rpt>
<Crrctn>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
<RpTrad>

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

73
 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

Unique Trade
1 PUTI1
Identifier (UTI) <SctiesFincgRptgTxRpt>
<TradData>
5 Cleared true <Rpt>
<Crrctn>
98 Action type CORR ...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
<RpTrad>

<UnqTradIdr>PUTI1</UnqTradIdr>
<ClrSts>
<Clrd>
...
</Clrd>
</ClrSts>
99 Level PSTN

</RpTrad>
</LnData>
<CollData>
...
</CollData>
<LvlTp>PSTN</LvlTp>
</Crrctn>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>

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.

74
Table 42 - Valuation of SFT (only for SLB)
No Field Example XML Message
Unique Trade Identifier <SctiesFincgRptgTxRpt>
1 UTI1
(UTI) <TradData>
57 Market value 1000000 <Rpt>
<ValtnUpd>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
<UnqTradIdr>UTI1</UnqTradIdr>
<MktVal
Ccy="EUR">1000000</MktVal>
98 Action type VALU </LnData>
<CollData>
...
</CollData>
...
</ValtnUpd>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>

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
Unique Trade Identifier <SctiesFincgRptgTxRpt>
1 UTI1
(UTI) <TradData>
<Rpt>
98 Action type COLU
<CollUpd>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
99 Level <RpTrad>

<UnqTradIdr>UTI1</UnqTradIdr>
</RpTrad>
</LnData>
<CollData>

75
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
Unique Trade Identifier < SctiesFincgRptgTxRpt>
1
(UTI) <TradData>
<CollUpd>
98 Action type COLU
…
<CtrPtyData>
...
</CtrPtyData>
<LnData>
…
</LnData>
<CollData>
99 Level
...
</CollData>
…
</CollUpd>
</TradData>
…
</SctiesFincgRptgTxRpt>

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.

76
Table 45 - Early termination of an SFT
No Field Example XML Message
Unique Trade Identifier <SctiesFincgRptgTxRpt>
1 UTI1
(UTI) <TradData>
<Rpt>
98 Action type ETRM
<EarlyTermntn>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
<UnqTradIdr>UTI1</UnqTradIdr>
</LnData>
99 Level <CollData>
...
</CollData>
...
</EarlyTermntn>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>

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
Unique Trade Identifier <SctiesFincgRptgTxRpt>
1 UTI1
(UTI) <TradData>
<Rpt>
98 Action type EROR
<Err>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
<UnqTradIdr>UTI1</UnqTradIdr>
</LnData>
99 Level
<CollData>
...
</CollData>
...
</Err>
</Rpt>
</TradData>

77
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
Report tracking <SctiesFincgRptgTxRpt>
2 RTN1
number <TradData>
<Rpt>
5 Cleared true
<New>
2020-04- ...
6 Clearing timestamp
22T16:41:07Z <CtrPtyData>

78
Table 47 - From CCP and CM perspective
No Field Example XML Message
{LEI} of CCP ...
7 CCP
O </CtrPtyData>
Master agreement <LnData>
9 OTHR
Type <RpTrad>
Other master CCPClearing
10 <RptTrckgNb>RTN1</RptTrckgNb>
agreement type Conditions
<ExctnDtTm>2020-04-
22T16:41:07Z</ExctnDtTm>
<ClrSts>
<Clrd>
<CCP>

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

<OthrMstrAgrmtDtls>CCPClearingCondition
s</OthrMstrAgrmtDtls>
</MstrAgrmt>
</RpTrad>
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>

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:

79
 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

Unique Trade <SctiesFincgRptgTxRpt>
1 UTI2
Identifier (UTI) <TradData>
Report tracking <Rpt>
2
number <New>
<CtrPtyData>
5 Cleared true
...
2020-04- </CtrPtyData>
6 Clearing timestamp <LnData>
22T16:41:07Z
{LEI} of CCP <RpTrad>
7 CCP <UnqTradIdr>UTI2</UnqTradIdr>
O
Master agreement
9 OTHR <ExctnDtTm>2020-04-
Type
Other master CCPClearing 22T14:41:07Z</ExctnDtTm>
10 <ClrSts>
agreement type Conditions
<Clrd>
<CCP>

<LEI>BBBBBBBBBB1111111111</LEI>
</CCP>
<ClrDtTm>2020-04-
22T16:41:07Z</ClrDtTm>
</Clrd>
</ClrSts>
<MstrAgrmt>
<Tp>
<Tp>OTHR</Tp>
2020-04- </Tp>
12 Execution timestamp
22T14:41:07Z
<OthrMstrAgrmtDtls>CCPClearingCondition
s</OthrMstrAgrmtDtls>
</MstrAgrmt>
</RpTrad>
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>

80
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
Unique Trade <SctiesFincgRptgTxRpt>
1 UTI2
Identifier (UTI) <TradData>
Report tracking <Rpt>
2 UTI1
number <New>
...
5 Cleared true
<CtrPtyData>
2020-04- ...
6 Clearing timestamp </CtrPtyData>
22T16:41:07Z
{LEI} of CCP <LnData>
7 CCP <RpTrad>
O
Master agreement <UnqTradIdr>UTI2</UnqTradIdr>
9 OTHR <ExctnDtTm>2020-04-
Type
Other master CCPClearing 22T14:41:07Z</ExctnDtTm>
10 <ClrSts>
agreement type Conditions
<Clrd>
<CCP>

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

<RptTrckgNb>UTI1</RptTrckgNb>
</Clrd>
</ClrSts>
<MstrAgrmt>
2020-04- <Tp>
12 Execution timestamp <Tp>OTHR</Tp>
22T14:41:07Z
</Tp>

<OthrMstrAgrmtDtls>CCPClearingCondition
s</OthrMstrAgrmtDtls>
</MstrAgrmt>
</RpTrad>
</LnData>
<CollData>
...
</CollData>
...
</New>

81
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
Unique Trade <SctiesFincgRptgTxRpt>
1 UTI2
Identifier (UTI) <TradData>
Report tracking <Rpt>
2
number <New>
...
5 Cleared true
<CtrPtyData>
2020-04- ...
6 Clearing timestamp </CtrPtyData>
22T16:41:07Z
{LEI} of CCP <LnData>
7 CCP <RpTrad>
O
Master agreement <UnqTradIdr>UTI2</UnqTradIdr>
9 OTHR <ExctnDtTm>2020-04-
Type
Other master CCPClearing 22T14:41:07Z</ExctnDtTm>
10 <ClrSts>
agreement type Conditions
2020-04- <Clrd>
12 Execution timestamp <CCP>
22T14:41:07Z

<LEI>BBBBBBBBBB1111111111</LEI>
</CCP>
<ClrDtTm>2020-04-
Delivery by Value 22T16:41:07Z</ClrDtTm>
19 true
(“DBV”) indicator </Clrd>
</ClrSts>
<MstrAgrmt>
<Tp>
<Tp>OTHR</Tp>

82
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
Unique Trade
1 UTI2
Identifier (UTI)
Report tracking <SctiesFincgRptgTxRpt>
2 UTI1
number <TradData>
<Rpt>
5 Cleared true
<New>
2020-04- ...
6 Clearing timestamp
22T16:41:07Z <CtrPtyData>
{LEI} of CCP ...
7 CCP </CtrPtyData>
O
Master agreement <LnData>
9 OTHR <RpTrad>
Type
Other master CCPClearing <UnqTradIdr>UTI2</UnqTradIdr>
10 <ExctnDtTm>2020-04-
agreement type Conditions
2020-04- 22T14:41:07Z</ExctnDtTm>
12 Execution timestamp <ClrSts>
22T14:41:07Z
<Clrd>
<CCP>

<LEI>BBBBBBBBBB1111111111</LEI>
</CCP>
<ClrDtTm>2020-04-
Delivery by Value 22T16:41:07Z</ClrDtTm>
19 true
(“DBV”) indicator
<RptTrckgNb>UTI1</RptTrckgNb>
</Clrd>
</ClrSts>
<MstrAgrmt>
<Tp>

83
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
Field Example XML Message
o
Unique Trade
1 UTI1
Identifier (UTI)
Report tracking <SctiesFincgRptgTxRpt>
2
number <TradData>
<Rpt>
5 Cleared false
<New>
...
6 Clearing timestamp
<CtrPtyData>
...
7 CCP
</CtrPtyData>
<LnData>
<RpTrad>
<UnqTradIdr>UTI1</UnqTradIdr>
<ExctnDtTm>2020-04-
22T14:41:07Z</ExctnDtTm>
2020-04- </RpTrad>
12 Execution timestamp
22T14:41:07Z </LnData>
<CollData>
...
</CollData>
...
</New>

84
Table 52 - Non-cleared SFT
N
Field Example XML Message
o
</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
Master agreement <SctiesFincgRptgTxRpt>
9 GMRA
type <TradData>
Other master <Rpt>
10 <New>
agreement type
...
<CtrPtyData>
...
</CtrPtyData>
Master agreement <LnData>
11 2011
version <RpTrad>
<MstrAgrmt>
<Tp>
<Tp>GMRA</Tp>

85
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
Master agreement <SctiesFincgRptgTxRpt>
9 OTHR
type <TradData>
Other master CCP O Repo <Rpt>
10 <New>
agreement type Rulebook
<LnData>
...
<CtrPtyData>
...
</CtrPtyData>
<RpTrad>
<MstrAgrmt>
Master agreement <Tp>
11 <Tp>OTHR</Tp>
version
</Tp>
<OthrMstrAgrmtDtls>CCP O
Repo Rulebook</OthrMstrAgrmtDtls>
</MstrAgrmt>
</RpTrad>
</LnData>
<CollData>

86
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
Master agreement <SctiesFincgRptgTxRpt>
9 OTHR
type <TradData>
Other master <Rpt>
10 Undocumented <New>
agreement type
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
<RpTrad>
<MstrAgrmt>
<Tp>
<Tp>OTHR</Tp>
</Tp>

Master agreement <OthrMstrAgrmtDtls>Undocumented</Oth

11 rMstrAgrmtDtls>
version
</MstrAgrmt>
</RpTrad>
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>

87
 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
2020-04- <SctiesFincgRptgTxRpt>
12 Execution timestamp
22T16:41:07Z <TradData>
<Rpt>
<New>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
<RpTrad>
<ExctnDtTm>2020-04-
22T16:41:07Z</ExctnDtTm>
Value date (Start
13 2020-04-24 <ValDt>2020-04-24</ValDt>
date)
</RpTrad>
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>

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.

88
Table 57 - Forward
No Field Example XML Message
2020-04- <SctiesFincgRptgTxRpt>
12 Execution timestamp
22T16:41:07Z <TradData>
<Rpt>
<New>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
<RpTrad>
<ExctnDtTm>2020-04-
22T16:41:07Z</ExctnDtTm>
Value date (Start
13 2020-05-22 <ValDt>2020-05-22</ValDt>
date)
</RpTrad>
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>

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.

89
Table 58 - Open term
No Field Example XML Message
Maturity date (End <SctiesFincgRptgTxRpt>
14
date) <TradData>
<Rpt>
16 Minimum notice period 1
<New>
...
17 Earliest call-back date
<CtrPtyData>
...
</CtrPtyData>
<LnData>
<RpTrad>
<MinNtcePrd>1</MinNtcePrd>
<Term>
<Opn>NOAP</Opn>
</Term>
</RpTrad>
21 Open term true
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>

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
Maturity date (End <SctiesFincgRptgTxRpt>
14 2020-05-22
date) <TradData>
<Rpt>
16 Minimum notice period 5
<New>
...
17 Earliest call-back date 2020-05-07
<CtrPtyData>
...
21 Open term false </CtrPtyData>
<LnData>

90
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

91
 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
General collateral <SctiesFincgRptgTxRpt>
18 SPEC
indicator <TradData>
Delivery By Value <Rpt>
19 false
(‘DBV’) indicator <New>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
<RpTrad>
<GnlColl>SPEC</GnlColl>
<DlvryByVal>false</DlvryByVal>
Method used to provide
20 TTCA
collateral
<CollDlvryMtd>TTCA</CollDlvryMtd>
</RpTrad>
</LnData>
<CollData>
...
</CollData>
...
</New>

92
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
General collateral <SctiesFincgRptgTxRpt>
18 GENE
indicator <TradData>
Delivery By Value <Rpt>
19 false
(‘DBV’) indicator <New>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
<RpTrad>
<GnlColl>GENE</GnlColl>
<DlvryByVal>false</DlvryByVal>

Method used to provide <CollDlvryMtd>SICA</CollDlvryMtd>

20 SICA
collateral </RpTrad>
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>

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.

93
Table 62 - DBV general collateral in title transfer
No Field Example XML Message
General collateral <SctiesFincgRptgTxRpt>
18 GENE
indicator <TradData>
Delivery By Value <Rpt>
19 true
(‘DBV’) indicator <New>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
<RpTrad>
<GnlColl>GENE</GnlColl>
<DlvryByVal>true</DlvryByVal>

Method used to provide <CollDlvryMtd>TTCA</CollDlvryMtd>

20 TTCA
collateral </RpTrad>
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>

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 pre-
agreed 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).

94
 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
<SctiesFincgRptgTxRpt>
1 UTI UTI1
<TradData>
<Rpt>
23 Fixed rate -0.23455
<New>
...
24 Day count convention A004
<CtrPtyData>
...
</CtrPtyData>
<LnData>
<UnqTradIdr>UTI1</UnqTradIdr>
<RpTrad>
<IntrstRate>
<Fxd>
<Rate>-0.23455</Rate>
<DayCntBsis>
<Cd>A004</Cd>
</DayCntBsis>
98 Action type NEWT </Fxd>
</IntrstRate>
</RpTrad>
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>

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>

95
Table 64 - Fixed rate – modification
No Field Example XML Message
<TradData>
23 Fixed rate 0.12345
<Rpt>
<Mod>
24 Day count convention A005
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>

<RpTrad><UnqTradIdr>UTI1</UnqTradIdr>
<IntrstRate>
<Fxd>
<Rate>0.12345</Rate>
<DayCntBsis>
<Cd>A005</Cd>
</DayCntBsis>
98 Action type MODI
</Fxd>
</IntrstRate>
</RpTrad>
</LnData>
<CollData>
...
</CollData>
...
</Mod>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>

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).

96
Table 65 - Floating rate – Initial report
No Field Example XML Message
EONA <SctiesFincgRptgTxRpt>
25 Floating rate <TradData>
Floating rate reference DAYS <Rpt>
26 <New>
period - time period
Floating rate reference 1 ...
27 <CtrPtyData>
period - multiplier
Floating rate payment WEEK ...
28 </CtrPtyData>
frequency - time period
Floating rate payment 1 <LnData>
29 <RpTrad>
frequency - multiplier
Floating rate reset DAYS <IntrstRate>
30 <Fltg>
frequency - time period
Floating rate reset 1 <RefRate>
31 <Indx>EONA</Indx>
frequency - multiplier
5 </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>
32 Spread <BsisPtSprd>5</BsisPtSprd>
</Fltg>
</IntrstRate>
</RpTrad>
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>

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.

97
 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
Principal amount on <SctiesFincgRptgTxRpt>
37
the value date 10162756.90 <TradData>
Principal amount on <Rpt>
38
the maturity date 10161551.48 <New>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
<RpTrad>
<PrncplAmt>
<ValDtAmt
Ccy="EUR">10162756.9</ValDtAmt>
<MtrtyDtAmt
Principal amount Ccy="EUR">10161551.48</MtrtyDtAmt>
39 EUR
currency </PrncplAmt>
</RpTrad>
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>

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, add-
on, 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.

98
 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.”

99
 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>
41 Security identifier {ISIN}
<New>
Classification of a ...
42 {CFI}
security <CtrPtyData>
Quantity or nominal ...
46 100000000
amount </CtrPtyData>
Currency of nominal <LnData>
48 EUR <SctiesLndg>
amount
Security or commodity <AsstTp>
49 99.5 <Scty>
price
<Id>DE0010877643</Id>
50 Price currency
<ClssfctnTp>DBFTFR</ClssfctnTp>
51 Security quality INVG <QtyOrNmnlVal>
<NmnlVal>
52 Maturity of the security 2030-04-22 <Amt
Jurisdiction of the Ccy="EUR">100000000</Amt>
53 DE </NmnlVal>
issuer

100
Table 67 - Bonds
No Field Example XML Message
{LEI} of the </QtyOrNmnlVal>
54 LEI of the issuer
issuer <UnitPric>
<Ptrg>99.5</Ptrg>
55 Security type GOVS
</UnitPric>
<Qlty>INVG</Qlty>
56 Loan value 99500000
<Mtrty>2030-04-22</Mtrty>
<Issr>
<Id>
<LEI>
NNNNNNNNNNNNNNNNNNNN </LEI>
</Id>

<JursdctnCtry>DE</JursdctnCtry>
</Issr>
<Tp>
<Cd>GOVS</Cd>
</Tp>

<ExclsvArrgmnt>false</ExclsvArrgmnt>
Exclusive
68 FALSE </Scty>
arrangements
</AsstTp>
<LnVal
Ccy="EUR">99500000</LnVal>
</SctiesLndg>
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>DBFTFR</

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).

101
 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
<SctiesFincgRptgTxRpt>
40 Type of asset SECU <TradData>
<Rpt>
41 Security identifier {ISIN} <New>
Classification of a ...
42 {CFI} <CtrPtyData>
security
Quantity or nominal ...
46 100000 </CtrPtyData>
amount
Security or commodity <LnData>
49 9.95 <SctiesLndg>
price
<AsstTp>
50 Price currency EUR <Scty>
<Id>FR0000120271</Id>
51 Security quality NOAP
<ClssfctnTp>ESVUFN</ClssfctnTp>
52 Maturity of the security 9999-12-31 <QtyOrNmnlVal>
Jurisdiction of the <Qty>100000</Qty>
53 FR </QtyOrNmnlVal>
issuer
{LEI} of the <UnitPric>
54 LEI of the issuer <MntryVal>
issuer
<Amt
55 Security type MEQU Ccy="EUR">9.95</Amt>
</MntryVal>
56 Loan value 995000 </UnitPric>
<Qlty>NOAP</Qlty>
<Mtrty>9999-12-31</Mtrty>
<Issr>
<Id>
<LEI>
529900S21EQ1BO4ESM68 </LEI>
</Id>

<JursdctnCtry>FR</JursdctnCtry>
Exclusive
68 FALSE </Issr>
arrangements
<Tp>
<Cd>MEQU</Cd>
</Tp>

<ExclsvArrgmnt>false</ExclsvArrgmnt>
</Scty>
</AsstTp>
<LnVal
Ccy="EUR">995000</LnVal>

102
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>
41 Security identifier {ISIN} <Rpt>
<New>
Classification of a
42 {CFI} ...
security
<CtrPtyData>
Quantity or nominal ...
46 100000
amount </CtrPtyData>
Security or commodity <LnData>
49 99.5
price <SctiesLndg>
50 Price currency EUR <AsstTp>
<Scty>
51 Security quality NOAP <Id>FR0010877000</Id>

103
Table 69 – Other securities without maturity
No Field Example XML Message
<ClssfctnTp> ESVUFN
52 Maturity of the security 9999-12-31
</ClssfctnTp>
Jurisdiction of the <QtyOrNmnlVal>
53 FR
issuer <Qty>100000</Qty>
{LEI} of the </QtyOrNmnlVal>
54 LEI of the issuer
issuer <UnitPric>
<MntryVal>
55 Security type OTHR
<Amt
Ccy="EUR">99.5</Amt>
56 Loan value 9950000
</MntryVal>
</UnitPric>
<Qlty>NOAP</Qlty>
<Mtrty>9999-12-31</Mtrty>
<Issr>
<Id>

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

<JursdctnCtry>FR</JursdctnCtry>
</Issr>
<Tp>
<Cd>OTHR</Cd>
</Tp>
Exclusive
68 FALSE
arrangements
<ExclsvArrgmnt>false</ExclsvArrgmnt>
</Scty>
</AsstTp>
<LnVal
Ccy="EUR">9950000</LnVal>
</SctiesLndg>
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>

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).

104
 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>
43 Base product NRGY <Rpt>
<New>
44 Sub - product OIL ...
<CtrPtyData>
45 Further sub - product BRNT
...
Quantity or nominal </CtrPtyData>
46 100000
amount <LnData>
47 Unit of measure BARL <SctiesLndg>
<AsstTp>
Securities or
49 60 <Cmmdty>
commodities price
<Clssfctn>
50 Price currency USD
<Nrgy>
<Oil>
<BasePdct>NRGY</Base
Pdct>
<SubPdct>OILP</SubPdc
t>
<AddtlSubPdct>BRNT</A
ddtlSubPdct>
</Oil>
</Nrgy>
</Clssfctn>
<Qty>
<Val>100000</Val>
<UnitOfMeasr>BARL</UnitO
56 Loan value 6000000 fMeasr>
</Qty>
<UnitPric>
<MntryVal>
<Amt
Ccy="USD">60</Amt>
</MntryVal>
</UnitPric>
</Cmmdty>
</AsstTp>
<LnVal
Ccy="USD">6000000</LnVal>
</SctiesLndg>

105
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>
59 Floating rebate rate EONA
…
Floating rebate rate DAYS <CtrPtyData>
60 reference period - time ...
period </CtrPtyData>
Floating rebate rate 1 <LnData>
61 reference period - ...
multiplier <TxLnData>
Floating rebate rate WEEK <SctiesLndg>
62 payment frequency - ...
time period <RbtRate>

106
Table 71 - Cash rebate SLB
No Field Example XML Message
Floating rebate rate 1 <Fltg>
63 payment frequency - <RefRate>
multiplier <Indx>EONA</Indx>
Floating rebate rate DAYS </RefRate>
64 reset frequency - time <Term>
period <Unit>DAYS</Unit>
Floating rebate rate 1 <Val>1</Val>
65 reset frequency - </Term>
multiplier <PmtFrqcy>
<Unit>WEEK</Unit>
<Val>1</Val>
</PmtFrqcy>
<RstFrqcy>
<Unit>DAYS</Unit>
<Val>1</Val>
</RstFrqcy>
<BsisPtSprd>5</BsisPtSprd>
</Fltg>
</RbtRate>
Spread of the rebate
66 5 </SctiesLndg>
rate </TxLnData>
</LnData>
<CollData>
...
</CollData>
...
</New>
</TradData>
...
</SctiesFincgRptgTxRpt>

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 (non-
rebate 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
<SctiesFincgRptgTxRpt>
67 Lending fee 1.23456 <TradData>
<Rpt>

107
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..

108
 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
Margin lending <SctiesFincgRptgTxRpt>
33 -100000
currency amount <TradData>
Margin lending <Rpt>
34 USD <New>
currency
Margin lending ...
33 50000 <CtrPtyData>
currency amount
Margin lending ...
34 GBP </CtrPtyData>
currency
Margin lending <LnData>
33 150000 <MrgnLndg>
currency amount
Margin lending <OutsdngMrgnLnAmt
34 EUR Ccy="EUR">150000</OutsdngMrgnLnAmt>
currency
Outstanding margin <ShrtMktValAmt
69 100000 Ccy="EUR">0</ShrtMktValAmt>
loan
Base currency of <MrgnLnAttr>
70 outstanding margin EUR <Amt>
loan <Amt Ccy="USD">-
100000</Amt>
<Amt
Ccy="GBP">50000</Amt>
<Amt
Ccy="EUR">100000</Amt>
</Amt>
</MrgnLnAttr>
</MrgnLndg>
71 Short market value 0 </LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>

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

109
 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
Margin lending <SctiesFincgRptgTxRpt>
33 -100000 <TradData>
currency amount
Margin lending <Rpt>
34 USD <New>
currency
Outstanding margin ...
69 0 <CtrPtyData>
loan
Base currency of ...
70 outstanding margin GBP </CtrPtyData>
loan <LnData>
<MrgnLndg>
<OutsdngMrgnLnAmt
Ccy="GBP">0</OutsdngMrgnLnAmt>
<ShrtMktValAmt
Ccy="GBP">500000</ShrtMktValAmt>
<MrgnLnAttr>
<Amt>
<Amt Ccy="USD">-
100000</Amt>
</Amt>
71 Short market value 500000 </MrgnLnAttr>
</MrgnLndg>
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>

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
Margin lending <SctiesFincgRptgTxRpt>
33 0
currency amount <TradData>

110
Table 75 - Credit in base currency and no short market value
No Field Example XML Message
Margin lending <Rpt>
34 USD
currency <New>
Outstanding margin ...
69 0
loan <CtrPtyData>
Base currency of ...
70 outstanding margin EUR </CtrPtyData>
loan <LnData>
<MrgnLndg>
<OutsdngMrgnLnAmt
Ccy="EUR">0</OutsdngMrgnLnAmt>
<ShrtMktValAmt
Ccy="EUR">0</ShrtMktValAmt>
<MrgnLnAttr>
<Amt>
<Amt Ccy="USD">0</Amt>
</Amt>
</MrgnLnAttr>
71 Short market value 0 </MrgnLndg>
</LnData>
<CollData>
...
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>

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”.

111
 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
LEI of <SctiesFincgRptgTxRpt>
Reporting
1.3 counterparty <TradData>
counterparty
A <Rpt>
LEI of <New>
1.11 Other counterparty counterparty <CtrPtyData>
B <CtrPtyData>
1.9 Counterparty side GIVE <RptgCtrPty>
<Id>
{LEI} of
1.18 Agent lender agent lender <LEI>12345678901234500000</LEI>
F </Id>
Unique Transaction <Sd>GIVE</Sd>
1 UTI1
Identifier ('UTI') </RptgCtrPty>
<OthrCtrPty>
3 Event date 24/04/2020 <Id>

112
Table 76 - Single transaction with collateral basket
No Field Example XML Message

9 Master agreement GMRA <LEI>ABCDEFGHIJKLMNOPQRST</LEI>

Collateralisation of </Id>
73 FALSE </OthrCtrPty>
net exposure
Collateral basket <OthrPtyData>
96 {ISIN} <AgtLndr>
identifier
98 Action type NEWT <LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
</AgtLndr>
LEI of </OthrPtyData>
Reporting
1.3 counterparty </CtrPtyData>
counterparty
A </CtrPtyData>
LEI of <LnData>
1.11 Other counterparty counterparty <RpTrad>
B
1.9 Counterparty side GIVE <UnqTradIdr>UTI1</UnqTradIdr>
<EvtDt>2020-04-24</EvtDt>
{LEI} of <MstrAgrmt>
1.18 Agent lender agent lender <Tp>
F <Tp>GMRA</Tp>
Unique Transaction </Tp>
1 UTI2
Identifier ('UTI') </MstrAgrmt>
</RpTrad>
3 Event date 24/04/2020 </LnData>
<CollData>
9 Master agreement GMRA <RpTrad>
Collateralisation of
73 FALSE <NetXpsrCollstnInd>false</NetXpsrCollstnI
net exposure
nd>
Collateral basket <BsktIdr>
96 {ISIN}
identifier <Id>GB00BH4HKS39</Id>
</BsktIdr>
</RpTrad>
</CollData>
...
</New>
</Rpt>
<Rpt>
<New>
<CtrPtyData>
98 Action type NEWT <CtrPtyData>
<RptgCtrPty>
<Id>

<LEI>12345678901234500000</LEI>
</Id>
<Sd>GIVE</Sd>
</RptgCtrPty>
<OthrCtrPty>
<Id>

113
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>

<UnqTradIdr>UTI2</UnqTradIdr>
<EvtDt>2020-04-24</EvtDt>
<MstrAgrmt>
<Tp>
<Tp>GMRA</Tp>
</Tp>
</MstrAgrmt>
</RpTrad>
</LnData>
<CollData>
<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”).

114
Table 77 - Single transaction without basket at time of reporting
No Field Example XML Message
LEI of <SctiesFincgRptgTxRpt>
Reporting
1.3 counterparty <TradData>
counterparty
A <Rpt>
LEI of <New>
1.11 Other counterparty counterparty <CtrPtyData>
B <CtrPtyData>
<RptgCtrPty>
1.9 Counterparty side GIVE <Id>
{LEI} of
1.18 Agent lender agent lender <LEI>12345678901234500000</LEI>
F </Id>
Unique Transaction <Sd>GIVE</Sd>
1 UTI1 </RptgCtrPty>
Identifier ('UTI')
<OthrCtrPty>
3 Event date 24/04/2020 <Id>

9 Master agreement GMRA <LEI>ABCDEFGHIJKLMNOPQRST</LEI>

</Id>
Collateralisation of </OthrCtrPty>
73 FALSE
net exposure <OthrPtyData>
Collateral basket <AgtLndr>
96 NTAV
identifier
<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
</AgtLndr>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
<RpTrad>

<UnqTradIdr>UTI1</UnqTradIdr>
<EvtDt>2020-04-24</EvtDt>
<MstrAgrmt>
<Tp>
<Tp>GMRA</Tp>
</Tp>
98 Action type NEWT
</MstrAgrmt>
</RpTrad>
</LnData>
<CollData>
<RpTrad>

<NetXpsrCollstnInd>false</NetXpsrCollstnI
nd>
<BsktIdr>
<Id>NTAV</Id>
</BsktIdr>
</RpTrad>
</CollData>
...

115
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
LEI of <SctiesFincgRptgTxRpt>
Reporting
1.3 counterparty <TradData>
counterparty
A <Rpt>
LEI of <New>
1.11 Other counterparty counterparty <CtrPtyData>
B <CtrPtyData>
<RptgCtrPty>
1.9 Counterparty side GIVE
<Id>
{LEI} of
1.18 Agent lender <LEI>12345678901234500000</LEI>
agent lender
Unique Transaction </Id>
1 UTI1 <Sd>GIVE</Sd>
Identifier ('UTI')
</RptgCtrPty>
3 Event date 24/04/2020 <OthrCtrPty>
<Id>
9 Master agreement GMRA
<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
Collateralisation of </Id>
73 TRUE
net exposure </OthrCtrPty>
Collateral basket <OthrPtyData>
96 {ISIN}
identifier <AgtLndr>
98 Action type NEWT <LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
LEI of </AgtLndr>
Reporting </OthrPtyData>
1.3 counterparty
counterparty </CtrPtyData>
A

116
Table 78 - Net exposure basis with basket
No Field Example XML Message
LEI of </CtrPtyData>
1.11 Other counterparty counterparty <LnData>
B <RpTrad>
1.9 Counterparty side GIVE <UnqTradIdr>UTI1</UnqTradIdr>
{LEI} of <EvtDt>2020-04-24</EvtDt>
1.18 Agent lender <MstrAgrmt>
agent lender
<Tp>
Unique Transaction
1 UTI2 <Tp>GMRA</Tp>
Identifier ('UTI')
</Tp>
3 Event date 24/04/2020 </MstrAgrmt>
</RpTrad>
9 Master agreement GMRA </LnData>
<CollData>
Collateralisation of <RpTrad>
73 TRUE
net exposure
Collateral basket <NetXpsrCollstnInd>true</NetXpsrCollstnIn
96 {ISIN} d>
identifier
<BsktIdr>
<Id>GB00BH4HKS39</Id>
</BsktIdr>
</RpTrad>
</CollData>
...
</New>
</Rpt>
<Rpt>
<New>
<CtrPtyData>
<CtrPtyData>
<RptgCtrPty>
<Id>

<LEI>12345678901234500000</LEI>
98 Action type NEWT </Id>
<Sd>GIVE</Sd>
</RptgCtrPty>
<OthrCtrPty>
<Id>

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

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

117
Table 78 - Net exposure basis with basket
No Field Example XML Message
</CtrPtyData>
<LnData>
<RpTrad>

<UnqTradIdr>UTI2</UnqTradIdr>
<EvtDt>2020-04-24</EvtDt>
<MstrAgrmt>
<Tp>
<Tp>GMRA</Tp>
</Tp>
</MstrAgrmt>
</RpTrad>
</LnData>
<CollData>
<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
Collateralisation of net <SctiesFincgRptgTxRpt>
73 true <TradData>
exposure
Collateral basket <Rpt>
96 NTAV <New>
identifier
...
<CtrPtyData>
98 Action type NEWT ...
</CtrPtyData>

118
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
<SctiesFincgRptgTxRpt>
76 Cash collateral amount 1000000 <TradData>
<Rpt>
<New>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
...
Cash collateral </LnData>
77 EUR
currency <CollData>
<RpTrad>
<AsstTp>
<Csh>
<Amt
Ccy="EUR">1000000</Amt>
</Csh>
</AsstTp>

119
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
Type of collateral <SctiesFincgRptgTxRpt>
75 CASH <TradData>
component
<Rpt>
76 Cash collateral amount 0 <CollUpd>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
...
</LnData>
<CollData>
<RpTrad>
<AsstTp>
Cash collateral <Csh>
77 EUR
currency <Amt Ccy="EUR">0</Amt>
</Csh>
</AsstTp>
</RpTrad>
</CollData>
...
</CollUpd>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>

120
 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
<SctiesFincgRptgTxRpt>
76 Cash collateral amount 100000
<TradData>
Cash collateral <Rpt>
77 EUR
currency <New>
...
<CtrPtyData>
89 Haircut or margin 0
...
</CtrPtyData>

121
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
<SctiesFincgRptgTxRpt>
76 Cash collateral amount 105000
<TradData>
Cash collateral <Rpt>
77 USD
currency <New>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
...
</LnData>
<CollData>
<RpTrad>
89 Haircut or margin 0
<AsstTp>
<Csh>
<Amt
Ccy="USD">105000</Amt>

<HrcutOrMrgn>0</HrcutOrMrgn>
</Csh>
</AsstTp>
</RpTrad>

122
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
<SctiesFincgRptgTxRpt>
76 Cash collateral amount 55000
<TradData>
Cash collateral <Rpt>
77 EUR
currency <New>
...
89 Haircut or margin 0
<CtrPtyData>
...
88 Collateral market value 60000
</CtrPtyData>
<LnData>
...
</LnData>
<CollData>
<RpTrad>
<AsstTp>
<Scty>
<MktVal
Ccy="EUR">60000</MktVal>

<HrcutOrMrgn>5</HrcutOrMrgn>
</Scty>
89 Haircut or margin 5
<Csh>
<Amt
Ccy="EUR">55000</Amt>

<HrcutOrMrgn>0</HrcutOrMrgn>
</Csh>
</AsstTp>
</RpTrad>
</CollData>
...
</New>
</Rpt>

123
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
<SctiesFincgRptgTxRpt>
88 Collateral market value 110000
<TradData>
<Rpt>
89 Haircut or margin 6.25
<New>
...
88 Collateral market value 50000
<CtrPtyData>
...
</CtrPtyData>
<LnData>
...
</LnData>
<CollData>
<RpTrad>
<AsstTp>
<Scty>
<MktVal
Ccy="EUR">110000</MktVal>
89 Haircut or margin 6.25
<HrcutOrMrgn>6.25</HrcutOrMrgn>
</Scty>
<Scty>
<MktVal
Ccy="EUR">50000</MktVal>

<HrcutOrMrgn>6.25</HrcutOrMrgn>
</Scty>
</AsstTp>
</RpTrad>
</CollData>

124
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.

125
 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.

126
Table 86 - Plain vanilla Bonds
No Field Example XML Message
<SctiesFincgRptgTxRpt>
3 Event date 2020-04-24 <TradData>
Type of the collateral <Rpt>
75 SECU <New>
component
Identification of a ...
78 security used as {ISIN} <CtrPtyData>
collateral ...
Classification of a </CtrPtyData>
79 security used as {CFI} <LnData>
collateral <RpTrad>
<EvtDt>2020-04-24</EvtDt>
Collateral quantity or
83 100000000 </RpTrad>
nominal amount
</LnData>
Currency of collateral <CollData>
85 EUR
nominal amount <RpTrad>
86 Price currency <AsstTp>
<Scty>
<Id>DE0010877643</Id>
87 Price per unit 102
<ClssfctnTp>DBFTFR</ClssfctnTp>
88 Collateral market value 102000000 <NmnlVal>
<Amt
89 Haircut or margin 2 Ccy="EUR">100000000</Amt>
</NmnlVal>
90 Collateral quality INVG </QtyOrNmnlVal>
<UnitPric>
Maturity date of the <Ptrg>102</Ptrg>
91 2030-04-22
security </UnitPric>
Jurisdiction of the <MktVal
92 DE
issuer Ccy="EUR">102000000</MktVal>
{LEI} of the
93 LEI of the issuer
issuer <HrcutOrMrgn>2</HrcutOrMrgn>
<Qlty>INVG</Qlty>
94 Collateral type GOVS <Mtrty>2030-04-22</Mtrty>
Availability for collateral <Issr>
95 true <Id>
reuse
<LEI>NNNNNNNNNNNNNNNNNNNN
</LEI>
</Id>

<JursdctnCtry>DE</JursdctnCtry>
</Issr>
98 Action type NEWT <Tp>
<Cd>GOVS</Cd>
</Tp>

<AvlblForCollReuse>true</AvlblForCollReu
se>
</Scty>

127
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>
Type of the collateral <Rpt>
75 SECU
component <New>
Identification of a ...
78 security used as {ISIN} <CtrPtyData>
collateral ...
Classification of a </CtrPtyData>
79 security used as {CFI} <LnData>
collateral <RpTrad>
Collateral quantity or <EvtDt>2020-04-24</EvtDt>
83 100000000
nominal amount </RpTrad>
Currency of collateral </LnData>
85 EUR <CollData>
nominal amount
<RpTrad>
86 Price currency <AsstTp>
<Scty>
87 Price per unit 102 <Id>ES0010877643</Id>

128
Table 87 - Perpetual bonds
No Field Example XML Message

88 Collateral market value 102000000 <ClssfctnTp>DBFTPR</ClssfctnTp>

<QtyOrNmnlVal>
89 Haircut or margin 2 <NmnlVal>
<Amt
90 Collateral quality INVG Ccy="EUR">100000000</Amt>
</NmnlVal>
Maturity date of the </QtyOrNmnlVal>
91 9999-12-31
security <UnitPric>
Jurisdiction of the <Ptrg>102</Ptrg>
92 ES
issuer </UnitPric>
{LEI} of the <MktVal
93 LEI of the issuer
issuer Ccy="EUR">102000000</MktVal>
94 Collateral type GOVS
<HrcutOrMrgn>2</HrcutOrMrgn>
Availability for collateral <Qlty>INVG</Qlty>
95 true <Mtrty>9999-12-31</Mtrty>
reuse
<Issr>
<Id>

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

<JursdctnCtry>ES</JursdctnCtry>
</Issr>
<Tp>
<Cd>GOVS</Cd>
</Tp>
98 Action type NEWT
<AvlblForCollReuse>true</AvlblForCollReu
se>
</Scty>
</AsstTp>
</RpTrad>
</CollData>
...
</New>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>

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

129
 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
<SctiesFincgRptgTxRpt>
3 Event date 2020-04-24 <TradData>
Type of the collateral <Rpt>
75 SECU <New>
component
Identification of a ...
78 security used as {ISIN} <CtrPtyData>
collateral ...
Classification of a </CtrPtyData>
79 security used as {CFI} <LnData>
collateral <RpTrad>
<EvtDt>2020-04-24</EvtDt>
Collateral quantity or
83 10000000 </RpTrad>
nominal amount
</LnData>
86 Price currency EUR <CollData>
<RpTrad>
87 Price per unit 10.5 <AsstTp>
<Scty>
<Id> FR0000120271</Id>
88 Collateral market value 105000000
<ClssfctnTp> ESVUFN
</ClssfctnTp>
89 Haircut or margin 5 <QtyOrNmnlVal>
<Qty>100000000</Qty>
90 Collateral quality NOAP </QtyOrNmnlVal>
<UnitPric>
Maturity date of the
91 9999-12-31 <MntryVal>
security
<Amt
Jurisdiction of the Ccy="EUR">10.5</Amt>
92 FR
issuer </MntryVal>
{LEI} of the </UnitPric>
93 LEI of the issuer
issuer <MktVal
Ccy="EUR">105000000</MktVal>
94 Collateral type MEQU
Availability for collateral <HrcutOrMrgn>5</HrcutOrMrgn>
95 true <Qlty>NOAP</Qlty>
reuse
<Mtrty>9999-12-31</Mtrty>
98 Action type NEWT <Issr>
<Id>

130
Table 88 - Main Index Equities
No Field Example XML Message

<LEI>529900S21EQ1BO4ESM68</LEI>
</Id>

<JursdctnCtry>FR</JursdctnCtry>
</Issr>
<Tp>
<Cd>MEQU</Cd>
</Tp>

<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.

131
Table 89 - Variation margin update to SLB
No Field Example XML Message
LEI of <SctiesFincgRptgTxRpt>
Reporting
1.3 counterparty <TradData>
counterparty
A <Rpt>
LEI of <CollUpd>
1.11 Other counterparty counterparty ...
B <CtrPtyData>
{LEI} of the <CtrPtyData>
1.18 Agent lender agent lender <RptgCtrPty>
F <Id>
Unique Transaction
1 UTI1
Identifier ('UTI') <LEI>12345678901234500000</LEI>
3 Event date 24/04/2020 </Id>
</RptgCtrPty>
<OthrCtrPty>
9 Master agreement GMSLA <Id>
Collateralisation of
73 FALSE <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
net exposure
</Id>
Type of the collateral
75 SECU </OthrCtrPty>
component
<OthrPtyData>
Identification of a
<AgtLndr>
78 security used as {ISIN}
collateral
<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
Classification of a </AgtLndr>
79 security used as {CFI} </OthrPtyData>
collateral </CtrPtyData>
Collateral quantity or </CtrPtyData>
83 101000099
nominal amount <LnData>
Currency of collateral <SctiesLndg>
85 EUR
nominal amount
86 Price currency
<UnqTradIdr>UTI1</UnqTradIdr>
<EvtDt>2020-04-24</EvtDt>
87 Price per unit 100.99 <MstrAgrmt>
Collateral market <Tp>
88 102000000 <Tp>GMSLA</Tp>
value
</Tp>
89 Haircut or margin 0 </MstrAgrmt>
</SctiesLndg>
90 Collateral quality INVG </LnData>
<CollData>
Maturity date of the <SctiesLndg>
91 22/04/2030
security <Collsd>
Jurisdiction of the <AsstTp>
92 DE
issuer <Scty>
{LEI} of the <Id>DE0010877643</Id>
93 LEI of the issuer
issuer
<ClssfctnTp>DBFTFR</ClssfctnTp>
94 Collateral type GOVS <QtyOrNmnlVal>

132
Table 89 - Variation margin update to SLB
No Field Example XML Message
Availability for <NmnlVal>
95 TRUE <Amt
collateral reuse
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>

<JursdctnCtry>DE</JursdctnCtry>
98 Action type COLU </Issr>
<Tp>
<Cd>GOVS</Cd>
</Tp>

<AvlblForCollReuse>true</AvlblForCollReu
se>
</Scty>
</AsstTp>

<NetXpsrCollstnInd>false</NetXpsrCollstnI
nd>
</Collsd>
</SctiesLndg>
</CollData>
...
</CollUpd>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>

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

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

134
Table 90 - Variation margin update to a repo
No Field Example XML Message
{LEI} of the
93 LEI of the issuer <ClssfctnTp>DBFTFR</ClssfctnTp>
issuer
<QtyOrNmnlVal>
94 Collateral type GOVS <NmnlVal>
Availability for <Amt
95 TRUE Ccy="EUR">101000099</Amt>
collateral reuse
</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>

<JursdctnCtry>DE</JursdctnCtry>
98 Action type COLU </Issr>
<Tp>
<Cd>GOVS</Cd>
</Tp>

<AvlblForCollReuse>true</AvlblForCollReu
se>
</Scty>
</AsstTp>

<NetXpsrCollstnInd>false</NetXpsrCollstnI
nd>
</RpTrad>
</CollData>
...
</CollUpd>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>

135
 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
LEI of <SctiesFincgRptgTxRpt>
Reporting
1.3 counterparty <TradData>
counterparty
A <Rpt>
LEI of <CollUpd>
1.11 Other counterparty counterparty ...
B <CtrPtyData>
{LEI} of the <CtrPtyData>
1.18 Agent lender
agent lender F <RptgCtrPty>
Unique Transaction <Id>
1 UTI1
Identifier ('UTI')
<LEI>12345678901234500000</LEI>
3 Event date 24/04/2020
</Id>
</RptgCtrPty>
9 Master agreement GMSLA <OthrCtrPty>
Collateralisation of <Id>
73 FALSE
net exposure
<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
Type of the
</Id>
75 collateral SECU
</OthrCtrPty>
component
<OthrPtyData>
Identification of a
<AgtLndr>
78 security used as {ISIN}
collateral
<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
Classification of a </AgtLndr>
79 security used as {CFI}
</OthrPtyData>
collateral </CtrPtyData>
Collateral quantity </CtrPtyData>
83 99000291
or nominal amount <LnData>
Currency of <SctiesLndg>
85 collateral nominal EUR <EvtDt>2020-04-24</EvtDt>
amount
86 Price currency <UnqTradIdr>UTI1</UnqTradIdr>
<MstrAgrmt>
<Tp>
87 Price per unit 103.03
<Tp>GMSLA</Tp>
Collateral market </Tp>
88 102000000 </MstrAgrmt>
value
</SctiesLndg>
89 Haircut or margin 0 </LnData>

136
Table 91 - Variation margining of an SLB with return of the same securities to the
collateral provider
No Field Example XML Message
<CollData>
90 Collateral quality INVG <SctiesLndg>
Maturity date of the <Collsd>
91 22/04/2030 <AsstTp>
security
Jurisdiction of the <Scty>
92 DE <Id>DE0010877643</Id>
issuer
{LEI} of the <ClssfctnTp>DBFTFR</ClssfctnTp>
93 LEI of the issuer
issuer <QtyOrNmnlVal>
94 Collateral type GOVS <NmnlVal>
<Amt
Availability for Ccy="EUR">99000291</Amt>
95 TRUE
collateral reuse </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>
98 Action type COLU
<JursdctnCtry>DE</JursdctnCtry>
</Issr>
<Tp>
<Cd>GOVS</Cd>
</Tp>

<AvlblForCollReuse>true</AvlblForCollReu
se>
</Scty>
</AsstTp>

<NetXpsrCollstnInd>false</NetXpsrCollstnI
nd>
</Collsd>
</SctiesLndg>
</CollData>
...
</CollUpd>

137
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
LEI of <SctiesFincgRptgTxRpt>
Reporting
1.3 counterparty <TradData>
counterparty
A <Rpt>
LEI of <CollUpd>
1.11 Other counterparty counterparty ...
B <CtrPtyData>
{LEI} of the <CtrPtyData>
1.18 Agent lender
agent lender F <RptgCtrPty>
Unique Transaction <Id>
1 UTI1
Identifier ('UTI')
<LEI>12345678901234500000</LEI>
3 Event date 24/04/2020 </Id>
</RptgCtrPty>
9 Master agreement GMRA <OthrCtrPty>
<Id>
Collateralisation of
73 FALSE
net exposure <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
Type of the </Id>
75 collateral SECU </OthrCtrPty>
component <OthrPtyData>
Identification of a <AgtLndr>
78 security used as {ISIN}
collateral <LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
Classification of a </AgtLndr>
79 security used as {CFI} </OthrPtyData>
collateral </CtrPtyData>
Collateral quantity </CtrPtyData>
83 99000291
or nominal amount <LnData>

138
Table 92 - Variation margining of a repo with return of the same securities to the
collateral provider
No Field Example XML Message
Currency of <RpTrad>
85 collateral nominal EUR <EvtDt>2020-04-24</EvtDt>
amount
<UnqTradIdr>UTI1</UnqTradIdr>
86 Price currency <MstrAgrmt>
<Tp>
87 Price per unit 103.03 <Tp>GMRA</Tp>
Collateral market </Tp>
88 102000000 </MstrAgrmt>
value
</RpTrad>
89 Haircut or margin 0 </LnData>
<CollData>
90 Collateral quality INVG <RpTrad>
<AsstTp>
Maturity date of the <Scty>
91 22/04/2030
security <Id>DE0010877643</Id>
Jurisdiction of the
92 DE <ClssfctnTp>DBFTFR</ClssfctnTp>
issuer
{LEI} of the <QtyOrNmnlVal>
93 LEI of the issuer <NmnlVal>
issuer
<Amt
94 Collateral type GOVS Ccy="EUR">99000291</Amt>
</NmnlVal>
Availability for </QtyOrNmnlVal>
95 TRUE
collateral reuse <UnitPric>
<Ptrg>103.03</Ptrg>
</UnitPric>
<MktVal
Ccy="EUR">102000000</MktVal>

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

98 Action type COLU <LEI>NNNNNNNNNNNNNNNNNNNN

</LEI>
</Id>

<JursdctnCtry>DE</JursdctnCtry>
</Issr>
<Tp>
<Cd>GOVS</Cd>
</Tp>

<AvlblForCollReuse>true</AvlblForCollReu
se>
</Scty>

139
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.

140
 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
LEI of
Reporting <SctiesFincgRptgTxRpt>
1.3 counterparty
counterparty <TradData>
A
<Rpt>
LEI of <CollUpd>
1.11 Other counterparty counterparty …
B <CtrPtyData>
{LEI} of <CtrPtyData>
1.18 Agent lender agent lender <RptgCtrPty>
F <Id>
Unique Transaction
1 UTI1
Identifier ('UTI') <LEI>12345678901234500000</LEI>
3 Event date 24/04/2020 </Id>
</RptgCtrPty>
<OthrCtrPty>
9 Master agreement GMSLA
<Id>
Collateralisation of
73 TRUE <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
net exposure
Type of the collateral </Id>
75 CASH </OthrCtrPty>
component

141
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
Cash collateral <OthrPtyData>
76 <AgtLndr>
amount 100000000
Cash collateral
77 EUR <LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
currency
</AgtLndr>
98 Action type COLU </OthrPtyData>
</CtrPtyData>
LEI of
Reporting </CtrPtyData>
1.3 counterparty
counterparty <LnData>
A
<SctiesLndg>
LEI of
<EvtDt>2020-04-24</EvtDt>
1.11 Other counterparty counterparty
B
<UnqTradIdr>UTI1</UnqTradIdr>
{LEI} of <MstrAgrmt>
1.18 Agent lender agent lender <Tp>
F <Tp>GMSLA</Tp>
Unique Transaction </Tp>
1 UTI2
Identifier ('UTI') </MstrAgrmt>
3 Event date 24/04/2020 </SctiesLndg>
</LnData>
<CollData>
9 Master agreement GMSLA
<SctiesLndg>
Collateralisation of <Collsd>
73 TRUE <AsstTp>
net exposure
Type of the collateral <Scty>
75 CASH </Scty>
component
<Csh>
Cash collateral
76 <Amt
amount 100000000
Ccy="EUR">100000000</Amt>
Cash collateral </Csh>
77 EUR
currency </AsstTp>
98 Action type COLU <NetXpsrCollstnInd>true</NetXpsrCollstnIn
d>
LEI of </Collsd>
Reporting
1.3 counterparty </SctiesLndg>
counterparty
A </CollData>
LEI of ...
1.11 Other counterparty counterparty </CollUpd>
B </Rpt>
{LEI} of <Rpt>
1.18 Agent lender agent lender <CollUpd>
F <CtrPtyData>
<CtrPtyData>
3 Event date 24/04/2020 <RptgCtrPty>
<Id>
9 Master agreement GMSLA
<LEI>12345678901234500000</LEI>
Type of the collateral
75 CASH </Id>
component

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
Cash collateral </RptgCtrPty>
76 <OthrCtrPty>
amount 5000000
Cash collateral <Id>
77 EUR
currency
<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>
98 Action type COLU </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>

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
<Id>

<LEI>12345678901234500000</LEI>
</Id>
</RptgCtrPty>
<OthrCtrPty>
<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>

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
</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
LEI of <SctiesFincgRptgTxRpt>
Reporting
1.3 counterparty <TradData>
counterparty
A <Rpt>
LEI of <CollUpd>
1.11 Other counterparty counterparty …
B <CtrPtyData>
{LEI} of <CtrPtyData>
1.18 Agent lender agent lender <RptgCtrPty>
F <Id>
Unique Transaction
1 UTI1
Identifier ('UTI') <LEI>12345678901234500000</LEI>
</Id>
3 Event date 24/04/2020 </RptgCtrPty>
<OthrCtrPty>
9 Master agreement GMRA <Id>
Collateralisation of
73 TRUE <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
net exposure
</Id>
Type of the collateral </OthrCtrPty>
75 SECU
component <OthrPtyData>
Identification of a <AgtLndr>
78 security used as {ISIN}
collateral <LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
Classification of a </AgtLndr>
79 security used as {CFI} </OthrPtyData>
collateral </CtrPtyData>
Collateral quantity or </CtrPtyData>
83
nominal amount 100000000 <LnData>
Currency of collateral <RpTrad>
85 EUR <EvtDt>2020-04-24</EvtDt>
nominal amount

145
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 <UnqTradIdr>UTI1</UnqTradIdr>

<MstrAgrmt>
87 Price per unit 100 <Tp>
Collateral market <Tp>GMRA</Tp>
88 </Tp>
value 100000000
</MstrAgrmt>
89 Haircut or margin 0 </RpTrad>
</LnData>
90 Collateral quality INVG <CollData>
<RpTrad>
Maturity date of the <AsstTp>
91 22/04/2030
security <Scty>
Jurisdiction of the <Id>DE0010877643</Id>
92 DE
issuer
{LEI} of the <ClssfctnTp>DBFTFR</ClssfctnTp>
93 LEI of the issuer <QtyOrNmnlVal>
issuer
<NmnlVal>
94 Collateral type GOVS <Amt
Ccy="EUR">100000000</Amt>
Availability for
95 TRUE </NmnlVal>
collateral reuse
</QtyOrNmnlVal>
Type of the collateral <UnitPric>
75 SECU
component <Ptrg>100</Ptrg>
Identification of a </UnitPric>
78 security used as {ISIN} <MktVal
collateral Ccy="EUR">100000000</MktVal>
Classification of a
79 security used as {CFI} <HrcutOrMrgn>0</HrcutOrMrgn>
collateral <Qlty>INVG</Qlty>
Collateral quantity or <Mtrty>2030-04-22</Mtrty>
83
nominal amount 50000000 <Issr>
Currency of collateral <Id>
85 EUR
nominal amount
<LEI>NNNNNNNNNNNNNNNNNNNN</LEI
86 Price currency >
</Id>
87 Price per unit 100
<JursdctnCtry>DE</JursdctnCtry>
Collateral market </Issr>
88
value 50000000 <Tp>
89 Haircut or margin 0 <Cd>GOVS</Cd>
</Tp>
90 Collateral quality INVG
<AvlblForCollReuse>true</AvlblForCollReu
Maturity date of the se>
91 22/04/2030 </Scty>
security
Jurisdiction of the <Scty>
92 FR <Id>FR0010877643</Id>
issuer

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
{LEI} of the <ClssfctnTp>DBFTFR
93 LEI of the issuer </ClssfctnTp>
issuer
<QtyOrNmnlVal>
94 Collateral type GOVS <NmnlVal>
Availability for <Amt
95 TRUE Ccy="EUR">50000000</Amt>
collateral reuse
</NmnlVal>
98 Action type COLU </QtyOrNmnlVal>
<UnitPric>
LEI of <Ptrg>100</Ptrg>
Reporting
1.3 counterparty </UnitPric>
counterparty
A <MktVal>50000000</MktVal>
LEI of
1.11 Other counterparty counterparty <HrcutOrMrgn>0</HrcutOrMrgn>
B <Qlty>INVG</Qlty>
{LEI} of <Mtrty>2030-04-22</Mtrty>
1.18 Agent lender agent lender <Issr>
F <Id>
Unique Transaction
1 UTI2
Identifier ('UTI') <LEI>FFFFFFFFFFFFFFFFFFFF</LEI>
</Id>
3 Event date 24/04/2020
<JursdctnCtry>FR</JursdctnCtry>
9 Master agreement GMRA </Issr>
Collateralisation of <Tp>
73 TRUE <Cd>GOVS</Cd>
net exposure
</Tp>
Type of the collateral
75 SECU
component
<AvlblForCollReuse>true</AvlblForCollReu
Identification of a se>
78 security used as {ISIN} </Scty>
collateral </AsstTp>
Classification of a
79 security used as {CFI} <NetXpsrCollstnInd>true</NetXpsrCollstnIn
collateral d>
Collateral quantity or </RpTrad>
83
nominal amount 50000000 </CollData>
Collateral unit of ...
84
measure </CollUpd>
Currency of collateral </Rpt>
85 EUR <Rpt>
nominal amount
<CollUpd>
86 Price currency <CtrPtyData>
<CtrPtyData>
87 Price per unit 100 <RptgCtrPty>
<Id>
Collateral market
88
value 50000000

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

89 Haircut or margin 0 <LEI>12345678901234500000</LEI>

</Id>
90 Collateral quality INVG </RptgCtrPty>
Maturity date of the <OthrCtrPty>
91 22/04/2030 <Id>
security
Jurisdiction of the <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
92 FR
issuer </Id>
{LEI} of the </OthrCtrPty>
93 LEI of the issuer
issuer <OthrPtyData>
94 Collateral type GOVS <AgtLndr>

Availability for <LEI>BBBBBBBBBBBBBBBBBBBB</LEI>

95 TRUE
collateral reuse </AgtLndr>
</OthrPtyData>
98 Action type COLU </CtrPtyData>
LEI of </CtrPtyData>
Reporting <LnData>
1.3 counterparty
counterparty <RpTrad>
A
LEI of <EvtDt>2020-04-24</EvtDt>
1.11 Other counterparty counterparty <UnqTradIdr>UTI2/UnqTradIdr>
B <MstrAgrmt>
{LEI} of <Tp>
1.18 Agent lender agent lender <Tp>GMRA</Tp>
F </Tp>
</MstrAgrmt>
Unique Transaction
1 UTI3 </RpTrad>
Identifier ('UTI')
</LnData>
3 Event date 24/04/2020 <CollData>
<RpTrad>
9 Master agreement GMRA <AsstTp>
<Scty>
Collateralisation of <Id>FR0010877643</Id>
73 TRUE
net exposure
Type of the collateral <ClssfctnTp>DBFTFR</ClssfctnTp>
75 SECU <QtyOrNmnlVal>
component
Identification of a <NmnlVal>
78 security used as {ISIN} <Amt
collateral Ccy="EUR">50000000</Amt>
Classification of a </NmnlVal>
79 security used as {CFI} </QtyOrNmnlVal>
collateral <UnitPric>
Collateral quantity or <Ptrg>100</Ptrg>
83 </UnitPric>
nominal amount 5000000
<MktVal
Collateral unit of Ccy="EUR">50000000</MktVal>
84
measure

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
Currency of collateral
85 EUR <HrcutOrMrgn>0</HrcutOrMrgn>
nominal amount
<Qlty>INVG</Qlty>
86 Price currency <Mtrty>2030-04-22</Mtrty>
<Issr>
87 Price per unit 100 <Id>
Collateral market <LEI>FFFFFFFFFFFFFFFFFFFF</LEI>
88
value 5000000 </Id>
89 Haircut or margin 0
<JursdctnCtry>FR</JursdctnCtry>
90 Collateral quality INVG </Issr>
<Tp>
Maturity date of the <Cd>GOVS</Cd>
91 22/04/2040
security </Tp>
Jurisdiction of the
92 NL <AvlblForCollReuse>true</AvlblForCollReu
issuer
{LEI} of the se>
93 LEI of the issuer </Scty>
issuer
</AsstTp>
94 Collateral type GOVS
<NetXpsrCollstnInd>true</NetXpsrCollstnIn
Availability for d>
95 TRUE
collateral reuse </RpTrad>
98 Action type COLU </CollData>
...
LEI of </CollUpd>
Reporting
1.3 counterparty </Rpt>
counterparty
A <Rpt>
LEI of <CollUpd>
1.11 Other counterparty counterparty <CtrPtyData>
B <CtrPtyData>
{LEI} of <RptgCtrPty>
1.18 Agent lender agent lender <Id>
F
<LEI>12345678901234500000</LEI>
3 Event date 24/04/2020 </Id>
</RptgCtrPty>
9 Master agreement GMRA <OthrCtrPty>
<Id>
Collateralisation of
73 TRUE
net exposure
<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
Type of the collateral </Id>
75 SECU
component </OthrCtrPty>
Identification of a <OthrPtyData>
78 security used as {ISIN} <AgtLndr>
collateral

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
Classification of a
79 security used as {CFI} <LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
collateral </AgtLndr>
Collateral quantity or </OthrPtyData>
83 </CtrPtyData>
nominal amount 2000000
Collateral unit of </CtrPtyData>
84 <LnData>
measure
Currency of collateral <RpTrad>
85 EUR <EvtDt>2020-04-24</EvtDt>
nominal amount
86 Price currency <UnqTradIdr>UTI3</UnqTradIdr>
<MstrAgrmt>
87 Price per unit 100 <Tp>
<Tp>GMRA</Tp>
Collateral market </Tp>
88
value 2000000 </MstrAgrmt>
</RpTrad>
89 Haircut or margin 0 </LnData>
<CollData>
90 Collateral quality INVG <RpTrad>
Maturity date of the <AsstTp>
91 22/04/2040 <Scty>
security
<Id>NL0010877643</Id>
Jurisdiction of the <ClssfctnTp>DBFTFR
92 IT
issuer </ClssfctnTp>
{LEI} of the <QtyOrNmnlVal>
93 LEI of the issuer
issuer <NmnlVal>
94 Collateral type GOVS <Amt
Ccy="EUR">5000000</Amt>
Availability for </NmnlVal>
95 TRUE </QtyOrNmnlVal>
collateral reuse
Type of the collateral <UnitPric>
75 SECU <Ptrg>100</Ptrg>
component
Identification of a </UnitPric>
78 security used as {ISIN} <MktVal
collateral Ccy="EUR">5000000</MktVal>
Classification of a
79 security used as {CFI} <HrcutOrMrgn>0</HrcutOrMrgn>
collateral <Qlty>INVG</Qlty>
<Mtrty>2030-04-22</Mtrty>
Collateral quantity or
83 <Issr>
nominal amount 2000000
<Id>
Collateral unit of
84
measure <LEI>DDDDDDDDDDDDDDDDDDDD
Currency of collateral </LEI>
85 EUR
nominal amount </Id>
86 Price currency
<JursdctnCtry>NL</JursdctnCtry>

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
</Issr>
87 Price per unit 100 <Tp>
Collateral market <Cd>GOVS</Cd>
88 </Tp>
value 2000000
89 Haircut or margin 0 <AvlblForCollReuse>true</AvlblForCollReu
se>
90 Collateral quality INVG </Scty>
</AsstTp>
Maturity date of the
91 22/04/2040
security <NetXpsrCollstnInd>true</NetXpsrCollstnIn
Jurisdiction of the d>
92 ES
issuer </RpTrad>
{LEI} of the </CollData>
93 LEI of the issuer
issuer ...
</CollUpd>
94 Collateral type GOVS </Rpt>
Availability for <Rpt>
95 TRUE <CollUpd>
collateral reuse
<CtrPtyData>
<CtrPtyData>
<RptgCtrPty>
<Id>

<LEI>12345678901234500000</LEI>
</Id>
</RptgCtrPty>
<OthrCtrPty>
<Id>

<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</Id>
</OthrCtrPty>
<OthrPtyData>
98 Action type COLU <AgtLndr>

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

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
</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>

<JursdctnCtry>IT</JursdctnCtry>
</Issr>
<Tp>
<Cd>GOVS</Cd>
</Tp>

<AvlblForCollReuse>true</AvlblForCollReu
se>
</Scty>
<Scty>
<Id>ES0010877643</Id>

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

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
<Ptrg>100</Ptrg>
</UnitPric>
<MktVal>2000000</MktVal>

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

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

<JursdctnCtry>ES</JursdctnCtry>
</Issr>
<Tp>
<Cd>GOVS</Cd>
</Tp>

<AvlblForCollReuse>true</AvlblForCollReu
se>
</Scty>
</AsstTp>

<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

153
 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
LEI of <SctiesFincgRptgTxRpt>
1.
Reporting counterparty counterparty <TradData>
3
A <Rpt>
LEI of <CollUpd>
1.
Other counterparty counterparty ...
11
B <CtrPtyData>
{LEI} of the <CtrPtyData>
1.
Agent lender agent lender <RptgCtrPty>
18
F <Id>
3 Event date 24/04/2020
<LEI>12345678901234500000</LEI>
</Id>
9 Master agreement GMSLA
</RptgCtrPty>
Collateralisation of net <OthrCtrPty>
73 TRUE <Id>
exposure
Type of the collateral
75 SECU <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
component
</Id>
Identification of a
</OthrCtrPty>
78 security used as {ISIN}
<OthrPtyData>
collateral
<AgtLndr>
Classification of a
79 security used as {CFI}
<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
collateral
</AgtLndr>
Collateral quantity or </OthrPtyData>
83 101000000
nominal amount </CtrPtyData>
Currency of collateral </CtrPtyData>
85 EUR
nominal amount <LnData>
86 Price currency <SctiesLndg>
<EvtDt>2020-04-24</EvtDt>
87 Price per unit 103.03 <MstrAgrmt>
<Tp>
88 Collateral market value 104060300 <Tp>GMSLA</Tp>

154
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
</Tp>
89 Haircut or margin 0
</MstrAgrmt>
</SctiesLndg>
90 Collateral quality INVG </LnData>
Maturity date of the <CollData>
91 22/04/2030 <SctiesLndg>
security
<Collsd>
Jurisdiction of the <AsstTp>
92 DE
issuer
<Scty>
{LEI} of the <Id>DE0010877643</Id>
93 LEI of the issuer
issuer
94 Collateral type GOVS <ClssfctnTp>DBFTPR</ClssfctnTp>
<QtyOrNmnlVal>
Availability for collateral <NmnlVal>
95 TRUE
reuse <Amt
Type of the collateral Ccy="EUR">101000000</Amt>
75 SECU </NmnlVal>
component
Identification of a </QtyOrNmnlVal>
78 security used as {ISIN} <UnitPric>
collateral <Ptrg>103.03</Ptrg>
Classification of a </UnitPric>
79 security used as {CFI} <MktVal
collateral Ccy="EUR">104060300</MktVal>
Collateral quantity or
83 -2000000 <HrcutOrMrgn>0</HrcutOrMrgn>
nominal amount
<Qlty>INVG</Qlty>
Currency of collateral <Mtrty>2030-04-22</Mtrty>
85 EUR
nominal amount <Issr>
86 Price currency <Id>

<LEI>NNNNNNNNNNNNNNNNNNNN
87 Price per unit 103.015
</LEI>
</Id>
88 Collateral market value -2060300
<JursdctnCtry>DE</JursdctnCtry>
89 Haircut or margin 0 </Issr>
<Tp>
90 Collateral quality INVG <Cd>GOVS</Cd>
</Tp>
Maturity date of the
91 22/04/2030
security <AvlblForCollReuse>true</AvlblForCollReu
Jurisdiction of the se>
92 FR
issuer </Scty>
{LEI} of the <Scty>
93 LEI of the issuer
issuer <Id>FR0010877643</Id>
94 Collateral type GOVS <ClssfctnTp>DBFTPR</ClssfctnTp>

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
Availability for collateral <QtyOrNmnlVal>
95 TRUE
reuse <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>

98 Action type COLU <JursdctnCtry>FR</JursdctnCtry>

</Issr>
<Tp>
<Cd>GOVS</Cd>
</Tp>

<AvlblForCollReuse>true</AvlblForCollReu
se>
</Scty>
</AsstTp>

<NetXpsrCollstnInd>true</NetXpsrCollstnIn
d>
</Collsd>
</SctiesLndg>
</CollData>
...
</CollUpd>
</Rpt>
</TradData>
</SctiesFincgRptgTxRpt>

156
 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
LEI of <SctiesFincgRptgTxRpt>
Reporting
1.3 counterparty <TradData>
counterparty
A <Rpt>
LEI of <CollUpd>
1.11 Other counterparty counterparty …
B <CtrPtyData>
{LEI} of <CtrPtyData>
1.18 Agent lender agent lender <RptgCtrPty>
F <Id>
Unique Transaction
1 UTI1
Identifier ('UTI') <LEI>12345678901234500000</LEI>
</Id>
3 Event date 24/04/2020
</RptgCtrPty>
<OthrCtrPty>
9 Master agreement GMRA <Id>
Collateralisation of
73 TRUE <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
net exposure
Type of the collateral </Id>
75 SECU </OthrCtrPty>
component
<OthrPtyData>
Identification of a
<AgtLndr>
78 security used as {ISIN}
collateral
<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
Classification of a </AgtLndr>
79 security used as {CFI} </OthrPtyData>
collateral </CtrPtyData>
Collateral quantity or </CtrPtyData>
83 100000000
nominal amount <LnData>
Currency of collateral <RpTrad>
85 EUR
nominal amount <EvtDt>2020-04-24</EvtDt>
86 Price currency
<UnqTradIdr>UTI1</UnqTradIdr>
<MstrAgrmt>
87 Price per unit 100 <Tp>
Collateral market <Tp>GMRA</Tp>
88 100000000 </Tp>
value

157
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
</MstrAgrmt>
89 Haircut or margin 0
</RpTrad>
</LnData>
90 Collateral quality INVG <CollData>
Maturity date of the <RpTrad>
91 22/04/2030 <AsstTp>
security
<Scty>
Jurisdiction of the <Id>DE0010877643</Id>
92 DE
issuer
{LEI} of the <ClssfctnTp>DBFTFR</ClssfctnTp>
93 LEI of the issuer
issuer <QtyOrNmnlVal>
94 Collateral type GOVS <NmnlVal>
<Amt
Availability for Ccy="EUR">100000000</Amt>
95 TRUE
collateral reuse </NmnlVal>
Identification of a </QtyOrNmnlVal>
78 security used as {ISIN} <UnitPric>
collateral <Ptrg>100</Ptrg>
Classification of a </UnitPric>
79 security used as {CFI} <MktVal
collateral Ccy="EUR">100000000</MktVal>
Collateral quantity or
83 50000000 <HrcutOrMrgn>0</HrcutOrMrgn>
nominal amount
<Qlty>INVG</Qlty>
Currency of collateral
85 EUR <Mtrty>2030-04-22</Mtrty>
nominal amount
<Issr>
86 Price currency <Id>

87 Price per unit 100 <LEI>NNNNNNNNNNNNNNNNNNNN</LEI

>
Collateral market </Id>
88 50000000
value
<JursdctnCtry>DE</JursdctnCtry>
89 Haircut or margin 0 </Issr>
<Tp>
90 Collateral quality INVG <Cd>GOVS</Cd>
</Tp>
Maturity date of the
91 22/04/2030
security
<AvlblForCollReuse>true</AvlblForCollReu
Jurisdiction of the se>
92 DE
issuer </Scty>
{LEI} of the <Scty>
93 LEI of the issuer
issuer <Id>DE0010877643</Id>
94 Collateral type GOVS
<ClssfctnTp>DBFTFR</ClssfctnTp>
Availability for <QtyOrNmnlVal>
95 TRUE <NmnlVal>
collateral reuse

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
<Amt
98 Action type COLU
Ccy="EUR">50000000</Amt>
LEI of </NmnlVal>
Reporting </QtyOrNmnlVal>
1.3 counterparty
counterparty <UnitPric>
A
LEI of <Ptrg>100</Ptrg>
1.11 Other counterparty counterparty </UnitPric>
B <MktVal>50000000</MktVal>
{LEI} of
1.18 Agent lender agent lender <HrcutOrMrgn>0</HrcutOrMrgn>
F <Qlty>INVG</Qlty>
Unique Transaction <Mtrty>2030-04-22</Mtrty>
1 UTI2 <Issr>
Identifier ('UTI')
<Id>
3 Event date 24/04/2020
<LEI>NNNNNNNNNNNNNNNNNNNN</LEI
9 Master agreement GMRA >
</Id>
Collateralisation of
73 TRUE
net exposure <JursdctnCtry>DE</JursdctnCtry>
Identification of a </Issr>
78 security used as {ISIN} <Tp>
collateral <Cd>GOVS</Cd>
Classification of a </Tp>
79 security used as {CFI}
collateral <AvlblForCollReuse>true</AvlblForCollReu
Collateral quantity or se>
83 50000000 </Scty>
nominal amount
Collateral unit of </AsstTp>
84
measure
Currency of collateral <NetXpsrCollstnInd>true</NetXpsrCollstnIn
85 EUR d>
nominal amount
</RpTrad>
86 Price currency </CollData>
...
87 Price per unit 100 </CollUpd>
</Rpt>
Collateral market <Rpt>
88 50000000
value <CollUpd>
<CtrPtyData>
89 Haircut or margin 0 <CtrPtyData>
<RptgCtrPty>
90 Collateral quality INVG <Id>
Maturity date of the
91 22/04/2030 <LEI>12345678901234500000</LEI>
security
</Id>
Jurisdiction of the </RptgCtrPty>
92 FR
issuer

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
{LEI} of the <OthrCtrPty>
93 LEI of the issuer
issuer <Id>
94 Collateral type GOVS <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
Availability for </Id>
95 TRUE </OthrCtrPty>
collateral reuse
<OthrPtyData>
98 Action type COLU <AgtLndr>
LEI of <LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
Reporting
1.3 counterparty </AgtLndr>
counterparty
A </OthrPtyData>
LEI of </CtrPtyData>
1.11 Other counterparty counterparty </CtrPtyData>
B <LnData>
{LEI} of <RpTrad>
Agent lender agent lender <EvtDt>2020-04-24</EvtDt>
1.18
F
Unique Transaction <UnqTradIdr>UTI2</UnqTradIdr>
1 UTI3
Identifier (‘UTI’) <MstrAgrmt>
<Tp>
3 Event date 24/04/2020
<Tp>GMRA</Tp>
</Tp>
9 Master agreement GMRA </MstrAgrmt>
Collateralisation of </RpTrad>
73 TRUE </LnData>
net exposure
<CollData>
Identification of a
<RpTrad>
78 security used as {ISIN}
<AsstTp>
collateral
<Scty>
Classification of a
<Id>FR0010877643</Id>
79 security used as {CFI}
<ClssfctnTp>DBFTFR
collateral
</ClssfctnTp>
Collateral quantity or <QtyOrNmnlVal>
83 50000000
nominal amount <NmnlVal>
Collateral unit of <Amt
84
measure Ccy="EUR">50000000</Amt>
Currency of collateral </NmnlVal>
85 EUR
nominal amount </QtyOrNmnlVal>
<UnitPric>
86 Price currency <Ptrg>100</Ptrg>
</UnitPric>
87 Price per unit 100 <MktVal
Collateral market Ccy="EUR">50000000</MktVal>
88 50000000
value
<HrcutOrMrgn>0</HrcutOrMrgn>
89 Haircut or margin 0 <Qlty>INVG</Qlty>

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
<Mtrty>2030-04-22</Mtrty>
90 Collateral quality INVG
<Issr>
Maturity date of the <Id>
91 22/04/2040
security
Jurisdiction of the <LEI>FFFFFFFFFFFFFFFFFFFF</LEI>
92 NL </Id>
issuer
{LEI} of the <JursdctnCtry>FR</JursdctnCtry>
93 LEI of the issuer
issuer
</Issr>
94 Collateral type GOVS <Tp>
<Cd>GOVS</Cd>
Availability for </Tp>
95 TRUE
collateral reuse
<AvlblForCollReuse>true</AvlblForCollReu
98 Action type COLU
se>
LEI of </Scty>
Reporting </AsstTp>
1.3 counterparty
counterparty
A
LEI of <NetXpsrCollstnInd>true</NetXpsrCollstnIn
1.11 Other counterparty counterparty d>
B </RpTrad>
{LEI} of </CollData>
1.18 Agent lender agent lender ...
F </CollUpd>
</Rpt>
3 Event date 24/04/2020 <Rpt>
<CollUpd>
9 Master agreement GMRA <CtrPtyData>
<CtrPtyData>
Collateralisation of <RptgCtrPty>
73 TRUE
net exposure <Id>
Identification of a
78 security used as {ISIN} <LEI>12345678901234500000</LEI>
collateral </Id>
Classification of a </RptgCtrPty>
79 security used as {CFI} <OthrCtrPty>
collateral <Id>
Collateral quantity or
83 2000000
nominal amount <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
Collateral unit of </Id>
84 </OthrCtrPty>
measure
Currency of collateral <OthrPtyData>
85 EUR <AgtLndr>
nominal amount
86 Price currency <LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
</AgtLndr>
87 Price per unit 100 </OthrPtyData>

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
Collateral market </CtrPtyData>
88 2000000
value </CtrPtyData>
<LnData>
89 Haircut or margin 0 <RpTrad>
<EvtDt>2020-04-24</EvtDt>
90 Collateral quality INVG
<UnqTradIdr>UTI3</UnqTradIdr>
Maturity date of the <MstrAgrmt>
91 22/04/2040
security
<Tp>
Jurisdiction of the <Tp>GMRA</Tp>
92 IT
issuer </Tp>
{LEI} of the </MstrAgrmt>
93 LEI of the issuer
issuer </RpTrad>
</LnData>
94 Collateral type GOVS
<CollData>
Availability for <RpTrad>
95 TRUE <AsstTp>
collateral reuse
<Scty>
98 Action type COLU <Id>NL0010877000</Id>
<ClssfctnTp>DBFTFR
LEI of
Reporting </ClssfctnTp>
1.3 counterparty
counterparty <QtyOrNmnlVal>
A
<NmnlVal>
LEI of
<Amt
1.11 Other counterparty counterparty
Ccy="EUR">50000000</Amt>
B
</NmnlVal>
{LEI} of </QtyOrNmnlVal>
1.18 Agent lender agent lender <UnitPric>
F <Ptrg>100</Ptrg>
3 Event date 24/04/2020 </UnitPric>
<MktVal
9 Master agreement GMRA Ccy="EUR">50000000</MktVal>

Collateralisation of <HrcutOrMrgn>0</HrcutOrMrgn>
73 TRUE
net exposure <Qlty>INVG</Qlty>
Identification of a <Mtrty>2030-04-22</Mtrty>
78 security used as {ISIN} <Issr>
collateral <Id>
Classification of a
79 security used as {CFI} <LEI>DDDDDDDDDDDDDDDDDDDD
collateral </LEI>
Collateral quantity or </Id>
83 -2000000
nominal amount
Collateral unit of <JursdctnCtry>NL</JursdctnCtry>
84 </Issr>
measure
<Tp>
Currency of collateral <Cd>GOVS</Cd>
85 EUR
nominal amount

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
</Tp>
86 Price currency
<AvlblForCollReuse>true</AvlblForCollReu
87 Price per unit 100 se>
Collateral market </Scty>
88 -2000000 </AsstTp>
value
89 Haircut or margin 0 <NetXpsrCollstnInd>true</NetXpsrCollstnIn
d>
90 Collateral quality INVG </RpTrad>
</CollData>
Maturity date of the ...
91 22/04/2040
security </CollUpd>
Jurisdiction of the </Rpt>
92 ES
issuer <Rpt>
{LEI} of the <CollUpd>
93 LEI of the issuer <CtrPtyData>
issuer
<CtrPtyData>
94 Collateral type GOVS <RptgCtrPty>
<Id>
Availability for
95 TRUE
collateral reuse
<LEI>12345678901234500000</LEI>
</Id>
</RptgCtrPty>
<OthrCtrPty>
<Id>

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

<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
98 Action type COLU </AgtLndr>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
<RpTrad>
<EvtDt>2020-04-24</EvtDt>
<MstrAgrmt>
<Tp>
<Tp>GMRA</Tp>
</Tp>
</MstrAgrmt>
</RpTrad>
</LnData>

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
<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>

<JursdctnCtry>IT</JursdctnCtry>
</Issr>
<Tp>
<Cd>GOVS</Cd>
</Tp>

<AvlblForCollReuse>true</AvlblForCollReu
se>
</Scty>
</AsstTp>

<NetXpsrCollstnInd>true</NetXpsrCollstnIn
d>
</RpTrad>
</CollData>
...
</CollUpd>
</Rpt>
<Rpt>
<CollUpd>

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
<CtrPtyData>
<CtrPtyData>
<RptgCtrPty>
<Id>

<LEI>12345678901234500000</LEI>
</Id>
</RptgCtrPty>
<OthrCtrPty>
<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>

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
<MktVal Ccy="EUR">-
2000000</MktVal>

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

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

<JursdctnCtry>ES</JursdctnCtry>
</Issr>
<Tp>
<Cd>GOVS</Cd>
</Tp>

<AvlblForCollReuse>true</AvlblForCollReu
se>
</Scty>
</AsstTp>

<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.

166
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
LEI of <SctiesFincgRptgTxRpt>
Reporting
1.3 counterparty <TradData>
counterparty
A <Rpt>
LEI of <CollUpd>
1.11 Other counterparty counterparty …
B <CtrPtyData>
{LEI} of <CtrPtyData>
1.18 Agent lender agent lender <RptgCtrPty>
F <Id>
Unique Transaction
1 UTI1
Identifier (‘UTI’) <LEI>12345678901234500000</LEI>
</Id>
3 Event date 24/04/2020
</RptgCtrPty>
<OthrCtrPty>
9 Master agreement GMRA <Id>
Collateralisation of
73 TRUE <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
net exposure
</Id>
Type of the collateral
75 SECU </OthrCtrPty>
component
<OthrPtyData>
Identification of a <AgtLndr>
78 security used as {ISIN}
collateral <LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
Classification of a </AgtLndr>
79 security used as {CFI} </OthrPtyData>
collateral </CtrPtyData>
Collateral quantity or </CtrPtyData>
83
nominal amount 100000000 <LnData>
Currency of collateral <RpTrad>
85 EUR
nominal amount <EvtDt>2020-04-24</EvtDt>
86 Price currency <UnqTradIdr>UTI1</UnqTradIdr>
<MstrAgrmt>
87 Price per unit 100 <Tp>
Collateral market <Tp>GMRA</Tp>
88 </Tp>
value 100000000
</MstrAgrmt>
89 Haircut or margin 0 </RpTrad>
</LnData>
90 Collateral quality INVG <CollData>
<RpTrad>
Maturity date of the <AsstTp>
91 22/04/2030
security <Scty>
Jurisdiction of the <Id>DE0010877643</Id>
92 DE
issuer
{LEI} of the <ClssfctnTp>DBFTFR</ClssfctnTp>
93 LEI of the issuer <QtyOrNmnlVal>
issuer

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
<NmnlVal>
94 Collateral type GOVS <Amt
Availability for Ccy="EUR">100000000</Amt>
95 TRUE </NmnlVal>
collateral reuse
Type of the collateral </QtyOrNmnlVal>
75 SECU <UnitPric>
component
<Ptrg>100</Ptrg>
Identification of a
</UnitPric>
78 security used as {ISIN}
collateral
<MktVal
Classification of a
Ccy="EUR">100000000</MktVal>
79 security used as {CFI}
collateral
<HrcutOrMrgn>0</HrcutOrMrgn>
Collateral quantity or <Qlty>INVG</Qlty>
83
nominal amount 50000000 <Mtrty>2030-04-22</Mtrty>
Currency of collateral <Issr>
85 EUR
nominal amount <Id>
86 Price currency
<LEI>NNNNNNNNNNNNNNNNNNNN</LEI
>
87 Price per unit 100 </Id>
Collateral market
88 <JursdctnCtry>DE</JursdctnCtry>
value 50000000
</Issr>
89 Haircut or margin 0 <Tp>
<Cd>GOVS</Cd>
90 Collateral quality INVG </Tp>

Maturity date of the <AvlblForCollReuse>true</AvlblForCollReu

91 22/04/2030
security se>
Jurisdiction of the </Scty>
92 FR
issuer <Scty>
{LEI} of the <Id>FR0010877643</Id>
93 LEI of the issuer <ClssfctnTp>DBFTFR
issuer
</ClssfctnTp>
94 Collateral type GOVS <QtyOrNmnlVal>
<NmnlVal>
Availability for
95 TRUE <Amt
collateral reuse
Ccy="EUR">50000000</Amt>
98 Action type COLU </NmnlVal>
</QtyOrNmnlVal>
LEI of <UnitPric>
Reporting
1.3 counterparty <Ptrg>100</Ptrg>
counterparty
A </UnitPric>
LEI of
1.11 Other counterparty counterparty <MktVal>50000000</MktVal>
B

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
{LEI} of
1.18 Agent lender agent lender <HrcutOrMrgn>0</HrcutOrMrgn>
F <Qlty>INVG</Qlty>
Unique Transaction <Mtrty>2030-04-22</Mtrty>
1 UTI2 <Issr>
Identifier (‘UTI’)
<Id>
3 Event date 24/04/2020
<LEI>FFFFFFFFFFFFFFFFFFFF</LEI>
9 Master agreement GMRA </Id>
Collateralisation of <JursdctnCtry>FR</JursdctnCtry>
73 TRUE
net exposure </Issr>
Type of the collateral <Tp>
75 SECU
component <Cd>GOVS</Cd>
Identification of a </Tp>
78 security used as {ISIN}
collateral <AvlblForCollReuse>true</AvlblForCollReu
Classification of a se>
79 security used as {CFI} </Scty>
collateral </AsstTp>
Collateral quantity or
83
nominal amount 50000000 <NetXpsrCollstnInd>true</NetXpsrCollstnIn
Collateral unit of d>
84 </RpTrad>
measure
Currency of collateral </CollData>
85 EUR ...
nominal amount
</CollUpd>
86 Price currency </Rpt>
<Rpt>
87 Price per unit 100 <CollUpd>
<CtrPtyData>
Collateral market <CtrPtyData>
88
value 50000000 <RptgCtrPty>
<Id>
89 Haircut or margin 0
<LEI>12345678901234500000</LEI>
90 Collateral quality INVG </Id>
Maturity date of the </RptgCtrPty>
91 22/04/2030 <OthrCtrPty>
security
<Id>
Jurisdiction of the
92 FR
issuer
<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
{LEI} of the </Id>
93 LEI of the issuer
issuer </OthrCtrPty>
94 Collateral type GOVS <OthrPtyData>
<AgtLndr>
Availability for
95 TRUE
collateral reuse <LEI>BBBBBBBBBBBBBBBBBBBB</LEI>

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
</AgtLndr>
98 Action type COLU </OthrPtyData>
LEI of </CtrPtyData>
Reporting </CtrPtyData>
1.3 counterparty
counterparty <LnData>
A
LEI of <RpTrad>
1.11 Other counterparty counterparty <EvtDt>2020-04-24</EvtDt>
B
{LEI} of <UnqTradIdr>UTI2</UnqTradIdr>
1.18 Agent lender agent lender <MstrAgrmt>
B <Tp>
Unique Transaction <Tp>GMRA</Tp>
1 UTI3 </Tp>
Identifier ('UTI')
</MstrAgrmt>
3 Event date 24/04/2020 </RpTrad>
</LnData>
9 Master agreement GMRA <CollData>
<RpTrad>
Collateralisation of <AsstTp>
73 TRUE
net exposure <Scty>
Type of the collateral <Id>FR0010877643</Id>
75 SECU
component <ClssfctnTp>DBFTFR
Identification of a </ClssfctnTp>
78 security used as {ISIN} <QtyOrNmnlVal>
collateral <NmnlVal>
Classification of a <Amt
79 security used as {CFI} Ccy="EUR">50000000</Amt>
collateral </NmnlVal>
Collateral quantity or </QtyOrNmnlVal>
83 <UnitPric>
nominal amount 50000000
Collateral unit of <Ptrg>100</Ptrg>
84 </UnitPric>
measure
<MktVal
Currency of collateral Ccy="EUR">50000000</MktVal>
85 EUR
nominal amount
86 Price currency <HrcutOrMrgn>0</HrcutOrMrgn>
<Qlty>INVG</Qlty>
87 Price per unit 100 <Mtrty>2030-04-22</Mtrty>
<Issr>
Collateral market <Id>
88
value 50000000
<LEI>FFFFFFFFFFFFFFFFFFFF</LEI>
89 Haircut or margin 0 </Id>

90 Collateral quality INVG <JursdctnCtry>FR</JursdctnCtry>

</Issr>
Maturity date of the <Tp>
91 22/04/2040
security

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
Jurisdiction of the <Cd>GOVS</Cd>
92 NL </Tp>
issuer
{LEI} of the
93 LEI of the issuer <AvlblForCollReuse>true</AvlblForCollReu
issuer
se>
94 Collateral type MEQU </Scty>
</AsstTp>
Availability for
95 TRUE
collateral reuse <NetXpsrCollstnInd>true</NetXpsrCollstnIn
98 Action type GOVS d>
</RpTrad>
LEI of </CollData>
Reporting
1.3 counterparty ...
counterparty
A </CollUpd>
LEI of </Rpt>
1.11 Other counterparty counterparty <Rpt>
B <CollUpd>
{LEI} of <CtrPtyData>
1.18 Agent lender agent lender <CtrPtyData>
F <RptgCtrPty>
<Id>
3 Event date 24/04/2020
<LEI>12345678901234500000</LEI>
9 Master agreement GMRA </Id>
Collateralisation of </RptgCtrPty>
73 TRUE <OthrCtrPty>
net exposure
<Id>
Type of the collateral
75 CASH
component
<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
Cash collateral </Id>
76
amount 2000000 </OthrCtrPty>
Cash collateral <OthrPtyData>
77 EUR
currency <AgtLndr>

<LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
</AgtLndr>
</OthrPtyData>
</CtrPtyData>
</CtrPtyData>
<LnData>
<RpTrad>
98 Action type COLU
<EvtDt>2020-04-24</EvtDt>

<UnqTradIdr>UTI3</UnqTradIdr>
<MstrAgrmt>
<Tp>
<Tp>GMRA</Tp>
</Tp>
</MstrAgrmt>

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
</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>

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

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

<JursdctnCtry>NL</JursdctnCtry>
</Issr>
<Tp>
<Cd>MEQU</Cd>
</Tp>

<AvlblForCollReuse>true</AvlblForCollReu
se>
</Scty>
</AsstTp>

<NetXpsrCollstnInd>true</NetXpsrCollstnIn
d>
</RpTrad>
</CollData>
...
</CollUpd>
</Rpt>

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
<Rpt>
<CollUpd>
<CtrPtyData>
<CtrPtyData>
<RptgCtrPty>
<Id>

<LEI>12345678901234500000</LEI>
</Id>
</RptgCtrPty>
<OthrCtrPty>
<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>
<Csh>
<Amt
Ccy="EUR">2000000</Amt>
</Csh>
</AsstTp>

<NetXpsrCollstnInd>true</NetXpsrCollstnIn
d>
</RpTrad>
</CollData>
...
</CollUpd>

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>
</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
LEI of <SctiesFincgRptgTxRpt>
Reporting
1.3 counterparty <TradData>
counterparty
A <Rpt>
LEI of <CollUpd>
1.11 Other counterparty counterparty …
B <CtrPtyData>
{LEI} of <CtrPtyData>
1.18 Agent lender agent lender <RptgCtrPty>
F <Id>
Unique Transaction
1 UTI1
Identifier ('UTI') <LEI>12345678901234500000</LEI>
</Id>
3 Event date 24/04/2020 </RptgCtrPty>
<OthrCtrPty>
9 Master agreement GMRA <Id>
Collateralisation of
73 TRUE <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
net exposure
</Id>
Type of the collateral </OthrCtrPty>
75 SECU
component <OthrPtyData>
Identification of a <AgtLndr>
78 security used as {ISIN}
collateral <LEI>BBBBBBBBBBBBBBBBBBBB</LEI>
Classification of a </AgtLndr>
79 security used as {CFI} </OthrPtyData>
collateral </CtrPtyData>
Collateral quantity or </CtrPtyData>
83
nominal amount 100000000 <LnData>
Currency of collateral <RpTrad>
85 EUR <EvtDt>2020-04-24</EvtDt>
nominal amount

174
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>
87 Price per unit 100 <Tp>
Collateral market <Tp>GMRA</Tp>
88 </Tp>
value 100000000
</MstrAgrmt>
89 Haircut or margin 0 </RpTrad>
</LnData>
90 Collateral quality INVG <CollData>
<RpTrad>
Maturity date of the <AsstTp>
91 22/04/2030
security <Scty>
Jurisdiction of the <Id>DE0010877643</Id>
92 DE
issuer
{LEI} of the <ClssfctnTp>DBFTFR</ClssfctnTp>
93 LEI of the issuer <QtyOrNmnlVal>
issuer
<NmnlVal>
94 Collateral type GOVS <Amt
Ccy="EUR">100000000</Amt>
Availability for
95 TRUE </NmnlVal>
collateral reuse
</QtyOrNmnlVal>
Type of the collateral <UnitPric>
75 SECU
component <Ptrg>100</Ptrg>
Identification of a </UnitPric>
78 security used as {ISIN}
collateral <MktVal
Classification of a Ccy="EUR">100000000</MktVal>
79 security used as {CFI}
collateral <HrcutOrMrgn>0</HrcutOrMrgn>
Collateral quantity or <Qlty>INVG</Qlty>
83
nominal amount 50000000 <Mtrty>2030-04-22</Mtrty>
Currency of collateral <Issr>
85 EUR <Id>
nominal amount
86 Price currency <LEI>NNNNNNNNNNNNNNNNNNNN</LEI
>
87 Price per unit 100 </Id>
Collateral market <JursdctnCtry>DE</JursdctnCtry>
88
value 50000000 </Issr>
89 Haircut or margin 0 <Tp>
<Cd>GOVS</Cd>
</Tp>
90 Collateral quality INVG
Maturity date of the <AvlblForCollReuse>true</AvlblForCollReu
91 22/04/2030 se>
security

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
Jurisdiction of the </Scty>
92 FR
issuer <Scty>
{LEI} of the <Id>FR0010877643</Id>
93 LEI of the issuer <ClssfctnTp>DBFTFR
issuer
</ClssfctnTp>
94 Collateral type GOVS <QtyOrNmnlVal>
<NmnlVal>
Availability for <Amt
95 TRUE
collateral reuse
Ccy="EUR">50000000</Amt>
98 Action type COLU </NmnlVal>
</QtyOrNmnlVal>
LEI of <UnitPric>
Reporting
1.3 counterparty <Ptrg>100</Ptrg>
counterparty
A </UnitPric>
LEI of
1.11 Other counterparty counterparty <MktVal>50000000</MktVal>
B
{LEI} of <HrcutOrMrgn>0</HrcutOrMrgn>
1.18 Agent lender agent lender <Qlty>INVG</Qlty>
F <Mtrty>2030-04-22</Mtrty>
Unique Transaction <Issr>
1 UTI2
Identifier ('UTI') <Id>
3 Event date 24/04/2020 <LEI>FFFFFFFFFFFFFFFFFFFF</LEI>
</Id>
9 Master agreement GMRA
<JursdctnCtry>FR</JursdctnCtry>
Collateralisation of
73 TRUE </Issr>
net exposure
<Tp>
Type of the collateral <Cd>GOVS</Cd>
75 SECU
component </Tp>
Identification of a
78 security used as {ISIN} <AvlblForCollReuse>true</AvlblForCollReu
collateral se>
Classification of a </Scty>
79 security used as {CFI} </AsstTp>
collateral
Collateral quantity or <NetXpsrCollstnInd>true</NetXpsrCollstnIn
83
V nominal amount 50000000 d>
Collateral unit of </RpTrad>
84 </CollData>
measure
Currency of collateral ...
85 EUR </CollUpd>
nominal amount
</Rpt>
86 Price currency <Rpt>
<CollUpd>
87 Price per unit 100 <CtrPtyData>

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

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
Collateral unit of <Ptrg>100</Ptrg>
84
measure </UnitPric>
Currency of collateral <MktVal
85 EUR Ccy="EUR">50000000</MktVal>
nominal amount
86 Price currency <HrcutOrMrgn>0</HrcutOrMrgn>
<Qlty>INVG</Qlty>
87 Price per unit 100 <Mtrty>2030-04-22</Mtrty>
<Issr>
Collateral market <Id>
88
value 50000000
89 Haircut or margin 0 <LEI>FFFFFFFFFFFFFFFFFFFF</LEI>
</Id>
90 Collateral quality INVG
<JursdctnCtry>FR</JursdctnCtry>
Maturity date of the </Issr>
91 22/04/2040 <Tp>
security
Jurisdiction of the <Cd>GOVS</Cd>
92 NL </Tp>
issuer
{LEI} of the
93 LEI of the issuer <AvlblForCollReuse>true</AvlblForCollReu
issuer
se>
94 Collateral type GOVS </Scty>
</AsstTp>
Availability for
95 TRUE
collateral reuse <NetXpsrCollstnInd>true</NetXpsrCollstnIn
d>
98 Action type COLU </RpTrad>
LEI of </CollData>
Reporting ...
1.3 counterparty
counterparty </CollUpd>
A
LEI of </Rpt>
1.11 Other counterparty counterparty <Rpt>
B <CollUpd>
{LEI} of <CtrPtyData>
1.18 Agent lender agent lender <CtrPtyData>
F <RptgCtrPty>
<Id>
3 Event date 24/04/2020
<LEI>12345678901234500000</LEI>
9 Master agreement GMRA </Id>
</RptgCtrPty>
Collateralisation of <OthrCtrPty>
73 TRUE
net exposure <Id>
Type of the collateral
75 CASH
component <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
Cash collateral </Id>
76 0
amount </OthrCtrPty>

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
Cash collateral <OthrPtyData>
77 EUR
currency <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>
</RpTrad>
</LnData>
<CollData>
<RpTrad>
<AsstTp>
<Scty>
<Id>NL0010877643</Id>
98 Action type COLU
<ClssfctnTp>DBFTFR</ClssfctnTp>
<QtyOrNmnlVal>
<NmnlVal>
<Amt
Ccy="EUR">50000000</Amt>
</NmnlVal>
</QtyOrNmnlVal>
<UnitPric>
<Ptrg>100</Ptrg>
</UnitPric>

<MktVal
Ccy="EUR">50000000</MktVal>

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

<LEI>DDDDDDDDDDDDDDDDDDDD
</LEI>

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
</Id>

<JursdctnCtry>NL</JursdctnCtry>
</Issr>
<Tp>
<Cd>MEQU</Cd>
</Tp>

<AvlblForCollReuse>true</AvlblForCollReu
se>
</Scty>
</AsstTp>

<NetXpsrCollstnInd>true</NetXpsrCollstnIn
d>

<HrcutOrMrgn>0</HrcutOrMrgn>
</RpTrad>
</CollData>
...
</CollUpd>
</Rpt>
<Rpt>
<CollUpd>
<CtrPtyData>
<CtrPtyData>
<RptgCtrPty>
<Id>

<LEI>12345678901234500000</LEI>
</Id>
</RptgCtrPty>
<OthrCtrPty>
<Id>

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

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

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
<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.

181
Table 99 - Prepaid collateral
No Field Example XML Message
<SctiesFincgRptgTxRpt>
3 Event date 2020-04-23 <TradData>
Collateralisation of <Rpt>
73 true <CollUpd>
net exposure
Value date of the ...
74 2020-04-24 <CtrPtyData>
collateral
...
Identification of a
</CtrPtyData>
78 security used as {ISIN}
<LnData>
collateral
<SctiesLndg>
Classification of a
<EvtDt>2020-04-23</EvtDt>
79 security used as {CFI}
</SctiesLndg>
collateral
</LnData>
Collateral quantity or <CollData>
83 100000000
nominal amount <SctiesLndg>
Collateral unit of <Collsd>
84
measure <CollValDt>2020-04-
Currency of collateral 24</CollValDt>
85 EUR
nominal amount <AsstTp>
<Scty>
86 Price currency <Id>DE0010877643</Id>

87 Price per unit 102 <ClssfctnTp>DBFTFR</ClssfctnTp>

<QtyOrNmnlVal>
Collateral market
88 102000000 <NmnlVal>
value
<Amt
89 Haircut or margin 2 Ccy="EUR">100000000</Amt>
</NmnlVal>
90 Collateral quality INVG </QtyOrNmnlVal>
<UnitPric>
Maturity date of the <Ptrg>102</Ptrg>
91 2030-04-22
security </UnitPric>
Jurisdiction of the <MktVal
92 DE Ccy="EUR">102000000</MktVal>
issuer
{LEI} of the
93 LEI of the issuer <HrcutOrMrgn>2</HrcutOrMrgn>
issuer
<Qlty>INVG</Qlty>
94 Collateral type GOVS <Mtrty>2030-04-22</Mtrty>
<Issr>
<Id>

<LEI>NNNNNNNNNNNNNNNNNNNN
</LEI>
Availability for </Id>
95 true
collateral reuse
<JursdctnCtry>DE</JursdctnCtry>
</Issr>
<Tp>
<Cd>GOVS</Cd>
</Tp>

182
 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.

183
 CCP interposing itself between the two counterparties that are clearing members

Case 1. CCP interposing itself between the two counterparties that are clearing members

SFT loan

Margin Margin
Counterparty 1 Counterparty 2
CCP
(Clearing member 1) (Clearing member 2)

SFT collateral

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

Case 2. CCP interposing itself between the two counterparties that are not clearing members

SFT loan

Margin* Margin Margin Margin*

Counterparty 1 CM 1 CCP CM 2 Counterparty 2

SFT collateral

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

184
 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
2020-04- <SctiesFincgRptgTxMrgnDataRpt>
1 Reporting timestamp
22T16:41:07Z <TradData>
<Rpt>
2 Event date 2020-04-23 <TradUpd>
{LEI} of
Report submitting <RptgDtTm>2020-04-
3 counterparty
entity 22T16:41:07Z</RptgDtTm>
D
Reporting {LEI} of
4 <EvtDt>2020-04-23</EvtDt>
Counterparty counterparty J
{LEI} of <CtrPty>
Entity responsible for
5 <RptgCtrPty>
the report counterparty J
{LEI} of CCP <LEI>CCCCCCCCCCCCCCCCCCCC
6 Other counterparty O </LEI>
EMIRSFTRC </RptgCtrPty>
7 Portfolio code
ODE1 <OthrCtrPty>
8 Initial margin posted 1000000
<LEI>BBBBBBBBBB1111111111</LEI>
Currency of the initial </OthrCtrPty>
9 EUR <NttyRspnsblForRpt>
margin posted
Variation margin
10 300000 <LEI>CCCCCCCCCCCCCCCCCCCC
posted
Currency of the </LEI>
11 variation margins EUR </NttyRspnsblForRpt>
posted <RptSubmitgNtty>

12 Initial margin received <LEI>11223344556677889900</LEI>

</RptSubmitgNtty>
Currency of the initial </CtrPty>
13
margin received
Variation margin <CollPrtflId>EMIRSFTRCODE1</CollPrtflId
14
received >
Currency of the <PstdMrgnOrColl>
15 variation margins <InitlMrgnPstd
received Ccy="EUR">1000000</InitlMrgnPstd>
Excess collateral <VartnMrgnPstd
16 100000
posted Ccy="EUR">300000</VartnMrgnPstd>

185
 Table 100 – Margin data
No Field Example XML Message
Currency of the <XcssCollPstd
17 excess collateral EUR Ccy="EUR">100000</XcssCollPstd>
posted </PstdMrgnOrColl>
Excess collateral <RcvdMrgnOrColl>
18 ...
received
Currency of the </RcvdMrgnOrColl>
19 excess collateral </TradUpd>
received </Rpt>
</TradData>
20 Action type MARU </SctiesFincgRptgTxMrgnDataRpt>

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-Use-
Measures-and-Metrics.pdf

186
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.

187
 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 metrics 18 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
2020-04- <SctiesFincgRptgTxReusdCollDataRpt>
1 Reporting timestamp
22T16:41:07Z <TradData>
2 Event date 2020-04-23 <Rpt>
<CollReuseUpd>
{LEI} of ...
Report submitting
3 counterparty <RptgDtTm>2020-04-
entity
B 22T16:41:07Z</RptgDtTm>
{LEI} of <CtrPtyData>
Reporting
4 counterparty <RptSubmitgNtty>
counterparty
B
{LEI} of <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
Entity responsible for
5 counterparty </RptSubmitgNtty>
the report
B <RptgCtrPty>
Type of collateral
6 SECU
component <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</RptgCtrPty>
7 Collateral component {ISIN} <NttyRspnsblForRpt>
Value of reused
8 <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
collateral

18
9 See section 4 of the FSB framework on non-cash collateral re-use.

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

</SctiesFincgRptgTxReusdCollDataRpt>

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
2020-04- <SctiesFincgRptgTxReusdCollDataRpt>
1 Reporting timestamp
22T16:41:07Z <TradData>
2 Event date 2020-04-23 <Rpt>
<CollReuseUpd>
{LEI} of ...
Report submitting
3 counterparty <RptgDtTm>2020-04-
entity
B 22T16:41:07Z</RptgDtTm>
{LEI} of <CtrPtyData>
Reporting
4 counterparty <RptSubmitgNtty>
counterparty
A
{LEI} of <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
Entity responsible for
5 counterparty </RptSubmitgNtty>
the report
A <RptgCtrPty>
Type of collateral
6 SECU <LEI>12345678901234500000</LEI>
component
</RptgCtrPty>
7 Collateral component {ISIN} <NttyRspnsblForRpt>

189
Table 102 – Reuse of securities by FC or non-SME NFC with delegation of reporting
No Field Example XML Message
Value of reused
8 <LEI>12345678901234500000</LEI>
collateral
Estimated reuse of </NttyRspnsblForRpt>
9 10000000 </CtrPtyData>
collateral
Reused collateral <CollCmpnt>
10 EUR <Scty>
currency
<ISIN> IT00BH4HKS39</ISIN>
<ReuseVal>
<Estmtd
Ccy="EUR">10000000</Estmtd>
</ReuseVal>
</Scty>
</CollCmpnt>
18 Action type REUU <EvtDt>2020-04-23</EvtDt>
...
</CollReuseUpd>
</Rpt>
</TradData>

</SctiesFincgRptgTxReusdCollDataRpt>

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
2020-04- <SctiesFincgRptgTxReusdCollDataRpt>
1 Reporting timestamp
22T16:41:07Z <TradData>
<Rpt>
2 Event date 2020-04-23
<CollReuseUpd>
{LEI} of ...
Report submitting
3 counterparty <RptgDtTm>2020-04-
entity
B 22T16:41:07Z</RptgDtTm>
{LEI} of <CtrPtyData>
Reporting <RptSubmitgNtty>
4 counterparty
counterparty
C
{LEI} of <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
Entity responsible for </RptSubmitgNtty>
5 counterparty
the report <RptgCtrPty>
B
Type of collateral
6 SECU <LEI>123456789ABCDEFGHIJK</LEI>
component

190
Table 103 – Reuse of securities by SME NFC with one counterparty
No Field Example XML Message
</RptgCtrPty>
7 Collateral component {ISIN} <NttyRspnsblForRpt>
Value of reused <LEI>
8 ABCDEFGHIJKLMNOPQRST</LEI>
collateral
Estimated reuse of </NttyRspnsblForRpt>
9 10000000 </CtrPtyData>
collateral
<CollCmpnt>
Reused collateral <Scty>
10 EUR
currency <ISIN>IT00BH4HKS39</ISIN>
<ReuseVal>
<Estmtd
Ccy="EUR">10000000</Estmtd>
</ReuseVal>
</Scty>
</CollCmpnt>
18 Action type REUU <EvtDt>2020-04-23</EvtDt>
...
</CollReuseUpd>
</Rpt>
</TradData>

</SctiesFincgRptgTxReusdCollDataRpt>

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
2020-04- <SctiesFincgRptgTxReusdCollDataRpt>
1 Reporting timestamp
22T16:41:07Z <TradData>
<Rpt>
2 Event date 2020-04-23 <CollReuseUpd>
{LEI} of ...
Report submitting <RptgDtTm>2020-04-
3 counterparty
entity 22T16:41:07Z</RptgDtTm>
B

191
Table 104 – Reuse of securities by SME NFC with several counterparties (1)
No Field Example XML Message
{LEI} of <CtrPtyData>
Reporting
4 counterparty <RptSubmitgNtty>
counterparty
C
{LEI} of <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
Entity responsible for
5 counterparty </RptSubmitgNtty>
the report
B <RptgCtrPty>
Type of collateral
6 SECU <LEI>123456789ABCDEFGHIJK</LEI>
component
</RptgCtrPty>
7 Collateral component {ISIN} <NttyRspnsblForRpt>
Value of reused
8 <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
collateral
</NttyRspnsblForRpt>
Estimated reuse of </CtrPtyData>
9 10000000
collateral <CollCmpnt>
Reused collateral <Scty>
10 EUR
currency <ISIN> IT00BH4HKS39</ISIN>
<ReuseVal>
<Estmtd
Ccy="EUR">10000000</Estmtd>
</ReuseVal>
</Scty>
</CollCmpnt>
18 Action type REUU <EvtDt>2020-04-23</EvtDt>
...
</CollReuseUpd>
</Rpt>
</TradData>

</SctiesFincgRptgTxReusdCollDataRpt>

Table 105 – Reuse of securities by SME NFC with several counterparties (2)
No Field Example XML Message
2020-04- <SctiesFincgRptgTxReusdCollDataRpt>
1 Reporting timestamp
22T18:41:07Z <TradData>
<Rpt>
2 Event date 2020-04-23
<CollReuseUpd>
{LEI} of ...
Report submitting <RptgDtTm>2020-04-
3 counterparty
entity 22T16:41:07Z</RptgDtTm>
D
{LEI} of <CtrPtyData>
Reporting <RptSubmitgNtty>
4 counterparty
counterparty
C
{LEI} of <LEI>11223344556677889900</LEI>
Entity responsible for </RptSubmitgNtty>
5 counterparty
the report <RptgCtrPty>
D

192
Table 105 – Reuse of securities by SME NFC with several counterparties (2)
No Field Example XML Message
Type of collateral
6 SECU <LEI>123456789ABCDEFGHIJK</LEI>
component
</RptgCtrPty>
7 Collateral component {ISIN} <NttyRspnsblForRpt>
Value of reused
8 <LEI>11223344556677889900</LEI>
collateral
</NttyRspnsblForRpt>
Estimated reuse of </CtrPtyData>
9 2000000
collateral <CollCmpnt>
Reused collateral <Scty>
10 EUR
currency <ISIN> FR00BH4HKS3</ISIN>
<ReuseVal>
<Estmtd
Ccy="EUR">2000000</Estmtd>
</ReuseVal>
</Scty>
</CollCmpnt>
18 Action type REUU <EvtDt>2020-04-23</EvtDt>
...
</CollReuseUpd>
</Rpt>
</TradData>

</SctiesFincgRptgTxReusdCollDataRpt>

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.

193
 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
2020-04- <SctiesFincgRptgTxReusdCollDataRpt>
1 Reporting timestamp
22T16:41:07Z <TradData>
<Rpt>
2 Event date 2020-04-23 <CollReuseUpd>
{LEI} of ...
Report submitting <RptgDtTm>2020-04-
3 counterparty
entity 22T16:41:07Z</RptgDtTm>
B
{LEI} of <CtrPtyData>
Reporting <RptSubmitgNtty>
4 counterparty
counterparty
B
{LEI} of <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
Entity responsible for </RptSubmitgNtty>
5 counterparty
the report <RptgCtrPty>
B
11 Reinvestment Rate 1.5 <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
</RptgCtrPty>
Type of re-invested <NttyRspnsblForRpt>
12 REPM
cash investment
Re-invested cash <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
13 100000
amount </NttyRspnsblForRpt>
Re-invested cash </CtrPtyData>
14 EUR
currency <CollCmpnt>

19
CPMI-IOSCO, February 2015, “Public quantitative disclosure standards for central counterparties”:
https://www.bis.org/cpmi/publ/d125.pdf

194
Table 106 - Reinvestment of cash by FC or non-SME NFC without delegation of
reporting
No Field Example XML Message
<Csh>
<RinvstdCsh>
<Tp>REPM</Tp>
<RinvstdCshAmt
Ccy="EUR">100000</RinvstdCshAmt>
</RinvstdCsh>

<CshRinvstmtRate>1.5</CshRinvstmtRate>
</Csh>
18 Action type REUU </CollCmpnt>
<EvtDt>
2020-04-23
</EvtDt>
...
</CollReuseUpd>
</Rpt>
</TradData>

</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
2020-04- <SctiesFincgRptgTxReusdCollDataRpt>
1 Reporting timestamp
22T16:41:07Z <TradData>
<Rpt>
2 Event date 2020-04-23
<CollReuseUpd>
{LEI} of ...
Report submitting
3 counterparty <RptgDtTm>2020-04-
entity
B 22T16:41:07Z</RptgDtTm>
{LEI} of <CtrPtyData>
Reporting <RptSubmitgNtty>
4 counterparty
counterparty
A
{LEI} of <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
Entity responsible for </RptSubmitgNtty>
5 counterparty
the report <RptgCtrPty>
A
11 Reinvestment Rate 1 <LEI>12345678901234500000</LEI>

195
Table 107 - Reinvestment of cash by FC or non-SME NFC with delegation of
reporting
No Field Example XML Message
Type of re-invested </RptgCtrPty>
12 REPM <NttyRspnsblForRpt>
cash investment
Re-invested cash
13 100000 <LEI>12345678901234500000</LEI>
amount
Re-invested cash </NttyRspnsblForRpt>
14 EUR </CtrPtyData>
currency
<CollCmpnt>
<Csh>
<RinvstdCsh>
<Tp>REPM</Tp>
<RinvstdCshAmt
Ccy="EUR">100000</RinvstdCshAmt>
</RinvstdCsh>

<CshRinvstmtRate>1</CshRinvstmtRate>
</Csh>
18 Action type REUU </CollCmpnt>
<EvtDt>
2020-04-23

</EvtDt>
...
</CollReuseUpd>
</Rpt>
</TradData>

</SctiesFincgRptgTxReusdCollDataRpt>

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

2020-04- <SctiesFincgRptgTxReusdCollDataRpt>
1 Reporting timestamp
22T16:41:07Z <TradData>
<Rpt>
2 Event date 2020-04-23 <CollReuseUpd>

196
Table 108 - Reinvestment of cash by SME NFC with one counterparty

No Field Example XML Message

{LEI} OF ...
Report submitting
3 counterparty <RptgDtTm>2020-04-
entity
B 22T16:41:07Z</RptgDtTm>
{LEI} of <CtrPtyData>
Reporting
4 counterparty <RptSubmitgNtty>
counterparty
C
{LEI} of <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
Entity responsible for </RptSubmitgNtty>
5 counterparty
the report <RptgCtrPty>
B
11 Reinvestment Rate 1 <LEI>123456789ABCDEFGHIJK</LEI>
Type of re-invested </RptgCtrPty>
12 REPM <NttyRspnsblForRpt>
cash investment
Re-invested cash
13 100000 <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
amount
</NttyRspnsblForRpt>
Re-invested cash </CtrPtyData>
14 EUR
currency <CollCmpnt>
<Csh>
<RinvstdCsh>
<Tp>REPM</Tp>
<RinvstdCshAmt
Ccy="EUR">100000</RinvstdCshAmt>
</RinvstdCsh>

<CshRinvstmtRate>1</CshRinvstmtRate>
</Csh>
18 Action type REUU </CollCmpnt>
<EvtDt>
2020-04-23

</EvtDt>
...
</CollReuseUpd>
</Rpt>
</TradData>

</SctiesFincgRptgTxReusdCollDataRpt>

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.

197
 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
2020-04- <SctiesFincgRptgTxReusdCollDataRpt>
1 Reporting timestamp <TradData>
22T16:41:07Z
<Rpt>
2 Event date 2020-04-23 <CollReuseUpd>
{LEI} of ...
Report submitting <RptgDtTm>2020-04-
3 counterparty
entity 22T16:41:07Z</RptgDtTm>
B
{LEI} of <CtrPtyData>
Reporting <RptSubmitgNtty>
4 counterparty
counterparty
C
{LEI} of <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
Entity responsible for </RptSubmitgNtty>
5 counterparty
the report <RptgCtrPty>
B
11 Reinvestment Rate 1 <LEI>123456789ABCDEFGHIJK</LEI>
</RptgCtrPty>
Type of re-invested <NttyRspnsblForRpt>
12 REPM
cash investment
Re-invested cash <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
13 100000
amount </NttyRspnsblForRpt>
Re-invested cash </CtrPtyData>
14 EUR
currency <CollCmpnt>
<Csh>
<RinvstdCsh>
<Tp>REPM</Tp>
<RinvstdCshAmt
Ccy="EUR">100000</RinvstdCshAmt>
</RinvstdCsh>

<CshRinvstmtRate>1</CshRinvstmtRate>
</Csh>
</CollCmpnt>
18 Action type REUU
<EvtDt>
2020-04-23

</EvtDt>
...
</CollReuseUpd>
</Rpt>
</TradData>

</SctiesFincgRptgTxReusdCollDataRpt>

198
Table 110 - Reinvestment of cash by SME NFC with several counterparties (2)
No Field Example XML Message
2020-04- <SctiesFincgRptgTxReusdCollDataRpt>
1 Reporting timestamp <TradData>
22T16:41:07Z
<Rpt>
2 Event date 2020-04-23 <CollReuseUpd>
{LEI} of ...
Report submitting <RptgDtTm>2020-04-
3 counterparty
entity 22T16:41:07Z</RptgDtTm>
D
{LEI} of <CtrPtyData>
Reporting <RptSubmitgNtty>
4 counterparty
counterparty
C
{LEI2} of <LEI>11223344556677889900</LEI>
Entity responsible for </RptSubmitgNtty>
5 counterparty
the report <RptgCtrPty>
D
11 Reinvestment Rate 1 <LEI>123456789ABCDEFGHIJK</LEI>
</RptgCtrPty>
Type of re-invested <NttyRspnsblForRpt>
12 REPM
cash investment
Re-invested cash <LEI>11223344556677889900</LEI>
13 100000
amount </NttyRspnsblForRpt>
Re-invested cash </CtrPtyData>
14 EUR
currency <CollCmpnt>
<Csh>
<RinvstdCsh>
<Tp>REPM</Tp>
<RinvstdCshAmt
Ccy="EUR">100000</RinvstdCshAmt>
</RinvstdCsh>

<CshRinvstmtRate>1</CshRinvstmtRate>
</Csh>
</CollCmpnt>
18 Action type REUU
<EvtDt>
2020-04-23

</EvtDt>
...
</CollReuseUpd>
</Rpt>
</TradData>

</SctiesFincgRptgTxReusdCollDataRpt>

199
 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
2020-04- <SctiesFincgRptgTxReusdCollDataRpt>
1 Reporting timestamp
22T16:41:07Z <TradData>
<Rpt>
2 Event date 2020-04-23 <CollReuseUpd>
{LEI} of ...
Report submitting <RptgDtTm>2020-04-
3 counterparty
entity 22T16:41:07Z</RptgDtTm>
D
{LEI} of <CtrPtyData>
Reporting <RptSubmitgNtty>
4 counterparty
counterparty
C
{LEI2} of <LEI>11223344556677889900</LEI>
Entity responsible for </RptSubmitgNtty>
5 counterparty
the report <RptgCtrPty>
D
Type of collateral
6 CASH <LEI>123456789ABCDEFGHIJK</LEI>
component
</RptgCtrPty>
Type of re-invested <NttyRspnsblForRpt>
12 OTHR
cash investment
Re-invested cash <LEI>11223344556677889900</LEI>
13 0
amount </NttyRspnsblForRpt>
</CtrPtyData>
<CollCmpnt>
<Csh>
<RinvstdCsh>
<Tp>OTHR</Tp>
<RinvstdCshAmt
Ccy="EUR">0</RinvstdCshAmt>
</RinvstdCsh>
</Csh>
Re-invested cash </CollCmpnt>
14 EUR
currency <EvtDt>
2020-04-23

</EvtDt>
...
</CollReuseUpd>
</Rpt>
</TradData>

</SctiesFincgRptgTxReusdCollDataRpt>

200
 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
2020-04- <SctiesFincgRptgTxReusdCollDataRpt>
1 Reporting timestamp <TradData>
22T16:41:07Z
<Rpt>
2 Event date 2020-04-23 <Crrctn>
{LEI} of <RptgDtTm>2020-04-
Report submitting 22T16:41:07Z</RptgDtTm>
3 counterparty
entity <CtrPtyData>
B
{LEI} of <RptSubmitgNtty>
Reporting
4 counterparty
counterparty <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
B
{LEI} of </RptSubmitgNtty>
Entity responsible for <RptgCtrPty>
5 counterparty
the report
B
<LEI>ABCDEFGHIJKLMNOPQRST</LEI>
15 Funding sources REPO </RptgCtrPty>
<NttyRspnsblForRpt>
Market value of the
16 5000000
funding sources <LEI>ABCDEFGHIJKLMNOPQRST</LEI>
Funding sources </NttyRspnsblForRpt>
17 EUR
currency </CtrPtyData>
<CollCmpnt>
...
</CollCmpnt>
<EvtDt>
2020-04-23

</EvtDt>
<FndgSrc>
18 Action type REUU <Tp>REPO</Tp>
<MktVal
Ccy="EUR">5000000</MktVal>
</FndgSrc>
</Crrctn>
</Rpt>
</TradData>

</SctiesFincgRptgTxReusdCollDataRpt>

201
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:

202
Table 113 – Rejection feedback
Details to be XML Message
No. Field reported
1 Number of files received Numeric values <SctiesFincgRptgTxStsAdvc>
2 No. of files accepted Numeric values <TxRptStsAndRsn>
<Rpt>
3 No. of files rejected Numeric values
<RptSttstcs>
4 File identification Textual value <TtlNbOfRpts>2</TtlNbOfRpts>
5 Rejection reason Error code
6 Rejection description Error description <TtlNbOfRptsAccptd>1</TtlNbOfRptsAccptd>
7 Number of SFTs received Numeric values
<TtlNbOfRptsRjctd>1</TtlNbOfRptsRjctd>
8 Number of SFTs accepted Numeric values <NbOfRptsRjctdPerErr>
9 Number of SFT s rejected Numeric values <DtldNb>1</DtldNb>
10 Identification of the SFT <RptSts>
11 Reporting counterparty Table A Field 3 <MsgRptId>ReportID</MsgRptId>
<Sts>RJCT</Sts>
12 UTI Table B Field 1 <DtldVldtnRule>
13 Other counterparty Table A Field 11 <Id>RuleID</Id>
14 Master agreement type Table B Field 9 <Desc>Rule description</Desc>
15 Rejection reason Error codes <SchmeNm>
<Cd>1</Cd>
</SchmeNm>
</DtldVldtnRule>
</RptSts>
</NbOfRptsRjctdPerErr>
</RptSttstcs>
<TxSttstcs>
<TtlNbOfTxs>2</TtlNbOfTxs>

<TtlNbOfTxsAccptd>1</TtlNbOfTxsAccptd>

<TtlNbOfTxsRjctd>1</TtlNbOfTxsRjctd>
<NbOfTxsRjctd>
<TxId>
<Tx>
Rejection description Error description <RptgCtrPty>

<LEI>12345678901234500000</LEI>
</RptgCtrPty>
<OthrCtrPty>

<LEI>12345678901234500000</LEI>
</OthrCtrPty>

<UnqTradIdr>UTI1</UnqTradIdr>
<MstrAgrmt>
<Tp>
<Tp>OTHR</Tp>
</Tp>
<Vrsn>2019</Vrsn>
16 </MstrAgrmt>

203
 </Tx>
</TxId>
<Sts>RJCT</Sts>
<DtldVldtnRule>
<Id>RuleID</Id>
<Desc>Rule description</Desc>
</DtldVldtnRule>
</NbOfTxsRjctd>
</TxSttstcs>
</Rpt>
</TxRptStsAndRsn>
</SctiesFincgRptgTxStsAdvc>

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

204
 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

Details to be XML Message
No. Field reported
Reporting
1 Table A Field 3
counterparty <SctiesFincgRptgRcncltnStsAdvc>
2 UTI Table B Field 1 <RcncltnData>
Other <Rpt>
3 Unique key Table A Field <PairgRcncltnSts>
counterparty 11
Master
4 agreement Table B Field 9 <DtldNbOfRpts>2</DtldNbOfRpts>
type <DtldSts>PARD</DtldSts>
Report Paired/Reconcil </PairgRcncltnSts>
status ed <RcncltnRpt>
Information …
on the last <TxId>
reporting <RptgCtrPty>
Reporting timestamp
Table A Field 1 <LEI>12345678901234500000</LEI>
timestamp pertaining
to the SFT </RptgCtrPty>
that is <OthrCtrPty>
reconciled
Information <LEI>ABCDEFGHIJKLMNOPQRST</
if the LEI>
transaction </OthrCtrPty>
Modification
subject of True/False
status <UnqTradIdr>UTI10</UnqTradIdr>
reconciliati
on was </TxId>
modified <Modfd>true</Modfd>
<RcncltnSts>
Indication
No <RptgData>
that the
Reconciliati True/False <NotMtchd>
transaction
on required <CtrPty1>
is not

205
Table 115 - Reconciliation Feedback
Details to be XML Message
No. Field reported
subject of
reconciliati <LEI>AAAAAAAAAAAAAAAAAAAA</
on LEI>
Matching </CtrPty1>
True/False
status <CtrPty2>
Loan
reconciled/not <LEI>EEEEEEEEEEEEEEEEEEEE</
reconciliatio
reconciled LEI>
n status
Only not </CtrPty2>
reconciled <MtchgCrit>
fields are to <LnMtchgCrit>
Reportable <TermntnDt>
be Loan fields of
loan fields <Val1>2019-04-20
reported, Table 1 of RTS
subject of </Val1>
both values on data
reconciliatio <Val2>2019-04-21
subject of verification
n </Val2>
reconciliati
on shall be </TermntnDt>
reported </LnMtchgCrit>
Collateral <CollMtchgCrit>
reconciled/not <CmpntTp>
reconciliatio
reconciled <Scty>
n status
<Qty>

<Val1>1234</Val1>

Only not <Val2>1243</Val2>

reconciled </Qty>
Reportable fields are to </Scty>
collateral be Collateral fields </CmpntTp>
fields reported, of Table 1 of </CollMtchgCrit>
subject of both values RTS on data </MtchgCrit>
reconciliatio subject of verification </NotMtchd>
n reconciliati </RptgData>
on shall be </RcncltnSts>
reported </RcncltnRpt>
</Rpt>
</RcncltnData>

</SctiesFincgRptgRcncltnStsAdvc>
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.

206
 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.

207
 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

Details to be
No. Field reported XML schema
<SctiesFincgRptgTxStatRpt>
<Stat>
...
<CtrPtyData>
...
</CtrPtyData>
<LnData>
Table 1 Field 1 to ...
Field 18 </LnData>
1 Reportable field
Table 2 Field 1 to <CollData>
Field 99 ...
</CollData>
<RcncltnFlg>
...
</RcncltnFlg>
<CtrctMod>
...
</CtrctMod>

208
Table 116 – SFT report – counterparty, loan and collateral data
Details to be
No. Field 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

Details
to be
No. Field reported XML schema
<SctiesFincgRptgMrgnDataTxStatRpt>
<Stat>
...
<CtrPty>
...
</CtrPty>
<CollPrtflId>...</CollPrtflId>
<PstdMrgnOrColl>
...
</PstdMrgnOrColl>
<RcvdMrgnOrColl>
Table 3
...
1 Reportable field Field 1 to
</RcvdMrgnOrColl>
Field 20
<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

209
 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

Details
to be
No. Field reported XML schema
<SctiesFincgRptgReusdCollDataTxStatRpt>
<Stat>
...
<CtrPtyData>
...
</CtrPtyData>
<CollCmpnt>
...
</CollCmpnt>
...
Table 4 <FndgSrc>
Field 1 ...
1 Reportable field
to Field </FndgSrc>
18 <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.

210
Table 119 – Rejections report
Additional Details to be XML schema
No. Field information reported
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
Identification of the
10 SFT
Reporting
Table 1 Field 3
11 counterparty
12 UTI Unique key of Table 2 Field 1
13 Other counterparty the SFT Table 1 Field 11
Master agreement
Table 2 Field 9
14 type
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

Details to be XML
No. Field Additional information reported schema
1 Reporting counterparty Table 1 Field 3
2 UTI Table 2 Field 1
Unique key
3 Other counterparty Table 1 Field 11
4 Master agreement type Table 2 Field 9
5 Report status Paired/Reconciled
Information if the
transaction subject of
7 Modification status True/False
reconciliation was
modified

211
Table 120 – SFT reconciliation status report
Details to be XML
No. Field Additional information reported schema
Indication that the
No Reconciliation
8 transaction is not True/False
required
subject of reconciliation
9 Matching status True/False
Loan reconciliation reconciled/not
10
status reconciled
Only not reconciled
fields are to be reported,
Reportable loan fields
11 both values subject of
subject of reconciliation
reconciliation shall be
reported
Collateral reconciliation reconciled/not
12
status reconciled
Only not reconciled
Reportable collateral fields are to be reported,
13 fields subject of both values subject of
reconciliation 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>

212
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

213
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 non-
scheduled 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).

214
If the execution of a query returns no transactions, a relevant feedback message should
be sent by the TR.

215