Guidelines on transfer of data between Trade Repositories under EMIR and SFTR

05-01-2024
ESMA74-362-2351
Guidelines on transfer of data between Trade Repositories under EMIR and SFTR

Table of contents
1 Scope...................................................................................................................... 4
2 Legislative references, abbreviations and definitions............................................... 5
2.1 Legislative references ............................................................................................. 5
2.2 Abbreviations .......................................................................................................... 7
2.3 Glossary of concepts and terms .............................................................................. 8
3 Purpose..................................................................................................................10
4 Compliance and reporting obligations ....................................................................11
4.1 Status of the guidelines ..........................................................................................11
4.2 Reporting requirements..........................................................................................11
5 Amendments to Guidelines on transfer of data between Trade Repositories under
EMIR ........................................................................................................................12
5.1 Annex I - Procedure for transfer of data at the request of a TR participant under EMIR
...............................................................................................................................15
5.2 Annex II - Procedure for migration in case of withdrawal of registration under EMIR.
...............................................................................................................................17
Guidelines on transfer of data between Trade Repositories under SFTR .............................19
1 Scope.....................................................................................................................19
2 Legislative references, abbreviations and definitions..............................................20
2.1 Legislative references ............................................................................................20
2.2 Abbreviations .........................................................................................................21
2.3 Glossary of concepts and terms .............................................................................22
3 Purpose..................................................................................................................24
4 Compliance and reporting obligations ....................................................................25
4.1 Status of the guidelines ..........................................................................................25
4.2 Reporting requirements..........................................................................................26
5 Guidelines on transfer of data between Trade Repositories under SFTR ...............26
5.1 Annex I - Procedure for transfer of data at the request of a TR participant under SFTR
...............................................................................................................................33
5.2 Annex II - Procedure for migration in case of withdrawal of registration under SFTR.
...............................................................................................................................35

1 Scope
Who?

1. These guidelines apply to trade repositories (TRs) registered or recognised by ESMA,
   to national competent authorities (NCAs), and to reporting counterparties or the entities reporting on their behalf. What?
2. The adopted guidelines apply in relation to:
   the reporting without duplication of details of derivatives by counterparties and CCPs under Article 9(1) of EMIR; the procedures for portability under Article 78(9) of EMIR; the transfer of derivatives between TRs at the request of the counterparties, or the entity reporting on their behalf, or in the situation where the registration of a TR has been withdrawn covered by Article 79(3) of EMIR; the record-keeping of details of derivatives in accordance with Article 80(3) of EMIR; and
   Article 21(2) of RTS on registration (EMIR).
   When?
3. The existing guidelines on data transfer under EMIR apply as of 16 October 2017. The
   amendments to these Guidelines apply as of 3 October 2022.

2 Legislative references, abbreviations and definitions
2.1 Legislative references
EMIR Regulation (EU) No 648/2012 of the European Parliament and of the Council of 4 July 2012 on OTC derivatives, central counterparties and trade repositories1 ESMA Regulation Regulation (EU) No 1095/2010 of the European Parliament and of the Council of 24 November 2010 establishing a European Supervisory Authority (European Securities and Markets Authority), amending Decision No 716/2009/EC and repealing Commission Decision 2009/77/EC2 RTS on reporting Commission Delegated Regulation (EU) No 148/2013 of 19 December 2012 supplementing Regulation (EU) No 648/2012 of the European Parliament and of the Council on OTC derivatives, central counterparties and trade repositories with regard to regulatory technical standards on the minimum details of the data to be reported to trade repositories, as amended by Commission Delegated Regulation (EU) 2017/1043 Draft RTS on reporting Commission Delegated Regulation (EU) No YYYY/XXX of … supplementing Regulation (EU) No 648/2012 of the European Parliament and of the Council on OTC derivatives, central counterparties and trade repositories with regard to regulatory technical standards specifying the minimum details of the data to be reported to trade repositories and repealing Commission Delegated Regulation (EU) No 148/20134 ITS on reporting Commission Implementing Regulation (EU) No 1247/2012 of 19 December 2012 laying down implementing technical standards with regard to the format and frequency of trade reports to trade repositories according to Regulation (EU) No 648/2012 of the European Parliament and of the Council on OTC derivatives, central counterparties and trade repositories, 1 OJ L 201, 27.7.2012, p.1 2 OJ L 331, 15.12.2010, p. 84–119 3 OJ L 52, 23.2.2013, p. 1–10 4 3 The Draft RTS on reporting, adopted by ESMA on 17/12/2020 (ESMA74-362-824), are submitted to the European Commission for endorsement.

as amended by Commission Implementing Regulation (EU) 2017/1055 RTS on registration Commission Delegated Regulation (EU) No 150/2013 of 19 December 2012 supplementing Regulation (EU) No 648/2012 of the European Parliament and of the Council on OTC derivatives, central counterparties and trade repositories with regard to regulatory technical standards specifying the details of the application for registration as a trade repository, as amended by Commission Delegated Regulation (EU) 2019/362 of 13 December 20186 RTS on data access Commission Delegated Regulation (EU) No 151/2013 of 19 December 2012 supplementing Regulation (EU) No 648/2012 of the European Parliament and of the Council on OTC derivatives, central counterparties and trade repositories, with regard to regulatory technical standards specifying the data to be published and made available by trade repositories and operational standards for aggregating, comparing and accessing the data, as amended by Commission Delegated Regulation (EU) 2017/1800 and by Commission Delegated Regulation (EU) 2019/3617 Guidelines on positions Guidelines on position calculation by trade repositories under EMIR8 MiFIR Commission Delegated Regulation (EU) No 600/2014 of 15 May 2014 of the European Parliament and of the Council on markets in financial instruments and amending Regulation (EU) No 648/20129 5 OJ L 352, 21.12.2012, p. 20–29 6 OJ L 52, 23.2.2013, p. 25–32 7 OJ L 52, 23.2.2013, p. 33–36 8 ESMA70-151-1350 9 OJ L 173, 12.6.2014, p. 84

2.2 Abbreviations
CP Consultation Paper
CSV Comma-separated values
ECB European Central Bank
EEA European Economic Area
EER Entity Responsible for Reporting
ESMA European Securities and Markets Authority EU European Union FSB Financial Stability Board ISO International Organization for Standardization ITS Implementing Technical Standards LEI Legal Entity Identifier NCA National Competent Authority NCB National Central Bank Q&A Questions and Answers RSE Report Submitting Entity RTS Regulatory Technical Standards SLA Service Level Agreement TR Trade Repository TRACE System for single access to TR data XML Extensible Mark-up Language

2.3 Glossary of concepts and terms
All the definitions, concepts and terms that are used in EMIR, in the applicable RTS on reporting and ITS on reporting , as well as in the applicable RTS on data access and in the Q&As and in these Guidelines are used with the same meaning. For the purpose of these Guidelines the following terms have been defined/described:

