Final Report on Guidelines on position calculation under EMIR

18 December 2023
ESMA12-2121844265-3173
Final Report
Guidelines on position calculation under EMIR

ESMA - 201-203 rue de Bercy - CS 80910 - 75589 Paris Cedex 12 - France - Tel. +33 (0) 1 58 36 43 21 - www.esma.europa.eu 2

Table of Contents
1 Executive Summary ....................................................................................................4
2 Legislative references, abbreviations, and definitions..................................................5
3 Final Report.................................................................................................................7
3.1 Scope and purpose ..............................................................................................7
3.2 Legal provisions ...................................................................................................7
3.3 Summary of feedback received to public consultation ..........................................8
4 Annexes ....................................................................................................................13
4.1 Advice of the Securities and Markets Stakeholders Group .................................13
4.2 Feedback on the consultation paper...................................................................14
4.3 Guidelines ..........................................................................................................29

1 Executive Summary
Reasons for publication
This Final Report contains the assessment of the feedback received from stakeholders and the proposed updates to the ESMA Guidelines on position calculation under EMIR Refit. The Guidelines provide clarification regarding the time of calculations, the scope of the data to be used in calculations and the calculation methodologies under the new EMIR Refit standards. The Final Report also clarifies the way forward for TRs to adopt for managing the 6-month EMIR Refit transition period. Contents
Section 2 contains the list of legislative references, abbreviations, and definitions. The scope
and purpose of these Guidelines are explained in section 3.1, together with the legal provisions in section 3.2. Section 3.3 provides a high-level summary of the most relevant feedback received to the public consultation on key topics and describes the way forward proposed by ESMA. It covers important aspects such as the implementation timeline and go-live date, methodology to be used for determining the ‘buyer’ and ‘seller’ of a transaction, and an overview of newly added fields to be included in the position reports. Annex 4.1 refers to the request for advice of the Securities and Markets Stakeholders Group, while
Annex 4.2 contains the extended feedback to the consultation paper. Finally, section 4.3
contains the Guidelines that will apply from 28 October 2024.
Next Steps
ESMA will publish the Final Report and the Guidelines on the ESMA’s website. 6 months prior to the date of application, the original guidelines (ESMA70-151-1350) 1 will be repealed. 1 https://www.esma.europa.eu/document/guidelines-position-calculation-trade-repositories-under-emir

2 Legislative references, abbreviations, and definitions Unless otherwise specified, terms used in EMIR have the same meaning in these Guidelines. In addition, the following concepts and terms apply:
Legislative references and abbreviations
EMIR European Market Infrastructures Regulation – Regulation (EU) No 648/2012 of the European Parliament and of the Council of 4 July 2012 on OTC derivatives, central counterparties and trade repositories– also referred to as ‘the Regulation’ EMIR Refit Refers to the set of Commission Delegated Regulations (EU) 2022/1855, 2022/1856, 2022/1857, 2022/1858, 2022/1859, 2022/1860 ISO International Organization for Standardization ITS on reporting Commission Implementing Regulation (EU) No 2022/1860 of 10 June 2022 laying down implementing technical standards for the application of Regulation (EU) No 648/2012 of the European Parliament and of the Council on OTC derivatives, central counterparties and trade repositories, with regard to the standards, formats, frequency and methods and arrangements for reporting and repealing Implementing Regulation (EU) No 1247/2012. OTC Over-the-counter Q&A Questions and Answers RTS on reporting Commission Delegated Regulation (EU) No 2022/1855 of 10 June 2022 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 the type of reports to be used. RTS on data access Commission Delegated Regulation (EU) No 2022/1856 of 10 June 2022 amending the regulatory technical standards laid down in Delegated Regulation (EU) No 151/2013 by further

specifying the procedure for accessing details of derivatives as well as the technical and operational arrangements for their access. TR A Trade Repository within the meaning of Article 2(2) of EMIR that has been registered or recognised by ESMA in accordance with Articles 55 and 77 of EMIR respectively XML Extensible Mark-up Language Glossary of concepts and terms ‘Positions’ means the representation of exposures between a pair of counterparties that comprise positions sets, collateral sets, currency positions sets and currency position collateral sets. ‘Position Set’ means (a set of) outstanding derivatives that are considered to be economically related according to their dimensions for a pair of counterparties. Position sets will contain derivatives that are mutually fungible and also those which are not mutually fungible yet have similar economic characteristics. ‘Collateral Set’ means a set of collateral that has equal values for the relevant dimensions. ‘Currency Position Set’ is a set of derivatives that have the same currency reported in the relevant dimensions. ‘Currency Collateral Position Set’ is a set of collateral that has the same currency reported in the relevant dimensions. ‘Outstanding Derivative’ is a derivative referred to in Article 2(2a-b) of the ITS on reporting. ‘Variables’ are those values either taken directly from the EMIR reporting fields or derived from those fields that will be used by TRs to calculate positions. ‘Authority’ means one of the entities referred to in Article 81(3) of EMIR. ‘Metrics’ are variables used to quantify the different calculations. The fields used to define metrics (and dimensions) follow the nomenclature as per the ITS on reporting under EMIR. For instance, T1F17 means field 17 of table 1. ‘Dimensions’ are variables related to derivatives that are used to group derivatives together into positions. ‘Reference Date’ means the date the calculation refers to.

3 Final Report
3.1 Scope and purpose
Who?
The Guidelines will apply to TRs that are registered or recognised by ESMA in accordance with Articles 55 and 77 of EMIR respectively. What? The Guidelines provide information to ensure harmonisation and consistency in relation to:
a) the calculations carried out by TRs pursuant to Article 80(4) of Regulation (EU) No 648/2012 (EMIR); b) the level of access to positions provided by TRs to the entities included in Article 81(3) of EMIR with access to positions in line with Article 2 of Regulation (EU) No 151/20132 ; c) the operational aspects for access to position data by the entities included in Article 81(3) of EMIR, and d) changes introduced by EMIR Refit technical standards, in particular the Commission Delegated Regulation (EU) No 2022/1855 (RTS on reporting), Commission Implementing Regulation (EU) No 2022/1860 (ITS on reporting) and Guidelines3 for reporting under EMIR published by ESMA on 14 December 2022. When? The existing Guidelines that were applicable as of 3 December 2018 will be repealed on 29 April 2024 and replaced with the new Guidelines that will apply from 28 October 2024, providing for a 6-month transition period.
3.2 Legal provisions
Article 81(1) of EMIR provides that a TR shall regularly, and in an easily accessible way,
publish aggregate positions by class of derivatives on the contracts reported to it. 2 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 on the minimum details of the data to be reported to trade repositories and operational standards for aggregating, comparing and accessing the data, OJ L52, 23.2.2013, p.33-36 3 https://www.esma.europa.eu/sites/default/files/library/esma74-362-2281_final_report_guidelines_emir_refit.pdf

Furthermore, in accordance with Article 16(1) of Regulation (EU) No 1095/20104 , the objectives of these Guidelines are to establish consistent, efficient, and effective supervisory practices within the European System of Financial Supervision and to ensure the common, uniform and consistent application of the following EMIR provisions:
a) Article 80(4) of EMIR which provides that TRs shall calculate positions by class of derivative and by reporting entity based on the details of the derivative contracts reported in accordance with Article 9 of EMIR; and, b) Article 81(3) of EMIR which provides that a TR shall make the necessary information available to authorities to enable them to fulfil their respective responsibilities and mandates.
3.3 Summary of feedback received to public consultation
The Guidelines on position calculation published on 3 December 20185 (the ‘existing Guidelines’) have so far ensured harmonisation and consistency across position calculations and aggregations of derivatives by TRs. This has allowed authorities to obtain data aggregations of high standards and use the information to assess systemic risks to financial stability as well as act quickly in the case of a crisis. In preparation for EMIR Refit go-live on 29 April 2024, ESMA launched a consultation paper in May 2023 with the aim to replace the existing Guidelines on position calculation to ensure full alignment with the requirements set out by EMIR Refit technical standards and the Guidelines on reporting under EMIR Refit6 . A key topic covered in the consultation paper was determining whether TRs could implement a cost-efficient technical solution for generating the position report as of EMIR Refit go-live date and throughout the initial 6-month transition period while ensuring a high level of data quality. Several challenges with calculating positions using both updated and non-updated EMIR Refit data were recognised due to the different data standards that will coexist during the transition period. Three alternatives were presented by ESMA: A) calculate positions using both pre- and post-Refit data as of EMIR Refit go-live, B) calculate positions as of EMIR Refit go-live using only data that have been updated to the latest standards or C) calculate positions 4 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/EC OJ L 331, 15.12.2010, p. 84–119. 5 https://www.esma.europa.eu/sites/default/files/library/esma70-151- 1350_guidelines_on_position_calculation_by_trs_under_emir.pdf 6 https://www.esma.europa.eu/sites/default/files/library/esma74-362-2281_final_report_guidelines_emir_refit.pdf

only after the EMIR Refit transition period is over. According to the below table, each of these alternatives has certain advantages and disadvantages. Alternative Description Advantages Disadvantages A Calculate positions using both pre- and post-Refit data as of EMIR Refit go￾live

• Including updated
  and non-updated data would allow authorities to obtain a full picture of positions in the market.
• Continuity would
  be fully ensured.
• Lower reliability
  and more data quality issues could arise.
• TRs would need to
  implement temporary solutions to deal with upgraded and non-upgraded data, which adds additional costs.
• Shorter
  implementation time adds pressure on TR’s resources.
  B Calculate positions as of EMIR Refit go-live using only data that have been updated to the latest standards
• More reliable and
  consistent results
• Better data quality
• TRs avoid
  implementing temporary solutions to deal with different data standards
