EMIRR 2.1 Verification of derivatives by trade repositories

EMIRR 2.1.1 R

1A trade repository shall verify all of the following in a received derivative:

  1. (1)

    the identity of the report submitting entity as referred to in field 2 of Table 1 and field 2 of Table 3 of the Annex to the EMIR Technical Standards on the Standards, Formats, Frequency and Methods and Arrangements for Reporting 2023;

  2. (2)

    that the XML template complies with the ISO 20022 methodology referred to in Article 2 of the EMIR Technical Standards on the Standards, Formats, Frequency and Methods and Arrangements for Reporting 2023 is used to report the derivative;

  3. (3)

    that the report submitting entity, if different from the entity responsible for reporting as referred to in field 3 of Table 1 and field 3 in Table 3 of the Annex to the EMIR Technical Standards on the Standards, Formats, Frequency and Methods and Arrangements for Reporting 2023, is duly authorised to report on behalf of the Counterparty 1 or entity responsible for reporting, if different from Counterparty 1, as referred to in field 4 of Table 1 and field 4 in Table 3 of the Annex to the EMIR Technical Standards on the Standards, Formats, Frequency and Methods and Arrangements for Reporting 2023;

  4. (4)

    that the same derivative has not been submitted previously;

  5. (5)

    that a derivative report with action type ‘Modification’, ‘Margin Update’, ‘Valuation’, ‘Correction’, ‘Error’ or ‘Terminate’ relates to a previously submitted derivative;

  6. (6)

    that a derivative report with action type ‘Modification’ does not relate to a derivative that has been reported as cancelled with action type ‘Error’ and which has not been subsequently reported with action type ‘Revive’;

  7. (7)

    that a derivative report does not include the action type ‘New’ in respect of a derivative that has previously been reported;

  8. (8)

    that a derivative report does not include the action type ‘Position component’ in respect of a derivative that has previously been reported;

  9. (9)

    that a derivative report does not purport to modify the details of fields ‘Counterparty 1’ or ‘Counterparty 2’ to a previously reported derivative;

  10. (10)

    that a derivative report does not purport to modify an existing derivative by specifying an effective date later than the reported maturity date of the derivative;

  11. (11)

    that a derivative reported with action type ‘Revive’ relates to a previously submitted derivative report with action type ‘Error’ or ‘Terminate’ or to a derivative that has matured; and

  12. (12)

    the correctness and completeness of the derivative report.

EMIRR 2.1.2 R

1A trade repository shall reject a derivative report that does not comply with one of the requirements set out in EMIRR 2.1.1R and assign to it one of the rejection categories set out in the following table:

Rejection categories

Reason

Schema

the derivative has been rejected, because of non-compliant schema.

Permission

the derivative has been rejected because the report submitting entity is not permissioned to report on behalf of the reporting counterparty or the entity responsible for reporting.

Logical

the derivative has been rejected because the action type for the derivative is not logically correct.

Business

the derivative is rejected because the derivative does not comply with one or more content validations.

EMIRR 2.1.3 R

1A trade repository shall provide the report submitting entities with detailed information on the results of the data verification referred to in EMIRR 2.1.1R within 60 minutes of receiving a derivative report. A trade repository shall provide the results in an XML format and a template developed in accordance with the ISO 20022 methodology. The results shall include the specific reasons for the rejection of a derivative report in accordance with the table in EMIRR 2.1.2R.

EMIRR 2.2 Procedure for updates of the LEIs

EMIRR 2.2.1 R

1A trade repository to which a request under Article 9 of the EMIR Technical Standards on the Standards, Formats, Frequency and Methods and Arrangements for Reporting 2023 is addressed shall identify the derivatives referred to in points (a) and (b) of Article 3(2) of the technical standards at the time of the corporate restructuring event where the entity is reported with the old identifier in the field ‘Counterparty 1’ or ‘Counterparty 2’, as informed in the relevant request, and shall replace the old identifier with the new LEI in the reports relating to all those derivatives at the time of the event referred to in Article 9 of the technical standards pertaining to that counterparty. A trade repository shall perform the procedure on the update of the identifier at the latest on the day of restructuring or within 30 calendar days as of receipt of the request if reported less than 30 calendar days prior to the date of the corporate restructuring event.

