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 EMIR data we receive from our clients:
- Country of the other Counterparty field populated with invalid country code
- UTI reused for a new trade
- Invalid LEI used
1. Country of the other Counterparty field populated with invalid country code
The field Country of the other Counterparty 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
| WRONG | CORRECT |
|---|---|
| Country of the other Counterparty | Country of the other Counterparty |
| UK | GB |
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.
| Execution Timestamp | UTI | Action Type |
|---|---|---|
| 2020-01-09T20:00:00Z | NZQJG78ABCYBZVYXED | N (NEW) |
| 2020-06-20T18:00:00Z | NZQJG78ABCYBZVYXEDN | N (NEW) |
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 Reporting Firm ID 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.)
What goes wrong?
If the LEI populated in the Reporting Firm ID 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.
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.