• Only a partial
  picture of the positions in the market would be available.
  However, this would improve throughout the duration of the transition period as more data gets upgraded to the latest standards.
• Continuity is only
  partially ensured.
• Shorter
  implementation

time adds pressure on TR’s resources.
C Calculate positions only after the EMIR
Refit transition period is over.

• Full picture of
  positions in the market from the start.
• High data quality
  and reliable results.
• Longer
  implementation time would allow
  TRs to focus on to the EMIR Refit implementation.
• Authorities would
  not receive any position reports during the 6-month transition period (i.e. continuity is not ensured). Feedback from stakeholders showed that there is a significant inclination for delaying the go-live date of the new Guidelines until the EMIR Refit transition period has been concluded (alternative C). ESMA also assessed the current usage and dependencies of the position report by authorities to understand the impact it would have if the report would not be delivered by the TRs during the 6-month transition period. The outcome from the discussions concluded that some authorities are using it more than others, but the overall dependencies are low to medium and the disruption of critical analytical processes using this dataset is manageable if it would not be delivered for 6 months. More importantly, in case needed, authorities could rely during that period on the more granular transaction data provided by the TRs. Given that most authorities still have low to medium dependencies on the position reports, the disruption would be minimal; thus, ESMA's proposal is to delay the go-live date of the new Guidelines until the EMIR Refit transition period has been concluded (alternative C). Furthermore, the concerns mentioned by respondents about field and format relationship between old and new standards should have no bearing because all data should have been updated to the most recent standards by the time ESMA proposes applying the new Guidelines after the EMIR Refit transition period expires.

Another key topic covered in the consultation paper was to define a consistent methodology to identify whether a reporting counterparty is the ‘Buyer’ or ‘Seller’ of a derivative contract for ensuring consistency in the aggregation. ESMA proposed that the ‘Buyer’ should be determined when either ‘Direction’ = ‘BYER’ is populated or when ‘TAKE’ and ‘MAKE’ are populated in ‘Direction of leg 1’ and ‘Direction of leg 2’, respectively. The ‘Seller’ should be determined when either ‘Direction’ = ‘SLLR’ is populated or when ‘MAKE’ and ‘TAKE’ are populated in ‘Direction of leg 1’ and ‘Direction of leg 2’, respectively. ESMA recommended this methodology, which is also in accordance with the Guidelines on reporting under EMIR Refit section 4.12. Most respondents agreed with the proposal which has been reflected in the new Guidelines. A suggestion from one respondent to have distinct metrics for Buyer/Seller and Make/Take was rejected since it would add complexity because two sets of each metric would need to be calculated. Additionally, the extra fields that have been suggested for inclusion in the aggregations (such as Delta, Other payment amount, Notional amount in effect) have increased the number of metrics that need to be calculated. Furthermore, ESMA proposed to decommission old metrics that referred to negative notional values. Under EMIR Refit, reporting of negative notionals will not be accepted so the new metrics proposed by ESMA and agreed by most respondents will consider the new reporting logic of notional values. ESMA also proposed a set of new EMIR Refit fields that could potentially be included in the calculation of positions if considered useful for financial stability monitoring purposes, suitable for aggregation or for providing additional granularity in terms of dimensions, and meaningful when represented in an aggregated form. Authorities using the report supported inclusion of these fields, while a few respondents replied that the additional complexity that will be introduced is not merited and pointed out that the report would grow significantly in terms of size.

ESMA recognises that the addition of new EMIR Refit fields will undoubtedly increase the complexity and size of the position report compared to its current state. The goal, however, has been to increase the level of information included in the position report to facilitate for authorities to perform their duties. With new technologies and upgraded IT infrastructure to support data-driven supervision and monitoring activities, processing larger amounts of data and use it for a variety of purposes should be feasible; thus, ESMA believes that the benefits of expanding the position report outweigh the drawbacks. Finally, several smaller modifications, typo corrections, and other minor alterations were also addressed, and can be found in section 4.2 which describes the full details of the feedback to the consultation paper. The Guidelines can be found in section 4.3.

4 Annexes
4.1 Advice of the Securities and Markets Stakeholders Group
In accordance with Article 10 of Regulation (EU) No 1095/2010 ESMA requested the opinion of the ESMA Securities and Markets Stakeholder Group. The SMSG decided not to provide an opinion.

4.2 Feedback on the consultation paper
ESMA performed a field relationship analysis between the current and new reporting standards to assess and identify possible backward-compatibility issues that could prevent TRs from calculating positions efficiently and accurately during the transition period when pre- and post-EMIR Refit data would coexist. Q1: Based on the field relationship analysis, please list any critical issues that might prevent TRs from calculating positions using pre- and post-EMIR Refit data during the transition period? One respondent suggested to implement the Position Aggregation reporting changes after the transition period, because the data will be updated to the new standards by then. Two respondents asked how should records where pre-REFIT T2F7 ‘Underlying Identification Type’ is populated with code ‘A’ (AII - Alternative Investment ID) be aggregated, given that post-REFIT T2F13 ‘Underlying Identification Type’ does not allow to be populated with code ‘A’. According to the understanding of one of the respondents, this would imply the creation of another aggregation, valid only during the transition period. One respondent remarked that the relationship between pre-REFIT T2F8 ‘Underlying identification’ and post-REFIT T2F14 ‘Underlying identification’ is in fact not one-to-one, contrary to what is stated by ESMA in the Consultation Paper, and suggested it should be one to many, not only with field T2F14 ‘Underlying identification’, but potentially also with field T2F18 ‘Identifier of the basket’s constituents’ and T2F16 ‘Name of the underlying index’. The respondent also asked for guidance in relation to the aggregation of indexes, as they can be identified with an ISIN (optionally) or with the name of the index and they are not necessarily having a one-to-one relationship between them. As a potential solution, the respondent suggested to aggregate by the ISIN, if populated, and by the name of the index, if the ISIN is not populated. An alternative proposal to group all indexes without ISIN in a single bucket named ‘OTHR’ was also provided by the respondent. One respondent raised a concern for the calculation of the positions regarding the cases where pre-REFIT T1F4 ‘ID of the other Counterparty’ is populated with a client code that does not match the required format for post-REFIT ‘Counterparty 2’ for natural persons. One respondent remarked that the relationship between pre-REFIT T1F21 ‘Collateralisation’ and post-REFIT T3F11 ‘Collateralisation category’ is in fact not one-to￾one, contrary to what is stated by ESMA in the Consultation Paper. As a result, the respondent highlighted that the matching of these two fields may be difficult. One respondent remarked that the matching of pre-REFIT T2F30 ‘Master Agreement Type’ and post-REFIT T2F34 ‘Master Agreement Type’ is challenging, as the former contains

values in the format of free text up to 50 characters, while the latter should be populated according to the specified 4-character codes. One respondent highlighted the complexity regarding the mapping between different multi￾commodity categories for the pre-REFIT T2F65 ‘Commodity base’ and post-REFIT T2F116 ‘Base product’. ESMA’s response to Q1: Given that ESMA is proposing to implement the new Guidelines when the EMIR Refit transition period expires, the issues raised by respondents regarding field relationship analysis should no longer be relevant because all data should have been upgraded to the most recent standards. ESMA also performed a format relationship analysis between the current and new reporting standards to assess and identify possible backward-compatibility issues that could prevent TRs from calculating positions efficiently and accurately during the transition period when pre- and post-EMIR Refit data would coexist. Q2: Based on the format relationship analysis, please list any critical issues that might prevent TRs from calculating positions using pre- and post-EMIR Refit data during the transition period? One respondent suggested to implement the Position Aggregation reporting changes after the transition period, because by then the data will be updated to the new standards. Four respondents raised concerns for post-REFIT T3F9 ‘Collateral portfolio code’ not allowing for special characters in contrast to pre-REFIT T1F23 ‘Collateral portfolio code’ where special characters are allowed. Four respondents pointed out that the mapping between pre-REFIT T1F21 ‘Collateralisation’ and post-REFIT T3F11 ‘Collateralisation category’ is problematic for the legacy ‘OC’ (one-way collateralised) and ‘PC’ (partially collateralised) values. One respondent asked whether pre-REFIT T2F55 ‘Floating rate of leg 1’ values that are not in the list of the specified 4-letter codes would not be mapped (or in other words mapped with an empty value) to post-REFIT T2F84 ‘Indicator of the floating rate of leg 1’. The same question was raised for the pre-REFIT T2F58 ‘Floating rate of leg 2’ and its mapping with post-REFIT T2F100 ‘Indicator of the floating rate of leg 2’. Two respondents raised a concern on the calculation of the positions regarding the cases where pre-REFIT T1F4 ‘ID of the other Counterparty’ is populated with a client code that does not match the required format for post-REFIT ‘Counterparty 2’ for natural persons. The respondent claimed that the REFIT methodology of creating a client code would lead to incorrectly duplicated positions, as both counterparties are ultimately the same. Also,