EMIRR 2.2.2 R

1A trade repository shall identify the relevant derivatives referred to in points (a) and (b) of Article 3(2) of the EMIR Technical Standards on the Standards, Formats, Frequency and Methods and Arrangements for Reporting 2023 at the time of the corporate restructuring event where the entity is identified with the old identifier in any of the fields and replace that identifier with the new LEI. Where a corporate restructuring event relates to an update of the LEI for fields other than ‘Counterparty 1’ or ‘Counterparty 2’, the trade repository shall perform such an update of the relevant derivatives only following a timely confirmation by the Counterparty 1 or the entity responsible for reporting.

EMIRR 2.2.3 R

1A trade repository shall carry out the following actions:

  1. (1)

    Following the receipt of the relevant confirmation under EMIRR 2.2.2R, implement the change as of the date referred to in EMIRR 2.2.1R.

  2. (2)

    Broadcast the following information at the earliest possibility and no later than 5 working days after the complete notification is received to all the other trade repositories and to the relevant reporting counterparties, report submitting entities, entities responsible for reporting, as well as third parties which have been granted access to information under Article 78(7) of Regulation (EU) No 648/2012, as applicable, involved in the derivatives contracts concerned by the LEI change:

    1. (a)

      old identifier(s);

    2. (b)

      the new identifier;

    3. (c)

      the date by which the change shall be done; and

    4. (d)

      in the case of corporate events affecting a subset of the derivatives outstanding at the date of the event, the list of the UTIs of the derivatives concerned by the LEI change.

  3. (3)

    Notify, at the latest the working day before the date on which the change is applied, the entities listed in Article 81(3) of Regulation (EU) No 648/2012 that have access to the data relating to the derivatives that have been updated, through a specific file in machine readable format, including:

    1. (a)

      old identifier(s);

    2. (b)

      the new identifier;

    3. (c)

      the date by which the change shall be done; and

    4. (d)

      in the case of corporate events affecting a subset of the derivatives outstanding at the date of the event, the list of the UTIs of the derivatives concerned by the LEI change.

  4. (4)

    Record the change in the reporting log.

EMIRR 2.2.4 R

1A trade repository shall not update the LEIs reported for derivatives different from those referred to in points (a) and (b) of Article 3(2) of the EMIR Technical Standards on the Standards, Formats, Frequency and Methods and Arrangements for Reporting 2023 at the time of the corporate event.

EMIRR 2.3 Reconciliation of data by trade repositories

EMIRR 2.3.1 R

1A trade repository shall seek to reconcile a reported derivative by undertaking the steps set out in EMIRR 2.3.3R, provided that all of the following conditions are met:

  1. (1)

    the trade repository has completed the verifications set out in EMIRR 2.1.1R and EMIRR 2.1.2R;

  2. (2)

    both counterparties to the reported derivative have a reporting obligation; and

  3. (3)

    the trade repository has not received a report with the action type ‘Error’ in respect of the reported derivative, unless it has been followed by a report with action type ‘Revive’.

EMIRR 2.3.2 R

1A trade repository shall have arrangements in place to ensure the confidentiality of the data exchanged with other trade repositories and when providing information to reporting counterparties, report submitting entities, entities responsible for reporting as well as third parties which have been granted access to information under Article 78(7) of Regulation (EU) No 648/2012 about the values for all the fields that are subject to reconciliation.

EMIRR 2.3.3 R

