UK EMIR reporting questions and answers

Our expectation is for all entities responsible for reporting to ensure any outstanding derivative reports are updated to comply with the new requirements by the end of the transitional period on 31 March 2025.

We will monitor progress during the 6-month transition period. We expect entities responsible for reporting to proactively engage with us ahead of the completion of the transition period, with explanation, if they are at risk of not updating their outstanding reports to comply with the new requirements after 31 March 2025. We may consider using our supervisory powers in a proportionate and risk-based manner in the event of firms failing to meet the new requirements.

No. TRs should not unilaterally terminate outstanding derivative reports that have not been updated to comply with the new requirements after 31 March 2025.

TRs should take all reasonable steps to encourage entities responsible for reporting to ensure their outstanding derivative reports are updated to comply with the new requirements by the end of the transition period. However, it is the responsibility of entities responsible for reporting to ensure all outstanding derivative reports comply with the new requirements by the end of the transitional period on 31 March 2025.

We will monitor progress during the 6-month transition period. We expect entities responsible for reporting to engage with us, with explanation, if they are at risk of not being able to update their outstanding reports to comply with the new requirements after 31 March 2025. We may consider using our supervisory powers in a proportionate and risk-based manner where firms fail to comply with the new requirements.

Yes. TRs should include all outstanding derivative reports in the reconciliation process (see Section 2 Reconciliation for further detail on the reconciliation process) regardless of whether they have been updated to comply with the new requirements or not. Reconciliations should be based on the new requirements only. Only fields required to be reconciled under the new requirements should be subject to reconciliation. Fields that are no longer required under the new requirements do not need to be reconciled.

We are aware this approach will result in reconciliation breaks during the 6-month transition period, particularly where one counterparty reporting a trade may have updated a report to comply with the new requirements, but the other counterparty, reporting the same transaction, has not. However, we expect this to be a short-term issue, which will reduce as more reporting counterparties update their reports to comply with the new requirements. We will monitor progress during the 6-month transition period.

No. The reconciliation status of outstanding derivative reports should be based on the most recent reconciliation. All reports subject to reconciliation should be included in the reconciliation process, regardless of whether they have been updated to comply with the new requirements. Once a report is updated to comply with the new requirements, a new reconciliation should take place.  

We are aware this approach will result in reconciliation breaks during the 6-month transition period, particularly where one counterparty reporting a trade may have updated a report to comply with the new requirements, but the other counterparty, reporting the same transaction, has not. However, we expect this to be a short-term issue during the transition period.  

This will provide a more accurate view of reconciliation for Authorities.

Trade level derivatives that are included in a position are not outstanding and therefore do not need to be re-reported and updated to comply with the new requirements. Only the corresponding derivative at position level needs to be updated to comply with the new requirements, provided it is outstanding on 30 September 2024.

As with other outstanding reports, outstanding position level reports should be updated to comply with the new requirements with the action type 'Modify' and event type 'Update' before the conclusion of the transition period. However, this will not be necessary where counterparties have corrected or modified an outstanding report with the action type 'Modify' or 'Correct', since doing so will require updating the report to comply with the new requirements. Counterparties must ensure that outstanding position level reports that have not been modified or corrected during the transition period, regardless of whether daily valuation and collateral updates are being reported, are updated with the action type 'Modify' and the event type 'Update' since the daily valuation and collateral updates will not include details for every field.

Counterparties should keep in mind acceptable action and event type combinations when reporting at position level. See also Section 5 Actions and Events.

Yes. We have provided a full suite of XML Schemas for reporting from 30 September 2024 onwards.

This includes 'relaxed' XML schema for the Trade State Report, Margin Derivative State Report, and Reconciliation Statistics Report. These permit TRs to submit details of all derivative reports, regardless of whether they have been updated to comply with the new requirements during the 6-month transition period. That is both those derivatives trades entered into or modified on or after 30 September 2024 that are subject to the new requirements, and those derivative trades entered into before 30 September 2024 that have not yet been updated to meet the new requirements.

Trade Activity, Margin Derivative Activity, Rejection Statistics, and Warning Statistics files must only include reports that have been updated to comply with the new requirements due to the ‘strict’ XML schemas that are in place for these files.

Yes. TRs should include all derivatives reported by counterparties in the reports made available to Authorities, regardless of whether they have been updated to comply with the new requirements or not, and where the relaxed schemas allow them to do so. See our response to question 1.6.

Yes, for certain types of reports where there is a ‘relaxed’ XML schema that can accommodate derivative reports not updated to comply with the new requirements.

Specifically, the Trade State Report, Margin Derivative State Report, and Reconciliation Statistics Report files can include updated and non-updated contracts due to the relaxed schemas for these files. That is both those derivatives trades entered into or modified on or after 30 September 2024 that are subject to the new requirements, and those derivative trades entered into before 30 September 2024 that have not yet been updated to meet the new requirements.

Trade Activity, Margin Derivative Activity, Rejection Statistics, and Warning Statistics files must only include updated reports that comply with the new requirements due to the 'strict' XML schemas that are in place for these files.

Yes. TRs should include all derivative reports in the reports made available to other TRs and entities responsible for reporting, regardless of whether they have been updated to comply with the new requirements, where the type of report being shared permits this due to the 'relaxed' XML schemas. See our response to question 1.8.

No. Our expectation is that from 31 March 2025, all XML schemas will be 'strict'. That is, they will only allow reports consistent with the new requirements to be reported. See also questions 1.1 and 1.2.

Yes, outstanding derivative reports can be ported during the transition period. However, from 30 September 2024, any outstanding derivative reports that require porting must have been updated to comply with the new requirements. It will not be possible to port outstanding reports that have not been updated, as the relevant XML schema will only permit the sharing of updated records which comply with the new requirements between TRs.

In the event a reporting counterparty wishes to move TR during the transition period, the reporting counterparty should ensure any outstanding derivative reports are updated to comply with the new requirements before porting to a new TR. Reporting counterparties should keep this in mind when developing and implementing plans to ensure outstanding reports comply with the new requirements as it may impact reporting arrangements, for example, where firms use delegated reporting arrangements.

When outstanding derivative reports (trades and positions that are still outstanding after 30 September 2024) are updated to comply with the new requirements, reporting counterparties should use action type 'Modify' and event type 'Update'. The same action and event types ('Modify' and 'Update') should also be used for any new values that are added to an outstanding position or trade to comply with the new requirements.

We expect that a transaction or position will be updated once only.

Any corrections to reports that have previously been updated to meet the new requirements should be done with action type 'Correction'.

We do not expect there to be any Modify/Update reports after the transition period, as we expect all outstanding positions and trades to comply with the new requirements after that period.

TRs should reconcile derivatives with 2 legs by reconciling each of the legs as reported by the counterparties. In most cases, including interest rate swaps, the 2 legs of a derivatives trade are not sequenced in a particular order. Accordingly, TRs should match the two legs using the values in the Direction of Leg 1 field (Table 1, Item 18) with the opposite value, regardless of the order in which the legs were reported. This is in line with the reconciliation 'Conditions' detailed in the UK EMIR Validation Rules (applicable from 30 September 2024) ('Reconciliation Information', Column J).

As set out in PS23/2, our expectation is for TRs to conduct reconciliations based on 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.

As set out in PS23/2, TRs are required to provide the results of the reconciliation process to entities responsible for reporting for each working day. This should allow entities responsible for reporting to easily identify and remediate reconciliation breaks.

In terms of the format in which this information should be shared, TRs shall provide the results of the reconciliation process in an XML format and a template developed in accordance with the ISO 20022 methodology (available on the FCA’s UK EMIR Reporting obligation webpage). This should include information on the fields that have not been reconciled. However, we do not oppose TRs sending reports in other formats in addition to XML. TRs may take this decision individually based on the needs and requirements of their respective client base.

Entities responsible for reporting are required to have arrangements in place to ensure the remediation of reconciliation breaks as soon as practically possible. As the nature and severity of reconciliation breaks will vary, we do not intend to provide prescriptive guidance as to when and how counterparties should remediate breaks. However, the expectation is that entities responsible for reporting have arrangements to remediate reconciliation breaks that are appropriate to the nature, scale, and complexity of their business.

TRs must comply with the rules outlined in Section 2.3 of the FCA’s EMIRR relating to inter-TR reconciliation. TRs should have the flexibility to agree, between them, the best way in which they can meet the requirements in EMIRR 2.3 from an operational perspective. As such, we do not intend to provide more prescriptive guidance for TRs in this area at this time. However, we will continue to monitor the effectiveness of the inter-TR reconciliation process to determine whether further guidance may be needed.

No. Reconciliation reports do not distinguish between whether valuation updates are 'missing' or 'late'.

However, it is possible under the Warnings XML schema to distinguish between ‘missing’ valuations and ‘late’ valuations. As part of their end-of-day response mechanisms, TRs are required under section 2.4.1 of the FCA’s EMIRR to provide reporting counterparties with the outstanding derivative reports for which no valuation information has been reported, or the valuation information that was reported is dated more than 14 calendar days from the day for which the report was generated.

Details of the reportable fields that are subject to reconciliation and the applicable reconciliation tolerance levels, can be found in the UK EMIR Validation Rules (applicable from 30 September 2024) ('Reconciliation Information' sheet, Columns H-J).

Entities with an obligation to report the details of derivative trades under Article 9 of UK EMIR are required to ensure that such details are complete, accurate and reported on time. 

