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.
We’ve identified the most common errors (for both EU and UK EMIR) in the data we receive from our clients:
- Original Not Found
- Invalid Lifecycle Transition
- ‘Valuation timestamp’
- ‘Country of the counterparty 2’ field populated with invalid country code
- UTI reused for a new trade
- Invalid LEI used
Original Not Found
What is “Original Not Found”?
Each trade is assigned a Unique Transaction Identifier (UTI), which is used to track its reporting lifecycle. Every trade or position must be initially submitted with an Action Type of “NEWT” (i.e. new transaction) before any subsequent lifecycle events (e.g. modifications, valuations or terminations) can be applied.
What goes wrong?
If a UTI appears in a submission with a lifecycle event but does not have a corresponding original “NEWT” submission, the TR will reject it as “Original Not Found”.
Example of “Original Not Found” Error
| Execution timestamp | UTI | Action type |
|---|---|---|
| 2020-01-09T20:00:00Z | NZQJG78ABCYBZVYXED | VALU (Valuation) |
In this scenario, the valuation (VALU) action is submitted without a corresponding original trade submission (NEWT), resulting in an error.
How is this fixed?
When a TR identifies a UTI as “Original Not Found,” the resolution depends on the trade’s status:
- Verification with Clients
TRAction will first confirm whether the UTI is indeed reportable. -
Data Resubmissions
If the trade is reportable but was erroneously reported as a modification (MODI) or VALU without a prior NEWT submission, the issue must be resolved by resubmitting the trade with the correct lifecycle sequence. It’s important to ensure that the initial “NEWT” action is properly recorded before any subsequent updates and the client will need to provide accurate details to submit the trade with an Action Type of “NEWT.”
Invalid Lifecycle Transition
What is an Invalid Lifecycle Transition?
Every trade follows a structured lifecycle sequence – once a trade is either terminated (TERM) or has reached its maturity date, it can no longer undergo further modifications or valuations.
If a trade that has been terminated or matured is subsequently submitted with lifecycle events such as VALU, MODI, or correction (CORR), the TR will reject the submission, flagging it as an “Invalid Lifecycle Transition.” A Unique Transaction Identifier (UTI) is used to track the reporting lifecycle.
What goes wrong?
Example 1: Trade Terminated (TERM) followed by an Invalid action type submission
| Reporting timestamp | Execution timestamp | UTI | Action type |
|---|---|---|---|
| 2024-01-02 | 2020-01-09T20:00:00Z | NZQJG78ABCYBZVYXED | TERM |
| 2024-01-03 | 2020-01-09T20:00:00Z | NZQJG78ABCYBZVYXED | VALU (Invalid) |
In this scenario, the trade was terminated on 2024-01-02, and an attempt was made to submit a VALU on 2024-01-03. Since a terminated trade cannot have further lifecycle events, the submission fails with an Invalid Lifecycle Transition error.
Example 2: Trade ‘Maturity date’ passed, but still sending valuations
| Reporting timestamp | Execution timestamp | UTI | Action type | Maturity date |
|---|---|---|---|---|
| 2024-01-02 | 2020-01-09T20:00:00Z | NZQJG78ABCYBZVYXED | NEWT | 2024-01-03 |
| 2024-01-03 | 2020-01-09T20:00:00Z | NZQJG78ABCYBZVYXED | VALU (Valid) | 2024-01-03 |
| 2024-01-04 | 2020-01-09T20:00:00Z | NZQJG78ABCYBZVYXED | VALU (Invalid) | 2024-01-03 |
Here, the trade had a maturity date of 2024-01-03, which means it is considered closed after that date. Any further submissions (such as VALU on 2024-01-04) will be rejected due to an Invalid Lifecycle Transition.
How is this fixed?
When the TR detects an Invalid Lifecycle Transition, the following steps are taken:
- Verification of the Trade Status
TRAction will check whether the trade has matured or was terminated and confirm with our client whether the termination was intentional or a reporting error. - Clarification with the Client and Data Resubmissions
If the trade was mistakenly terminated, TRAction will ask the client to confirm whether the UTI needs to be revived (Action type: REVI) to reactivate the trade.
If the maturity date was incorrect, TRAction will request confirmation of the correct expiration date. Since the UTI has matured, we would have to revive the UTI and submit a CORR with the correct maturity date to ensure the trade follows a logical lifecycle.
Valuation timestamp
Valuation timestamp ensures that valuations reflect accurate and timely market data. It represents the date and time of the last valuation marked to market, provided by the CCP or calculated using the current or last available market price of the inputs.
Valuation timestamp exceptions occur in two different cases based on the action types: NEWT and VALU.
Action type ‘NEWT’ – When the action type is NEWT, the ‘Valuation Timestamp’ is expected to be equal to or greater than the execution date.
- Action type ‘VALU’ – For the action type VALU, the valuation date and time should meet these conditions:
It should not be set to a future date and time. - The timestamp should accurately reflect the market conditions at the time of valuation to avoid misreporting.
Valuation timestamp – Rules
- If the ‘Valuation amount’ is populated, ‘Valuation timestamp’ field should be populated in YYYY-MM-DDThh:mm:ssZ. Otherwise, the field should be left blank.
- The ‘Valuation timestamp’ should be equal to or later than 2014-02-12 and ‘Execution timestamp’.
- The ‘Valuation timestamp’ should not be greater than the ‘Reporting timestamp’.
- The date part of the ‘Valuation timestamp’ should not be greater than the ‘Expiration date’ or, where populated, the early termination date.
- The date part of the ‘Valuation timestamp’ should be equal to the field ‘Event date’.
What goes wrong?
Examples of incorrect ‘Valuation timestamp’:
| Reporting timestamp | Execution timestamp | UTI | Action type | Valuation timestamp |
|---|---|---|---|---|
| 2024-01-02 | 2024-01-01T20:00:00Z | NZQJG78ABCYBZVYXED | NEWT | 2024-01-01T18:00:00Z |
| 2024-01-03 | 2024-01-01T20:00:00Z | NZQJG78ABCYBZVYXED | VALU (Valid) | 2020-01-10T21:00:00Z |
As you can see from the above table in red, these dates and times have occurred prior to the ‘Execution timestamp’ and also the ‘Reporting timestamp’ which cannot be logically possible.
How is this fixed?
When the TR detects Valuation timestamp exceptions, the following steps are taken by TRAction:
- Data Validation
Verify the data provided by clients to check for incorrect timestamps. - Client Confirmation
If discrepancies are found, we confirm the correct date and time with the client. - Trade Resubmission
Once the correct data is obtained, we resubmit the trade with accurate timestamps.
‘Country of the counterparty 2’ field populated with invalid country code
The field ‘Country of the counterparty 2’ 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.
TRAction have 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 where it should actually be “GB”.
| WRONG | CORRECT |
|---|---|
| NonReportingPartyCountry | NonReportingPartyCountry |
| UK | GB |
B. This field is left blank – The customer detail is not obtained or populated during the customer onboarding process.
| NonReportingPartyCountry |
|---|
How is this fixed?
TRAction will contact its clients to obtain the correct customer details and then re-submit the trades once the exception has been fixed.
UTIs reused for a new trade
UTIs are a unique ID assigned to a trade and cannot be reused in 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.
| ExecutionDateTime | UTI | Action |
|---|---|---|
| 2020-01-09T20:00:00Z | NZQJG78ABCYBZVYXED | N (NEW) |
| 2020-06-20T18:00:00Z | NZQJG78ABCYBZVYXED | N (NEW) |
How is this fixed?
When the TR identifies a duplicate UTI, TRAction clarify with our clients whether the same UTI is being reused for a new trade or should in fact be unique. 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.
Invalid LEI used
Where the action types under EU EMIR and UK EMIR are NEWT (New), MODI (Modify), CORR (Correct), VALU (Valuation), POSC (Position component) and MARU (Margin update) (for EU EMIR only), the field ‘Counterparty 1 (Reporting Counterparty)’ must contain a valid LEI which is maintained in the GLEIF database. This is a common issue 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.
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 ‘Counterparty 1 (Reporting Counterparty)’ 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 an example 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 LEI (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 TR 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 so the renewal can be monitored.
- 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 the transaction report to be incorrect and therefore rejected by the TR.
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 on communication to fix errors in your EMIR trade reporting, it’s important to get the raw data right before you submit it to the TR or to 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.