• “active client” means a TR participant that has outstanding derivatives at a TR.
• “compressed derivatives” means derivatives that were terminated due to
  compression as defined in Article 2(1)(47) of MiFIR and derivatives included in a position. Therefore, compressed derivatives refers to a a set of derivatives between a pair of counterparties which have been terminated before their initially established maturity date by the two counterparties and are identified with action type “Z” or “P” under the current RTS on reporting. In addition, under the draft RTS on reporting, such a set of derivatives are identified with a combination of action type “TERM” and event type ”COMP”, a combination of action type “TERM” and event type ”INCP”, or action type “POSC”.
• “errored derivative” means a derivative which is reported to a TR as a result of a
  mistake. It is identified with action type “E” under the current RTS on reporting and “EROR” under the draft RTS on reporting.
• “life-cycle events” comprise all action types reported for a given derivative.
• “matured derivative” means a derivative which is reported to a TR and at a given
  point in time has reached its contractually-agreed maturity date.
• “new TR” means a TR to which a TR participant has started or intends to start
  reporting derivatives under Article 9 of EMIR, although initially that entity was reporting, either directly or through an RSE, to the old TR.
• “non-active client” means a TR participant that no longer has outstanding
  derivatives at a TR.
• “old TR” means a TR to which a TR participant was reporting or to which the
  derivatives of a TR participant were reported by an RSE under Article 9 of EMIR, but (i) the TR participant decided to discontinue its contractual arrangement reporting or (ii) the registration of the TR was withdrawn.
• “outstanding derivative” means such a derivative, including CCP-cleared
  derivatives, which is reported to a TR and has not matured and has not been subject of a report with action types “E”, “C”, “P” or “Z” under the current RTS on reporting. In addition, under the draft RTS on reporting, “outstanding derivative” means a derivative that has not matured or which has not been the subject of reports with action types "TERM”, “EROR”, or “POSC”. Furthermore, under the draft RTS on reporting, “outstanding derivative” means a derivative that has been subject to a

report with the action type “REVI” not followed by another report with the action type “TERM” or “EROR”.

• “portability” means the possibility to transfer records relating to details of derivatives
  reported under Article 9 of EMIR from the old TR to the new TR, as those are defined in these guidelines.
• “positions” means the representation of exposures between a pair of counterparties
  as included in the Guidelines on positions.
• “reconciliation” means the process through which TRs confirm that the two sides of
  a derivative have been reported with the same information by each ERR.
• “rejections” means derivatives that have been rejected by a TR due to errors in the
  information reported by an ERR or RSE.
• “report submitting entity” (RSE, hereinafter), which is one of the counterparty fields
  of the technical standards on reporting10, should be understood as the entity which has entered in a contractual relationship with a registered or recognised TR and it:
  o reports only derivatives where it is one of the counterparties, in which case it would coincide with either the reporting counterparty of the contract or the other counterparty, or o reports derivatives where it might be or might not be one of the counterparties.
• “terminated derivatives”, under the RTS on reporting, means derivatives which have
  been terminated before their contractually-agreed maturity date by the two counterparties and are identified with action type “C”. In addition, under the draft RTS on reporting, such a set of derivatives are identified with a combination of action type “TERM” or action type “POSC”. Under the draft RTS on reporting, “terminated derivatives” also comprise the above mentioned compressed derivatives.
• “transfer” or “transfer (of details) of derivatives” means an act or process of moving
  the records of the derivatives, respectively, from the old TR to the new TR.
• “TR participant”11 means an entity which has a contractual arrangement for the
  purpose of reporting derivative contracts under Article 9 of EMIR with at least one registered or recognised TR. The TR participant may be an RSE, an ERR, a reporting counterparty or a CCP. 10 https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32017R0104 11 Some TRs might further specify the types of TR participants such as reporting, general reporting, non-reporting, etc. participants. These sub-categories are transparent from the perspective of these guidelines.

3 Purpose
4. The objectives of these guidelines are to establish consistent, efficient and effective
supervisory practices within the ESFS and to ensure the common, uniform and consistent application of by providing clarification for TRs, reporting counterparties and ERR on how to ensure compliance at all time with the following EMIR provisions:
Article 9(1) (e) of EMIR which provides that “Counterparties and CCPs that are
required to report the details of derivative contracts shall ensure that such details are reported correctly and without duplication.”;
Article 80(3) of EMIR which provides that “A trade repository shall promptly
record the information received under Article 9 and shall maintain it for at least 10 years following the termination of the relevant contracts. It shall employ timely and efficient record keeping procedures to document changes to recorded information.”;
Article 79(3) of EMIR which provides that “A trade repository from which
registration has been withdrawn shall ensure orderly substitution including the transfer of data to other trade repositories and the redirection of reporting flows to other trade repositories.”; and The procedures for portability under Article 78(9) of EMIR.
5. The Guidelines are based on Article 16(1) of ESMA Regulation,which provides that
"The Authority shall, with a view to establishing consistent, efficient and effective supervisory practices within the ESFS, and to ensuring the common, uniform and consistent application of Union law, issue guidelines addressed to all competent authorities or all financial market participants and issue recommendations to one or more competent authorities or to one or more financial market participants.”.
6. The purpose of the amended Guidelines on transfer of data under EMIR is threefold:
Remove portability obstacles from the competitive TR environment, and ensure that TR participants can benefit from the multi-TR environment; Ensure the quality of data available to authorities, including the aggregations carried out by TRs, even when the TR participant changes the TR to which it reports and irrespective of the reason for such a change; Ensure that there is a consistent, standardised and harmonised way to transfer records from one TR to another TR and support the continuity of reporting and reconciliation in all cases including the withdrawal of registration of a TR.
7. The need to transfer data to another TR may arise for different reasons. The Guidelines
therefore address separately the situations where (i) the transfer is due to withdrawal of registration of the TR from the cases in which (ii) the transfer is done on a voluntary basis and under normal market conditions. Guidelines 1 to 15 and Guidelines 33 and 34 apply to both situations; Guidelines 16 to 22 apply only to voluntary porting; and

Guidelines 23 to 32 apply only to withdrawal of registration of a TR. The incentives and motivations for the relevant parties in each of the two cases would be different and therefore there is a need for a specific approach in each particular situation.
8. The Guidelines establish high-level principles that would need to be followed by the TR
participants, e.g. RSE, counterparties and CCPs, on the one hand, and the TRs on the other. Those principles are complemented by specific procedures, set out to ensure the timely and robust transfer of details of derivatives. These Guidelines however do not cover situations that do not require transfer of data, such as reporting counterparties that have decided to report to two or more TRs at the same time. 4 Compliance and reporting obligations
4.1 Status of the guidelines
9. In accordance with Article 16(3) of the ESMA Regulation, national competent
authorities, TRs, reporting counterparties and entities responsible for the report must make every effort to comply with these guidelines.
10. Competent authorities to which these guidelines apply should comply by incorporating
them into their national legal and/or supervisory frameworks as appropriate, including where particular guidelines are directed primarily at financial market participants. In this case, competent authorities should ensure through their supervision that financial market participants comply with the guidelines.
11. ESMA will assess the application of these guidelines by TRs through its ongoing direct
supervision.
4.2 Reporting requirements
12. Within two months of the date of publication of the guidelines on ESMA’s website in all
EU official languages, competent authorities to which these guidelines apply must notify ESMA whether they (i) comply, (ii) do not comply, but intend to comply, or (iii) do not comply and do not intend to comply with the guidelines.
13. In case of non-compliance, competent authorities must also notify ESMA within two
months of the date of publication of the guidelines on ESMA’s website in all EU official languages of their reasons for not complying with the guidelines
14. A template for notifications is available on ESMA’s website. Once the template has
been filled in, it shall be transmitted to ESMA.
15. TRs are not required to report whether they comply with these guidelines.
16. Reporting counterparties and entities reporting on their behalf are not required to report
whether they comply with these guidelines.