Entities responsible for reporting are expected to remediate all errors and omissions to their reports. This includes both live and matured trades regardless of age and any impacted position reports. 

However, where remediation may be large and complex, entities responsible for reporting should engage bilaterally with the relevant Authority to agree a remediation plan that is proportionate to the complexity of the error and/or omission that requires remediation.  

Where any material errors or omissions are identified, entities responsible for reporting must notify the relevant Authority as soon as practicably possible.  

• CCPs should notify the Bank of England by completing the Errors and Omissions form available on its website. 
• All other reporting counterparties should notify the FCA by completing the Errors and Omissions form available on its website. 

Whereas completion of the form can be performed by any party, it is the responsibility of the counterparty in scope of UK EMIR Article 9 reporting requirement who should submit the notification to the relevant Authority.

At a minimum, we expect entities responsible for reporting to have systems and controls in place to ensure timely and complete reporting in accordance with Article 9 of UK EMIR.

In addition, entities responsible for reporting should ensure they have in place:

• effective governance to oversee their UK EMIR reporting
• effective systems and controls to identify and remediate errors and omissions (including the notification of any errors and omissions to the relevant Authority); and
• arrangements with counterparties to address reconciliation breaks

Entities responsible for reporting should assess the materiality of any errors or omissions in their UK EMIR reporting (including identification of any errors and omissions that are to be reported to the relevant Authority) based on the size, nature, and complexity of their business.

Entities responsible for reporting should use reconciliation reports received from TRs to validate the contents of their reports with their counterparties. All entities responsible for reporting should have arrangements in place with their counterparties to ensure any reconciliation breaks are appropriately resolved as soon as practicably possible.

The severity and drivers of reconciliation breaks will differ. As such, more prescriptive timelines within which entities should remediate breaks would not be appropriate for the remediation of certain reconciliation breaks.

The Warnings Feedback message provided by TRs to entities responsible for reporting is to identify missing data and potential outlier values without rejecting the reports, and to help reporting counterparties identify and remediate possible errors and omissions within reported data. The reports included within the Warnings Feedback message have been accepted by the TR which is reflected in its status (Acknowledged or ACK).

Entities responsible for reporting should use the information provided in the Warnings Feedback message to monitor the accuracy of their reporting by investigating the potential issues. They should then confirm if remediation is required to correct any errors or omissions without undue delay to comply with Article 9 UK EMIR, including by submitting an Errors and Omissions form on the appropriate Authority’s website where necessary.

In accordance with the provisions of Section 2.4 of the FCA’s EMIRR, TRs will be required to notify entities responsible for reporting of any reports where the notional amount exceeds a threshold for that class of derivative as part of the Warning Feedback message. The intention of having thresholds to identify outlier values is to identify possible erroneous reporting of notional amounts in a particular asset class that would materially affect the Authorities' view of the largest exposures in a particular asset class.  

To achieve this outcome, the Authorities propose to co-ordinate with UK TRs to implement a set of thresholds to make the Warnings Feedback message a useful and consistent data quality metric for both industry and the Authorities. We will request that TRs make these thresholds available to clients in an easily accessible manner once they have been established. 

The Authorities will continue to monitor the introduction of the Warnings Feedback message, including the ongoing effectiveness of the thresholds set.

Where a reporting counterparty uses the Revive action type to reopen a report that has not been updated to comply with the new requirements, for example to correct errors in matured trades, the reporting counterparty should provide all relevant details to update the report to comply with the requirements as of the date of the revival action. This is the same approach as for any revived report.

Counterparties are expected to provide all the relevant data to update revived reports so they comply with the new requirements. But if this is not possible, counterparties are expected to proactively engage with us, with an explanation and a proposed solution.

No. In line with the UK EMIR Validation Rules (applicable from 30 September 2024), UTIs should not be amended once they have been reported.

As set out in CP21/31, we are not expecting the generation of new UTIs for outstanding trades and positions and the UK EMIR Validation Rules (applicable from 30 September 2024) permit the use of old format UTIs to reflect this. UTIs allocated to a trade or position should remain the same throughout the lifetime of the trade or position and a new UTI should be used only if a trade or position is replaced by one or more trades or positions, for example following a post trade risk reduction (PTRR) event. Therefore, TRs should reject any modifications to pre-existing UTIs.

The updated UTI structure in UK EMIR is based on CPMI-IOSCO Technical Guidance on the Harmonisation of the Unique Transaction Identifier. UTIs generated by non-UK counterparties pursuant to a different reporting regime should align with the formatting requirements under UK EMIR, meaning they can be treated in the same manner as UTIs generated under UK EMIR. 

Noting there may be differences in implementation timelines for the updated UTI structure between jurisdictions which may present issues, we will monitor progress and consider if further guidance is necessary.

There is no requirement for UTIs generated by trading venues to incorporate the trading venue’s TVTIC into the UTI. In line with Article 8 of the Technical Standards on the Standards, Formats, Frequency and Methods and Arrangements for Reporting 2023, UTIs must be composed of the LEI for the counterparty who generated the UTI, followed by a code of up to 32 characters which should be unique at the level of the generating entity.

While a trading venue’s TVTIC can’t be used in place of a UTI, there is nothing to prevent trading venues from incorporating an existing TVTIC into the UTIs it generates, provided the UTIs continue to meet the requirements in Article 8 of the Technical Standards on the Standards, Formats, Frequency and Methods and Arrangements for Reporting 2023.

Article 7 of the Technical Standards on the Standards, Formats, Frequency and Methods and Arrangements for Reporting 2023, requires derivatives to be identified with an ISIN where the derivative is either:

• admitted to trading or traded on a trading venue; or
• traded on a systematic internaliser (SI) and the underlying is admitted to trading or traded on a trading venue or an index or basket composed of instruments traded on a trading venue

Where a derivative does not meet one of these conditions it should be identified with a UPI, regardless of whether the derivative has an ISIN. Accordingly, ISINs and UPIs should not be used in combination, and the UK EMIR Validation Rules (applicable from 30 September 2024) will not permit the reporting of a UPI where an ISIN is provided.

CFI codes should be provided where possible for all derivatives in addition to an ISIN or UPI, depending on whether it is admitted to trading or traded on a trading venue or SI.

A product identifier is not required to be reported for derivatives executed on a third country organised trading platform if neither an ISIN nor a UPI exist.

Yes. Entities responsible for reporting must report all the applicable fields specified in the Technical Standards on the Minimum Details of the Data to be Reported to Trade Repositories 2023, including those which overlap with UPI reference data.

However, we will continue to monitor the implementation of the UPI system under the UK regime and will communicate any developments accordingly.

No. TRs are not required to enrich reports as entities responsible for reporting must continue to report fields which overlap with UPI reference data.

However, we will continue to monitor the implementation of the UPI system under the UK regime and will communicate any developments accordingly.

No, except in the case of mandatory delegated reporting.

Article 4 of the Technical Standards on the Standards, Formats, Frequency and Methods and Arrangements for Reporting 2023, requires entities responsible for reporting to ensure the reference data related to their LEI is renewed in accordance with the terms of any of the accredited Local Operating Units of the Global LEI System.

For mandatory delegated reporting, the non-financial counterparty (NFC) is responsible for renewing and maintaining its LEI, as explained in PS23/2. But as required under Article 10 of the Technical Standards on the Standards, Formats, Frequency and Methods and Arrangements for Reporting 2023, financial counterparties must have in place arrangements for due renewals by the NFC of its LEI to ensure accurate reporting for which the FC is solely responsible and legally liable.

Accordingly, the UK EMIR Validation Rules (applicable from 30 September 2024) require the LEI status of Counterparty 1 (Table 1, Item 4) and the Entity responsible for reporting (Table 1, Item 3) to be Issued, Pending transfer or Pending archival for certain action types. However, for Counterparty 2 (Table 1, Item 9) the LEI status may be Lapsed for certain action types. The Validation Rules provide further details as to what LEI status is required for the different action types.

Yes. TRs should, where applicable, validate LEIs against the GLEIF database as of the date reported in the Reporting Timestamp field.

The stepping-in counterparty is expected to make reasonable efforts to populate the Prior UTI field. Where this is not possible the field may initially be populated with the code 'NOTAVAILABLE', and then amended with the correct Prior UTI value as soon as practicable once it is available. In this circumstance there is no requirement to resubmit previous reports to retrospectively include the Prior UTI.

The PTRR ID is made up of the LEI of the provider (PTRR service provider or a CCP providing the PTRR service) followed by up to 32 alphanumeric characters that uniquely identify the PTRR event. The PTRR ID should be generated by that same provider. All derivatives directly resulting from, or terminated because of, a given PTRR event, should be reported with the same PTRR ID.

Where a RTN is not available at the time of reporting, entities responsible for reporting may populate the Report Tracking Number field (Table 2, Item 2) with 'RTNNotProvided' but this field should be updated with the RTN as soon as practicable once it becomes available. In this circumstance there is no requirement to resubmit previous reports to retrospectively include the RTN.

As specified in Table 2 of the Annex to the Technical Standards on the Standards, Formats, Frequency and Methods and Arrangements for Reporting, counterparties are required to report RTNs for derivatives executed on trading venues. The Technical Standards define the RTN as 'a number generated by a trading venue unique to that execution'. Our expectation is accordingly for trading venues who generate RTNs to make the RTN available in a timely manner so entities responsible for reporting can meet their UK EMIR reporting obligations. Similarly, where applicable, our expectation is for intermediaries to make the RTN available to their counterparties so they can meet their UK EMIR reporting obligations.

No. The UK EMIR Validations Rules (applicable from 30 September 2024) only require a RTN for derivatives executed on UK trading venues and do not permit the reporting of RTNs for derivatives not executed on UK trading venues.

Yes. The new Event Date field will impact TR validation of reports, dependent on which action type is reported.

For details on how the Event Date is limited depending on action type, see the UK EMIR Validation Rules (applicable from 30 September 2024) where we detail our expectations in the 'Trade validations auth.030' sheet in Table 2, Item 153 Validation Rules.

The Event Date field affects several TR validation steps. Primarily, it is used in conjunction with the Reporting Timestamp field (Table 1, Item 1) to validate the order of incoming submissions.  The Event Date field is also used to determine whether the LEI status of various parties to a trade needs to be validated and, in instances where the Valuation Timestamp (Table 2, Item 23) field is populated, it should match the Event Date field.

For full details on how the Event Date field restricts other fields, see the UK EMIR Validation Rules (applicable from 30 September 2024) where we detail our expectations in the 'Trade validations auth.030' sheet and the 'Margins validations auth.108' sheet.

The possible combinations of action and event type, and when they can be used, are described in Table 5.1 below.

Table 5.1 Applicability of Action type – Event type combinations

This table has been drafted using material downloaded from the European Securities and Markets Authority (ESMA’s) website. ESMA does not endorse this publication and is in no way liable for copyright or other intellectual property rights infringements, nor for any damages caused to third parties through this publication.

Where an equity reset results in a change in reportable properties, for example, a notional increase or decrease, it should be reported. Where an equity reset does not result in a change in reportable properties, it should not be reported.

The Price field (Table 2, Item 48) should not change in an equity reset, as this is populated with the initial price of the underlying at the time of execution for equity swaps.

In line with the definition of an OTC derivative in Article 2 of UK EMIR, derivatives executed on third country organised trading platforms should be considered OTC derivatives and reported as such unless the third country organised trading platform is considered as equivalent to a UK Regulated Market (see the list of equivalent third country markets maintained by the FCA).

Derivatives executed on third country markets considered as equivalent to a UK Regulated Market (pursuant to Article 2a of UK EMIR) should be reported as exchange traded derivatives.

Not at present.

A list of Multilateral Trading Facilities (MTFs) and Organised Trading Facilities (OTFs) authorised by the FCA along with Systematic Internalisers notified to the FCA is available on the FCA’s MTF, OTF and SI Register.

A list of UK Regulated Markets is also available on the Financial Services Register and a list of third country markets considered as equivalent to a UK Regulated Market is available on the FCA website.

Yes. As specified in the UK EMIR Validations Rules (applicable from 30 September 2024), this field is mandatory when reporting at both transaction and position level. For details of how to populate this field when reporting at position level see question 6.4.

When reporting at position level, the Venue of Execution field should contain the Market Identifier Code (MIC) of the venue (or XXXX or XOFF where applicable) where the greatest number of derivative contracts making up the position were executed.

As specified in Table 2 of the Annex of the Technical Standards on the Minimum Details of the Data to be Reported to Trade Repositories 2023, the Venue of Execution field (Table 2, Item 41) should be populated with the venue of execution’s ISO 10383 segment MIC. If a segment MIC does not exist, the operating MIC should be reported.

Operating and segment MICs are both enabled by the UK EMIR Validations Rules (applicable from 30 September 2024) to populate the Venue of Execution field, provided they are included in the list maintained and updated by ISO (column 'MIC' in the worksheet 'ISO10383_MIC_NewFormat').

Where derivatives are executed pursuant to the rules of a venue but not executed on the venue, for example block trades executed outside the trading platform of a Regulated Market but executed pursuant to the rules of that Regulated Market, the Venue of Execution field should be populated with the MIC for the venue whose rules the derivative has been executed pursuant to.

This applies to both UK trading venues and third country organised trading platforms.

Yes. Derivatives resulting from clearing should be reported with the original derivative’s venue of execution (or XXXX or XOFF where applicable).

No. New derivatives resulting from PTRR events, such as portfolio compressions, should be reported with the code XXXX or XOFF (as applicable) to reflect they were not executed on a trading venue, SI or third country organised trading platform.

The Execution Timestamp field should contain the date and time a derivative was originally executed, resulting in the generation of a new Unique Transaction Identifier (UTI).

When reporting at position level, the Execution Timestamp field should refer to the time when a position was opened for the first time using the earliest execution timestamp of the trades making up a position.

In the case of ETDs where a counterparty chooses to report on its own behalf rather than delegate the submission of the report to a third party, the Report Submitting Entity ID field should contain the counterparty's own LEI as the report submitting entity. The Entity Responsible for Reporting field (Table 1, Item 3) not being applicable to ETDs does not impact how the Report Submitting Entity ID field should be populated.