the respondent highlighted that this will also impact non-legacy trades that are subject to an LEI update in the context of the Q&A 40. One respondent referred to the existence of negative values for pre-REFIT T2F20 ‘Notional’, which are no longer allowed in the relevant REFIT fields for the notional amount (like T2F55). This is already addressed in ESMA’s Consultation Paper. Two respondents remarked that the matching of pre-REFIT T2F30 ‘Master Agreement Type’ and post-REFIT T2F34 ‘Master Agreement Type’ is challenging, as the former contains values in the format of free text up to 50 characters, while the latter should be populated according to the specified 4-character codes. The respondent pointed out that it is unclear whether these values should be aggregated under the bucket ‘OTHR’, or if they should create a number of additional positions for every ‘free text’ Master agreement type reported in the old standards. One respondent asked whether the pre-REFIT T2F89 ‘Index Factor’ values should be normalised during the transition period in line with the post-REFIT T2F147 ‘Index factor’, as the former are between 0-100 and the latter between 0-1. Three respondents asked how should records where pre-REFIT T2F7 ‘Underlying Identification Type’ is populated with code ‘A’ (AII - Alternative Investment ID) or ‘U’ (UPI) be aggregated, given that post-REFIT T2F13 ‘Underlying Identification Type’ does not allow to be populated with code ‘A’ nor ‘U’. According to the understanding of one of the respondents, this would imply the creation of another aggregation, valid only during the transition period. ESMA’s response to Q2: Given that ESMA is proposing to implement the new Guidelines when the EMIR Refit transition period expires, the issues raised by respondents regarding format relationship analysis should no longer be relevant because all data should have been upgraded to the most recent standards. ESMA suggested an arbitrary convention to determine whether the reporting counterparty is the ‘buyer’ or the ‘seller’ of a derivative contract, to ensure consistency in the aggregations. According to this convention, the ‘Buyer’ should be determined when either ‘Direction’ = ‘BYER’ is populated or when ‘TAKE’ and ‘MAKE’ are populated in ‘Direction of leg 1’ and ‘Direction of leg 2’, respectively. The ‘Seller’ should be determined when either ‘Direction’ = ‘SLLR’ is populated or when ‘MAKE’ and ‘TAKE’ are populated in ‘Direction of leg 1’ and ‘Direction of leg 2’, respectively. Q3: For aggregating metrics as ‘Buyer’ or ‘Seller’ positions, do you agree with the overall logic to be used for determining such grouping? If not, please explain why and propose an alternative approach.

Four respondents agreed with the logic for determining the aggregation of "Buyer" or "Seller" positions. Two respondents disagreed with the proposal and with the statement that “reporting entities are not obliged to coordinate on the order of legs”, since Article 4 of EU 2022/1860 says that counterparty 2 should report opposite values to counterparty 1, and they suggest having separate metrics for buyer/seller and make/take. One respondent also mentioned that Table 2 of 2022/1858, in turn, puts on TRs obligation to reconcile the legs between counterparties’ reports. The other respondent supported that Buyer / seller should be based on the specific products in table 14 of EMIR Refit Guidelines, for those that should be buyer/seller and make/take for the others, and afterwards the rules in Article 4 of EU 2022/1860 to determine if it is buyer or seller. ESMA’s response to Q3:
a) The statement in the consultation paper “reporting entities are not obliged to coordinate on the order of the legs”, was somewhat unclear and below clarification from L2/L3 EMIR text should be considered.
i. Article 4 of the ITS on reporting provides that the counterparty
side to the derivative contract shall be determined at the time of the conclusion of the derivative on the basis of the type of contract concluded.
ii. EMIR Refit guidelines further specify that counterparties should
determine the counterparty side at the time of the conclusion of the derivative and report either Buyer/Seller in field ‘Direction’ or Make/Take in fields ‘Direction of Leg 1’ and ‘Direction of Leg 2’ depending on the type of the derivative concluded, as provided in the table below.

iii. Counterparties, once determined the counterparty side, should
report the fields related to ‘Direction’, ‘Direction of Leg 1’ and ‘Direction of Leg 2’ with the opposite values.
iv. This means that in case where the two counterparties concluded
a contract which requires the population of the field ‘Direction’, if the counterparty 1 reports Buyer in field ‘Direction’, the other counterparty to the contract should report Seller and vice versa.
v. Similarly, assuming that counterparties should agree on the
consistent way of reporting of the respective legs of the derivative, in case where the two counterparties concluded a contract which requires the population of the fields ‘Direction of Leg 1’ and ‘Direction of Leg 2’, if the counterparty 1 reports MAKE in field ‘Direction of Leg 1’ and TAKE in field ‘Direction of Leg 2’, the other counterparty to the contract should report TAKE in field ‘Direction of Leg 1’ and MAKE in field ‘Direction of Leg 2’.
vi. It is also expected that the counterparty which reports MAKE in
field ‘Direction of Leg 1’ should report TAKE in field ‘Direction of Leg 2’ and vice versa. b) Regarding the proposal to have separate metrics for buyer/seller and make/take was considered but discarded as it would add additional complexity as two sets of each metrics would need to be calculated. Moreover, considering that the number of metrics to be calculated as ‘Total’ and ‘Clean’ have significantly increased with

the additional fields such as ‘Delta’, ‘Other payment amount’, ‘Notional amount in effect’, etc. Certain types of derivatives with two legs, such as interest-rate swaps, cross-currency swaps and FX swaps, the order of the legs cannot be unequivocally defined, as there is no specific prevalence of one leg over the other. For example, in the case of a FX swap on EUR/USD the counterparties should report consistently the direction for each currency involved, i.e., one counterparty would report itself as a buyer (TAKE) of EUR and seller (MAKE) of USD, whereas the other counterparty would report itself as seller (MAKE) a of EUR and buyer (TAKE) of USD. The counterparties are not required to coordinate on the order of the currencies in the report, i.e., whether EUR or USD should be reported in leg

1. As specified by EMIR Refit Guideline 432, the reporting of the direction of the derivative
   and of the currencies involved should be done by parties taking into account their own booking irrespective of the other party booking. Consequently, the direction and the order of currencies may vary in the reporting. TRs should in such cases use an alphabetical order logic to determine the direction and the order of currencies for derivatives with two legs (e.g., USD/EUR would translate to Leg 1 = EUR and LEG 2 = USD) for the purpose of calculating the positions. In this example, the counterparty reporting itself as a buyer (TAKE) for the leg involving EUR (which would translate to leg 1) would be considered the buyer in line with the paragraph 21. Q4: Do you agree having an alphabetical order logic to determine Leg 1 and Leg 2 for FX and Cross-Currency Swaps? If not, please explain why and propose an alternative approach. All six respondents agreed to the proposal. One respondent highlighted that TRs would need explicit rules to identify the use cases under this rule, for example “TRs should determine Leg 1 and Leg 2 for all contracts where field 2.10 Contract type = SWAP and 2.11 Asset class = CURR and currencies reported under 2.115 Exchange rate basis are different”. One respondent asked for guidance on how on how to determine Leg 1 and Leg 2 for FX and Cross-Currency Swaps for historical position reports, as new fields have been introduced for the position calculation, such as ‘T1F18 Direction of leg 1’ and ‘T1F19 Direction of leg 2’. ESMA’s response to Q4: this proposal has been included in the final Guidelines. Regarding the comment in paragraph 27, ESMA has only outlined the general principle to be applied by TRs at this stage. The set of specific conditions to be used should be developed by each individual TR. Regarding the comment in paragraph 28, given that ESMA intends to propose implementing the new Guidelines when the EMIR Refit transition period expires, the issues raised by respondents should have no bearing because all data should have been upgraded to the most recent standards.

Under EMIR Refit, the notional value(s) will be reported in fields ‘Notional of leg 1’ and ‘Notional of leg 2’ and only positive values will be allowed. These changes will need to be accounted for when aggregating metrics on ‘total notional’ values. Q5: Following the logic described under use case 1 for determining the ‘Buyer’ and ‘Seller’ positions, do you agree with the approach on how aggregation of notional values should be performed? If not, please explain why and propose an alternative approach. All 6 respondents agreed to the proposal. ESMA’s response to Q5: the proposal will be adopted. Counterparties should update all their outstanding derivatives to conform with the revised reporting requirements of EMIR Refit within 180 calendar days of the reporting start date. During this transition period, updated and non-updated data will coexist, due to the different data standards. Q6: Should position aggregation of field ‘Notional of leg 2’ only be applicable after the transition period to account for the fact that it is a new field that will only start to be reported as of the go-live? Five respondents agree with the proposal, however one of them further specifies that in case of alternative A or B (see section 4.5 of the consultation paper) their preference is to still generate the aggregation of field ‘Notional of leg 2’ from the reporting start date, to prevent further changes to the software after the transition period. One respondent disagrees with the proposal, emphasising the importance of avoiding additional releases post transition period to include a new field "Notional of Leg 2" in the Position Calculation that would add complexity and incur technical risks/costs. Therefore, they prefer a single release that includes the new field during the transition phase. ESMA’s response to Q6: Given that ESMA is proposing to implement the new Guidelines when the EMIR Refit transition period expires, the issues raised by respondents regarding the aggregation of field 'Notional of leg 2' should have no negative impact. ESMA proposed two alternatives for dealing with derivatives that have not yet been updated to the latest standards during the transition period and have negative notional values reported: include negative notional values in absolute terms in the aggregation or exclude them from the aggregation. Q7: Which of the two alternatives for dealing with negative notional values is the preferred one? Are there other alternatives that could be used?

Five respondents agreed that their preferred alternative would be to exclude negative notional values. One of them explicitly mentioned that they find the addition of absolute values of positive and negative notionals methodologically incorrect. One respondent mentioned that there is no optimal approach and therefore no preferred logic, but they have a preference on option 1 to include negative notional in absolute terms in the Position Calculation as proposed under paragraph #25 during the transition phase. ESMA’s response to Q7: Given that ESMA is proposing to implement the new Guidelines when the EMIR Refit transition period expires, the issue with negative notional values should be resolved once all data is upgraded to the most recent standards. ESMA proposed two alternatives for dealing with derivatives that have not yet been updated to the latest standards during the transition period and have negative notional values reported: include negative notional values in absolute terms in the aggregation or exclude them from the aggregation. Q8: Do you believe field ‘Delta’ could be used to calculate the delta weighted average notional amounts for options and swaptions in an efficient and reliable manner by TRs? Would this information be useful to include in the position calculation report using the proposed methodology? If so, would you prefer having the metrics expressed as “netted” or in “absolute” terms? Two respondents confirmed that they would be able to calculate the field in question and one of them suggested to express it in absolute terms while the other conditioned their ability to perform this calculation on ESMA providing a more accurate position exposure reporting. Three respondents raised concerns regarding this metric, due to the delta hedging performed by market participants rendering it less useful, the absence of validations for the correct reporting of deltas, the existence of options with delta beyond the range of -1, 1, the unreliability of its calculation during the transition period, the introduction of increased complexity and its limited applicability only to a subset of positions (options and swaptions). One respondent pointed out that the naming convention and the description used for the new metrics based on the Delta are inaccurate. Given that the notional amounts are the weights used for computing the weighted average of the delta values, the name of the metric should be “notional amount-weighted average delta” instead. The respondent also highlighted that this metric will not be, in fact, expressed in currency units. One respondent asked whether TRs should be responsible for performing such complicated calculations as part of their obligations.

