TRAction’s reporting services include data validation and data enrichment to ensure any errors identified are resolved and the format meets requirements prior to ARM submission. The content of this article applies to both EU and UK MiFIR.
We’ve identified the 3 most common errors in the transaction data we receive from our clients.
1. Missing customer details
This is the most common type of MiFIR error. The exact error messages for this type of error can differ depending on the fields concerned.
There are many fields required to be populated for client details. Below are some errors that are most prevalent in relation to missing customer details.
What went wrong?
We get these exceptions because some, or all, of the customer details for these transactions are either missing in our client’s database or not in their client file (if they send one). Also, special symbols or spaces can give an error because they cannot be recognised by LSEG platform (the Approved Reporting Mechanism (“ARM”)).
- Missing client first name
- Missing Buyer ID and Buyer date of birth
How is this fixed?
Whenever there are missing customer details, TRAction contact our client and ask them to update the details in their database or in the files they send on a daily basis. Once the client has provided all the missing details that TRAction need, we then amend the exceptions and resubmit them to the ARM.
The files shared by the client need to be checked to make sure the specific trades that failed do not have any special characters or spaces. If they do, then we just remove them and resubmit them to the ARM with the corrected data.
2. Duplicate transactions
When there is a duplicate transaction in the client data, we get an error message of [Report Status]. See below highlighted in yellow.
What goes wrong?
There are 3 possible reasons behind this ARM exception. See below examples:
(a) Duplication of a transaction –
The client has duplicated a row of data (i.e. a duplicate of a transaction) in the file they send to us.
(b) Reuse of a deal number for different transactions –
The client has reused a deal number that has already been used for another transaction in the file.
(c) Using same trade number for a position with several transactions –
The client has a trade that includes several transactions and the same transaction reference number is used with different quantity and price for the same financial product.
How is this fixed?
For all three scenarios, TRAction will reach out to the client to confirm the data.
In the case where there is a duplicate, we confirm with our clients whether it was added to the file twice by mistake. If it was, we can clear the exception with ARM as it does not need resubmitting.
In the case where a client has mistakenly reused an existing deal ID, we ask them to provide the correct deal ID for the transaction. Once it is provided, we resubmit the exception with the correct information.
In cases where a client is using the same transaction reference number, we inform the client that even if the transactions are for the same trade (i.e. for various legs of the trade), they have to be submitted individually with a unique transaction reference number. Once we have been given the new unique transaction reference numbers, we resubmit the exception with the correct information.
3. Incorrectly formatted dates
We often see our clients populate the Trade Date Time fields in the wrong format. This ARM exception gives an error message of [Trading Date Time]. See below how it appears:
What went wrong?
This happens when a client incorrectly formats an open or close time for a trade in their file. Date formats must be in ‘YYYY-MM-DD’ format, so if the client puts the trading date as ‘2020-24-06’ for a transaction, it will get rejected as it is trying to report it as the 6th of the 24th month, which of course isn’t possible.
However, under certain circumstances, incorrect trading date times are mistakenly accepted by the ARM because the system is not able to pick up the error. For example, if a trade date time of 3 January 2020 is written as 2020-03-01 and it is a date prior to the submission date, this information would be accepted by the system as 1 March 2020.
How is this fixed?
TRAction can either fix the errors for our clients or get them to amend the error and re-submit the file. We can then re-process all the files again once the format is corrected.
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, it’s important to get the raw client data right in the first instance before you submit it 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. We also recommend our clients check if we can automatically extract the details from their platform to minimise the errors that occur when using ‘file submission’ method.
If you have any questions, please feel free to contact us.
