In this edition of our EMIR REFIT review we explore some of the new fields and changes to existing fields introduced by ESMA under EMIR refit, specifically the fields regarding lifecycle events namely: Action Type, Event Type and Event Date.
ESMA has revised its approach to the reporting of lifecycle events and introduced the Event Type field. With this approach lifecycle events will be reported by 2 dedicated fields, Action Type and Event Type. Where the Action type field declares what is the content of the given report, and Event Type field provides information about the type of business event triggering a given report. This should provide the regulator with a more complete picture of the lifecycle event reported.
Below are the updated Action Type Table and the New Event Type Table applicable under EMIR REFIT.
Action Type
| Action type | Definition |
| NEWT = New | A report of a derivative, at a trade or position level, for the first time. |
| MODI = Modify | A modification to the terms or details of a previously reported derivative, at a trade or position level, but not a correction of a report. |
| CORR = Correct | A report correcting the erroneous data fields of a previously submitted report. |
| TERM = Terminate | A Termination of an existing derivative, at a trade or position level. |
| EROR = Error | A cancellation of a wrongly submitted entire report in case the derivative, at a trade or position level, never came into existence or was not subject to Regulation (EU) No 648/2012 reporting requirements but was reported to a TR by mistake, or a cancellation of duplicate report |
| REVI = Revive | Re-opening of a derivative, at a trade or position level, that was cancelled with action type ‘Error’ or terminated by mistake. |
| VALU = Valuation | An update of a valuation of a derivative, at a trade or position level. |
| MARU = Margin update | An update of data related to margins (collateral). |
| POSC = Position component | A report of a new derivative that is included in a separate position report on the same day. |
Event Type
| Event type | Definition |
| TRAD = Trade | Conclusion of a derivative or renegotiation of its terms that does not result in change of a counterparty. |
| NOVA = Step-in | An event, where part or entirety of the derivative is transferred to another counterparty (and reported as a new derivative) and the existing derivative is either terminated or its notional is modified. |
| COMP = PTRR | Post-trade risk reduction exercise. |
| ETRM = Early termination | Termination of a derivative, at a trade or position level. |
| CLRG = Clearing | Clearing as defined in Article 2(3) of Regulation (EU) No 648/2012. |
| EXER = Exercise | The exercise of an option or a swaption by one counterparty of the transaction, fully or partially. |
| ALOC = Allocation | Allocation event, where an existing derivative is allocated to different counterparties and reported as new derivatives with reduced notional amounts. |
| CREV = Credit event | Applies only to credit derivatives. A credit event that results in a modification of a derivative, at a trade or position level. |
| INCP = Inclusion in position | Inclusion of a CCP-cleared derivative or CfD into a position, where an existing derivative is terminated and either a new position is created or the notional of an existing position is modified. |
| CORP = Corporate Event | A corporate action on equity underlying that impacts the derivatives on that equity. |
| UPDT = Update | Update of an outstanding derivative performed during the transition period in order to ensure its conformity with the amended reporting requirements. |
As clarified by ESMA counterparties should use action type ‘Modify’ to report modifications of the details of a derivative, ‘Valuation’ to report changes in the value of a derivative and ‘Margin update’ to report modifications of the corresponding collateral.
Counterparties should also ensure that the action types ‘Modify’ and ‘Correct’ are used correctly. In particular, ‘Modify’ should be used to report modifications to the terms or details of a previously reported derivative, and should not be used to report corrections of details of derivatives – only ‘Correct’ should be used for that purpose.‘Margin update’ should be used to report the collateral for the first time as well as to report modifications of the collateral data, but not the corrections of the previously reported collateral details which should be made with action type ‘Correct’.
It is also worth noting the reports sent by the other party to the trade do not impact allowable action types reported by the first counterparty. It applies in particular to action type ‘Error’, meaning that if one counterparty submitted ‘Error’ for a given UTI (and has not reported ‘Revive’ afterwards), only that counterparty will not be able to send further reports (other than ‘Revive’) for this UTI. In this way, if one counterparty reports ‘Error’ by mistake, it will not prevent the other counterparty from timely reporting relevant lifecycle events.
ESMA also confirmed that action type ‘Revive’ can be used to re-open derivatives cancelled (with action type ‘Error’), terminated by mistake (with action type ‘Terminate’) and to reopen derivatives that reached (incorrectly reported) maturity date.
Below we look at some Action Type and Event type combinations and how they should be applied to some of the common reporting scenarios.
| Action Type | Event Type | Applicability |
| New | Trade | When a derivative with a new UTI is created for the first time through trade and not because of another prior event. |
| New | Inclusion in position | When a new position is created by inclusion of trades in that position for the first time. |
| Modify | Trade | When a derivative or position with an existing UTI is modified due to renegotiation of the terms of the trade, because of the changes to the terms of the trade agreed upfront in the contract (except for when such changes are already reported e.g. notional schedule) or because previously not available data elements become available. |
| Modify | Early termination | When a derivative or position with an existing UTI is modified due to an early termination agreed in advance or due to a partial termination. |
| Modify | Inclusion in position | When a position with an existing UTI is modified because of inclusion of a new trade. |
| Modify | Update | When a derivative or position that is outstanding on the reporting start date is updated in order to conform with the amended reporting requirements. |
| Correct | No event type required | When a derivative or position with an existing UTI is corrected because of an earlier submission of incorrect information. |
| Terminate | Early termination | When a derivative or position with an existing UTI is terminated due to an early termination (and when no other cause/event is known as the reason for that termination). |
| Error | No event type required | When a derivative or position with an existing UTI is cancelled due to an earlier submission of incorrect information. E.g. this is used to cancel the UTI of a derivative or position that should not have been reported (e.g. it is not a derivative transaction). |
| Revive | No event type required | When a derivatives or position that has been cancelled is reinstated due to an earlier submission of incorrect information. E.g. this is used to reinstate the UTI of a derivative or position that has been erroneously terminated. |
| Valuation | No event type required | When data related to the valuation are submitted for a derivative or position with an existing UTI. |
| Margin update | No event type required | When data related to the collateral are submitted for a derivative or position with an existing UTI. |
| Position component | No event type required | When a new derivative is concluded and included in a position on the same day. |
For the complete list provided by ESMA please see the Final Report, section 4.6.2 Action types and event types combinations
Event Date
We are already familiar with this field from SFTR, and ESMA confirmed that it should be implemented consistently with the SFTR reporting requirements. This field is applicable to all reports and should refer to the date when a given event took place or when a modification became “effective” (rather than to the date of agreement to modify the trade).
At position level, this field should be populated when relevant events or modifications relating to the position took place. The actual reports should be submitted by the end of the working day following the event date. In the case of valuation updates, the counterparties should send daily valuations by the end of the working day following the date of the valuation and populating the date of valuation date in the field ’Event date‘. It should be equal to the date part of the field ‘Valuation timestamp’.
| Action type | Event date |
| New | Date of conclusion of the derivative or date of creation of a position |
| Modify | Effective date of modification |
| Correct | Date from which the correction should apply (typically the date for which previous incorrect data was reported) |
| Terminate | Date on which termination becomes effective |
| Error | Date of reporting of Error |
| Revive | Date of reporting of Revive |
| Valuation | Valuation date |
| Position component | Date of conclusion of the derivative and of its inclusion in the position |
| Margin update | Expected settlement date of the margin |
Finally it should be noted the trade repositories will take into account the lifecycle events based on the logical order derived from the fields ‘Event date’, ’Action type‘ and ’Event type‘. The trade repositories will also update the Trade State report based on the latest information for a given derivative as derived from the field ’Event date‘ field.
References
Final Report – Technical standards on reporting, data quality, data access and registration of Trade Repositories under EMIR REFIT
Final Report – Guidelines for reporting under EMIR
