UK EMIR Trade Repositories: draft questions and answers

Yes. TRs should include both the old and new formats of derivative reports in the open TSR that are submitted to us.

If a record cannot be included due to an optional block failing the schema, TRs should report that record but exclude the optional block data on the record that is failing. For records that fail the schema due to a mandatory block failing to be schema valid, that record should be removed from the report in full.

TRs should include the end of day position of all open trades they have received each day in the TSRs they generate for authorities. The reports should include all trades submitted to the TR on T and T+1. We recognise this may impact the reconciliation process and the feedback that TRs must provide to report submitting entities. However, this approach is necessary to ensure UK authorities have direct and immediate access to TR data to better support our market monitoring objectives, especially in times of market volatility. The UK EMIR Reporting Q&As (Q2.2) provides detail on how reconciliations should be conducted.

TRs should consider lifecycle events based on the order derived from the fields Event date (Table 2, Item 153), Action type (Table 2, Item 151) and Event type (Table 2, Item 152). TRs should update the TSR based on the latest information for a given derivative in the Event date field.

Where valuation and margin reports have the same event date, TRs should refer to the Valuation timestamp (Table 2, Item 23) and Collateral timestamp (Table 3, Item 7) fields respectively. If these fields are populated with the same values, TRs should use the submission timestamp to the TR as a last resort to order reports.

Where a derivative has multiple lifecycle events for a given event date, TRs should use the Event timestamp field that is available in the ISO 20022 XML to determine the latest lifecycle event.

TRs must publish aggregate data in order to comply with Article 1 of Technical Standards 151/2013. During the 6-month transition period, TRs should publish a single version of the aggregated data that incorporates both the current UK EMIR reporting format and the updated UK EMIR reporting format which complies with the new requirements. Following the end of the transition period, TRs should publish a single set of aggregate data based on the uplifted reporting format only.

Rejection feedback should be provided by means of an immediate rejection response within 60 minutes after the receipt of data and also by means of end-of-day reports made available by 09:00 UTC the following working day. Files can be considered as received by the TR from the moment the submitted file enters the system of the TR.

We have published additional information on error codes, their corresponding underlying issues, and the content of rejections reports in the UK EMIR Validation Rules (applicable from 30 September 2024) and Outgoing message XML schemas (applicable from 30 September 2024). These are available on our EMIR reporting obligation webpage. We consider the information they contain to be sufficient for industry to successfully interpret the rejection messages they will receive.

During the transition period, TRs should use the relaxed schema (RELAXEDauth.091.001.02_FCAUG_DATREC_1.0.0) as the inter-TR reconciliation process will contain both reports that have been uplifted to the new reporting format as well as reports that have not yet been updated. After the end of the transition period, TRs should use the strict schema (auth.091.001.02_FCAUG_DATREC_1.0.0) for the inter-TR reconciliations process.

TRs should use the value reported in the Reporting obligation of the counterparty 2 field (Table 1, Item 14) to identify whether counterparty 2 has a reporting obligation, and whether reports at trade and position level are subject to reconciliation. TRs will not be expected to validate the country of the counterparty identified in the Reporting obligation of the counterparty 2 field (Table 1, Item 14). If the Reporting obligation of the counterparty 2 field is blank, TRs should refer to the Country of the counterparty 2 field (Table 1, Item 10).

If a derivative report is already reconciled and the headquarters of one of the counterparties is moved from the UK to a third country, we expect the report will be updated to reflect its new status as a single-sided, unpaired report.

TRs must provide reconciliations feedback to report submitting entities with the results of the reconciliation process performed by it on the reported derivatives no later than 60 minutes after the conclusion of the reconciliation process, as set out in Section 2.3 of the EMIRR Sourcebook. This feedback must be 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.

However, in addition to XML format, TRs may also send reports in other formats should they want to do so, or if reporting counterparties request it.

TRs should refer to Section 2.3.3.A R of the EMIRR Sourcebook for a table of reconciliation categories and allowable values. Where a derivative becomes unmatched due to an issue, such as the reporting timestamp moving to another time period block on the schedule, TRs should provide feedback with a reconciliation category of ‘Further Modifications’ and a value of ‘FALSE’ to indicate that there has been a change, but not necessarily as a result of a modification.