1Where all the conditions of EMIRR 2.3.1R are met, a trade repository shall undertake the following steps, while using the latest reported value for each of the fields in Tables 1 and 2 of the Annex to the EMIR Technical Standards on the Standards, Formats, Frequency and Methods and Arrangements for Reporting 2023 as of the previous working day:

  1. (1)

    a trade repository that has received a derivative report shall verify whether it has received a corresponding report from or on behalf of the other counterparty;

  2. (2)

    a trade repository that has not received a corresponding derivative report, as referred to in EMIRR 2.3.3(1), shall attempt to identify the trade repository that has received the corresponding derivative report by communicating to all registered trade repositories the values of the following fields of the reported derivative: ‘Unique Transaction Identifier’, ‘Counterparty 1’ and ‘Counterparty 2’;

  3. (3)

    a trade repository that determines that another trade repository has received a corresponding derivative report, as referred to in EMIRR 2.3.3 (1), shall exchange with that trade repository the details of the reported derivative in an XML format and a template developed in accordance with the ISO 20022 methodology;

  4. (4)

    a trade repository shall treat a reported derivative as reconciled where the details of the derivative subject to reconciliation substantially match the details of the corresponding derivative, as referred to in EMIRR 2.3.3(1);

  5. (5)

    a trade repository shall subsequently assign values for the reconciliation categories for each reported derivatives transaction, as set out in the table in EMIRR 2.3.3AR;

  6. (6)

    a trade repository shall conclude the steps in EMIRR 2.3.3 (1) to (5) at the earliest opportunity and shall take no such steps after midnight Coordinated Universal Time on a given working day; and

  7. (7)

    a trade repository that cannot reconcile a reported derivative shall seek to match the details of that reported derivative on the following working day. The trade repository shall no longer seek to reconcile the reported derivative 30 calendar days after the derivative is not outstanding.

EMIRR 2.3.3A R

1Trade repositories shall use the following table for the purposes of EMIRR 2.3.3R(5).

Table of Values for Reconciliation categories

Reconciliation categories

Allowable values

Reporting requirement for both counterparties

Yes/No

Reporting type

Single-sided/dual-sided

Pairing

Paired/unpaired

Reconciliation

Reconciled/not reconciled

Valuation reconciliation

Reconciled/not reconciled

Revived

Yes/No

Further modifications:

Yes/No

EMIRR 2.3.4 R

1A trade repository shall confirm the total number of paired and reconciled derivatives with each trade repository with which it has reconciled derivatives at the end of each working day. A trade repository shall put in place written procedures for ensuring the resolution of all discrepancies identified in this process.

EMIRR 2.3.5 R

1No later than 60 minutes after the conclusion of the reconciliation process as set out in EMIRR 2.3.3R(6), a trade repository shall provide the report submitting entities, with the results of the reconciliation process performed by it on the reported derivatives. A trade repository shall provide the results in an XML format and a template developed in accordance with the ISO 20022 methodology, including information on the fields that have not been reconciled.

EMIRR 2.4 End-of-day response mechanisms

EMIRR 2.4.1 R

1For each working day, a trade repository shall make available to the reporting counterparties, report submitting entities, entities responsible for reporting and third parties which have been granted access to information under Article 78(7) of Regulation (EU) No 648/2012, as applicable, the following information on the relevant derivatives in an XML format and a template developed in accordance with the ISO 20022 methodology:

  1. (1)

    the derivatives reported during that day;

  2. (2)

    the latest trade states of the outstanding derivatives;

  3. (3)

    the derivative reports that have been rejected during that day;

  4. (4)

    the reconciliation status of all reported derivatives subject to reconciliation pursuant to EMIRR 2.3.1R;

  5. (5)

    the outstanding derivatives for which no valuation has been reported or the valuation that was reported is dated more than 14 calendar days from the day for which the report is generated;

  6. (6)

    the outstanding derivatives for which no margin information has been reported or the margin information that was reported is dated more than 14 calendar days from the day for which the report is generated; and

  7. (7)

    the derivatives that were received on that day with action type ‘New’, ‘Position component’, ‘Modification’ or ‘Correction’ whose notional amount is greater than a threshold for that class of derivatives.

EMIRR 2.4.2 R

1A trade repository shall provide such information no later than 09:00 Coordinated Universal Time on the following working day to which the information provided in EMIRR 2.4.1R refers to.