Envelope Phone-alt

Different EMIR Reporting Methods

Data Enrichment

Compliance Support

Reduce Costs

Under the EMIR Regulation you are required to report all details of a derivative contract as well as any modification or termination of the contract.  

TRAction have three different methods of reporting which can be used, depending on how the client’s system works:

  • Trade Lifecycle
  • Position Lifecycle
  • Position Lifecycle with aggregation

Trade Level / Trade Lifecycle Reporting

Trade lifecycle means reporting one Trade ID per order with no concept/reporting of a position.

All subsequent Valuation and Collateral updates take place at the Trade Level.

This system is most commonly used for reporting under MT4 as well as physical products such as FX Forwards. 

So, what does trade lifecycle look like?

Example

On 01/01/2020, I open a CFD trade, buying 1 contract of FTSE 100 Cash Index at a price of 6000.

In the EMIR report this is reported with an Action Type of ‘N’ = ‘New’ and Level = ‘T’ (for Trade).

ActionExecutionDateTimeUTICounterPartySideQuantityPriceMultiplierPriceOrRateNotionalAmountLevel
N2020-01-01T18:34:00ZE0212345678911234567892ABC12345TB110600060000T

Any subsequent modifications/valuations/collateral updates are made at Trade level.  

On 02/01/2020 I modify the Maturity Date with my counterparty, I would submit an Action of ‘M’ = ‘Modify’ and the updated Maturity Date.

ActionExecutionDateTimeUTICounterPartySideQuantityPriceMultiplierPriceOrRateNotionalAmountLevel
M2020-01-01T18:34:00ZE0212345678911234567892ABC12345TB110600060000T

If on 03/01/2020 I terminate the contract early (not at the maturity date), I would submit a report with Action of ‘C’, ‘early termination’.

ActionExecutionDateTimeUTICounterPartySideQuantityPriceMultiplierPriceOrRateNotionalAmountLevel
C2020-01-01T18:34:00ZE0212345678911234567892ABC12345TS110600060000T

Position Level / Position Lifecycle Reporting

Position Level reporting means you report all individual transactions as Compressed into a position, reporting the additional end of day Open Positions at position level.

This system works well where Partial Closes are used as you can report all single executions individually at trade level as well as report any modifications/updates at position level.

So, what does position lifecycle look like? 

Example

On 01/01/2020 I open a CFD trade, buying 10 contracts of FTSE 100 Cash Index at a price of 6000.

In the EMIR report this is reported with an Action Type of ‘P’ = ‘position component’ and Level = ‘T’ (for Trade).

This compressed trade contains a Termination Date, as upon compression the trade is terminated.

ActionExecutionDateTimeUTICounterPartySideQuantityPriceMultiplierPriceOrRateNotionalAmountLevel
P2020-01-01T18:34:00ZE0212345678911234567892ABC12345TB10106000600,000T

At the end of the day my position of 10 contracts in FTSE 100 is still open so I reported a New Position with an EOD Valuation. The UTI has been updated to be the Position UTI.

ActionExecutionDateTimeUTICounterPartySideQuantityPriceMultiplierPriceOrRateNotionalAmountLevel
N2020-01-01T18:34:00ZE0212345678911234567892ABC12345PB10106000600,000P

On 02/01/2020 I partially close my position by selling 4 contracts of FTSE 100 Cash Index at a price of 6500.

I will report this trade as a new compressed trade.

ActionExecutionDateTimeUTICounterPartySideQuantityPriceMultiplierPriceOrRateNotionalAmountLevel
P2020-01-02T18:34:00ZE0212345678911234567892ABC12346TS4106500260,000T

At the end of the day I have a position of 6 contracts long in the FTSE 100.  As the number of contracts have changed in my Position from yesterday I need to send a Modification to my position, I include the number of contracts I have left open as the Quantity and update the Notional Value.

ActionExecutionDateTimeUTICounterPartySideQuantityPriceMultiplierPriceOrRateNotionalAmountLevel
M2020-01-01T18:34:00ZE0212345678911234567892ABC12345PB6106000360,000P

All Valuations made are at the position level.

Position Level / Position Lifecycle Reporting with aggregation

Position lifecycle with aggregation means that TRAction will also aggregate your EOD open positions by Counterparty and Instrument.

So, what does position lifecycle with aggregation look like? 

Example

On 01/01/2020 I open two CFD trades, one buying 10 contracts of FTSE 100 Cash Index at a price of 6000, another buying 20 contracts of FTSE 100 Cash Index at a price of 6500.

