Preparing for EMIR REFIT – Optional Fields Becoming Mandatory
With the REFIT getting its 2024 go-live date last month (link), this month we are back with the EMIR REFIT preparation blog series. One of the coming changes is a large increase in reportable fields as they grow from 123 to 203. While much of the spotlight is on new fields being introduced, part of the REFIT update in technical standards covers changes to existing fields. Many of the fields remain the same but have new values. Others were optional or conditional and now become mandatory.
In today’s blog we look at these latter set of fields. The field review is part of the analysis work by my colleague Alex Rhodes, Senior Regulatory Reporting Product Manager at S&P Global Market Intelligence Cappitech, where he leads a lot of the work internally and for customers to prepare for the REFIT. Below are a list of the related fields and their changes (please note that final draft changes from ESMA may result in slight variations to validation rules).
Optional becoming mandatory or updated conditions
Report submitting entity ID (Field 1.2): Optional field becoming mandatory. It is currently used when a 3rd party or counterparty is submitting the report on behalf of the reporting entity. Self-reporting firms will now need to enter their LEI into submission
Clearing threshold counterparty 1 (Field 1.7): Currently only a mandatory field for Non-Financial Counterparties (NFC) that become required for Financial Counterparties (FC) as well
Report tracking number (Field 2.2): Optional field becoming conditional in cases where transaction was traded on a venue with a MIC code (XOFF and XXXX trades excluded).
Name of the underlying index (Field 2.16): In cases of where the underlying of a contract is an Index without an ISIN, it is mandatory to fill in free text the index name provided by the index provider. Currently, only reporting an ISIN is mandatory as Index name isn’t required to be entered.
Settlement currency 1(Field 2.19): Previously optional and now becomes mandatory for all Cash settled transactions
Collateral portfolio indicator (Field 2.26): This is a True/False field that was previously conditional to the collateralization type and now becomes mandatory across collateral values
Master Agreement type (Field 2.34): Currently optional field that becomes mandatory across multiple action types. Similar to SFTR where this field is required.
Becoming mandatory across all message types
Product classification (Field 2.4): The CFI code moves from a mandatory field for only the NEW action type messages to now becoming mandatory for all lifecycle action messages
Contract type (Field 2.1): Similar to the CFI code and becomes a required field across lifecycle action messages
Asset class (Field 2.11): As above becomes mandatory for all lifecycle events
Delivery type (Field 2.47): As above becomes mandatory for all lifecycle events
Notional amount of leg 1 (Field 2.55): As above becomes mandatory for all lifecycle events
Stay up to date with all of our EMIR preparation blogs