EMIRR 2.1 Verification of derivatives by trade repositories
1A trade repository shall verify all of the following in a received derivative:
- (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)
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)
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)
that the same derivative has not been submitted previously;
- (5)
that a derivative report with action type ‘Modification’, ‘Margin Update’, ‘Valuation’, ‘Correction’, ‘Error’ or ‘Terminate’ relates to a previously submitted derivative;
- (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)
that a derivative report does not include the action type ‘New’ in respect of a derivative that has previously been reported;
- (8)
that a derivative report does not include the action type ‘Position component’ in respect of a derivative that has previously been reported;
- (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)
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)
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)
the correctness and completeness of the derivative report.
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. |
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.