Changes to UK EMIR reporting requirements: draft questions and answers

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.

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.

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.

Our expectation is that entities generating RTNs, or providing RTNs to entities responsible for reporting, will make the RTN available in a timely manner so entities responsible for reporting can meet their UK EMIR reporting obligations. 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 should update it with the RTN as soon as practicable ones it becomes available.

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.

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 our 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 Validation 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. 

We are consulting on a corresponding change to the UK EMIR Validation Rules (applicable from 30 September 2024) to reflect this.

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.

The Venue of Execution field (Table 2, Item 41) should be populated with the venue’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 Validation 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, 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).

Fields related to the venue of execution should also be maintained. For instance, derivatives resulting from clearing should also be reported with the original execution timestamp in the Execution Timestamp field (Table 2, Item 42).

Yes. Derivatives resulting from PTRR events, such as portfolio compressions, should retain the original derivatives subject to the PTRR event’s venue of execution (or XXXX or XOFF where applicable) to accurately reflect where the original derivatives were executed. If the derivatives subject to a PTRR event were executed on multiple venues, the Venue of Execution field (Table 2, Item 41) should be populated with the venue where the greatest number of the original derivative contracts subject to the PTRR event were executed.

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 Validation 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.

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.

If subsequently an additional margin call is made and met with excess collateral that has already been posted, no change should be made to the reported collateral values. We acknowledge that excess collateral, initial margin and variation margin will not always be segregated.

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 Validation Rules (applicable from 30 September 2024) will cause it to be rejected.

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.

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).

We are consulting on corresponding changes to the UK EMIR Validation Rules (applicable from 30 September 2024) to allow the initial and variation margin fields to be populated when collateral is exchanged contrary to what is stipulated in the collateral agreement.

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, collateral should be reported in a single report, with the Master Agreement Type field (Table 2, Item 34) populated with ‘ISDA’. 

To avoid the risk of reportable margin amounts being duplicated across several trades or within a portfolio, an entity responsible for reporting should ensure the same initial or variation margin is not reported against more than one transaction or portfolio.

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 UK EMIR 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 and Cleared ‘Y’. The Clearing Obligation field remains ‘TRUE’ for the terminated, or alpha, trade.

A 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, 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 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 further 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 the position is netted to zero temporarily due to changes in the underlying transactions, the position should be reported daily with a zero valuation until the valuation increases.

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 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 in position level reports with the total monetary amount paid by the option buyer/s for the derivative trades that make up the position.

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.

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.

As defined in the Financial Services and Markets Act 2023, 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. 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 '99999999999999’9999' (for monetary values) or '99999999999' (for percentage values) and updated once the price is available.

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

We are consulting on a corresponding change to the UK EMIR Validation Rules (applicable from 30 September 2024) to reflect this.