5 Amendments to Guidelines on transfer of data between Trade Repositories under EMIR
17. Guidelines 11, 15, 18, 19, 23 and 26 of the existing Guidelines on transfer of data
between Trade Repositories under EMIR are replaced as follows:
Guideline 11. Prior to the data transfer on non-working day, TRs should ensure that TR participants modify the outstanding derivatives that are subject to data transfer to comply with the most up to date reporting requirement at the latest by 23:59:59 on the Friday ahead of the weekend on which the porting takes place and (i) in the case of full porting, from the start of the data transfer, the old TR should not accept reports on lifecycle events and position data relating to the derivatives subject to transfer; (ii) and in addition, in the case of partial porting, the TR participant should ensure accurate reporting of lifecycle events relating to the derivatives to the relevant TRs. For transfers on working days, the old TR and the new TR are to agree upon a time, prior to the data transfer, by which the modifications of the outstanding derivatives that are subject to data transfer should be completed by the TR participant. For transfers on working days, (i) and (ii) should be followed by the old TR and the TR participant. Guideline 15. In case all the data in the scope of the migration plan cannot be transferred in a single instance, the TRs should transfer the data in accordance with the following order:
(i) the latest state of the outstanding derivatives received, i.e. the “trade state”; (ii) in the case of withdrawal of registration, the reports related to lifecycle events applicable to the outstanding derivatives; (iii) in the case of withdrawal of registration, all terminated, compressed and matured derivatives that are still subject to the requirement under Article 80(3) of EMIR, together with the relevant lifecycle events; (iv) in the case of withdrawal of registration, all errored derivatives that are still subject to the requirement under Article 80(3) of EMIR together with the relevant lifecycle events; (v) in the case of withdrawal of registration, all rejected derivatives reported by the TR participant and that have not passed the data validations; (vi) in the case of withdrawal of registration, the reporting log in a machine readable format of the old TR which records the reason or reasons for a modification, the date, timestamp and a clear description of the changes (including the old and new contents of the relevant data) pertaining to the derivatives that are transferred ; and (vii) in the case of withdrawal of registration, all data on rejections, meaning the outbound reports for authorities pertaining to rejections in the XML format, and all data on reconciliation, meaning the outbound reports for authorities pertaining to reconciliation status in the XML format.

Guideline 18. In the case of transfer of data requested by a TR participant, and when the registration of the old TR is not withdrawn nor in the process to be withdrawn, only the latest state of the outstanding derivatives, i.e. the “trade state”, is to be transferred. Guideline 19. In the case of transfer of data requested by a TR participant, the process described in the procedure contained in Annex I for transfer of data at the request of a TR participant under EMIR should be followed by the old and the new TR. The TRs should agree the migration plan for the data transfer of a given TR participant as soon as possible and no later than in ten working days after the request is received. Guideline 23. In the case of withdrawal of registration of a TR, the transfer of data should comprise all the details of derivatives reported to the TR, including the rejected ones, together with the relevant reporting log and all data on rejections, meaning the outbound reports for authorities pertaining to rejections in the XML format, and all data on reconciliation, meaning the outbound reports for authorities pertaining to reconciliation status in the XML format. The order of data transfer outlined in Guideline 15 should be followed. Guideline 26. In the case of withdrawal of registration at the request of a TR, it should notify ESMA in advance of the intended date of cessation of operations and should then immediately notify the TR participants, the other TRs, and the relevant NCAs by electronic means. For TRs with more than 500 TR participants the advance notice should be at least nine months, while for TRs with 500 or with less than 500 TR participants, the advance notice should be at least six months.
18. New Guidelines 30 to 34 are added to the existing Guidelines on transfer of data
between Trade Repositories under EMIR as follows:
Guideline 30. In the case of withdrawal of registration, the new TR may charge fees to the active TR participants for their non-outstanding derivative data. Guideline 31. In the case of withdrawal of registration, the new TR can store non-outstanding derivative data of varying data quality and/or in different formats in separate databases/tables. The new TR should respond to the queries of authorities on demand. Guideline 32. In the case of withdrawal of registration, the TR whose registration will be withdrawn, should provide the new TR with the necessary technical information on the data that is to be transferred to facilitate the data transfer to and the subsequent storage by the new TR. The old TR should provide the new TR with the before-mentioned information in a timely manner to allow the new TR to prepare as necessary. The technical documentation should at least cover the following aspects:
(i) mapping of the fields to EMIR fields; and
(ii) technical explanations for each field.

Guideline 33. Before and following the transfer of records of a TR participant, the TR participant should verify and confirm with the new and the old TR the correctness of the following aggregate information regarding the derivatives subject to transfer, consistent with the timing detailed in Guideline 11:
(i) the total number of outstanding derivatives, where each derivative is identified by the unique combination of the fields “Reporting counterparty”, “Other counterparty”, and “Unique Transaction Identifier”, together with the corresponding margin reports; (ii) the total number of reports relating to lifecycle events of these derivatives (in case those are transferred); (iii) the total number of records relating to terminated, compressed and matured derivatives in the last five years, for which there is record keeping obligation in accordance with Article 9(2) of EMIR (in case those are transferred); (iv) the total number of records relating to errored derivatives in the last five years, for which there is a record keeping obligation in accordance with Article 9(2) of EMIR (in case those are transferred). Guideline 34. Where an FC and an NFC- report to two different TRs outstanding OTC derivatives subject to transfer:
(i) if the NFC- decides not to report itself, the outstanding derivatives of the NFC- should be transferred to the TR of the FC, unless the FC decides to become client of the TR of the NFC￾and report the derivatives concluded with the NFC- to that TR. (ii) each time an NFC changes its status from NFC+ to NFC- and decides not to report itself its derivatives, it should request the transfer of its outstanding derivatives concluded with the FC to the TR of that FC as of the date of its changed status unless the FC decides to become client of the TR of the NFC- and to report the derivatives concluded with the NFC- to that TR. Similarly, each time an NFC changes its status from NFC- to NFC+, the outstanding derivatives concluded with the FC should be transferred back to the TR of the NFC, unless the NFC decides to become client of the TR of the FC and to report the derivatives concluded with the FC to that TR. (iii) For the performance of data transfer, neither the NFC nor the FC (or any report submitting entity reporting on their behalf) are expected to onboard to the TRs of the other counterparty.

