EMIR-errors

TRAction’s reporting services include data validation and data enrichment to ensure any errors identified are resolved and the format meets trade repository and regulatory requirements prior submission.

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

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

1. NonReportingPartyCountry field populated with default country code

The field NonReportingPartyCountry should be populated with a valid ISO 3166 country code (2 alphabetical characters) if the field NonReportingPartyIDtype is populated with CLC. CLC is used if the counterparty is a natural person, otherwise an LEI would be populated if the counterparty is a non-individual.

What goes wrong?

If this field is not correctly populated, it gets automatically populated with the default country code XX when we run the client data for submission, which is then identified as an exception during submission.

We’ve observed 2 common reasons behind this error:

A. The wrong country code is used

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

EMIR-errors-Table1

B. This field is left blank

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

EMIR-errors-Table2

Default country code

EMIR-errors-Table3

Correction

EMIR-errors-Table4

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.

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

EMIR-errors-Table5

How is this fixed?

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) and P (Position component), the field ReportingPartyLEI must contain a valid LEI which is  maintained in the GLEIF database.

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.)

What goes wrong?

If the LEI populated in the ReportingPartyLEI field is not valid, this means the status is “lapse”, “annulled”, “retired”, “merged”, “duplicate”. Therefore an exception will be raised during submission.

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

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:

  • check the status of the LEIs during customer onboarding and make a note of the expiry date in their system
  • 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.

Russell Nethercot

Russell works in our London office. At TRAction, he provides operational support to the processing team alongside working on developing new relationships and improving the experience for existing clients. Russell has 15 years’ experience in the exchange-traded and over-the-counter derivatives markets, and has worked for some of the biggest investment organisations in London. He has a strong client-facing outlook and works to ensure the day-to day running of client transaction reporting is smooth.