In line with the UK EMIR Validations Rules (applicable from 30 September 2024), the Effective Date field must be populated for all derivatives as it is a mandatory field. In situations where there is no effective date specified in a derivative contract, as may be the case for ETDs, the execution date should be provided in the Effective Date field.

When reporting at position level, the Effective Date field should be populated with the earliest effective date of the trades making up the position. If there is no effective date specified in the derivative contracts making up the position, the earliest execution date of the trades making up the position should be provided.

For the CCP to clearing member leg of an ETD, the Master Agreement Type field should be populated with 'OTHR' and the Other Master Agreement Type field (Table 2, Item 35) should be populated with 'CCPClearingConditions'.

For the clearing member to client leg of an ETD, the Master Agreement Type field should be populated with 'BIAG'.

When the subsequent position is an intraday ETD position without a position UTI, the code 'NOTAVAILABLE' should be used in the Subsequent Position UTI field.

The 'NOTAVAILABLE' code should only be used where the subsequent position does not have a UTI. If the subsequent position is an intraday ETD position with a position UTI, that UTI should be reported.

See also question 10.1.

Entities responsible for reporting should populate the Initial Margin and Variation Margin fields with the amount of margin that was received or posted to meet the initial and variation margin requirements.

Initial margin, variation margin and excess collateral are defined by the purpose and timing in which they are posted: 

• If margin is posted to meet an initial margin call, it should be reported as initial margin.  
• If margin is posted to meet a variation margin call, it should be reported as variation margin.  
• If collateral is posted for a reason separate and independent of initial and variation margin requirements it should be reported as excess collateral. 

Where excess collateral has been reported, and subsequently an additional (variation or initial) margin call is made and met with that excess collateral, no change should be made to the reported posted collateral values.  

We acknowledge that excess collateral, initial margin and variation margin will not always be segregated.  

If margin posted to meet a combined initial and variation margin call is more than that requested, the additional margin posted should be allocated proportionally to the initial and variation margin initially requested. 

As an illustration:

• A margin call of £120 is made, comprising £80 initial margin and £40 variation margin. 
• In response, £126 of margin is posted. This should be reported as: 
  • initial margin £84 
  • variation margin £42  
  • excess collateral £0 

When variation margin is posted and received on the same day and reported in a single report, the values should be netted so that the overall net margin (posted or received) that day is reported. If a report contains variation margin posted and received on the same day the UK EMIR Validations Rules (applicable from 30 September 2024) will cause it to be rejected.

If variation margin is posted or received in multiple currencies, it should be reported on a net basis and in a single currency. The reporting currency should be the one with the largest net contribution to the variation margin.

Entities responsible for reporting have an obligation to submit daily valuation updates regardless of whether the derivative is collateralised or not.

Entities responsible for reporting should submit a margin update for every uncollateralised transaction. If subsequently, there is no change to the collateral data fields from the original margin update, daily margin updates do not need to be submitted for uncollateralised transactions. However, correction reports should still be submitted if applicable.

When a derivative trade has matured, expired or been terminated, reporting counterparties are not required to report any collateral amounts that have not yet been returned. Collateral remaining unreturned after a derivative trade has matured, expired or been terminated should not be reported, unless it is reported as part of a portfolio which contains outstanding trades as of the event date.

Collateral update reports may still be submitted for non-outstanding trades which were outstanding on the event date. Collateral update reports may be submitted for non-outstanding portfolios which were outstanding on the event date.

Collateral update reports should not be submitted for trades and portfolios which were not outstanding on the event date.

Where a portfolio no longer contains any outstanding derivative trades, reporting counterparties are not required to report collateral amounts that have not been returned.

Collateral should only be reported for outstanding portfolios where there is at least one outstanding transaction (including where a position is flat).

Collateral update reports can be submitted for non-outstanding portfolios which were outstanding on the event date.

Yes. In line with Article 6 of the UK EMIR Technical Standards on the Minimum Details of the Data to be Reported to Trade Repositories 2023, counterparties (excluding non-financial counterparties which do not exceed the clearing threshold) are required to report all posted and received collateral, regardless of whether that collateral is required to be received or posted. This includes where counterparties voluntarily collateralise transactions exempt from the margin requirements.

Initial or variation margin posted or received that exceed the required margins should be reported as part of the initial or variation margin posted or received. Any additional collateral posted or received independently of the initial and variation margins should be reported as excess collateral.

The Collateralisation Category field should always reflect what is in the agreement between counterparties, irrespective of what collateral is exchanged in practice.

It is our expectation that any collateral exchanged should be consistent with the collateral agreement in place between the counterparties.

Nevertheless, the entity responsible for reporting should report the collateral that has been exchanged in practice in the initial and variation margin fields, even if it is contrary to the collateral agreement. In this case:

