Consultation opened
04/09/2024
Consultation closed
25/09/2024
25/09/2024
We sought feedback on our guidance for UK Trade Repositories registered under Article 55 of UK EMIR ahead of the implementation of the new requirements.
On 24 February 2023, we published a joint Policy Statement (PS23/2[1]) with the Bank of England (the Bank) confirming changes to the derivative reporting framework[2] under UK EMIR. The majority of the new requirements are applicable from 30 September 2024, with a transition period for some aspects.
We received requests for guidance from UK Trade Repositories (TRs) that were specific to TR operations or how to validate certain fields in industry submitted reports. In response, we consulted on guidance to support TRs in the implementation of the updated UK EMIR reporting requirements that apply from 30 September 2024. This guidance is in the form of questions and answers (Q&As).
The consultation for these Q&As closed on 25 September 2024.
Feedback that we received will be incorporated into the final guidance, which will be made available via our Trade Repositories[3] webpage.
The Q&As we consulted on were informed by discussions with Trade Repositories in the UK EMIR Reporting Industry Engagement Group.
The group, co-chaired by us and the Bank, provides a forum for discussing derivatives reporting issues with industry to help ensure consistent reporting.
1.1a Should TRs include both the old and new format reports in the Trade State Reports (TSR) generated for authorities?
Yes. TRs should include both the old and new formats of derivative reports in the open TSR that are submitted to us.
1.1b How should TRs address records from prior to the implementation of the new requirements in the Trade State and Margin State reports which fail the schema, both during and after the transition period?
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.
1.2 What reports should TRs include when generating the TSR each day?
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[4] (Q2.2) provides detail on how reconciliations should be conducted.
1.3a How should TRs validate the Event Date field (Table 2, Item 153) when processing client submissions and generating the TSR?
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.
1.3b How should TRs order the processing of lifecycle events where a derivative has multiple lifecycle events on a given event date?
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.
1.4 What approach should TRs take to the publication of aggregate data?
TRs must publish aggregate data in order to comply with Article 1 of Technical Standards 151/2013[5]. 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.
1.5 How should TRs provide entities responsible for reporting with rejection response error messages?
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[2]. We consider the information they contain to be sufficient for industry to successfully interpret the rejection messages they will receive.
1.6 What schema should TRs use for the inter-TR reconciliations process?
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.
1.7 How should TRs determine whether both counterparties to a trade have a reporting obligation and if the trade is subject to reconciliation?
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.
1.8 What format should TRs provide Allege information to counterparties in?
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[6]. 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.
1.9 Which reconciliation category should TRs use when providing reconciliation feedback to indicate that a previously matched derivative with schedules has become unmatched due to the reporting timestamp moving to another time period block on the schedule?
TRs should refer to Section 2.3.3.A R of the EMIRR Sourcebook[7] 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.
1.10 How should TRs report historic TSRs that reference dates prior to the implementation of the new requirements where a) clients back-report missed transactions and b) where TRs have sent incomplete or inaccurate reports?
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.
1.11 What logic should TRs use for valuations when a counterparty moves from NFC+ to NFC-?
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).
1.12 What is the expected approach for legacy derivatives reported under RTS 1.0 and RTS 2.0 that need to be reported after the end of the transition period?
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.
1.13 How should TRs address the porting of historical data when the updated requirements come into effect in September 2024?
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.
1.14 Which schema is to be used for Porting data between trade repositories?
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.
1.15 How should TRs manage the rights of third parties to access data held in the repository?
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[8]. Article 18 of CDR (EU) 150/2013[6] 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.
1.16 How should TRs address outstanding derivatives reports where the reporting counterparty has been dissolved?
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.
1.17 What is the process for updating LEIs following receipt of a notification relating to a corporate restructuring event?
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?
We expect TRs to comply with the requirements detailed in Section 2.2 of the EMIRR Sourcebook[7], 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:
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.
1.18 How should TRs populate the mandatory tag CollTmStmp (Collateral Time Stamp) in the Warnings Report Schema when margin is not reported?
TRs should populate this tag with a default value of ‘2014-02-12:00:00:00’ in instances where margin has not been reported.
The following Q&As relate to feedback we received on specific field or schema issues.
1.19 What is the approach to validating the MIC code for fields 1.3, 2.29, 2.30, and 2.37?
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[8] 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.
1.20 When reporting at portfolio level, how should TRs validate fields reported in Margin submissions where the Collateral Portfolio Indicator = ‘TRUE’ and some derivatives within a portfolio meet the requirements of a field but others do not? These include the Entity Responsible for Reporting (Table 3, Item 3) and Counterparty 2 (Table 3, Item 6) fields.
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.
1.21 What is the limit to the number of <Rpt> tags per TAR for outgoing schema Auth.030 files and Auth.108 files?
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).
1.22a How should TRs validate the Execution Agents field and the associated relationship record, StartRelationshipParty, and EndRelationshipParty fields?
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).
1.22b How should TRs engage with executing entities with regard to the sharing of data in auth.108 messages and valuation updates for auth.030 messages given that the Execution Agent field is not able to be included as part of these messages?
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.
1.23 How should the PTRR ID field (Table 2, Item 5) be reported when the PTRR service is provided by a service provider or CCP?
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.
1.24 How should the Base Product field (Table 2, Item 116) and Sub-product field (Table 2, Item 117) be reported if the Base Product field is populated with ‘PAPR?
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.
1.25 Where should TRs source EIC codes and EIC area codes to populate the Delivery Point or Zone (Table 2, Item 119) and Interconnection Point (Table 2, Item 120) fields?
TRs should follow their current procedures when sourcing reference data to validate these fields under the new requirements.
1.26 How should the Delta field (Table 2, Item 25) be validated by TRs?
TRs highlighted a potential contradiction between two elements of the validation rule for this field. The UK EMIR Validation Rules state that:
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.
1.27 Can a negative value be assigned to the Package Transaction Price field (Table 2, Item 53) and Strike Price field (Table 2, Item 134) for Auth.030 files?
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.
Please complete this form if you require this content in an alternative format[9].
Links