The Most Common ASIC Reporting Errors in 2022 – Part 2


It is important to ensure your trade reporting data is correct prior to submission to the trade repository (DTCC) or your reporting service provider such as TRAction. This will minimise the burden on your operations and compliance teams, and reduce time spent fixing errors that could have been avoided.

TRAction has identified four commonly occurring errors in the data we receive from firms. Look out for the following errors in your reporting data to avoid unnecessary mistakes.

1. Missing or wrong identifier of Non-Reporting Counterparty

An entity identifier (such as LEI/AVID/BIC) is required to be reported for all non-individual accounts, e.g. corporate accounts. Often clients don’t include any entity identifier or provide the wrong LEI information in their data.

What goes wrong?

In the example below, there are 3 position files submitted to TRAction on 1, 2 and 3 March in relation to the same order.

For the exact same non-reporting counterparty (ABC Investments Pty Ltd), the Trade Party 2 – ID field is populated differently.

Position Date Trade Party 2 - Counterparty SideTrade Party 2 - IDComments
2021-03-02T00:00:00ZsellMT4136123Internal login

On 1 March, ABC Investments Pty Ltd already has an LEI which is reported in the Trade Party 2 – ID field.

On 2 March, the Trade Party 2 – ID field is populated with the internal login number of ABC Investments Pty Ltd instead of their LEI.

On 3 March, the field is then reported with the LEI again. This causes issues when TRAction report trades to DTCC leading to erroneous output values.

How is this fixed?

TRAction can either fix the errors for our clients in consultation with them or get them to amend the error and re-submit the file. We can then re-process all the files once the format is corrected.

2. Wrong notional amount

There are 2 common reasons why the field Notional Amount 1 is reported incorrectly.

What goes wrong?

  • Wrong price multiplier (contract size)

Different platforms use different contract sizes such as 1, 100 or 10000. When a firm offers multiple platforms, they can easily be confused about what the correct contract size is as they move between platforms. They may therefore provide TRAction with the wrong contract size in all or parts of the files submitted. As a result, the value of the Notional Amount can be incorrectly generated for reporting. ASIC may identify this issue when the notional amount is above their trigger levels and make further inquiries.

The Notional Amount is calculated as follows:  Volume (Quantity) x Price multiplier (contract size) x Price

  • Wrong Volume (Quantity)

Sometimes clients have mistakenly already taken into account the contract size when they provide the volume/quantity.

For example:


Notional AmountVolume (Quantity)Price Multiplier (Contract size)Price


Notional AmountVolume (Quantity)Price Multiplier (Contract size)Price
30,000,000100 (=10000x0.01)1000030

How is this fixed?

This issue is difficult to detect as OTC derivative trades can occur across a wide range of sizes. However, as a result of previous issues with incorrect multipliers, if any notional amount above 100,000,000 is identified during data validation, TRAction will generally clarify the issue with our client and fix any error.

We also recommend our clients check if TRAction can automatically extract the product details directly from their platform to minimise the errors that occur when using the ‘file submission’ method.

3. Incorrect Datetime/Timestamp format

We often see our clients populate the Datetime/Timestamp fields in the wrong format, some of these being:

  • Trade Date
  • Original Execution Timestamp
  • Confirmation Date Time
  • Valuation Datetime Clearing Datetime

The validation requirement for these fields is YYYY-MM-DDTHH:MM:SSZ.

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. If the client puts the date as ‘24-02-2021’ for a trade when it is supposed to be ‘2021-02-24’, it is considered an unacceptable input and will be rejected by DTCC. At TRAction, we identify this incorrect input and reformat the field correctly before submission to DTCC.

 Trade Date

This issue usually occurs when the file has been opened in excel and then saved. The datetime/timestamp data is automatically formatted to the system time of the user’s computer when opened in excel. When clients are making manual changes to files in excel, they should be mindful of the implications that it will have on the formatting within the spreadsheet.

How is this fixed?

TRAction can either fix the errors for our clients or get them to amend the error and re-send the file. We recommend clients resubmit their file in csv format so that the raw data itself is correct. TRAction will then re-process all the files again once the format is corrected.

4. UTI/USI format in csv file

This error only happens when you manually edit the csv files for reporting using Microsoft Excel. UTI/USI is a key component in your reconciliation process as they are used to identify trades. If a UTI/USI formatted incorrectly in your submission files, you may find difficulties in your reconciliation process.

What goes wrong?

This formatting issue typically happens when your UTI/USI contains numbers only (example 1 below) or number(s) + E + number(s) (example 2). If you manually process these UTI/USI from your trading platforms/systems in Microsoft Excel (either by copying/pasting to a csv file or editing an automatically generated csv file), it gets converted in the form of E/exponent of 10. The wrong figure is then submitted to DTCC and is unlikely to be identified as an error during submission.

 Example 1 – UTI/USI /Deal IDExample 1 – UTI/USI /Deal ID
(How it is supposed to be)
(How it could appear in a manually generated csv)

How is this fixed?

This particular error is unlikely to be picked up by our internal validation nor DTCC’s as the validation tool does not know what your UTI/USI is supposed to look like.

Automatic generation of csv files from trading platforms helps to avoid this issue. We generally recommend our clients connect to us via linked server or API.

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. This will minimise the burden on your operations and compliance teams and also reduce time spent on back and forth communication to fix errors in your ASIC OTC derivative trade reporting.

TRAction’s reporting services include data validation and data enrichment to identify and resolve errors, as well as adjust the format so it meets trade repository and regulatory requirements prior to submission.

If you have any questions, please feel free to contact us.

Article Author:


Stay in the Know

Recent Articles:

Reporting Millisecond

Do You Need to Report (MiFIR) Trade Time in Milliseconds?

When reporting transactions to regulatory bodies, there are variations in the data format that is required from region to region.  An example of this difference is the accuracy of the timestamp that is deemed acceptable. Under MiFID II/ MiFIR,milliseconds are required in an attempt to increase the transparency and detail of the information passed to the regulator.

Want to know why over 400 firms report their trades through TRAction?

Contact us to simplify your trade and transaction reporting.