a. Where the collateral agreement states that margin should be exchanged, but margin is not exchanged, the relevant margin fields should be populated with zero and the associated currency fields with GBP.

b. Where the collateral agreement states that margin should not be exchanged, but margin is exchanged, the associated margin fields should be populated (unless the value is netted off).

The net variation margin that is posted and collected that day should be reported in daily margin updates. This is not expected to be zero.

The daily change in valuation should be reported in daily valuation updates.

For uncleared derivatives where there are multiple CSAs under a single ISDA Master Agreement, the Master Agreement Type field (Table 2, Item 34) in the transactions report should be populated with 'ISDA'.

Although more than one Collateral Portfolio Code (Table 3, Item 9) can be reported, to avoid the risk of reportable margin amounts being duplicated, an entity responsible for reporting must ensure the same initial or variation margin is only reported against a single Collateral Portfolio Code.

No. From 30 September 2024, all portfolio codes should not contain special characters. The UK EMIR Validation Rules (applicable from 30 September 2024) will not permit portfolio codes containing special characters.

No. As set out in Table 3 of the Technical Standards on the Minimum Details of the Data to be Reported to Trade Repositories 2023, contingent variation margin should not be included in calculations of variation margin.

When an OTC derivative trade is cleared by a CCP, ie the CCP is a counterparty to the trade, it is no longer subject to the clearing obligation (UK EMIR, Article 4).

The Clearing Obligation field is then populated based on whether the derivative being cleared belongs to a class of OTC derivatives that has been declared subject to the clearing obligation as set out in the public register maintained by the Bank.

• Where the contract belongs to a class of OTC derivatives that has been declared subject to the clearing obligation, the Clearing Obligation field value should be reported as 'FLSE'.
• Where the derivative trade does not belong to a class of OTC derivatives that has been declared subject to the clearing obligation, the Clearing Obligation field should be reported as 'UKWN'.

In line with the requirements of the clearing obligation (UK EMIR, Article 4), our expectation is that any trade which is subject to the clearing obligation will be cleared. Once a trade is cleared, it should then be reported with Cleared field (Table 2, Item 31) as 'Y' and the Clearing Obligation field (Table 2, Item 30) as 'FLSE', as set out in Question 9.1.

If a trade has not yet been entered into clearing with a CCP by close of business the Cleared field should be reported ‘N’ and the Clearing Obligation field should be reported as 'TRUE'.

Once the trade has been entered into clearing with a CCP, another report should be submitted, with action type Terminate, event type Clearing with the Cleared field not reported. The Clearing Obligation field remains 'TRUE' for the terminated, or alpha, trade.

An NFC performs a clearing threshold calculation to determine if it is subject to the clearing obligation (see Article 10 of UK EMIR). The threshold levels are different depending on the asset class. If an NFC finds that it is below the clearing threshold in the asset class relevant to that transaction or position, it is not subject to the clearing obligation. In this scenario, for OTC derivatives it reports: 

• 'FLSE' if the contract belongs to a class of OTC derivatives that has been declared subject to the clearing obligation
• 'UKWN' if the contract does not belong to a class of OTC derivatives that has been declared subject to the clearing obligation

If an NFC does not perform the clearing obligation threshold calculation it will be deemed to be subject to the clearing obligation. In this scenario, NFCs should populate the Clearing Obligation field as set out in questions 9.1 and 9.2.

When a clearing member defaults, and a CCP temporarily assumes both sides of a contract, where the UTI is unchanged, the Clearing Member field should continue to be populated with the original clearing member until the transaction is terminated, matures, expires or the CCP transfers the transaction to another clearing member.

If a temporary contract with a new UTI is created where the CCP assumes both sides of a contract, the prior UTI field (Table 2, Item 3) should be populated with the previous UTI. If a CCP transfers the derivative trade to another clearing member, where feasible the Prior UTI field (Table 2, Item 3) should be populated by the CCP with the UTI of the predecessor transaction. See question 10.5 for more details.

The position should not be reported in this scenario. However, the underlying transactions must still be reported. The Subsequent Position UTI field (Table 2, Item 4) should be populated with the position UTI even though the position itself is not reported.

When the subsequent position does not have a UTI (for example, an intraday ETD position without a position UTI), the code 'NOTAVAILABLE' should be used in the Subsequent Position UTI field. If a position is subsequently opened and a position UTI made available, the Subsequent Position UTI field should be updated to reflect this as soon as possible. In this circumstance there is no requirement to resubmit previous reports to retrospectively include the Subsequent Position UTI.

If the position is netted to zero temporarily due to changes in the underlying transactions, the position should continue to be reported daily.  

If the position is netted to zero due to an account closure, the position should be terminated. If a terminated position is subsequently reopened, the position should be reported with a new UTI.

