Position vs Trade Level reporting under EMIR – What is the difference?
Under EMIR you are required to report all details of a derivative contract as well as any modification or termination of the contract.
TRAction have 3 different methods of reporting which can be used, depending on how the client’s system works:
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:
Fields | Values |
---|---|
Action | N |
ExecutionDateTime | 2020-01-01T18:34:00Z |
UTI | E0212345678911234567892ABC12345T |
CounterPartySide | B |
Quantity | 1 |
PriceMultiplier | 10 |
PriceOrRate | 6000 |
NotionalAmount | 60000 |
Level | T |
Any subsequent modifications/valuations/collateral updates are made at the trade level.
On 02/01/2020, I modify the Maturity Date with my counterparty. Therefore, I would submit an Action of ‘M’ = ‘Modify’ and the updated Maturity Date.
Fields | Values |
---|---|
Action | M |
ExecutionDateTime | 2020-01-01T18:34:00Z |
UTI | E0212345678911234567892ABC12345T |
CounterPartySide | B |
Quantity | 1 |
PriceMultiplier | 10 |
PriceOrRate | 6000 |
NotionalAmount | 60000 |
Level | T |
On 03/01/2020, I terminate the contract early (not at the maturity date). Therefore, I would submit a report with Action of ‘C’ = ‘Early Termination’ and the updated Maturity Date.
Fields | Values |
---|---|
Action | C |
ExecutionDateTime | 2020-01-01T18:34:00Z |
UTI | E0212345678911234567892ABC12345T |
CounterPartySide | S |
Quantity | 1 |
PriceMultiplier | 10 |
PriceOrRate | 6000 |
NotionalAmount | 60000 |
Level | T |
Position Level/Lifecycle 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 the Position Lifecycle reporting method 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:
Therefore we need to create two reports for 01/01/2020:
1. This compressed trade contains a Termination Date, as upon compression the trade is terminated.
Fields | Values |
---|---|
Action | P |
ExecutionDateTime | 2020-01-01T18:34:00Z |
UTI | E0212345678911234567892ABC12345T |
CounterPartySide | B |
Quantity | 10 |
PriceMultiplier | 10 |
PriceOrRate | 6000 |
NotionalAmount | 600,000 |
Level | T |
2. At the end of the day, my position of 10 contracts in FTSE 100 is still open so I report a New Position with an EOD Valuation. The UTI has been updated to be the Position UTI.
Fields | Values |
---|---|
Action | N |
ExecutionDateTime | 2020-01-01T18:34:00Z |
UTI | E0212345678911234567892ABC12345P |
CounterPartySide | B |
Quantity | 10 |
PriceMultiplier | 10 |
PriceOrRate | 6000 |
NotionalAmount | 600,000 |
Level | P |
On 02/01/2020, I partially close my position by selling 4 contracts of FTSE 100 Cash Index at a price of 6500.
Therefore we need to create two reports for 02/01/2020:
1. I will report this trade as a new compressed trade.
Fields | Values |
---|---|
Action | P |
ExecutionDateTime | 2020-01-02T18:34:00Z |
UTI | E0212345678911234567892ABC12346T |
CounterPartySide | S |
Quantity | 4 |
PriceMultiplier | 10 |
PriceOrRate | 6500 |
NotionalAmount | 260,000 |
Level | T |
2. 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. Therefore, I include the number of contracts I have left open as the Quantity and update the Notional Value.
Fields | Value |
---|---|
Action | M |
ExecutionDateTime | 2020-01-01T18:34:00Z |
UTI | E0212345678911234567892ABC12345P |
CounterPartySide | B |
Quantity | 6 |
PriceMultiplier | 10 |
PriceOrRate | 6000 |
NotionalAmount | 360,000 |
Level | P |
All Valuations made are at the Position level.
Position Lifecycle with aggregation means that TRAction will aggregate your EOD open positions by Counterparty and Instrument (similar to Position level reporting).
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.
Fields | Values |
---|---|
Action | P |
ExecutionDateTime | 2020-01-01T18:34:00Z |
UTI | E0212345678911234567892ABC12345T |
CounterPartySide | B |
Quantity | 10 |
PriceMultiplier | 10 |
PriceOrRate | 6000 |
NotionalAmount | 600,000 |
Level | T |
Fields | Values | |||||||
---|---|---|---|---|---|---|---|---|
Action | P | |||||||
ExecutionDateTime | 2020-01-01T19:34:00Z | |||||||
UTI | E0212345678911234567892ABC12346T | |||||||
CounterPartySide | B | |||||||
Quantity | 20 | |||||||
PriceMultiplier | 10 | |||||||
PriceOrRate | 6500 | |||||||
NotionalAmount | 1,300,000 | |||||||
Level | T |
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.
Fields | Values |
---|---|
Action | N |
ExecutionDateTime | 2020-01-01T18:34:00Z |
UTI | E0212345678911234567892ABCFTSE100 |
CounterPartySide | B |
Quantity | 30 |
PriceMultiplier | 10 |
PriceOrRate | 6333.33 |
NotionalAmount | 1,9000,000 |
Level | P |
Any subsequent Valuations and collateral updates are made are at the Position level.
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 type | Description |
---|---|
N | entering 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 this 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. |
Clients must also be aware that under EMIR there is a Pairing & Matching obligation which requires you to agree on a method of reporting consistent with your counterparty. Please refer to our Pairing & Matching article for more information on this.
If you have any questions or would like to report under a particular method please let us know.
MiFID II extends the derivative transaction reporting obligations of MiFID to a larger group of businesses. Read More
EMIR requires all market participants to report details of all derivative contracts (interest rate swaps, FX, credit, equity and commodity) to Trade Repositories. Read More
Find out more about the requirements for Australian OTC derivatives reporting under the ASIC regime. Read More
Find out more about the requirements for Singaporean OTC derivatives reporting under the MAS regime. Read More
The Hong Kong Monetary Authority (HKMA) requires specified OTC derivative transactions to be reported to HKTR. HKMA reporting obligations in relation to retail OTC Derivatives will come into effect from 1 July 2017. Read More