I report both as compressed trades.

ActionExecutionDateTimeUTICounterPartySideQuantityPriceMultiplierPriceOrRateNotionalAmountLevel
P2020-01-01T18:34:00ZE0212345678911234567892ABC12345TB10106000600,000T
ActionExecutionDateTimeUTICounterPartySideQuantityPriceMultiplierPriceOrRateNotionalAmountLevel
P2020-01-01T19:34:00ZE0212345678911234567892ABC12346TB201065001,300,000T

Both positions remain open at the end of the day, so I aggregate my two positions and use the Volume Weighted Average Price (VWAP) in the price field.

ActionExecutionDateTimeUTICounterPartySideQuantityPriceMultiplierPriceOrRateNotionalAmountLevel
N2020-01-01T18:34:00ZE0212345678911234567892ABCFTSE100B30106333.331,9000,000P

Any subsequent Valuations and collateral updates are made are at the position level.

How does ESMA identify the different reporting methods?

Reporting at Trade Level is identified by using the field and value, Level = ‘T’ in the reports

Reporting at Position Level is identified by using the field and value, Level = ‘P’ in the reports

Action Types that can be used in reports are as follows:

‘N’ — a derivative contract for the first time, in which case it will be identified as ‘new’; 

‘M’ — a modification to the terms or details of a previously reported derivative contract, but not a correction of a report, in which case it will be identified as ‘modify’. This includes an update to a previous report that is showing a position in order to reflect new trades included in that position;

‘E’ — a cancellation of a wrongly submitted entire report in case the contract never came into existence or was not subject to

EMIR reporting requirements but was reported to a trade repository by mistake, in which case, it will be identified as ‘error’;

‘C’ — an early termination of an existing contract, in which case it will be identified as ‘early termination’;

‘R’ – a previously submitted report contains erroneous data Fields, in which case the report correcting the erroneous data Fields of the previous report shall be identified as ‘correction’;

‘Z’ — a compression of the reported contract, in which case it will be identified as ‘compression’;

‘V’ — an update of a contract valuation or collateral, in which case it will be identified as ‘valuation update’;

‘P’ — a derivative contract that is to be reported as a new trade and also included in a separate position report on the same day, in which case it will be identified as a ‘position component’. This value will be equivalent to reporting a new trade followed by an update to that report showing it as compressed.

What do I need to consider before selecting or changing methods?

Clients must also be aware that under EMIR there is Pairing & Matching obligation which requires you to agree on a method of reporting consistent with your counterparty.

From ESMA’s EMIR Q&A:

‘Furthermore, ESMA would like to stress the importance of the general obligation according to which the counterparties need to agree the report’s contents before submitting it to TRs. This obligation stems from the requirement of Article 9(1) of EMIR, ‘counterparties and CCPs shall ensure that the details of their derivative contracts are reported without duplication’ and is specified in the European Commission’s Frequently Asked Questions document Section II Question 5: 

http://ec.europa.eu/internal_market/financial-markets/docs/derivatives/emir-faqs_en.pdf 

Therefore, it should be noted that reporting at position level should be done consistently by both counterparties to the derivative, i.e. it is not allowed that one counterparty reports subsequent updates at trade level, while the other reports those updates at position level. Furthermore, in certain circumstances reporting at position level is the only possible option to comply with EMIR reporting obligations (hence it becomes mandatory in order to report correctly), e.g. when the counterparties are not able to value the individual position components.’

This requirement does not affect reporting trades against individual retail clients as they do not have a reporting obligation, but any transactions executed with a corporate entity (like your Liquidity Provider), with an EMIR reporting obligation, need to be reported using the same method.

Therefore, to stay compliant in pairing and matching you must explain to your counterparty how you will be reporting and share how the ‘UTI’ is made up so they can replicate the reporting model on their side.

What are the advantages of moving to position level reporting?

  • Position level reporting is more likely to coincide with how your liquidity providers report 
  • It is easier to reconcile between raw data files and the submitted reports 
  • May result in reduced costs due to less valuation and collateral reports 
  • Increase efficiency at various stages of reporting due to reduced file sizes
  • Simpler to account for and report different lifecycle events

If you have any questions or would like to report under a particular method please let TRAction know.

Stay in the Know

Sign up to TRAction's newsletter

The Blog

The latest updates on regulatory changes and issues regarding trade/transaction reporting under ASIC, EMIR, MiFIR, SFTR, MAS and other regimes around the world.

View Blog