TRAction's reporting services include data validation and data enrichment to identify and resolve errors as well as ensure the format meets 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 in relation to OTC derivatives such as options, forwards and CFDs. Hence, it's 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 ACCUs; and
- Exchange traded derivatives.
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 of any additional trading platforms that our clients use 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 financial services firms who 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, have you added a new platform and forgotten to update your reporting delegate or processes e.g. cTrader, MetaTrader5, Bloomberg?
If you are using a reporting delegate, remember to inform them of any new platforms you may be using after onboarding with them.
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 our 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)
This error commonly occurs when firms launch new financial product offerings.
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), RIC, MIC or 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 getting your reporting service provider to 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 Trada Data
What goes wrong?
These errors typically arise when lifecycle events, such as amendments or terminations, are reported incorrectly. For example, it is not permitted to submit a Termination (TERM) event for a trade that has already mature. It would also be logically incorrect for a maturity date to be set before the execution date of a transaction.
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's 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 the new financial product that our clients are trading. If a new symbol is not added to our system prior to the processing of the daily trade files received, TRAction's system will not be able to recognise the new symbol. This will require the TRAction team's involvement to add a new symbol after liaising with the client for further details.
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 don't 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 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 2021-03-01T00:00:00Z sell 454571A9EA7058FJBE37 LEI 2021-03-02T00:00:00Z sell MT4136123 Internal login 2021-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, 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, 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 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 provide firms with a template which links the back-office account (at the account-holder level) with all of the person's trading accounts. This template will likely be populated by exporting from the firm's back-office system. This should also fix the issue where there are non-named data being reported in the name field like 'ACC#2(USD)', as this information wouldn't 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)
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 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. Date formats must be in 'YYYY-MM-DD' format. 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 | 2021-02-24T16:58:27Z |
| Wrong | 24-02-2021T16: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. 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 doesn't 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?
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 |
226179107585160001 |
22617910758516000E1 |
|
Wrong |
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.
How is this fixed?
Where an issue is identified, TRAction will contact the client to ensure the UTI is provided in the correct format.
Not informing your reporting delegate of any addition/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, noting that this relief will change slightly from 20 October 2025 onwards and firms should ensure that they still qualify for the relief after that date 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 either the oversight or 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, no trades are reported or they are not completed according to 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 haven't been checking the handback or confirmation files received from your reporting delegate or trade repository, see TRAction's tips on how you can do the cross-check.
With these simple tips, you'll 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.
Sign up to our newsletter for regular updates.
The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.