Common ASIC Trade Reporting Errors
Data Enrichment
Compliance Support
Reduce Costs
ASIC Common Errors Videos
TRAction’s reporting services include data validation and data enrichment to identify and resolve errors and to ensure the format meets the relevant requirements prior to trade repository submission.
TRAction has identified the most common errors made in ASIC OTC derivative trade reporting. We walk you through these common errors and provide steps on how to rectify (or avoid) each one.
Only OTC derivatives trades need to be reported
For the purpose of ASIC trade reporting, you are only required to report trades involving OTC derivatives such as options, forwards and CFDs. Hence, it is important that you only submit OTC derivatives-related trade data to your reporting delegate or trade repository.
Check your files to ensure you are excluding all of the following transactions:
- direct stocks and equities;
- direct cryptocurrency transactions (e.g. bitcoin trades which are not CFDs over bitcoin);
- direct Australian Carbon Credit Units (ACCUs); and
- exchange traded derivatives.
Your firm may enter into other transactions which should also be excluded. Make sure you consider your product suite thoroughly when setting up reporting filters.
Reporting all trading platforms and systems
All reportable trades from all trading platforms and systems are required to be reported to ASIC.
ASIC has previously issued fines to AMP and Westpac for not reporting large quantities of OTC derivatives transactions because they had forgotten about entire systems containing the information.
What goes wrong?
TRAction is not informed when a client starts using any additional trading platforms after the onboarding process is complete. As a result, trades from the additional platforms are not reported. It is important to note that this can also apply to firms that do not use a reporting delegate, as a lack of communication between departments can lead to the mis-identification of trades that need to be reported.
How is this fixed?
Check you are reporting trades from all of your platforms and systems. For example, if you have added a new platform – such as cTrader, MetaTrader5 or Bloomberg – make sure you have updated your reporting delegate after onboarding with them or have updated your processes accordingly.
Incorrect Direction Field
What goes wrong?
The direction field is sometimes populated incorrectly. Because this error does not typically prevent a trade from being accepted by the trade repository (the trade still validates and submits successfully), it can go undetected for a long period and affect a very large number of transactions before it is identified.
ASIC issued a $2 million infringement notice to Deutsche Bank for failing to accurately report the direction field for more than 260,000 OTC derivative transactions. ASIC found the failures to be systemic and to reflect deficiencies in the bank’s internal reporting framework.
How is this fixed?
Clients should ensure their systems correctly and consistently populate the direction fields. Conducting spot checks and reconciliations of your reporting against source information can also help to identify this error. Where TRAction identifies inconsistencies or irregular patterns in the direction fields during data validation, we will contact the client to clarify the correct information and, once confirmed, send corrections for the affected trades.
Missing Country of Counterparty 2 details
What goes wrong?
The ‘Country of Counterparty 2’ field is required when the ‘CDE-Counterparty 2 identifier type’ is equal to ‘FALSE’.
How is this fixed?
TRAction will need to contact the client to obtain the country (or country code) for the trade. We can then convert it into the required two-character ISO 3166 code, update the trade details and resubmit it to the trade repository.
UPI & ISIN Reference Errors (Missing or Incorrect Identifiers)
What goes wrong?
ASIC requires the use of Unique Product Identifiers (UPIs) or if a UPI is not available, an International Securities Identification Number (ISIN), a RIC, a MIC or an acronym or full name of the publisher of the rate, price or measure of the underlier of certain derivatives.
This error occurs where the UPI is either omitted or incorrectly formatted in the trade submission.
How is this fixed?
Where the UPI is not provided by your counterparty or you are the product manufacturer, we recommend that you create (where needed) or look up and store the UPI for your OTC derivatives in advance of trading and reporting them.
Lifecycle Event Errors (Incorrect Action Types) and Logical Issues in Trade Data
What goes wrong?
These errors typically arise when lifecycle events, such as amendments or terminations, are reported incorrectly. For example, it is logically incorrect for a maturity date to be set before the execution date of a transaction, and a Termination (TERM) event should not generally be submitted for a trade that has already matured.
There is, however, a narrow exception: under the DTCC operational rules, a TERM event may be submitted after a trade has matured, provided that the event timestamp of the termination is greater than the event timestamp of the latest position, and earlier than the point at which the position has expired or matured.
How is this fixed?
If a trade has matured naturally, a Termination (TERM) action is not necessary. Please ensure that lifecycle events are submitted in the correct sequence as described below:
- NEWT
- MODI
- TERM
You should also ensure that trade amendments follow a logical sequence e.g. execution and maturity dates are in logical order before submission.
Full visibility of your reportable trade accounts (only applicable to clients using MT4 API, MT4 & MT5 linked servers)
Some of TRAction’s clients use the grouping method to organise their clients’ trading accounts into particular categories when reporting for MetaTrader4 (MT4) and MetaTrader5 (MT5).
Trades from certain groups are reportable and some are not. Clients commonly set up different groups for the following purposes:
- their offshore entities
- test accounts
- categorisation of their client types
What goes wrong?
The visibility settings for the groups are inaccurate, for instance, the test accounts have been made visible to the reporting delegate rather than only the reportable trade accounts. Thus, the reporting that follows is incorrect.
How is this fixed?
If you use a grouping method to organise your clients’ trade accounts, it is imperative that you regularly conduct internal reviews to ensure all the reportable trade accounts are visible to your reporting delegate or to your internal team performing your firm’s ASIC OTC derivative trade reporting.
Addition of Symbols
This error commonly occurs when firms launch new financial product offerings.
What goes wrong?
TRAction is not informed of any new symbols relating to new financial products that our clients are trading. If a new symbol is introduced and not yet mapped in our system, trades may still be ingested; however, they may not be correctly classified or enriched for reporting purposes. In such cases, TRAction may liaise with the client to obtain the required product details and update the mapping to ensure accurate reporting, although in most instances the team will source the information and resolve the issue internally.
How is this fixed?
When we identify any new symbol in our clients’ data files, we contact them promptly to request all the required information about the new symbol to avoid any missing trades. If you are using a reporting delegate like TRAction, inform them in advance of any additional symbols before trading them.
If you report on your own, do a regular review to ensure all the financial products that are reportable under ASIC are being reported.
To improve the accuracy of your overall reporting, we encourage you to be diligent with regards to informing your reporting delegate or other internal departments about the introduction of any new platforms, systems or financial products in your business. We also recommend you set aside time to review your system settings and ensure that your reports are generated correctly.
Missing, wrong or duplicate identifier of Non-Reporting Counterparty
Under the ASIC Rules, a legal entity identifier (LEI) is required to be reported for all non-individual accounts, e.g. corporate accounts. For individuals, other identifiers are required, which may be either of the below:
- unique client codes in the format and structure of the LEI of the reporting entity (or execution agent) followed by up to 52 characters (which are to be the individual’s legal name); or
- designated business numbers (e.g. ABN, AVID or BIC) – although these are fairly unlikely.
Often clients do not include any entity identifier or provide the wrong LEI information in their data.
What goes wrong? Examples
- Example 1 – In the table below, we show the 3 position files that have been submitted to TRAction on 1, 2 and 3 March 2026 in relation to the same trade.
For the exact same non-reporting counterparty (e.g. ABC Investments Pty Ltd), the Trade Party 2 – ID field is populated differently.
Position Date Trade Party 2 – Counterparty Side Trade Party 2 – ID Comments 2026-03-01T00:00:00Z sell 454571A9EA7058FJBE37 LEI 2026-03-02T00:00:00Z sell MT4136123 Internal login 2026-03-03T00:00:00Z sell 454571A9EA7058FJBE37 LEI On 1 March, ABC Investments Pty Ltd already has an LEI which is reported in the Trade Party 2 – ID field.
On 2 March 2026, 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 2026, that same field is then reported with the LEI again. Such use of inconsistent entity identifiers will cause issues when TRAction reports trades to the trade repository, leading to erroneous output values.
How is this fixed?TRAction can either fix the errors for our clients in consultation with them or have them amend the error and re-submit the file. TRAction would reach out to confirm the correct counterparty details if these are not currently held. Once received, the team will work on sending a correction for the incorrect trade. TRAction can then re-process all the files once the format is corrected.
- Example 2 – Some firms allow their clients to trade with multiple accounts (logins) resulting in a duplicate of the identifier of their counterparties i.e. for the same Counterparty2name, there are multiple Counterparty 2 identifiers being used in reporting.
How is this fixed?
TRAction will reach out to the client to obtain a single correct unique identifier, linking the back-office account (at the account-holder level) with all of the person’s trading accounts. Once confirmed, the identifier is updated in our systems and corrections are sent for all affected trades.
This should also resolve cases where there are non-named data being reported in the name field like ‘ACC#2(USD)’, as this information would not be present in the back-office entity level record for the account-holder.
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)
The contract size column represents the lot associated with each symbol and may vary (e.g. 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 they 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:
Correct
| Notional Amount | Volume (Quantity) | Price Multiplier (Contract size) | Price |
|---|---|---|---|
| 3000 | 0.01 | 10000 | 30 |
Wrong
| Notional Amount | Volume (Quantity) | Price Multiplier (Contract size) | Price |
|---|---|---|---|
| 30,000,000 | 100 (=10000×0.01) | 10000 | 30 |
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 200,000,000USD (or equivalent in other currencies) is identified during data validation, TRAction will generally clarify the issue with our client and fix any error.
We also recommend firms check if their reporting delegate can automatically extract the product details directly from their platform to minimise the errors that occur when using the ‘file submission’ method.
Timestamp related errors:
What goes wrong?
The critical data element (CDE) Event Timestamp is sometimes not equal to the CDE – Execution timestamp or even earlier in time. This is incorrect since a transaction has to occur or be executed first in time before being able to submit the transaction.
The Event Timestamp therefore must be equal to or greater than (or in other words ‘after’) the specified Execution Timestamp.
How is this fixed?
To avoid these kinds of issues which can sometimes be due to human error, we suggest firms’ standard operating procedures are up to date, there is more automation and less manual handling or entries and extra layers of oversight in regards to the data in files provided to TRAction.
TRAction will contact its clients if these errors or patterns of errors are discovered during the daily data extraction and prior to the submission of transactions to the trade repository.
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. Dates must be in ‘YYYY-MM-DD’ format. Another common issue is where dates are provided in American format instead of European format, or vice versa. See below examples of what is correct and not correct, noting the incorrect format will be an unacceptable input and therefore rejected by the trade repository. At TRAction, we work to identify this incorrect input and reformat the field correctly before submission to the trade repository.
| Trade Date | |
|---|---|
| Correct | 2026-02-24T16:58:27Z |
| Wrong | 24-02-2026T16:58:27Z |
| Trade Date | |
|---|---|
| Client’s source data | 08/02/2026T16:58:27Z |
| If read as European (DD/MM) – Correct | 2026-02-08T16:58:27Z |
| If read as American (MM/DD) – Wrong | 2026-08-02T16:58:27Z |
Errors like this usually occur 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, so a date such as 08/02/2026 can silently be reinterpreted from 8 February to 2 August, or vice versa. 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 flawed Datetime/Timestamp data 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.
UTI format in csv file
This error occurs when the UTI provided does not adhere to the required XML schema. The UTI is a key component in your reconciliation process as it is used to identify trades. If a UTI is formatted incorrectly in your submission files, there will be difficulties in your reconciliation process.
What goes wrong?
UTI issues may include incorrect formatting or having fewer or more characters than required. This formatting issue typically happens when your UTI contains numbers only (example 1 below) or number(s) + E + number(s) (example 2). If you manually process these UTIs 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. See below examples of the error:
| Example 1 – UTI/USI /Deal ID | Example 1 – UTI/USI /Deal ID | |
|---|---|---|
| Correct (How it is supposed to be) | 226179107585160001 | 22617910758516000E1 |
| Wrong (How it could appear in a manually generated csv) | 2.26179E+17 | 2.26E+17 |
See below examples of the structure of how a UTI should look:
Correct UTI format – Post 21 October 2024, every UTI reported as ‘new’ must include the LEI of the entity generating the UTI, followed by a max 32-character trade ID. Additionally, the trade ID should not contain any special characters.
This particular error is difficult to identify as neither the TRAction or DTCC validation tools can know what your UTI is supposed to look like, nor which party is meant to be generating the UTI and therefore the correct LEI for concatenation.
How is this fixed?
Where an issue is identified, TRAction will contact the client to ensure the UTI is provided in the correct format.
Failing to notify your reporting delegate of any addition or removal of liquidity providers (LPs)
This is particularly relevant if you are using a delegate to report your trades. However, it is also applicable to large firms with multiple internal departments.
What goes wrong?
Many brokers change their LPs for commercial reasons throughout the year. Often, TRAction is not aware of the changes in our clients’ LPs. Consequently, the hedge trades related to the new LP are not reported. It is not possible for TRAction’s systems to detect the entire absence of LP transactions from the reporting submitted to us. A lack of communication between departments within an organisation regarding changes in LPs can also result in the same error for those self-reporting.
How is this fixed?
To ensure all of your hedge trades are captured in your reporting, you should conduct frequent reviews of your systems and regularly reconcile your handback files against the raw data as required by Regulatory Guide 251, section 2.2.7 of ASIC Reporting Rule and ASIC Schedule 1 – Technical Guidance. This helps to identify any missing hedged position.
If you are using a reporting delegate, you will need to inform your delegate promptly whenever there is any change to your list of liquidity providers.
TRAction can assist its clients with performing an overall system review. This helps to distil the key factors that need consideration in establishing the trades that need to be reported under the ASIC regime.
Incorrectly rely on single-sided relief
You are only required to submit trades entered into between your Australian entity and:
- your clients/counterparties (compulsory reporting obligations); and
- your hedging counterparties (unless single-sided relief applies). Firms should ensure that they continue to meet the requirements for this relief under the current ASIC rules which were updated from 20 October 2025, or otherwise make arrangements to start reporting).
Often, we receive backloading requests from new (and existing) clients to submit their hedge trades from the past as they failed to report them for a prolonged period of time due to oversight or a misunderstanding of ASIC requirements.
What goes wrong?
The assumption is made that the hedging counterparty is adequately complying with the single-sided relief provisions without any actual communication or confirmation from the LP. Therefore, as single-sided relief is incorrectly relied upon, trades are either not reported at all, or are reported in a way that does not meet ASIC’s requirements.
How is this fixed?
Ensure you have a proper understanding of which transactions should be captured, including which hedging relationships should be reported. Ensure these are properly reflected in the files being sent to TRAction as well as in the handback files received (sometimes we receive instructions from clients to automatically exclude some transactions from files).
Likewise, if you have related offshore or overseas entities, please ensure you are not sending any trades relating to those entities (unless there is a hedging arrangement from the offshore entity to your ASIC entity in place which requires reporting to ASIC) to your reporting delegate or trade repository.
Final Note
It is important to ensure your trade reporting data is correct prior to submission to the trade repository 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.
If you have not been checking the handback or confirmation files received from your reporting delegate or trade repository, see TRAction’s tips on how to carry out that cross-check.
With these simple tips, you will improve your reporting process. If you have any questions or would like to discuss further, please do not hesitate to contact us. Additionally, you can read more on ASIC trade reporting for further information.
Subscribe to our newsletter for regular updates.
Can't find the answers
you're looking for?
Get in touch with us for assistance.