The Most Common Errors in SFTR Transaction Reporting

SFTR

TRAction’s reporting services include data validation and data enrichment to ensure errors are identified, resolved and meet formatting requirements prior to submitting the data to the Trade Repository (TR). However, there is the odd occasion when we receive incorrect data, which upon submission causes an error at the TR. The content of this article applies to both EU and UK SFTR.

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

1. Incorrect Action Type used for a previously submitted report

This is the most common type of SFTR error that we receive from the TR. The exact error message for this would look as per the below:

What goes wrong?

When we first report a new SFT we report the action type as “NEWT” or “POSC”. If the transaction remains open, the next day when we go to report the collateral updates on this transaction, the action type would then change to “COLU”.

The error arises when the action type isn’t updated on the transaction file that the client provides, and we then submit with an action type of “NEWT” or “POSC” again.

As the error message states, we cannot report this transaction as a new again as this has already been done.

How is this fixed?

Whenever this issue occurs, we contact our client and ask them to update this field in the file they sent to us. Once they have provided the correct action type, we then amend the exceptions and resubmit them to the Trade Repository.

2. Incorrectly formatted dates

We often see our clients populate the date fields incorrectly, with the day and month sections the wrong way around. We get error messages like the below when this happens:

What goes wrong?

This happens when a client incorrectly formats a date field in their file, as they must be reported as ‘YYYY-MM-DD’. Taking the above as an example, if the client populates the Termination date of the SFT as ‘2022-12-03’ (when it should have been ‘2022-03-12), it will lead to an error because we are attempting to report it with a date that is in the future, and therefore later than the actual reporting timestamp of the trade. This of course is not possible and gets rejected. 

Under certain circumstances, incorrectly populated date fields can be mistakenly accepted by the Trade Repository because the system is not able to pick up the error. For example, if a trade date of 3 January 2022 is written as 2022-03-01 and it is a date prior to the submission date, this information would be accepted by the system as 1 March 2022.

How is this fixed?

TRAction can either fix the errors for our clients or get them to amend the incorrect date and re-submit the file. We can then re-process the transaction file 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.

Recent Articles:

EMIR

What is an NFC-?

Entering into derivative transactions, you become a ‘counterparty’.
EMIR introduces two types of counterparties: Financial Counterparties (FC) or Non-Financial Counterparties (NFC).

Repo Agreements
About TRAction

How Are Repurchase Agreements Reported for SFTR?

A repurchase agreement (repo) is a form of short-term secured loan where one party sells securities to another and agrees to repurchase those securities later at a higher price with the securities serving as collateral for the borrower.

EMIR

Refit, Rewrite, RTS, EMIR II; Navigating the Maze of EMIR Version Names

Regulatory reporting is hard enough without the confusion over which version of each regime is the latest. EMIR has gone through a number of variations since it was first implemented in 2012. We thought it would be a great time to outline what the EMIR version names relate to and where we are currently at as we anticipate further changes to the regime.

ASIC

Reminder: Daylight Saving Time Ends this Weekend for New York

Are you reporting trades by New York (NY) time or following NY close of business? If so, it is important to check your trades/transactions are still reported at the correct time now that daylight saving time (DST) has started in the US (13 March 2022).