ESMA’s response to Q8: The shortcomings identified by a few respondents in the reporting and aggregation of field 'delta' are well known by market participants and authorities. However, ESMA believes that including this field in the position report is a necessary first step toward utilizing this risk factor, which provides additional insights on counterparties' market risk exposures. ESMA also acknowledged that the name of this metric should be changed to "notional amount-weighted average delta position" and that it will not be expressed in currency units but will be unitless, as suggested by one respondent. ESMA described the proposed aggregation methodology for the field ‘Other payment amount’. Q9: Do you consider the information reported under field ‘Other payment amount’ useful to include in the position calculation report? Do you agree with the proposed methodology or is it perceived as too complex and cumbersome to compute? Two respondents agree that the methodology to compute these numbers is reasonable. Two respondents point out that the field in question could be used but at the same time doing so would increase complexity. Two respondents mentioned that this would increase the complexity. One respondent asked whether there would be a significant value addition by implementing this. One respondent pointed out that the code for “Unwind or Full termination” is “UWIN”, not “UNWIN”. One respondents pointed out that the following REFIT fields will be required to calculate these metrics (these were not listed above in section 4.1 as required fields for computing position aggregations): 2.78 “Other payment receiver”, 2.73 “Other payment type” and 2.75 “Other payment Currency”. Only the latter was also mentioned by one additional respondent. ESMA’s response to Q9: ESMA and other authorities recognise that the addition of new EMIR Refit fields such as 'Other payment amount' will undoubtedly increase the complexity and size of the position report compared to its current state. The goal, however, has been to increase the level of information included in the position report to make it easier for authorities to perform their duties. With new technologies and upgraded infrastructure, authorities can process larger amounts of data and use it for a variety of purposes; thus, ESMA believes that the benefits of expanding the position report outweigh the drawbacks. ESMA will correct the typo in the code describing "Unwind or Full termination" and add the three missing fields not mentioned in section 4.1 to the schema message.

Under EMIR Refit, commodity derivatives are classified by ‘Base product’, ‘Sub-product’ and ‘Further sub-product’. ESMA proposed the addition of the latter field to introduce further granularity in determining the positions sets for commodity derivatives. Q10: Do you agree that position calculation for commodities should consider field ‘Further sub-products’ for providing additional granularity as proposed under amended guideline 29 in section 4.5 of this consultation paper? Two respondents replied that the additional complexity that will be introduced by including the “Further Sub-Products” as a dimension is not merited. One respondent replied that they partially agree, but also stressed the negative impact from a computational perspective. ESMA’s response to Q10: ESMA and other authorities recognise that the addition of new EMIR Refit fields such as 'Further sub-products' will undoubtedly increase the complexity and size of the position report compared to its current state. The goal, however, has been to increase the level of information included in the position report to make it easier for authorities to perform their duties. With new technologies and upgraded infrastructure, authorities can process larger amounts of data and use it for a variety of purposes; thus, ESMA believes that the benefits of expanding the position report outweigh the drawbacks. Furthermore, given the recent energy crisis, additional granularity on commodity derivatives' "Further sub-products" is deemed necessary from a supervisory and monitoring standpoint. ESMA proposed the addition of initial and variation margin data, referring to post-haircut to introduce further granularity in determining the positions sets for commodity derivatives. Q11: Do you agree that initial and variation margin data, referring to post-haircut, should be included in the position calculation report as proposed under amended guideline 21 in section 4.5 of this consultation paper? Three respondents replied that the additional complexity that will be introduced by this is not merited. One of them asked whether there would be significant value addition by including this. Two respondents agreed with the proposal. ESMA’s response to Q11: ESMA and other authorities recognise that the addition of new EMIR Refit fields, such as initial and variation margin data referring to post-haircut, will undoubtedly increase the complexity and size of the position report in comparison to its current state. However, the goal has been to increase the level of information included in the position report to help authorities perform their duties. With new technologies and upgraded infrastructure, authorities can process larger amounts of data and use it for

different purposes; thus, ESMA believes that the benefits of expanding the position report outweigh the drawbacks. Q12: Are there other new EMIR Refit fields not mentioned in the above table that should be included as well, if so, please explain and provide examples how to best incorporate such fields? One respondent mentioned to include 2.78 “Other payment receiver”, 2.73 “Other payment type” and 2.75 “Other payment Currency”. ESMA’s response to Q12: the three missing fields will be included in the final schema message. ESMA described the amendments to the existing Guidelines based on the conclusions from the mapping exercise, the mapping table, and the use cases regarding the necessary EMIR Refit fields. Q13: Do you agree with the proposed amendments? If not, please elaborate on the reasons for your answer. Three respondents agreed with the proposed amendments. One of them, however, stressed that they are against the inclusion of additional fields in the report. One respondent mentioned to include 2.78 “Other payment receiver”, 2.73 “Other payment type” and 2.75 “Other payment Currency”. Two respondents commented Guideline 16:
a) TRs must compare all the currencies from the fields listed, i.e., valuation currency and all relevant margin currencies to determine whether at least one of them is different, thus triggering the conversion to EUR. However, this rule implies comparing – ahead of the calculation – a currency from Table 2 (valuation) with multiple currencies from Table 3 (margin). Our preference is to isolate the calculation of the position sets and the collateral position sets, thus enabling parallelization of the calculation and removing unnecessary dependencies between the reports. b) To simplify the calculation and reduce the risk of misinterpretation, we suggest applying the EUR- conversion irrespective if all the fields are reported in different or the same currency. We also suggest clarifying the expected approach if some of the values are empty and hence no currency is provided. Two respondents commented Guideline 21:

a) Although it is not the expected behaviour, it is technically possible (no rules prevent so) that counterparties submit a margin update at trade level over one of the derivatives included in a portfolio without having detached the contract from the portfolio. This implies that derivatives included within the same portfolio could have different margin details and, more importantly, different currencies. This scenario is not covered by Guideline 21, and it is paramount for TRs to aggregate collateral data. b) It is not fully clear – it says that the TRs should aggregate the collateral values across derivatives, which share the same portfolio code. In Refit, however, the collateral values will be provided in a separate table, only once per portfolio code – hence no aggregation across derivatives should be needed. We suggest clarifying or remove the guideline. One respondent commented on the following Guidelines:
a) Guideline 3: We agree with the proposal of delaying the SLA from 12:00 UTC to midnight at T+2. This will allow better management of the report generation process and reduce the risk of delays in the provision of reports to the supervisory Authorities. b) Guideline 13: For the benefit of consistency, this guideline should also consider fields 3.4 Counterparty 1 and 3.5 Counterparty 2. c) Guideline 17: We propose to amend the guideline to expand to other EU authorities the possibility to request to TRs the algorithm used for the compilation of the position’s datasets. d) Guideline 24 a-s defines field T3F9 Collateral Portfolio code as a dimension for position and currency position sets. Given that the rest of dimensions and metrics for these reports are based on fields from tables 1 and 2, it would be more consistent that the dimension is 2.27 Collateral portfolio code. This would allow TRs to consider this dimension also in positions where one or several derivatives have been linked to a portfolio, even if such portfolio that has not received margin updates yet. e) Guideline 30 a-j should consider field 3.4 Counterparty 1 and field 3.5 Counterparty 2 given that the reports collateral position and currency collateral position sets are based on margin data. ESMA’s response to Q13:
a) Response to number 66: ESMA and other authorities have acknowledged that the addition of new EMIR Refit fields will undoubtedly increase the complexity and size of the position report in comparison to its current state. The goal, however, has

been to increase the level of information included in the position report to make it easier for authorities to perform their duties. With new technologies and upgraded infrastructure, authorities can process larger amounts of data and use it for a variety of purposes, which is why ESMA believes that the benefits of expanding the position report outweigh the drawbacks. b) Response to number 67: the three missing fields will be included in the final schema message. c) Response to number 68a: The most appropriate technical execution of the relevant guideline will be determined by the structure of each TR's IT systems. It is up to the TRs to determine the best way to implement it. d) Response to number 68b: Converting all relevant fields to EUR, regardless of whether they are reported in different or same currency, may be more efficient, but the goal is to maintain the non-EUR reported currency when all relevant fields are reported in the same non-EUR currency. e) Response to number 69a: This is an edge case that must be handled inside the validation rules. Proposing a solution or workaround as part of these recommendations may not be the best approach. This use case already been updated by ESMA as part of the validation rules enhancement process. f) Response to number 69b: Guideline 21 has been clarified to ensure that no aggregation is needed when the collateral is part of a portfolio. g) Response to number 70a: acknowledged. h) Response to number 70b: guideline 13 will be revised to include fields 3.4 ‘Counterparty 1’ and 3.6 ‘Counterparty 2’ for consistency purposes. i) Response to number 70c: As the TRs' immediate supervisor, ESMA should maintain this supervisory information as part of its role. j) Response to number 70d: guideline 24a-s will be revised so that field ‘Collateral portfolio code’ from either table 2 (T2F27) or table 3 (T3F9) can be used. k) Response to number 70e: guideline 30a-j will be revised so that fields ‘Counterparty 1’ and Counterparty 2’ from either table 1 (T1F4 and T1F9) or table 3 (T3F4 and T3F6) can be used. During this transition period, updated and non-updated data will coexist, due to the different data standards. This presents various challenges regarding the consistent calculation of positions in this period. Three alternatives were presented: A. calculate positions using both pre- and post-Refit data as of EMIR Refit go-live, B. calculate positions as of EMIR