In both scenarios, our expectation is that TRs ensure that the latest version of the TSR, in the updated reporting format, is accurate and that historic Trade Activity Reports (TARs) are submitted to the Authorities. We do not expect TRs to resubmit all affected historic TSRs to the Authorities.

TRs should not purge or remove stale valuations from the TSR when a counterparty moves from NFC+ to NFC-. Our expectation is that TRs would retain the reported valuations in the TSR, but do not need to account for whether the valuations for affected records have not been reported for at least 14 days (‘stale’ valuation).

See Q&A 1.2 (Transitional Arrangements).

We expect TRs to proactively engage with us if they hold a significant proportion of trades that cannot be uplifted to the new reporting format.

For reporting counterparties to comply with their reporting obligations under Article 9, our expectation is that TRs should port the latest trade state for all trades relating to the reporting counterparty, including historical trades closed prior to the date of porting. This approach will only apply to trades closed after 30 September 2024. Trades closed prior to this date would not be required to be ported to a new TR.

TRs should port data using the schemas listed below, as only reports in the uplifted formats will be able to be ported to a new TR.

Withdrawal scenario

• auth.107.001.01_FCAUG_DATTSR_1.0.0,
• auth.109.001.01_FCAUG_DATMDS_1.0.0,
• auth.091.001.02_FCAUG_DATREC_1.0.0,
• auth.092.001.03_FCAUG_DATREJ_1.0.0,
• auth.106.001.01_FCAUG_DATWRN_1.0.0

Voluntary porting

• auth.107.001.01_FCAUG_DATTSR_1.0.0,
• auth.109.001.01_FCAUG_DATMDS_1.0.0

TRs must always comply with Article 80 of UK EMIR and ensure the confidentiality, integrity and protection of the information received under Article 9. They must also comply with the conditions of Section 2.3.2R of the EMIRR Sourcebook. Article 18 of CDR (EU) 150/2013 details that TRs must have policies and procedures which determine the rights and obligations of the different types of users in relation to the information maintained by the trade repository, and that these must be specific to a range of users as listed in the regulation.

TRs should follow the current process for the termination of dead trades. We recognise that, under the revised UK EMIR reporting framework, it may no longer be possible to uplift these trades to the new reporting standard. We will monitor the extent to which this issue occurs and may issue further guidance on how to terminate dead trades in the future.

Questions

a) What does 'complete notification' refer to and include? 

b) When does the 5 working day requirement to broadcast details of the LEI update to other trade repositories and relevant reporting counterparties, report submitting entities, entities responsible for reporting, and third parties begin?  

c) How should a TR deal with a client submitting a complete notification but also asking for the broadcast to be delayed? 

d) What is the process for mergers relating to the LEI of the Entity Responsible for Reporting?  

Answer

We expect TRs to comply with the requirements detailed in Section 2.2 of the EMIRR Sourcebook, which details the procedure for updating LEIs. With regard to the specific questions we’ve received on the process for dealing with corporate action notifications:  

a) A complete corporate action notification should include:  

• (i) the LEI(s) of the entities participating in the merger, acquisition, or other corporate event
• (ii) the LEI of the new entity
• (iii) the date on which the change takes place   
• (iv) the UTIs of the outstanding derivatives concerned 
• (v) evidence or proof that the corporate event has taken or will take place 

b) We do not intend to specify the timeframe in which TRs should complete the underlying steps of verifying the information received in a corporate action notification, as we recognise that notifications can be received at different times of day such as outside of working hours or require different levels of resource to verify before actioning.   

c) TRs should comply with the legislative requirements detailed in EMIRR 2.2.3R to broadcast the information received at the earliest possibility, and no later than 5 working days after the complete notification is received.  

