ESMA updates its validation rules (again)

Just when you thought it was safe to set out on holiday with no more reporting changes to worry about, ESMA announced some changes to its EMIR trade reporting validation rules on 9 August.

On first glance, the changes appear fairly innocuous with only five fields impacted:

• Reporting Timestamp; 
• Reporting Counterparty ID;
• ID of the Other Counterparty; 
• Underlying Identification; and  
• Confirmation means.

However, no change to reporting is ever easy for firms or trade repositories (TRs). Although an implementation date of 5 November 2018 gives the industry some time to prepare, it is surprising that the changes come without any warning or consultation. They also come without any explanation of their value to the regulator. This is frustrating as good regulation should result from a robust cost benefit analysis and the industry is going to struggle to understand the benefit of some of these changes.

Let’s take the first change – the ‘Reporting Timestamp’: “The reporting timestamp should be equal or earlier than the timestamp of the receipt of the report by the TR. The date part of the timestamp cannot be earlier than the day preceding the date of the receipt of the report by the TR. The receipt of the report should be understood as the moment the report enters a TR’s system.”

This is probably the biggest change to the industry as many trade repositories don’t ask for firms to populate this field, as the time the firm reports should be exactly the same time the TR receives it. If the TR doesn’t auto-populate this field, it appears to introduce the possibility of error by asking the reporting firm to populate the field itself. If the TRs were to incorrectly populate the reporting timestamp, it would be challenged by the reporting firms, so the regulators would appear to be trying to fix something that isn’t broken.                 

The validation changes to the ‘Reporting Counterparty ID’ and ‘ID of the other Counterparty’ shouldn’t present too many issues as they are both relaxations of the validations. In each case the LEI can have a status of ‘lapsed’ or ‘retired’ where the ‘Action Type’ is ‘C’ (for ‘early termination’), and the LEI no longer has any check on the ‘registration status’ where the Action Type is ‘E’.

The validation changes to the ‘Underlying identification’ appear to be both pointless and risible. The first element allows the special characters of hyphen and full stop where the ‘Underlying identification type’ is ‘A’ for Aii. It is pointless because the Aii code can no longer be used in the ‘underlying identification’ field post MiFIR implementation and it is laughable as the hyphen has always been an integral part of the Aii (i.e. the ESMA validation would have prevented the underlying Aii being reported correctly). The additional characters are also allowed where the underlying identification type is ‘B’ (for ‘basket’) – this would cause issues as the hyphen is also used as the separator for the individual components of a basket.

The final change impacts the ‘Confirmation means’ field which now stipulates that: If field 2.15 [Venue] is populated with a MIC code other than “XXXX” or “XOFF” and field 2.35 [‘Cleared’]is populated with “N”[Not cleared], this field shall be populated with “N”[non-confirmed]. This is sensible and is one of the tests that Kaizen already includes in our EMIR trade reporting quality assurance testing.  We apply more than 450 tests to EMIR reports to check if the data contained within them is accurate.  Our clients can also take advantage of a new Kaizen service which offer clients the opportunity to pre-test their compliance with the new validations through a tool that replicates the ESMA validation scheme.

For further details on our pre-testing validations service and other Kaizen quality assurance services please contact us.