Refit go-live using only data that have been updated to the latest standards or C. calculate positions only after the EMIR Refit transition period is over. Q14: Which of the three alternatives are you most in favour of? Please explain in detail. Five respondents prefer option C. One respondent prefers option B. ESMA’s response to Q14: There is a significant inclination for delaying the introduction of the new Guidelines until the EMIR Refit transition period has concluded. Given that most authorities still have little reliance on the report, the disruption will be minimal; thus, ESMA's proposal would be to adopt the new Guidelines after the EMIR Refit transition concludes. Q15: Do you see other potential alternatives as a way forward during the transition period? Please explain in detail. One respondent suggested the provision of 2 Position Calculations files (one for pre-refit Positions that consist of using pre-Refit Position Calculation logic + one for post-refit Positions that consist of using post-Refit Position Calculation logic without mixing of emir data standards) One respondent suggested option B. One respondent restated their preference for option C. ESMA’s response to Q15: Although the comment has been acknowledged, ESMA's proposal is for TRs to implement the new Guidelines once the EMIR Refit transition period is completed. Q16: If applicable, to what extent is the position report being used by your organisation? Would it have minimum, medium, or maximum impact if such report would not be provided during the 6-month transition period by the TRs? One respondent mentioned that the use of the report is limited. One respondent mentioned that they do not use the report. ESMA’s response to Q16: ESMA recognized the feedback received, which was also considered when deciding to postpone the implementation of the new Guidelines until the EMIR Refit transition period finished. Q17: Do you agree with the amendments proposed for Table 1-3 included in
Annex I?

Five respondents agreed.
One respondent pointed out that In the Table 2 it should be further clarified how the open range (XX years) should be encoded in the schema. In the Table 3, it is not clear which fields should be used to identify the indicator of the floating rate of leg 1: only T2F84 or also T2F83 and T2F85? ESMA’s response Q17: The schema will provide further guidance on how the open range (XX years) should be encoded. For the time being, only field ‘Indicator of the floating rate of leg 1’ (T2F84) and ‘Indicator of the floating rate of leg 2’ (T2F100), will be included in the schema. Q18: Are there any other clarifications required with regards to the calculation of positions under EMIR Refit? One respondent mentioned the following: In line with the clarification provided by ESMA, the TRs should in principle be able to update also the non-outstanding contracts. Any correction send after go-live would need to contain an Event date so the counterparties would also be able to specify the timespan during which the correction should have been applied by sending two correction re-ports. However, it is acknowledged that prior to EMIR REFIT there was no expectation to con-struct and update history of TSR throughout time thus it would be not proportionate to require to construct it ex-post for trades that became non-outstanding prior to EMIR REFIT go-live”. However, the guidelines on position calculation by Trade Repositories under EMIR seems to present different approach. It states: “in case of correction of erroneous data there is requirement to re-calculate and give NCAs the opportunity to request an amended version of each calculation that was incorrect from the relevant TR for the period of two previous years.” It seems that to be in￾consistent and needs clarification. ESMA’s response Q18: The relevant Guideline will be amended to limit the historical reference period for requesting corrected position calculation reports. TRs should be able to provide amended versions of each calculation up to 2 years back in time, which will be limited to the EMIR Refit go-live date. This means that if an authority requests corrected reports at T+6 month, where T is the EMIR Refit go-live, then TRs would need to only provide reports for the 6-month period (i.e., excluding the 1.5 years of pre-EMIR Refit period). This limitation would naturally disappear as time passes and will vanish completely after 2 years into the new EMIR Refit reporting regime.

4.3 Guidelines
TRs should calculate position data and make it available in four separate datasets − Position Set, Collateral Position Set, Currency Position Set and Currency Collateral Position Set. These datasets should be uniquely identifiable and labelled with the relevant reference date. Unless otherwise specified, all the Guidelines apply to each calculation. This excludes the following Guidelines which should be applied only to the following calculations:
a) Guideline 19, Guideline 24, Guideline 25, Guideline 26, Guideline 31, and Guideline 32 are applicable to Positions Sets; b) Guideline 20, Guideline 24, Guideline 25, Guideline 26, Guideline 31, and Guideline 32 are applicable to Currency Position Sets; c) Guideline 21, Guideline 22, Guideline 23, and Guideline 30 are relevant to Collateral Position Sets; d) Guideline 21, Guideline 22, Guideline 23, Guideline 30, Guideline 31, and Guideline 33 are applicable to Currency Collateral Position Sets; e) Guideline 27 is only applicable to Position Sets and Currency Position Sets where the field Asset class (T2F11) is reported as ‘INTR’ and field Contract type (T2F10) is reported as ‘SWAP’; f) Guideline 28 is only applicable to Position Sets and Currency Position Sets where the field Asset class (T2F11) is reported as ‘CRDT’; g) Guideline 29 is only applicable to Position Sets and Currency Position Sets where the field Asset class (T2F11) is reported as ‘COMM’. TRs should calculate positions consistently irrespective of whether the derivative reported is single or dual-sided and consistently irrespective of the reconciliation status of the report. TRs should determine outstanding derivatives, as referred to in Article 2(2) of ITS on reporting, to calculate the set of outstanding derivatives pertaining to a position. TRs should include all relevant derivatives reports held by a TR pertinent to a position of a particular Counterparty 1 (T1F4) in the relevant position calculation. TRs should include derivatives irrespective of whether they are or are not reconciled, paired or matched. TRs should calculate positions on a ‘best available information’ basis. TRs should include all information, as available at the date of the position calculation, conforming to common validation rules in the position calculation, irrespective of the reconciliation status.

TRs should calculate positions based on the information included in the latest trade state report, in line with the following steps:
If a TR provides an authority with access to erroneous data which is caused by a significant TR technical issue, then the TR should solve the issue as soon as possible and re-report correctly the historical data up to 2 years back in time, limited to EMIR Refit go-live date. When a significant misreporting mistake, caused by a reporting counterparty rather than the TR, has led to an incorrect calculation by a TR, all authorities should be notified, and given the opportunity to request an amended version of each calculation up to 2 years back in time, limited to EMIR Refit go-live date, that was incorrect from the relevant TR. TRs should maintain a record of all the position calculations which they have calculated for at least two years. TRs which receive data in line with the portability Guidelines (ESMA70-151-552)7 should keep the previously calculated positions transferred from the old TR for at least two years and follow Guideline 9 prospectively. For derivatives that have missing data for one or more of the metrics or dimensions, TRs should include the derivatives with those missing values in a separate position. However, 7 https://www.esma.europa.eu/document/guidelines-transfer-data-between-trade-repositories Event Day/time 1 End of trading day T Day T 2 Retrieve appropriate FX reference rates on day T for converting, where applicable, the required fields as per Guideline (14). Day T 16:00 UTC (17:00 CET) 3 Deadline for reporting entities to submit reports to TRs on derivatives traded on day T with event date T. Day T+1 23:59 UTC 4 Deadline for providing the trade state report by TRs based on lifecycle events reported up to T+1 with event date T or earlier. Day T+2 12:00 UTC 5 Deadline for providing the position report by TRs based on the trade state report provided on T+2 based on event date T or earlier. Day T+2 23:59 UTC

TRs should exclude derivatives from all relevant calculations only when there is missing data for field ‘Counterparty 1’ (T1F4 / T3F4), ‘Counterparty 2’ (T1F9 / T3F6), ‘Contract type’ (T2F10) or ‘Asset class’ (T2F11). A TR should have in place a robust procedure to identify abnormal values, i.e., outliers, relating to the derivatives it receives from counterparties. For a given position, a TR should calculate positions according to the metrics which exclude reports with outliers, and the metrics which include all reports which meet the dimensions for each calculation. TRs should provide access to positions to the relevant authorities by using an ISO 20022 XML template and following the operational standards defined in Articles 4 and 5 of the RTS on data access8 . If at least one of the below value fields is reported with a different currency, TRs should convert them all to EUR using the relevant FX rate published on the ECB website on the reference date. If the required rate is not published, then an appropriate alternative reference rate should be used by TRs. a) Valuation amount (T2F21) b) Initial margin posted by the counterparty 1 (pre-haircut) (T3F12) c) Initial margin posted by the counterparty 1 (post-haircut) (T3F13) d) Variation margin posted by the counterparty 1 (pre-haircut) (T3F15) e) Variation margin posted by the counterparty 1 (post-haircut) (T3F16) f) Excess collateral posted by the counterparty 1 (T3F18) g) Initial margin collected by the counterparty 1 (pre-haircut) (T3F20) h) Initial margin collected by the counterparty 1 (post-haircut) (T3F21) i) Variation margin collected by the counterparty 1 (pre-haircut) (T3F23) j) Variation margin collected by the counterparty 1 (post-haircut) (T3F24) k) Excess collateral collected by the counterparty 1 (T3F26) 8 Commission Delegated Regulation (EU) No 2022/1856 of 10 June 2022 amending the regulatory technical standards laid down in Delegated Regulation (EU) No 151/2013 by further specifying the procedure for accessing details of derivatives as well as the technical and operational arrangements for their access.

Fields ‘Notional amount of leg 1 (T2F55) and ‘Notional amount of leg 2 (T2F64) should never be converted. Upon request from ESMA, a TR should always have available the calculation algorithms they use as well as the procedure(s) which they follow to produce each of the four datasets relating to the position calculations described in these Guidelines. Figures included in calculations should not be rounded but the calculated position should be rounded to minimum 2 digits after decimal. For the purpose of calculating the positions, TRs should determine if a transaction refers to a ‘buyer’ or a ‘seller’ by applying the following logic:
a) The ‘Buyer’ should be determined when either ‘Direction’ = ‘BYER’ is populated or when ‘TAKE’ and ‘MAKE’ are populated in ‘Direction of leg 1’ and ‘Direction of leg 2’, respectively. b) The ‘Seller’ should be determined when either ‘Direction’ = ‘SLLR’ is populated or when ‘MAKE’ and ‘TAKE’ are populated in ‘Direction of leg 1’ and ‘Direction of leg 2’, respectively. The reporting of the direction of derivatives with two legs should be done by parties taking into account their own booking irrespective of the other party booking9 . Consequently, the direction and the order of currencies or interest rates involved may vary in the reporting of derivatives with two legs. To avoid double counting, TRs should in such cases use an alphabetical order logic to determine the direction and the order of currencies or interest rates indicators/names used for derivatives with two legs. For example, an FX swap with USD/EUR would translate to Leg 1 = EUR and Leg 2 = USD) for the purpose of calculating the positions. In this example, the counterparty reporting itself as a buyer (TAKE) for the leg involving EUR (which would translate to leg 1) would be considered the buyer. TRs should calculate and quantify positions by aggregating according to the following quantitative metrics. When the position does not include outliers, it should be referred to as ‘clean’, when it does include outliers, it should be referred to as ‘total’. Total and clean number of derivatives/trades a) Number of derivatives used for calculating the Buyer-Side position: This refers to the number of trades contained in the position set for which the Counterparty 1 (T1F4) has either reported ‘BYER’ in the field Direction (T1F17), or has reported 9 See EMIR Refit Guideline 432

‘TAKE’ and ‘MAKE’ in the fields Direction of leg 1 (T1F18) and Direction of leg 2 (T1F19), respectively; b) Number of trades used for calculating the Seller-Side position: This refers to the number of trades contained in the position set for which the Counterparty 1 (T1F4) has either reported ‘SLLR’ in the field Direction (T1F17), or has reported ‘MAKE’ and ‘TAKE’ in the fields Direction of leg 1 (T1F18) and Direction of leg 2 (T1F19), respectively; Total and clean notional amounts c) Buyer-Side Notional amount of leg 1: Aggregations of values in the field Notional of leg 1 (T2F55) for all derivatives pertaining to a position set for which the Counterparty 1 (T1F4) has either reported ‘BYER’ in the field Direction (T1F17) or has reported ‘TAKE’ and ‘MAKE’ in the fields Direction of leg 1 (T1F18) and Direction of leg 2 (T1F19), respectively. The notional amount should be expressed in terms of amount and in the reported Notional Currency 1 (T2F56); d) Buyer-Side Notional amount of leg 2: Aggregations of values in the field Notional of leg 2 (T2F64) for all derivatives pertaining to a position set for which the Counterparty 1 (T1F4) has either reported ‘BYER’ in the field Direction (T1F17) or has reported ‘TAKE’ and ‘MAKE’ in the fields Direction of leg 1 (T1F18) and Direction of leg 2 (T1F19), respectively. The notional amount should be expressed in terms of amount and in the reported Notional Currency 2 (T2F65); e) Seller-Side Notional amount of leg 1: Aggregations of values in the field Notional of leg 1 (T2F55) for all derivatives pertaining to a position set for which the Counterparty 1 (T1F4) has either reported ‘SLLR’ in the field Direction (T1F17) or has reported ‘MAKE’ and ‘TAKE’ in the fields Direction of leg 1 (T1F18) and Direction of leg 2 (T1F19), respectively. The notional amount should be expressed in terms of amount and in the reported Notional Currency 1 (T2F56); f) Seller-Side Notional amount of leg 2: Aggregations of values in the field Notional of leg 2 (T2F64) for all derivatives pertaining to a position set for which the Counterparty 1 (T1F4) has either reported ‘SLLR’ in the field Direction (T1F17) or has reported ‘MAKE’ and ‘TAKE’ in the fields Direction of leg 1 (T1F18) and Direction of leg 2 (T1F19), respectively. The notional amount should be expressed in terms of amount and in the reported Notional Currency 2 (T2F65); g) When Asset Class (T2F11) is ‘CRDT’, then the notional amount metric (Guideline 19(c), (d), (e) or (f)) should be multiplied by the Index Factor (T2F147) only when the index factor value is larger than zero; Total and clean notional amounts in effect

h) Buyer-Side Notional amount in effect of leg 1: Aggregations of values in the field Notional amount in effect on associated effective date of leg 1 (T2F59) for all derivatives pertaining to a position set for which the Counterparty 1 (T1F4) has either reported ‘BYER’ in the field Direction (T1F17) or has reported ‘TAKE’ and ‘MAKE’ in the fields Direction of leg 1 (T1F18) and Direction of leg 2 (T1F19), respectively. The notional amount should be expressed in terms of amount and in the reported Notional Currency 1 (T2F56); i) Buyer-Side Notional amount in effect of leg 2: Aggregations of values in the field Notional amount in effect on associated effective date of leg 2 (T2F68) for all derivatives pertaining to a position set for which the Counterparty 1 (T1F4) has either reported ‘BYER’ in the field Direction (T1F17) or has reported ‘TAKE’ and ‘MAKE’ in the fields Direction of leg 1 (T1F18) and Direction of leg 2 (T1F19), respectively. The notional amount should be expressed in terms of amount and in the reported Notional Currency 2 (T2F65); j) Seller-Side Notional amount in effect of leg 1: Aggregations of values in the field Notional amount in effect on associated effective date of leg 1 (T2F59) for all derivatives pertaining to a position set for which the Counterparty 1 (T1F4) has either reported ‘SLLR’ in the field Direction (T1F17) or has reported ‘MAKE’ and ‘TAKE’ in the fields Direction of leg 1 (T1F18) and Direction of leg 2 (T1F19), respectively. The notional amount should be expressed in terms of amount and in the reported Notional Currency 1 (T2F56); k) Seller-Side Notional amount in effect of leg 2: Aggregations of values in the field Notional amount in effect on associated effective date of leg 2 (T2F68) for all derivatives pertaining to a position set for which the Counterparty 1 (T1F4) has either reported ‘SLLR’ in the field Direction (T1F17) or has reported ‘MAKE’ and ‘TAKE’ in the fields Direction of leg 1 (T1F18) and Direction of leg 2 (T1F19), respectively. The notional amount should be expressed in terms of amount and in the reported Notional Currency 2 (T2F65); l) When Asset Class (T2F11) is ‘CRDT’, then the notional amount metric (Guideline 19(h), (i), (j) or (k)) should be multiplied by the Index Factor (T2F147) only when the index factor value is larger than zero; Total and clean valuation amounts m) Buyer-Side Negative Valuation Amount: aggregations of all negative values in field Valuation amount (T2F21) for all derivatives pertaining to a position set for which the Counterparty 1 (T1F4) has either reported ‘BYER’ in the field Direction (T1F17) or has reported ‘TAKE’ and ‘MAKE’ in the fields Direction of leg 1 (T1F18) and Direction of leg 2 (T1F19), respectively. The negative value should be

expressed in terms of amount and in the reported Valuation currency (T2F22), unless it has been subject to conversion as per Guideline 14; n) Buyer-Side Positive Valuation Amount: aggregations of all positive values in field Valuation amount (T2F21) for all derivatives pertaining to a position set for which the Counterparty 1 (T1F4) has either reported ‘BYER’ in the field Direction (T1F17) or has reported ‘TAKE’ and ‘MAKE’ in the fields Direction of leg 1 (T1F18) and Direction of leg 2 (T1F19), respectively. The positive value should be expressed in terms of amount and in the reported Valuation currency (T2F22), unless it has been subject to conversion as per Guideline 14; o) Seller-Side Negative Valuation Amount: aggregations of all negative values in field Valuation amount (T2F21) for all derivatives pertaining to a position set for which the Counterparty 1 (T1F4) has either reported ‘SLLR’ in the field Direction (T1F17) or has reported ‘MAKE’ and ‘TAKE’ in the fields Direction of leg 1 (T1F18) and Direction of leg 2 (T1F19), respectively. The negative value should be expressed in terms of amount and in the reported Valuation currency (T2F22), unless it has been subject to conversion as per Guideline 14; p) Seller-Side Positive Valuation Amount: aggregations of all positive values in field Valuation amount (T2F21) for all derivatives pertaining to a position set for which the Counterparty 1 (T1F4) has either reported ‘SLLR’ in the field Direction (T1F17) or has reported ‘MAKE’ and ‘TAKE’ in the fields Direction of leg 1 (T1F18) and Direction of leg 2 (T1F19), respectively. The positive value should be expressed in terms of amount and in the reported Valuation currency (T2F22), unless it has been subject to conversion as per Guideline 14; Total and clean delta position q) Net Buyer-Side Notional Amount of leg 1 Weighted Average Delta Position:
This refers to the following computation and aggregation ‘sum (delta * notional amount of leg 1) / sum (notional amount of leg 1)’ based on fields Delta (T2F25) and Notional amount of leg 1 (T2F55) for all derivatives pertaining to a position based on the following conditions: (i) Counterparty 1 (T1F4) has either reported ‘BYER’ in the field Direction (T1F17), or has reported ‘TAKE’ and ‘MAKE’ in the fields Direction of leg 1 (T1F18) and Direction of leg 2 (T1F19), respectively; (ii) Delta (T2F25) and Notional amount of leg 1 (T2F55) are not blank, and; (iii) Contract type (T2F10) is populated with 'OPTN' or 'SWPT' and Underlying identification type (T2F13) is not populated with 'B'; r) Net Buyer-Side Notional Amount of leg 2 Weighted Average Delta Position:
This refers to the following computation and aggregation ‘sum (delta * notional amount of leg 2) / sum (notional amount of leg 2)’ based on fields Delta (T2F25) and Notional amount of leg 2 (T2F64) for all derivatives pertaining to a position