5.1 Annex I - Procedure for transfer of data at the request of a TR
participant under EMIR
A. Planning and preparation
After signing the relevant contractual agreement with the TR participant, the new TR communicates to and agrees with the old TR the migration plan elaborated consistent with Guideline 3. The new TR notifies by email the relevant authorities about the transfer. The old TR determines and agrees with the TR participant the following aggregate information regarding the derivatives of the TR participant subject to transfer:
o The latest state of the outstanding derivatives received, i.e. the “trade state” o The total number of outstanding derivatives The old TR should request the TR participant’s confirmation of the accuracy of the information above vis-à-vis the TR participant’s own records12 as per Guideline 8. In case of a mismatch, the old TR should reconcile the relevant numbers with the TR participant and agree on the final list of derivative reports that will be migrated. The old TR should solve all discrepancies at the earliest convenience and in no later than five working days. B. Execution of transfer Once the number of derivatives and records are confirmed, the old TR should proceed with generating the relevant file(s) consistent with Guideline 5 and the relevant generic principles. The old and new TRs execute the migration plan. The old TR should transfer the files generated to the new TR which acknowledges the file transfer. In this respect the outstanding derivatives should be transferred within a predetermined weekend or on an agreed working day.
C. Verification of the data transferred
The new TR should determine the following figures and information for the received records and verify the completeness of the transfer:
o The latest state of the outstanding derivatives received, i.e. the “trade state” 12 As per Article 9(2) EMIR “Counterparties shall keep a record of any derivative contract they have concluded and any modification for at least five years following the termination of the contract.” In the case of reporting TR participant that reports on behalf of others, it should use also their records.

o The total number of outstanding derivatives
The new TR should request the TR participant’s confirmation of the accuracy of the information above vis-à-vis the TR participant’s own records 13 as per Guideline 33. In case there is a mismatch, the two TRs should try to reconcile the relevant numbers with the TR participant until an agreement is achieved. D. Final notifications The new TR should inform all the TRs that the reporting participant has switched to it. This information should be used to facilitate the reconciliation process for the relevant derivatives which have been migrated to the new TR. The new TR should inform the relevant NCA(s) and ESMA about the finalisation of the transfer of data of the TR participant and identify the types of derivatives involved. E. Recordkeeping and secure data deletion The old TR should remove the migrated outstanding derivatives from any data aggregations. The old TR should maintain the data transferred for as long as prescribed by the general principles and according to EMIR requirements as before the transfer. The old TR should retain the reporting log for at least 10 years following the termination of the relevant contracts. The old TR will destroy/delete the transferred data when this is permitted by following the relevant general principles for secure deletion/destruction. 13 As per Article 9(2) EMIR “Counterparties shall keep a record of any derivative contract they have concluded and any modification for at least five years following the termination of the contract.” In the case of reporting TR participant that reports on behalf of others, it should use also their records.

5.2 Annex II - Procedure for migration in case of withdrawal of
registration under EMIR
A. Initial notifications
(Voluntary withdrawal) The TR notifies ESMA, TR participants, other involved TRs and NCAs of its request to withdraw its registration at least in advance (as per Guideline 26) of the intended date of cessation of operations (in case withdrawal is requested by the TR). Or (Non-voluntary withdrawal) ESMA notifies the new TR(s) and the NCAs that the new TR(s) should receive data that was originally reported to the old TR (in the event that withdrawal is not requested by the TR) B. Planning and preparation The old TR informs the TR participants of its intention to cease operations. The TR(s) prepare(s) the migration plan, as detailed in Guideline 3, and submit it to ESMA and the new TR(s). ESMA and the other involved TRs raise any potential objections or concerns and after resolving them all parties agree on the migration plan details. The old TR identifies the derivatives subject to transfer and provides ESMA and the other involved TRs (as part of the migration plan or separately) the following information regarding the derivatives subject to transfer per TR:
o The latest state of the outstanding derivatives received, i.e. the “trade state” o The total number of outstanding derivatives o The total number of records relating to lifecycle events corresponding to the outstanding derivatives o The total number of records relating to terminated, compressed, and matured derivatives o The total number of records relating to errored derivatives o The total number of records relating to rejected derivatives reported by the TR participant and that have not passed the data validations o The number of reporting log entries o The number of outbound reports for authorities pertaining to rejections in the XML format and the number outbound reports for authorities pertaining to reconciliation status in the XML format
C. Execution of transfer
Once the number of derivatives and records are confirmed, the old TR should proceed with generating the relevant file(s) consistent with Guideline 5.

The old TR and new TR(s) execute the migration plan. Generated files are transferred from the old TR to the new TR(s) which acknowledge each transfer. The sequence prioritisation of derivatives and records included in Guideline 15 is followed. If possible, outstanding derivatives should be transferred during and within a weekend or on an agreed working day, while corresponding lifecycle events and valuations/collaterals at the earliest opportunity. If not possible, then outstanding derivatives should be segmented, per TR participant, to two or more batches to be transferred during consequent weekends or on agreed working days. The corresponding lifecycle events per batch should be transferred at the earliest opportunity. The remaining derivatives should be transferred as soon as possible. Any issues identified and progress made are reported regularly to ESMA in a timely manner. D. Verification of data transfer The new TR(s) should determine the following figures and information for the received records and verify the completeness of the transfer:
o The latest state of the outstanding derivatives received, i.e. the “trade state” o The total number of outstanding derivatives o The total number of records relating to lifecycle events corresponding to the outstanding derivatives o The total number of records relating to terminated, compressed, and matured derivatives o The total number of records relating to errored derivatives o The total number of records relating to rejected derivatives reported by the TR participant and that have not passed the data validations o The number of reporting log entries o The total number of outbound reports for authorities pertaining to rejections in the XML format and the number of outbound reports for authorities pertaining to reconciliation status in the XML format The new TRs should notify ESMA and the old TR of the result of the verification. In case of verification failure, the root cause is investigated by both parties (old and new TRs) and the transfer process is repeated until the data transfer is successful. E. Final notifications The new TRs should notify the relevant TR participants, all the remaining TRs and the respective NCAs (by email) of the successful conclusion of the transfer. F. Recordkeeping and secure data deletion The old TR should maintain the data transferred for as long as detailed in Guideline 28 and according to EMIR requirements as before the transfer.

The old TR should destroy/delete the transferred data when this is permitted and following the relevant principles for secure deletion/destruction included in Guideline 28. Guidelines on transfer of data between Trade Repositories under SFTR 1 Scope Who?

1. These guidelines apply to trade repositories (TRs) registered or recognised by ESMA,
   to national competent authorities (NCAs), and to reporting counterparties or the entities reporting on their behalf. What?
2. The adopted guidelines apply in relation to:
   The reporting of details of SFTs by counterparties or entities reporting on their behalf under Article 4(1) of SFTR; The procedures for portability under Article 78(9) of EMIR, as cross-referred to in Article 5(2) of SFTR; The transfer of SFT data between TRs at the request of the counterparties, or the entity reporting on their behalf, or in the situation where the registration of a TR has been withdrawn covered by Article 79(3) of EMIR as cross-referred to in Article 5(2) of SFTR; The record-keeping of details of SFTs in accordance with Article 80(3) of EMIR as cross-referred to in 5(2) of SFTR; and
   Article 21(2) of RTS on registration under SFTR.
   When?
3. These guidelines apply as of 3 October 2022.

2 Legislative references, abbreviations and definitions
2.1 Legislative references
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/201214 EMIR Regulation (EU) No 648/2012 of the European Parliament and of the Council of 4 July 2012 on OTC derivatives, central counterparties and trade repositories15 ESMA Regulation Regulation (EU) No 1095/2010 of the European Parliament and of the Council of 24 November 2010 establishing a European Supervisory Authority (European Securities and Markets Authority), amending Decision No 716/2009/EC and repealing Commission Decision 2009/77/EC16 RTS on data aggregation 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 repositories17 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 repositories18 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) 14 OJ L 337, 23.12.2015, p.1 15 OJ L 201, 27.7.2012, p.1 16 OJ L 331, 15.12.2010, p. 84–119 17 OJ L 81, 22.3.2019, p. 30–44 18 OJ L 81, 22.3.2019, p. 1–21

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 contracts19 RTS on registration Commission Delegated Regulation (EU) 2019/359 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 the application for registration and extension of registration as a trade repository20 RTS on data access Commission Delegated Regulation (EU) No 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 repositories21 SFTR Reporting Guidelines Guidelines on Reporting under Articles 4 and 12 SFTR22 Guidelines on positions Guidelines on calculation of SFT positions by trade repositories under SFTR23
2.2 Abbreviations
CP Consultation Paper
CSV Comma-separated values
ECB European Central Bank
EEA European Economic Area
EER Entity Responsible for Reporting
19 OJ L 81, 22.3.2019, p. 85–124 20 OJ L 81, 22.3.2019, p. 45–57 21 OJ L 81, 22.3.2019, p. 22–29 22 ESMA70-151-270 23 ESMA74-362-1986

ESMA European Securities and Markets Authority EU European Union FSB Financial Stability Board ISO International Organization for Standardization ITS Implementing Technical Standards LEI Legal Entity Identifier NCA National Competent Authority NCB National Central Bank Q&A Questions and Answers RSE Report Submitting Entity RTS Regulatory Technical Standards SFT Securities Financing Transaction SFTP SSH File Transfer Protocol SLA Service Level Agreement TR Trade Repository TRACE System for single access to TR data XML Extensible Mark-up Language
2.3 Glossary of concepts and terms
All the definitions, concepts and terms that are used in SFTR, the current RTS on reporting (SFTR) and ITS on reporting (SFTR), as well as in the applicable RTS on data access (SFTR) in the Q&As and in these guidelines are used with the same meaning. For the purpose of these Guidelines the following terms have been defined/described:

• “active client” means a TR participant that has outstanding SFTs at a TR.

• “entity responsible for the report” (ERR, hereinafter), which is one of the
  counterparty fields of the RTS on reporting (SFTR), should be understood as the financial counterparty which is responsible for reporting on behalf of the other counterparty.

• “errored SFT” means a SFT which is reported to a TR as a result of a mistake. It is
  identified with action type “EROR”.

• “life-cycle events” comprise all action types reported for a given SFT.

• “matured SFT” means a SFT which is reported to a TR and at a given point in time
  has reached its contractually-agreed maturity date.

• “new TR” means a TR to which a TR participant has started or intends to start
  reporting reporting SFT contracts under Article 4 of SFTR, although initially that entity was reporting, either directly or through an RSE, to the old TR.

• “non-active client” means a TR participant that no longer has outstanding SFTs at
  a TR.

• “old TR” means a TR to which a TR participant was reporting or to which the SFT
  contracts of a TR participant were reported by an RSE under Article 4 of SFTR, but (i) the TR participant decided to discontinue its contractual arrangement reporting or (ii) the registration of the TR was withdrawn.

• “outstanding SFT” means a SFTs that has not matured or which has not been the
  subject of reports with action types “EROR”, “ETRM”, or “POSC” as referred to in Field 98 of Table 2 of Annex I to ITS on reporting (SFTR).

• “portability” means the possibility to transfer records relating to details of of SFTs
  reported under Article 4 of SFTR from the old TR to the new TR, as those are defined in these guidelines.

• “positions” means the representation of exposures between a pair of counterparties
  as included in the Guidelines on positions (SFTR)

• “reconciliation” means the process through which TRs confirm that the two sides of
  a SFT have been reported with the same information by each ERR.

• “rejections” means SFTs that have been rejected by a TR due to errors in the
  information reported by an ERR or RSE.

• “report submitting entity” (RSE, hereinafter), which is one of the counterparty fields
  of the technical standards on reporting24, should be understood as the entity which has entered in a contractual relationship with a registered or recognised TR and it:
  24 https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32017R0104

o reports only SFTs where it is one of the counterparties, in which case it would coincide with either the reporting counterparty of the contract or the other counterparty, or o reports SFTs where it might be or might not be one of the counterparties.

• “terminated SFTs” means SFTs which have been terminated before their
  contractually-agreed maturity date by the two counterparties and are identified with action type “ETRM”.
• “transfer” or “transfer (of details) of SFTs” means an act or process of moving the
  records of the SFTs, respectively, from the old TR to the new TR.
• “TR participant”25 means an entity which has a contractual arrangement for the
  purpose of reporting SFT contracts under Article 4 of SFTR with at least one registered or recognised TR. The TR participant may be an RSE, an ERR, a reporting counterparty or a CCP. 3 Purpose

4. The objectives of these guidelines are to establish consistent, efficient and effective
   supervisory practices within the ESFS and to ensure the common, uniform and consistent application of by providing clarification for TRs, reporting counterparties and ERR on how to ensure compliance at all times with the following SFTR provisions:
   Article 4(1) of SFTR which provides “Counterparties to SFTs shall report the
   details of any SFTs they have concluded, as well as any modification or termination thereof to a trade repository registered in accordance with Article 5 or recognised in accordance with Article 19. Those details shall be reported no later than the working day following the conclusion, modification or termination of the transaction.”,
   Article 80(3) of EMIR which provides that “A trade repository shall promptly
   record the information received under Article 9 and shall maintain it for at least 10 years following the termination of the relevant contracts. It shall employ timely and efficient record keeping procedures to document changes to recorded information.”, as cross-referred to in Article 5(2) of SFTR;
   Article 79(3) of EMIR which provides that “A trade repository from which
   registration has been withdrawn shall ensure orderly substitution including the transfer of data to other trade repositories and the redirection of reporting flows to other trade repositories.” as cross-referred to in Article 5(2) of SFTR, and 25 Some TRs might further specify the types of TR participants such as reporting, general reporting, non-reporting, etc. participants. These sub-categories are transparent from the perspective of these guidelines.

The procedures for portability under Article 78(9) of EMIR as cross-referred to in Article 5(2) of SFTR.
5. The Guidelines are based on Article 16(1) of ESMA Regulation,which provides that
"The Authority shall, with a view to establishing consistent, efficient and effective supervisory practices within the ESFS, and to ensuring the common, uniform and consistent application of Union law, issue guidelines addressed to all competent authorities or all financial market participants and issue recommendations to one or more competent authorities or to one or more financial market participants.”
6. The purpose the new Guidelines on transfer of data under SFTR is threefold:
Remove portability obstacles from the competitive TR environment, and ensure that TR participants can benefit from the multi-TR environment; Ensure the quality of data available to authorities, including the aggregations carried out by TRs, even when the TR participant changes the TR to which it reports and irrespective of the reason for such a change; Ensure that there is a consistent, standardised and harmonised way to transfer records from one TR to another TR and support the continuity of reporting and reconciliation in all cases including the withdrawal of registration of a TR.
7. The need to transfer data to another TR may arise for different reasons. The Guidelines
therefore address separately the situations where (i) the transfer is due to withdrawal of registration of the TR from the cases in which (ii) the transfer is done on a voluntary basis and under normal market conditions. Guidelines 1 to 15 and Guidelines 33 and 34 apply for both situations; Guidelines 16 to 22 apply only to voluntary porting; and Guidelines 23 to 32 apply only to withdrawal of registration of a TR. The incentives and motivations for the relevant parties in each of the two cases would be different and therefore there is a need for a specific approach in each particular situation.
8. The Guidelines establish high-level principles that would need to be followed by the TR
participants, e.g. RSE, ERRs, counterparties and CCPs, on the one hand, and the TRs on the other. Those principles are complemented by specific procedures, set out to ensure the timely and robust transfer of details of SFTs. These Guidelines however do not cover situations that do not require transfer of data, such as reporting counterparties that have decided to report to two or more TRs at the same time. 4 Compliance and reporting obligations
4.1 Status of the guidelines
9. In accordance with Article 16(3) of the ESMA Regulation, national competent
authorities, TRs, reporting counterparties and entities responsible for the report must make every effort to comply with these guidelines.

10. Competent authorities to which these guidelines apply should comply by incorporating
    them into their national legal and/or supervisory frameworks as appropriate, including where particular guidelines are directed primarily at financial market participants. In this case, competent authorities should ensure through their supervision that financial market participants comply with the guidelines.
11. ESMA will assess the application of these guidelines by TRs through its ongoing direct
    supervision.
    4.2 Reporting requirements
12. Within two months of the date of publication of the guidelines on ESMA’s website in all
    EU official languages, competent authorities to which these guidelines apply must notify ESMA whether they (i) comply, (ii) do not comply, but intend to comply, or (iii) do not comply and do not intend to comply with the guidelines.
13. In case of non-compliance, competent authorities must also notify ESMA within two
    months of the date of publication of the guidelines on ESMA’s website in all EU official languages of their reasons for not complying with the guidelines
14. A template for notifications is available on ESMA’s website. Once the template has
    been filled in, it shall be transmitted to ESMA.
15. TRs are not required to report whether they comply with these guidelines.
16. Reporting counterparties and entities reporting on their behalf are not required to report
    whether they comply with these guidelines.
    5 Guidelines on transfer of data between Trade Repositories under SFTR Guideline 1. Only the old TR and the new TR should carry out the transfer of SFT data. The new TR should not accept duplicate reports by TR participants relating to SFTs subject to transfer. The old TR should not accept reports with action types “ETRM” and “EROR” made by TR participants relating to SFTs subject to transfer. Guideline 2. The transfer of data should be carried out by the TRs in accordance with a mutually agreed migration plan. The migration plan should contain the detailed planning (timeline) and a description of the required controls in place to ensure the timely, complete and accurate transfer of data. Guideline 3. All TRs should use a standardised migration plan template mutually agreed across all TRs and that is compliant with the content included in Guideline 4. Guideline 4. The migration plan should contain the following information:

(i) the scope of the data transfer (e.g. the TR participant(s), SFTs involved, etc.); (ii) detailed roles and responsibilities of the involved entities; (iii) timeline and relevant milestones for the transfer; (iv) the controls required to ensure the confidentiality of the transferred data (e.g. type of encryption used); (v) the controls required to ensure the integrity and accuracy of the transferred data (e.g. cryptographic checksums and hashing algorithms); (vi) the controls required to ensure continuity of operations and the inter-TR reconciliation status of the SFTs under transfer; (vii) cut-off time and data availability; and (viii) Any other information that will facilitate and secure the smooth transfer of data. Guideline 5. TRs should transfer data to each other by using the XML format and template defined in accordance with Article 4 of the RTS on data access. Notwithstanding this, in the case of (i) SFTs that are not outstanding at the time of transfer, or (iii) rejected SFTs, the TRs could use comma separated value (csv) files. In the files that will be transferred, the old TR should include all the relevant details of the SFTs subject to transfer. Guideline 6. The TRs should use secure machine-to-machine protocols, including the SSH File Transfer Protocol, to transfer data between each other. Guideline 7. The TRs should use advanced encryption protocols and should exchange the relevant public encryption keys with their peers. To ensure the seamless functioning of data encryption, the TRs should test in advance that they are able to encrypt and decrypt each one’s data files. Guideline 8. The old TR should calculate the number of SFTs and the number of corresponding lifecycle events that will be transferred to the new TR. The old TR should request the TR participant’s sign-off of the numbers related to outstanding SFTs and should resolve all discrepancies at the earliest convenience and no later than in five working days. Guideline 9. For every file generated and transferred, the old TR should generate and include in the data transfer a cryptographic checksum according to a mutually agreed hashing algorithm. Guideline 10. The transfer of data requested by a TR participant should be carried out, as a general principle, on a non-working day. The old and the new TR can however agree on carrying it out on a working day depending on the expected volume of the transfer. Guideline 11. Prior to the data transfer on non-working day, TRs should ensure that TR participants modify the outstanding SFTs that are subject to data transfer to comply with the most up to date reporting requirement at the latest by 23:59:59 on the Friday ahead of the weekend on which the porting takes place and

(i) in the case of full porting, from the start of the data transfer, the old TR should not accept reports on lifecycle events and position data relating to the SFTs subject to transfer; (ii) and in addition, in the case of partial porting, the TR participant should ensure accurate reporting of lifecycle events relating to the SFTs to the relevant TRs. For transfers on working days, the old TR and the new TR are to agree upon a time, prior to the data transfer, by which the modifications of the outstanding SFTs that are subject to data transfer should be completed by the TR participant. For transfers on working days, (i) and (ii) should be followed by the old TR and the TR participant. Guideline 12. Until the transfer of all the relevant files subject to the transfer is completed, the new TR should not accept lifecycle events and position data relating to the SFTs subject to transfer. The data on outstanding SFTs should be made available to the relevant authorities by the old TR. Guideline 13. Once the data transfer is completed, the new TR should:
(i) make the data available to the authorities; (ii) include the data subject to transfer in the relevant public and authorities–only aggregations; (iii) include the data in the inter-TR reconciliation process, as applicable. Guideline 14. Following the transfer of records of a TR participant to another TR, the old TR should not charge any specific fees for the recordkeeping of non-outstanding SFTs. Guideline 15. In case all the data in the scope of the migration plan cannot be transferred in a single instance, the TRs should transfer the data in accordance with the following order:
(i) the latest state of the outstanding SFTs received, i.e. the “trade state”; (ii) in the case of withdrawal of registration, the reports related to lifecycle events applicable to the outstanding SFTs; (iii) in the case of withdrawal of registration, all terminated and matured SFTs that are still subject to the requirement under Article 80(3) of EMIR, as cross-referred in Article 5(2) of SFTR, together with the relevant lifecycle events; (iv) in the case of withdrawal of registration, all errored SFTs that are still subject to the requirement under Article 80(3) of EMIR, as cross-referred in Article 5(2) of SFTR together with the relevant lifecycle events; (v) in the case of withdrawal of registration, all rejected SFTs reported by the TR participant and that have not passed the data validations;

(vi) in the case of withdrawal of registration, the reporting log in a machine readable format of the old TR which records the reason or reasons for a modification, the date, timestamp and a clear description of the changes (including the old and new contents of the relevant data) pertaining to the SFTs that are transferred; and (vii) in the case of withdrawal of registration, all data on rejections, meaning the outbound reports for authorities pertaining to rejections in the XML format, and all data on reconciliation, meaning the outbound reports for authorities pertaining to reconciliation status in the XML format. Guideline 16. In the case of transfer of data requested by a TR participant, the old TR should determine whether all or some of the SFTs pertaining to counterparties that are non-reporting TR participants and which were reported by the TR participant should be transferred to the new TR. Guideline 17. Where, in the case of transfer of data requested by a TR participant, a non￾reporting TR participant decides to remain with the old TR although its reporting TR participant has requested a transfer to another TR, the old TR should strip the SFTs submitted on behalf of the non-reporting TR participant from the SFTs that are transferred. Guideline 18. In the case of transfer of data requested by a TR participant, and when the registration of the old TR is not withdrawn nor in the process to be withdrawn, only the latest state of the outstanding SFTs, i.e. the “trade state”, is to be transferred. Guideline 19. In the case of transfer of data requested by a TR participant, the process described in the procedure contained in Annex I for transfer of data at the request of a TR participant under SFTR should be followed by the old and the new TR. The TRs should agree the migration plan for the data transfer of a given TR participant as soon as possible and no later than in ten working days after the request is received. Guideline 20. In the case of transfer of data requested by a TR participant, as soon as the outstanding SFTs of a TR participant are transferred to the new TR, the new TR should confirm this to the TR participant, the old TR, the rest of the TRs and the relevant authorities accessing SFTs reported by the TR participant. Guideline 21. In the case of transfer of data requested by a TR participant, the old TR should isolate and keep safely the transferred data, by applying the same recordkeeping policies, procedures and safeguards to the transferred data as to the rest of SFT data reported to that TR, for at least three months and should ensure the retrieval of data in no more than seven calendar days. Guideline 22. In the case of transfer requested by a TR participant, any fees charged by the old or the new TR should be cost-related, non-discriminatory and included in the fee schedule of the relevant TRs, which is made public.

Guideline 23. In the case of withdrawal of registration of a TR, the transfer of data should comprise all the details of SFTs reported to the TR, including the rejected ones, together with the relevant reporting log, and all data on rejections, meaning the outbound reports for authorities pertaining to rejections in the XML format, and all data on reconciliation, meaning the outbound reports for authorities pertaining to reconciliation status in the XML format. The order of data transfer outlined in Guideline 15 should be followed. Guideline 24. In the case of withdrawal of registration of a TR, the migration plan(s) for data transfer should be included as part of the wind-down plan presented by the TR. Guideline 25. Where the data transfer is related to the withdrawal of registration of a TR, the procedure contained in Annex II for migration in case of withdrawal of registration under SFTR should be followed by the old TR and the new TR. The order of data transfer indicated in Guideline 15 should be followed. The old TR, i.e. the one whose registration is to be withdrawn, should provide to ESMA enough evidence that all the transfers have been successful. Guideline 26. In the case of withdrawal of registration at the request of a TR, it should notify ESMA in advance of the intended date of cessation of operations and should then immediately notify the TR participants, the other TRs, and the relevant NCAs by electronic means. For TRs with more than 500 TR participants the advance notice should be at least nine months, while for TRs with 500 or with less than 500 TR participants, the advance notice should be at least six months. Guideline 27. In the case of withdrawal of registration, once the transfer(s) has been completed, the new TR should confirm it to the TR participants, all the remaining TRs and the respective NCAs. Guideline 28. In the case of withdrawal of registration, the old TR should isolate and keep safely the transferred data, by applying the same recordkeeping policies, procedures and safeguards to the transferred data as to the rest of the data, until the date of actual cessation of operations and should ensure the timely retrieval of data in no more than seven calendar days. At the date of actual cessation of operations, the old TR should perform a secure destruction/deletion, in accordance with leading practices and most reliable techniques available, ensuring that data could not be undeleted or recovered after that date. Guideline 29. In the case of withdrawal of registration, none of the TRs should charge fees for the transfer of data. Guideline 30. In the case of withdrawal of registration, the new TR may charge fees to the active TR participants for their non-outstanding SFT data. Guideline 31. In the case of withdrawal of registration, the new TR can store non-outstanding SFT data of varying data quality and/or in different formats in separate databases/tables. The new TR should respond to the queries of authorities on
demand.

Guideline 32. In the case of withdrawal of registration, the TR whose registration will be withdrawn, should provide the new TR with the necessary technical information on the data that is to be transferred to facilitate the data transfer to and the subsequent storage by the new TR. The old TR should provide the new TR with the before-mentioned information in a timely manner to allow the new TR to prepare as necessary. The technical documentation should at least cover the following aspects:
(i) mapping of the fields to SFTR fields; and
(ii) technical explanations for each field.
Guideline 33. Before and following the transfer of records of a TR participant, the TR participant should verify and confirm with the new and the old TR the correctness of the following aggregate information regarding the SFTs subject to transfer consistent with the timing detailed in Guideline 11:
(i) the total number of outstanding SFTs, where each SFT is identified by the unique combination of the fields “Reporting counterparty”, “Other counterparty”, and “Unique Transaction Identifier”, together with the corresponding collateral on net basis, margin reports and re-use reports; (ii) the total number of reports relating to lifecycle events of these SFTs for transaction, margin, and re-use reports (in case those are transferred), where

• each loan and collateral report is identified by the unique combination of the SFTR
  fields “Reporting counterparty”, “Other counterparty”, and “Unique Transaction Identifier” or “Master agreement type”;
• each margin report is identified by the unique combination of the SFTR fields “Reporting
  counterparty”, “Other counterparty”, and “Portfolio code”;
• each re-use report is identified by the unique combination of the SFTR fields “Reporting
  counterparty” and “Entity responsible for the report; (iii) the total number of records relating to terminated and matured SFTs for loan and collateral, margin, and re-use reports in the last five years, for which there is record keeping obligation in accordance with Article 4(4) of SFTR (in case those are transferred); (iv) the total number of records relating to errored SFTs for loan and collateral, margin, and re-use reports in the last five years, for which there is record keeping obligation in accordance with Article 4(4) of SFTR (in case those are transferred). Guideline 34. Further to Guideline 58 of the Guidelines on reporting under Article 4 and 12 of SFTR, where an FC and a SME NFC report to two different TRs outstanding SFTs subject to transfer:
  (i) if the SME NFC decides not to report itself, the outstanding SFTs of the SME NFC should be transferred to the TR of the FC, unless the FC decides to become client of the TR of the SME NFC and report the SFTs concluded with the SME NFC to that TR.

(ii) each time an NFC changes its status from non-SME NFC to SME NFC and decides not to report itself its SFTs, it should transfer its outstanding SFTs concluded with the FC to the TR of that FC as of the date of its changed status unless the FC decides to become client of the TR of the SME NFC and to report the SFTs concluded with the SME NFC to that TR. Similarly, each time an NFC changes its status from SME NFC to non-SME NFC, the outstanding SFTs concluded with the FC should be transferred back to the TR of the NFC, unless the NFC decides to become client of the TR of the FC and to report the SFTs concluded with the FC to that TR. (iii) for the performance of data transfer, neither the NFC nor the FC (or any report submitting entity reporting on their behalf) are expected to onboard to the TRs of the other counterparty.

5.1 Annex I - Procedure for transfer of data at the request of a TR
participant under SFTR
A. Planning and preparation
After signing the relevant contractual agreement with the TR participant, the new TR communicates to and agrees with the old TR the migration plan elaborated consistent with Guideline 3. The new TR notifies by email the relevant authorities about the transfer. The old TR determines and agrees with the TR participant the following aggregate information regarding the SFTs of the TR participant subject to transfer:
o The latest state of the outstanding SFTs received, i.e. the “trade state” o The total number of outstanding SFTs The old TR should request the TR participant’s confirmation of the accuracy of the information above vis-à-vis the TR participant’s own records26 as per Guideline 8. In case of a mismatch, the old TR should reconcile the relevant numbers with the TR participant and agree on the final list of SFT reports that will be migrated. The old TR should solve all discrepancies at the earliest convenience and in no later than five working days. B. Execution of transfer Once the number of SFTs and records are confirmed, the old TR should proceed with generating the relevant file(s) consistent with Guideline 5 and the relevant generic principles. The old and new TRs execute the migration plan. The old TR should transfer the files generated to the new TR which acknowledges the file transfer. In this respect the outstanding SFTs should be transferred within a predetermined weekend or on an agreed working day.
C. Verification of the data transferred
The new TR should determine the following figures and information for the received records and verify the completeness of the transfer:
o The latest state of the outstanding SFTs received, i.e. the “trade state” 26 As per Article 4(4) SFTR “Counterparties shall keep a record of any SFT that they have concluded, modified or terminated for at least five years following the termination of the transaction.” In the case of reporting TR participant that reports on behalf of others, it should use also their records.

o The total number of outstanding SFTs
The new TR should request the TR participant’s confirmation of the accuracy of the information above vis-à-vis the TR participant’s own records 27 as per Guideline 33. In case there is a mismatch, the two TRs should try to reconcile the relevant numbers with the TR participant until an agreement is achieved. D. Final notifications The new TR should inform all the TRs that the reporting participant has switched to it. This information should be used to facilitate the reconciliation process for the relevant SFTs which have been migrated to the new TR. The new TR should inform the relevant NCA(s) and ESMA about the finalisation of the transfer of data of the TR participant and identify the types of SFTs involved. E. Recordkeeping and secure data deletion The old TR should remove the migrated outstanding SFTs from any data aggregations. The old TR should maintain the data transferred for as long as prescribed by the general principles and according to SFTR requirements as before the transfer. The old TR should retain the reporting log for at least 10 years following the termination of the relevant contracts. The old TR will destroy/delete the transferred data when this is permitted by following the relevant general principles for secure deletion/destruction. 27 As per Article 4(4) SFTR “Counterparties shall keep a record of any SFT that they have concluded, modified or terminated for at least five years following the termination of the transaction.” In the case of reporting TR participant that reports on behalf of others, it should use also their records.

5.2 Annex II - Procedure for migration in case of withdrawal of
registration under SFTR
A. Initial notifications
(Voluntary withdrawal) The TR notifies ESMA, TR participants, other involved TRs and NCAs of its request to withdraw its registration at least in advance (as per Guideline 26) of the intended date of cessation of operations (in case withdrawal is requested by the TR). Or (Non-voluntary withdrawal) ESMA notifies the new TR(s) and the NCAs that the new TR(s) should receive data that was originally reported to the old TR (in the event that withdrawal is not requested by the TR) B. Planning and preparation The old TR informs the TR participants of its intention to cease operations. The TR(s) prepare(s) the migration plan, as detailed in Guideline 3, and submit it to ESMA and the new TR(s). ESMA and the other involved TRs raise any potential objections or concerns and after resolving them all parties agree on the migration plan details. The old TR identifies the SFTs subject to transfer and provides ESMA and the other involved TRs (as part of the migration plan or separately) the following information regarding the SFTs subject to transfer per TR:
o The latest state of the outstanding SFTs received, i.e. the “trade state” o The total number of outstanding SFTs o The total number of records relating to lifecycle events corresponding to these SFTs for transaction, margin, and re-use reports o The total number of records relating to terminated and matured SFTs o The total number of records relating to errored SFTs o The total number of records relating to rejected SFTs reported by the TR participant and that have not passed the data validations o The number of reporting log entries o The total number of outbound reports for authorities pertaining to rejections in the XML format and the number of outbound reports for authorities pertaining to reconciliation status in the XML format
C. Execution of transfer
Once the number of SFTs and records are confirmed, the old TR should proceed with generating the relevant file(s) consistent with Guideline 5. The old TR and new TR(s) execute the migration plan. Generated files are transferred from the old TR to the new TR(s) which acknowledge each transfer.

The sequence prioritisation of SFTs and records included in Guideline 15 is followed. If possible, outstanding SFTs should be transferred during and within a weekend or on an agreed working day, while corresponding lifecycle events to these SFTs for transaction, margin, and re-use reports at the earliest opportunity. If not possible, then outstanding SFTs should be segmented, per TR participant, to two or more batches to be transferred during consequent weekends or on agreed working days. The corresponding lifecycle events per batch should be transferred at the earliest opportunity. The remaining SFTs should be transferred as soon as possible. Any issues identified and progress made are reported regularly to ESMA in a timely manner. D. Verification of data transfer The new TR(s) should determine the following figures and information for the received records and verify the completeness of the transfer:
o The latest state of the outstanding SFTs received, i.e. the “trade state” o The total number of outstanding SFTs o The total number of records relating to lifecycle events to these SFTs for transaction, margin, and re-use reports o The total number of records relating to terminated and matured SFTs o The total number of records relating to errored SFTs o The total number of records relating to rejected SFTs reported by the TR participant and that have not passed the data validations o The number of reporting log entries o The total number of outbound reports for authorities pertaining to rejections in the XML format and the number of outbound reports for authorities pertaining to reconciliation status in the XML format The new TRs should notify ESMA and the old TR of the result of the verification. In case of verification failure, the root cause is investigated by both parties (old and new TRs) and the transfer process is repeated until the data transfer is successful. E. Final notifications The new TRs should notify the relevant TR participants, all the remaining TRs and the respective NCAs (by email) of the successful conclusion of the transfer. F. Recordkeeping and secure data deletion The old TR should maintain the data transferred for as long as detailed in Guideline 28 and according to SFTR requirements as before the transfer. The old TR should destroy/delete the transferred data when this is permitted and following the relevant principles for secure deletion/destruction included in Guideline 28.