d) As detailed in EMIRR 2.2.2R, where a corporate restructuring event relates to an update of the LEI for fields other than Counterparty 1 (Table 1, Item 4) or Counterparty 2 (Table 1, Item 9), 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. Corporate actions that affect the LEI of the Entity Responsible for Reporting should be treated in accordance with the rules detailed in EMIRR 2.2. Changes to the Entity Responsible for Reporting will result in changes to the Entity Responsible for Reporting field (Table 1, Item 3) of outstanding records and changes to the entity with a legal obligation to report details of derivative contracts to UK registered TRs. TRs should therefore undertake the same level of due diligence for such corporate actions to ensure that the details of derivative contracts are amended accurately. 

TRs should populate this tag with a default value of ‘2014-02-12:00:00:00’ in instances where margin has not been reported.

TRs have identified that, where business validations include ‘at the time of the conclusion of the derivative’, this introduces complexities to implementing validation rule logic as it requires TRs to refer to lists of regulated markets and third country markets considered equivalent to regulated markets, as well as the authorisation start and end dates for those markets. Based on the feedback received, we have removed ‘at the time of the conclusion of the derivative’ from the validation logic and have included this change to the UK EMIR Validation Rules (applicable from 30 September 2024) in the consultation published on 1 March 2024.

This change requires TRs to validate the MIC code based on the regulated markets and third country markets considered equivalent to regulated markets at the time of validating the record.

Our understanding of the issue is that there may be instances where some components of a collateral portfolio meet the conditions for certain fields to be reported, but other components do not. We expect reporting firms to populate these fields if they apply to all or part of a portfolio.

In instances where multiple submissions could be made for such fields, we would expect reporting firms to report the details that apply to the most significant proportion of the portfolio. TRs should validate these fields based on if at least one derivative within the portfolio meets the conditions for the field to be reported.

500,000. It was highlighted to us that the above schemas had a limit to the number of <Rpt> tags that could be reported of 100,000. We have amended the number of <Rpt> tags for these schemas to 500,000 in line with the other reports we receive from TRs (Auth.091, Auth.092, and Auth.106).

These fields all exist in the XML schema. While there are not specific validation rule rows for these fields, they are all captured within the validations for the Execution Agent field. There is guidance around how to populate these fields in the 'Changes' tab of the UK EMIR Validation Rules (applicable from 30 September 2024).

We recognise that the inability to include details of the Execution Agent in these message types may impact the ability of TRs to share details of affected reports with executing entities. We intend to address this issue after the introduction of the new reporting requirements. In the interim, we encourage affected parties to engage with their TR, entities responsible for reporting, and reporting counterparties to consider any reasonable steps that could be taken to ensure the accuracy of their reporting whilst this issue persists.

In the case of post-trade risk reduction (PTRR) event with a PTRR service provider or CCP providing the PTRR service, the counterparty should report a unique code identifying this event as provided by that PTRR service provider or CCP within all the reports pertaining to the derivatives that were either terminated due to or result from that event.

The UK EMIR Validation Rules (applicable from 30 September) state that if the Base Product field (Table 2, Item 116) is populated with ‘PAPR’ then there should be an option to populate the Sub-Product field (Table 2, Item 117) with ‘RCVP’, but the schema does not allow for this. We intend to amend this in the schema in the future, but in the interim, the Sub-product field should be reported as ‘OTHR’ in this circumstance.

TRs should follow their current procedures when sourcing reference data to validate these fields under the new requirements.

TRs highlighted a potential contradiction between two elements of the validation rule for this field. The UK EMIR Validation Rules state that:  

• When populated, this field shall contain up to 25 numeric characters including up to 5 decimal places. The decimal mark is not counted as a numeric character. If populated, it shall be represented by a dot. 
• Any value between -1 and 1 (including -1 and 1) is allowed. The negative symbol, if populated, shall not be counted as a numerical character. 

It is not clear to us where the contradiction exits. A reported value can be between 1 and -1, with up to 5 decimal places, and within the 25 numeric character limit for this field.

In the latest version of the schema, we can see the /Sgn tag is included for these fields. The ‘sign’ field is an optional element when the price is expressed as a monetary amount. This aligns with the policy description of the format of this field, ’[...] The negative symbol, if populated, is not counted as a numeric character’.

In the ‘changes’ worksheet in the file ‘UK EMIR Validation Rules V1.0’, we have not included any change to remove the signage, as we do not consider that this issue should result in a schema error.