If a position was netted to zero and reported each day as zero, the Execution Timestamp field should maintain the original value and not be modified.

If a position that was netted to zero and terminated is subsequently re-opened, the Execution Timestamp field should be populated with the time the position was re-opened.

The event type should be populated with the type of the first event that creates the position. Step-in, Inclusion in Position and Corporate Event are the permitted event types for new positions.

The Prior UTI of a report describing a new position following a position transfer should be populated with the UTI of the original position (the position the transfer came from). 

Our expectation is that each entity responsible for reporting will make all reasonable efforts to populate this correctly. Where this is not possible, the field may initially be populated with the code ‘NOTAVAILABLE’ and then amended as soon as practicable once the correct Prior UTI value becomes available. In this circumstance there is no requirement to resubmit previous reports to retrospectively include the Prior UTI.

In a scenario where 2 positions have merged, 1 position continues and the other terminates. Both counterparties must agree which position continues and which terminates. 

This event does not change the Prior UTI or UTI of the continuing position. The terminating position should be reported with an action type ‘Terminate’ and event type 'Inclusion in position'.

The Option Premium Amount field should be populated with '0' in position level reports. 

Alternative reporting methodologies, such as one based on the sum of the options’ premiums, would not provide meaningful interpretation. Therefore, the field must be populated with '0'. 

The entity responsible for reporting should populate the Option Premium Payment Date field with the earliest option premium payment date of the trades underlying the position.

Yes. Spread bets can initially be reported with the action type POSC before being aggregated and re-reported at position level. This is provided that the conditions in Article 5 of the Technical Standards on the Minimum Details of the Data to be Reported to Trade Repositories are met.

Only transactions subject to the UK EMIR reporting obligations need to be reported. If a package contains transactions which are not required to be reported under UK EMIR, only the transactions in the package subject to the UK EMIR reporting obligations must be reported.

However, for transactions that are reported as part of a package, all package transaction related fields should be populated with details applicable to the whole package, including both reportable and non-reportable transactions. For example, the Package Transaction Price field (Table 2, Item 53) should be populated with the traded price for the entire package in which the reported derivative is a component, including transactions which are part of the package but not required to be reported under UK EMIR.

In circumstances where the payer and receiver are not known at the point of reporting, the counterparty receiving the currency which appears first when sorted alphabetically by ISO 4217 standard should be identified as the receiver for leg 1 and the payer for leg 2. The counterparty delivering the currency should be identified as the payer for leg 1 and the receiver for leg 2.

A cryptoasset is any cryptographically secured digital representation of value or contractual rights that can be transferred, stored or traded electronically, and that uses technology supporting the recording or storage of data. This is in line with the definition in section 471(1) of the Financial Services and Markets Act 2000. 

Where a derivative is based on an underlying meeting this definition, the Derivative Based on Cryptoassets field should be populated with 'True'. Otherwise, it should be populated with 'False'.

Noting that the regulatory regime for cryptoassets is developing, the Authorities will monitor regulatory developments and consider if further guidance is needed.

Derivatives based on cryptoassets should be reported under the asset class of the cryptoasset they are based on. For example, derivatives based on security tokens akin to traditional shares (see the FCA’s Guidance on Cryptoassets (PS19/22)) would be reported as equity derivatives. Derivatives not clearly falling into one of the specified asset classes should be reported under the asset class most closely resembling the derivative. Derivatives based on cryptoassets should not, however, be reported under the currency asset class, since cryptoassets don’t have an ISO 4217 currency code required for currency derivatives.

Derivatives based on unregulated exchange tokens that don’t clearly fall into one of the specified asset classes, such as Bitcoin and Ether, should be reported under the commodity asset class. This is the asset class that most closely resembles these derivatives.

Noting that the regulatory regime for cryptoassets is developing, the Authorities will monitor regulatory developments and consider if further guidance is needed.

The UK EMIR Validation Rules (applicable from 30 September 2024) do not permit derivatives to be reported with 2 underlying commodities. Commodity swaps referencing 2 commodities should be reported as package transactions made up of 2 commodity forwards linked via a package identifier.

The Price (Table 2, Item 48) and Package Transaction Price (Table 2, Item 53) fields are mandatory for commodity forwards with a package identifier, but commodity swaps may not have a price at execution. When reporting a commodity swap as a package transaction made up of 2 commodity forwards, these fields should be populated with the default value '999999999999999999' (for monetary values) or '99999999999' (for percentage values) and updated once the price is available.

When reporting commodity swaps as 2 commodity forwards linked via a package identifier, reporting counterparties should provide valuations for both forwards even if there may only be a single valuation for the whole commodity swap. In this scenario, the Valuation Amount (Table 2, Item 21) field for both forwards should be populated with the valuation of the whole commodity swap.

Yes, where a spread is present it should be reported for all asset classes.