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 that we receive on a daily basis. 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, and the below are just some errors that we get most regularly.
What goes wrong?
We get these exceptions because some, or all, of the customer details for these transactions are missing in our client’s database, or not in their client file (if they send one).
Missing client first name
Missing Buyer ID and Buyer date of birth
How is this fixed?
Whenever there are missing customer details, we contact our client and ask them to update the details in their database or in the files they send on a daily basis. Once they have provided all the missing details that we need, we then amend the exceptions and resubmit them to the ARM.
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 2 possible reasons behind this ARM exception. See below examples.
(a) Duplication of a transaction
The client has duplicated a row of data (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.
How is this fixed?
For either of the above scenarios, TRAction will reach out to our 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 this exception with the ARM as it does not need resubmitting.
However, 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.
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].
What goes 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.
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 contact us.