based on the following conditions: (i) Counterparty 1 (T1F4) has either reported ‘BYER’ in the field Direction (T1F17), or has reported ‘TAKE’ and ‘MAKE’ in the fields Direction of leg 1 (T1F18) and Direction of leg 2 (T1F19), respectively; (ii) Delta (T2F25) and Notional amount of leg 2 (T2F64) are not blank, and; (iii) Contract type (T2F10) is populated with 'OPTN' or 'SWPT' and Underlying identification type (T2F13) is not populated with 'B'; s) Net Seller-Side Notional Amount of leg 1 Weighted Average Delta Position:
This refers to the following computation and aggregation ‘sum (delta * notional amount of leg 1) / sum (notional amount of leg 1)’ based on fields Delta (T2F25) and Notional amount of leg 1 (T2F55) for all derivatives pertaining to a position based on the following conditions: (i) Counterparty 1 (T1F4) has either reported ‘SLLR’ in the field Direction (T1F17), or has reported ‘MAKE’ and ‘TAKE’ in the fields Direction of leg 1 (T1F18) and Direction of leg 2 (T1F19), respectively; (ii) Delta (T2F25) and Notional amount of leg 1 (T2F55) are not blank, and; (iii) Contract type (T2F10) is populated with 'OPTN' or 'SWPT' and Underlying identification type (T2F13) is not populated with 'B'; t) Net Seller-Side Notional Amount of leg 2 Weighted Average Delta Position:
This refers to the following computation and aggregation ‘sum (delta * notional amount of leg 2) / sum (notional amount of leg 2)’ based on fields Delta (T2F25) and Notional amount of leg 2 (T2F64) for all derivatives pertaining to a position based on the following conditions: (i) Counterparty 1 (T1F4) has either reported ‘SLLR’ in the field Direction (T1F17), or has reported ‘MAKE’ and ‘TAKE’ in the fields Direction of leg 1 (T1F18) and Direction of leg 2 (T1F19), respectively; (ii) Delta (T2F25) and Notional amount of leg 2 (T2F64) are not blank, and; (iii) Contract type (T2F10) is populated with 'OPTN' or 'SWPT' and Underlying identification type (T2F13) is not populated with 'B'; Total and clean other payment amount u) Buyer-Side Upfront payment (payer): Aggregation of upfront payment values in field ‘Other payment amount’ (T2F74) for all derivatives pertaining to a position based on the following conditions: (i) Counterparty 1 (T1F4) has either reported ‘BYER’ in the field Direction (T1F17), or has reported ‘TAKE’ and ‘MAKE’ in the fields Direction of leg 1 (T1F18) and Direction of leg 2 (T1F19), respectively; (ii) Other payment type (T2F73) is populated with ‘UFRO’; and (iii) Other payment payer (T2F77) is the same as Counterparty 1 (T1F4). The upfront payment amount should be expressed in terms of amount and in the reported ‘Other payment currency’ (T2F75). v) Buyer-Side Upfront payment (receiver): Aggregation of upfront payment values in field ‘Other payment amount’ (T2F74) for all derivatives pertaining to a position based on the following conditions: (i) Counterparty 1 (T1F4) has either reported

‘BYER’ in the field Direction (T1F17), or has reported ‘TAKE’ and ‘MAKE’ in the fields Direction of leg 1 (T1F18) and Direction of leg 2 (T1F19), respectively; (ii) Other payment type (T2F73) was populated with ‘UFRO’; and (iii) Other payment receiver (T2F78) is the same as Counterparty 1 (T1F4). The upfront payment amount should be expressed in terms of amount and in the reported ‘Other payment currency’ (T2F75). w) Seller-Side Upfront payment (payer): Aggregation of upfront payment values in field ‘Other payment amount’ (T2F74) for all derivatives pertaining to a position based on the following conditions: (i) Counterparty 1 (T1F4) has either reported ‘SLLR’ in the field Direction (T1F17), or has reported ‘MAKE’ and ‘TAKE’ in the fields Direction of leg 1 (T1F18) and Direction of leg 2 (T1F19), respectively; (ii) Other payment type (T2F73) was populated with ‘UFRO’; and (iii) Other payment payer (T2F77) is the same as Counterparty 1 (T1F4). The upfront payment amount should be expressed in terms of amount and in the reported ‘Other payment currency’ (T2F75). x) Seller-Side Upfront payment (receiver): Aggregation of upfront payment values in field ‘Other payment amount’ (T2F74) for all derivatives pertaining to a position based on the following conditions: (i) Counterparty 1 (T1F4) has either reported ‘SLLR’ in the field Direction (T1F17), or has reported ‘MAKE’ and ‘TAKE’ in the fields Direction of leg 1 (T1F18) and Direction of leg 2 (T1F19), respectively; (ii) Other payment type (T2F73) was populated with ‘UFRO’; and (iii) Other payment receiver (T2F78) is the same as Counterparty 1 (T1F4). The upfront payment amount should be expressed in terms of amount and in the reported ‘Other payment currency’ (T2F75). y) Buyer-Side Unwind or Full termination (payer): Aggregation of unwind or full termination values in field ‘Other payment amount’ (T2F74) for all derivatives pertaining to a position set based on the following conditions: (i) Counterparty 1 (T1F4) has either reported ‘BYER’ in the field Direction (T1F17), or has reported ‘TAKE’ and ‘MAKE’ in the fields Direction of leg 1 (T1F18) and Direction of leg 2 (T1F19), respectively; (ii) Other payment type (T2F73) was populated with ‘UWIN’; and (iii) Other payment payer (T2F77) is the same as Counterparty 1 (T1F4). The unwind or full termination amount should be expressed in terms of amount and in the reported ‘Other payment currency’ (T2F75). z) Buyer-Side Unwind or Full termination (receiver): Aggregation of unwind or full termination values in field ‘Other payment amount’ (T2F74) for all derivatives pertaining to a position set based on the following conditions: (i) Counterparty 1 (T1F4) has either reported ‘BYER’ in the field Direction (T1F17), or has reported ‘TAKE’ and ‘MAKE’ in the fields Direction of leg 1 (T1F18) and Direction of leg 2 (T1F19), respectively; (ii) Other payment type (T2F73) was populated with ‘UWIN’; and (iii) Other payment receiver (T2F78) is the same as Counterparty 1
(T1F4). The

unwind or full termination amount should be expressed in terms of amount and in the reported ‘Other payment currency’ (T2F75). aa) Seller-Side Unwind or Full termination (payer): Aggregation of unwind or full termination values in field ‘Other payment amount’ (T2F74) for all derivatives pertaining to a position set based on the following conditions: (i) Counterparty 1 (T1F4) has either reported ‘SLLR’ in the field Direction (T1F17), or has reported ‘MAKE’ and ‘TAKE’ in the fields Direction of leg 1 (T1F18) and Direction of leg 2 (T1F19), respectively; (ii) Other payment type (T2F73) was populated with ‘UWIN’; and (iii) Other payment payer (T2F77) is the same as Counterparty 1 (T1F4). The unwind or full termination amount should be expressed in terms of amount and in the reported ‘Other payment currency’ (T2F75). bb) Seller-Side Unwind or Full termination (receiver): Aggregation of unwind or full termination values in field ‘Other payment amount’ (T2F74) for all derivatives pertaining to a position set based on the following conditions: (i) Counterparty 1 (T1F4) has either reported ‘SLLR’ in the field Direction (T1F17), or has reported ‘MAKE’ and ‘TAKE’ in the fields Direction of leg 1 (T1F18) and Direction of leg 2 (T1F19), respectively; (ii) Other payment type (T2F73) was populated with ‘UWIN’; and (iii) Other payment receiver (T2F78) is the same as Counterparty 1 (T1F4). The unwind or full termination amount should be expressed in terms of amount and in the reported ‘Other payment currency’ (T2F75). cc) Buyer-Side Principal exchange (payer): Aggregation of principal exchange values in field ‘Other payment amount’ (T2F74) for all derivatives pertaining to a position set based on the following conditions: (i) Counterparty 1 (T1F4) has either reported ‘BYER’ in the field Direction (T1F17), or has reported ‘TAKE’ and ‘MAKE’ in the fields Direction of leg 1 (T1F18) and Direction of leg 2 (T1F19), respectively; (ii) Other payment type (T2F73) was populated with ‘PEXH’; and (iii) Other payment payer (T2F77) is the same as Counterparty 1 (T1F4). The principal exchange amount should be expressed in terms of amount and in the reported ‘Other payment currency’ (T2F75). dd) Buyer-Side Principal exchange (receiver): Aggregation of principal exchange values in field ‘Other payment amount’ (T2F74) for all derivatives pertaining to a position set based on the following conditions: (i) Counterparty 1 (T1F4) has either reported ‘BYER’ in the field Direction (T1F17), or has reported ‘TAKE’ and ‘MAKE’ in the fields Direction of leg 1 (T1F18) and Direction of leg 2 (T1F19), respectively; (ii) Other payment type (T2F73) was populated with ‘PEXH’; and (iii) Other payment receiver (T2F78) is the same as Counterparty 1 (T1F4). The principal exchange amount should be expressed in terms of amount and in the reported ‘Other payment currency’ (T2F75).

ee) Seller-Side Principal exchange (payer): Aggregation of principal exchange values in field ‘Other payment amount’ (T2F74) for all derivatives pertaining to a position set based on the following conditions: (i) Counterparty 1 (T1F4) has either reported ‘SLLR’ in the field Direction (T1F17), or has reported ‘MAKE’ and ‘TAKE’ in the fields Direction of leg 1 (T1F18) and Direction of leg 2 (T1F19), respectively; (ii) Other payment type (T2F73) was populated with ‘PEXH’; and (iii) Other payment payer (T2F77) is the same as Counterparty 1 (T1F4). The principal exchange amount should be expressed in terms of amount and in the reported ‘Other payment currency’ (T2F75). ff) Seller-Side Principal exchange (receiver): Aggregation of principal exchange values in field ‘Other payment amount’ (T2F74) for all derivatives pertaining to a position set based on the following conditions: (i) Counterparty 1 (T1F4) has either reported ‘SLLR’ in the field Direction (T1F17), or has reported ‘MAKE’ and ‘TAKE’ in the fields Direction of leg 1 (T1F18) and Direction of leg 2 (T1F19), respectively; (i) Other payment type (T2F73) was populated with ‘PEXH’; and (iii) Other payment receiver (T2F78) is the same as Counterparty 1 (T1F4). The principal exchange amount should be expressed in terms of amount and in the reported ‘Other payment currency’ (T2F75). TRs should use the metrics listed in Guideline 19 to aggregate currency positions which should be made available to the central bank issuing that currency. The following metrics should be used to quantify all Collateral Position Sets and Currency Collateral Position Sets. When outliers are removed from the position the calculation should be referred to as ‘clean’, if outliers are included the position should be referred to as ‘total’:
a) Number of reports used for calculating the Set; b) Initial margin posted by the counterparty 1 (pre-haircut) (T3F12); c) Initial margin posted by the counterparty 1 (post-haircut) (T3F13); d) Variation margin posted by the counterparty 1 (pre-haircut) (T3F15); e) Variation margin posted by the counterparty 1 (post-haircut) (T3F16); f) Initial margin collected by the counterparty 1 (pre-haircut) (T3F20); g) Initial margin collected by the counterparty 1 (post-haircut) (T3F21); h) Variation margin collected by the counterparty 1 (pre-haircut) (T3F23) i) Total variation margin collected by the counterparty 1 (post-haircut) (T3F24);

j) Excess collateral posted by the counterparty 1 (T3F18); k) Excess collateral collected by the counterparty 1 (T3F26). When collateralisation is performed on a portfolio basis and derivatives share a collateral portfolio code (T3F9), TRs should use the collateral values listed in Guideline 21 across the derivatives which share the same code, as the value of that collateral portfolio for the purpose of the Collateral Position Set. When collateralisation is not performed on a portfolio basis, the variables that represent the value of the collateral only apply to an individual derivative and so where possible TRs should provide an aggregation of those collateral positions based on the Metrics listed in Guideline 21. All derivatives reported to TRs should be aggregated with derivatives with identical entries in the following fields representing dimensions of the derivatives grouped together in position sets to specify counterparties to derivatives:
a) Counterparty 1 (T1F4) b) Counterparty 2 (T1F9); c) Valuation currency (T2F22); d) Collateralisation category (T3F11); e) Collateral Portfolio code (T2F27 / T3F9) if applicable; f) Contract type (T2F10); g) Asset class (T2F11); h) Underlying identification type (T2F13) if applicable; i) Underlying identification (T2F14) if applicable; j) Notional Currency 1 (T2F56); k) Notional Currency 2 (T2F65) if applicable; l) Settlement currency 1 (T2F19) m) Settlement currency 2 (T2F20) if applicable; n) Master Agreement Type (T2F34);

o) Master Agreement Version (T2F36); p) Cleared (T2F31); q) Intragroup (T2F37) r) Exchange Rate basis (T2F115) when applicable; s) Option type (T2F132), when applicable. TRs should use the following buckets to aggregate derivatives with similar values for ‘Time to Maturity’. Time to Maturity should be calculated as the difference between a derivative’s expiration date (T2F44) and the reference date, based on a Gregorian calendar. Difference between ‘Expiration date’ (T2F44) and reference date Value of Time to maturity One month or less ‘T01_00M_01M’ More than one month but no more than three months (inclusive) ‘T02_01M_03M’ More than three months but less than six months (inclusive) ‘T03_03M_06M’ More than six months but less than nine months (inclusive) ‘T04_06M_09M’ More than nine months but less than 12 months (inclusive) ‘T05_09M_12M’ More than twelve months but less than 2 years (inclusive) ‘T06_01Y_02Y’ More than 24 months but less than 3 years (inclusive) ‘T07_02Y_03Y’ More than 36 months but less than 4 years (inclusive) ‘T08_03Y_04Y’ More than 48 months but less than 5 years (inclusive) ‘T09_04Y_05Y’ More than 5 years but less than 10 years (inclusive) ‘T10_05Y_10Y’ More than 10 years but less than 15 years (inclusive) ‘T11_10Y_15Y’ More than 15 years but less than 20 years (inclusive) ‘T12_15Y_20Y’

More than 20 years but less than 30 years (inclusive) ‘T13_20Y_30Y’ More than 30 years but less than 50 years (inclusive) ‘T14_30Y_50Y’ More than 50 years ‘T15_50Y_XXY’ Expiration date is blank (open ended contract) ‘T16_BL’ Expiration date is NA ‘T17_NA’ In the event that a derivative has an expiration date (T2F44) which does not exist in the month of the reference date (i.e. 29, 30, 31 month dependent), the decision for which maturity bucket that derivative should be included in, should be made by treating that derivative in the same way as if the calculation were being made on the expiration date (T2F44) for the month of the reference date. For example, if a derivative calculation has a reference date of 31 January and the derivative expires on 28 February, that derivative should be included in the ‘One month or less’ maturity bucket. If a reference date is on 31 January and the expiration date (T2F44) is 1 March, then that derivative should be included in the ‘More than one month but no more than three months’ maturity bucket. If a calculation’s reference date is on 30 April, and the derivative matures on 31 May then that derivative should be included in the ‘One month or less’ maturity bucket. IRS derivatives should also be grouped together according to their type. With reference to whether Leg 1 and Leg 2 are fixed or floating, the below table explains how ‘type of IRS’ should be discerned and how IRS derivatives should be grouped:
Fixed rate of leg 1 or coupon
(T2F79)
Fixed rate of leg 2
(T2F95)
Indicator of the floating rate of leg
1 (T2F84)
Indicator of the floating rate of leg
2 (T2F100)
Value of variable
Type of IRS10
P B B P FIX-FLOAT
10 When Fixed rate of leg 1 or coupon (T2F79) is populated and Indicator of the floating rate of leg 2 (T2F100) is populated with value “EURI”, the variable Type of IRS should be populated with “FIX-EURI”. When floating legs are not populated, but Fixed rate of leg 1 or coupon (T2F79) and Fixed rate of leg 2 (T2F95) are, then the variable Type of IRS should be populated with “FIX-FIX”. When fixed legs are not populated but Indicator of the Floating rate of leg 1 (T2F84) the value “LIBO” is provided and in the Indicator of the Floating rate of leg 2 (T2F100) the value “EURI” is provided, the variable Type of IRS will be populated with the value “EURI_LIBO”.

B P P B FIX-FLOAT
P P B B FIX-FIX
B B P P BASIS
For credit derivatives, TRs should use the following dimensions to group together derivatives for Position Sets and Currency Position Sets in addition to those dimensions referred to from Guideline 24 to Guideline 26:
a) Seniority (T2F143) when reference entity is populated in field Reference entity (T2F144); b) Tranche (T2F148) when ‘X’ is populated in field Underlying identification type (T2F13). For commodity derivatives, a TR should aggregate metrics for classes of commodity derivatives in accordance with the dimensions referred to in Guideline 24 to Guideline 26 of this paper as per each of the following details reported in field Base product (T2F116), Sub-product (T2F117), and field Further sub-product (T2F118) as defined in Table 4 ‘Classification of commodities’ of the ITS on reporting11 . TRs should use the below dimensions to group together derivatives using the same collateral as a Collateral Position Set:
a) Counterparty 1 (T1F4 / T3F4); b) Counterparty 2 (T1F9 / T3F6); c) Collateralisation category (T3F11); d) Collateral portfolio indicator (T3F8); e) Currency of the initial margin posted (T3F14); f) Currency of the variation margin posted (T3F17); 11 Commission Implementing Regulation (EU) No 2022/1860 of 10 June 2022 laying down implementing technical standards for the application of Regulation (EU) No 648/2012 of the European Parliament and of the Council on OTC derivatives, central counterparties and trade repositories, with regard to the standards, formats, frequency and methods and arrangements for reporting and repealing Implementing Regulation (EU) No 1247/2012.

g) Currency of the initial margin collected (T3F22); h) Currency of variation margin collected (T3F25); i) Currency of the excess collateral posted (T3F19), if applicable; j) Currency of excess collateral collected (T3F27), if applicable. TRs should determine the relevant Currency Position Sets for authorities where the counterparties have reported the currency of issue of that authority for one of the below dimensions. a) Notional Currency 1 (T2F56); or b) Notional Currency 2 (T2F65); or c) Settlement currency 1 (T2F19); or d) Settlement currency 2 (T2F20). TRs should provide a Currency Position Set to authorities determined in accordance with Guideline 31 and based upon all the dimensions included from Guideline 24 through to Guideline 26. Guideline 27, Guideline 28, and Guideline 29 should also be applied to Currency Position Sets when appropriate. TRs should aggregate the collateral pertaining to the Currency Position Sets determined in accordance with Guideline 31 and using the dimensions referred to in Guideline 30.