The 3 Most Common EMIR Reporting Errors

The 3 Most Common EMIR Reporting Errors

TRAction’s reporting services include data validation and data enrichment to ensure any errors identified are resolved and the format meets Trade Repository (TR) and regulatory requirements prior to submission. The content of this article applies to both EU and UK EMIR.

We’ve identified the 3 most common errors in the data we receive from our clients:

  1. NonReportingPartyCountry field populated with invalid country code
  2. UTI reused for a new trade
  3. Invalid LEI used

1. NonReportingPartyCountry field populated with invalid country code

The field NonReportingPartyCountry should be populated with a valid ISO 3166 country code (2 alphabetical characters).

What goes wrong?

When this field is not correctly populated, it gets identified as an exception either during TRAction’s internal validation before submission or during submission to the TR.

We’ve observed 2 common reasons behind this error:

A. The wrong country code is used

EMIR Error 1

One common example is that “UK” is easily mistaken as the country code where it should actually be “GB”.

B. This field is left blank

The customer detail is not obtained or populated during the customer onboarding process.

How is this fixed?

We will contact our clients to obtain the correct customer details. We then re-submit the trades once the exception is fixed.

2. UTIs reused for a new trade

Unique Transaction Identifiers (UTIs) are a unique ID assigned to a trade. It cannot be reused by another trade.

What goes wrong?

Some clients mistakenly recycle and reuse the UTI from an old trade for a new trade. This issue gets flagged as an exception by the TR validation system during TR submission.

In the example below, the same UTI is used twice for two different trades.

EMIR Error 2

How is this fixed?

When the TR identifies a duplicate UTI, we clarify with our clients whether the same UTI is being reused for a new trade. Where the same UTI is reused, we ask our clients to supply a new UTI. Where the UTI is not actually being reused, we check with our clients if the Action field is populated incorrectly.

3. Invalid LEI used

Where the action types are N (New), M (Modify), R (Correction), Z (Compression), V (Valuation) and P (Position component), the field ReportingPartyLEI must contain a valid LEI which is maintained in the GLEIF database. This is a common issue especially where our clients report on behalf of their counterparty under a delegated reporting arrangement or on behalf of their NFC- (Non-Financial Counterparties that are not subject to the clearing obligation) under EMIR Refit.

So, what is a valid LEI? The status of the LEI on the GLEIF database must show either:

  • issued;
  • pending­ transfer; or
  • pending archival.

(See the examples below from GLEIF.)

Invalid LEI used

What goes wrong?

If the LEI populated in the ReportingPartyLEI field is not valid, an exception will be raised during TR submission by the TR validation system. 

The invalid LEI could either mean:

  • the LEI does not exist; or
  • its status is “lapsed”, “annulled”, “retired”, “merged”, or “duplicate”.

Often a reporting counterparty is not aware of the status of its counterparty’s LEI especially when the LEI has recently expired (i.e. “lapsed”). Please see below the screenshot taken from GLEIF website.

Often a reporting counterparty is not aware of the status of its counterparty’s LEI

How is this fixed?

Once this error is identified during submission, we contact our clients and advise them to liaise with their clients to renew their LEIs (either our clients renew the LEI on behalf of their clients or their clients do it on their own). The trade with this error can only be re-submitted to the trade repository after the LEI is renewed.

We suggest our clients:

  • Lapsed LEI – check the status of the LEIs during customer onboarding and make a note of the expiry date in their system.
  • Non-existent LEI – Copy and paste the LEI directly from the GLEIF database rather than manually enter the LEIs into their database in order to minimise any transcription error which results in invalid LEIs. We have seen instances where a “Z” has mistakenly been entered as a “2” and “O” entered as “0” causing the LEI sent in transaction reporting to be incorrect and therefore rejected by the trade repository.

What do you need to do?

In order to minimise the burden on your operations and compliance teams and also reduce time spent on back and forth communication to fix errors in your EMIR trade reporting, it’s important to get the raw data right in the first instance before you submit it to the trade repository or your delegated reporting service provider such as TRAction.

Take the time to review your system settings to ensure the reports are being generated correctly to improve your reporting today.

If you have any questions, please feel free to contact us.

Recent Articles: