Common ASIC Errors

Data Enrichment

Compliance Support

Reduce Costs

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.

We’ve identified the most common errors made in ASIC OTC derivative trade reporting. In this article, we will walk you through the common errors and provide steps on how to rectify each one.

1. Reporting all trading platforms and systems

All reportable trades from all trading platforms and systems are required to be reported to ASIC.

In recent years, ASIC 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?

We are 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 same mistake.

How is this fixed?

Check you are reporting trades from all of your platforms and systems. For example, have you added MetaTrader5 or another platform and forgotten to update your reporting delegate or processes?

If you are using a reporting delegate, remember to inform them of your new platforms.

2. Full visibility of your reportable trade accounts (only applicable to clients using MT4 API, MT4 & MT5 linked servers)

Some clients use the grouping method to organise their clients’ trading accounts into particular categories. Trades from certain groups are reportable and some are not. Clients commonly set up different groups for the following purposes:

  1. their offshore entities
  2. test accounts
  3. 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 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 the team doing your ASIC OTC derivative trade reporting.

3. 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 files, our system will fail to recognise the new symbol and consider it a non-reportable product. This can result in missing trades.

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 regard 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.

4. 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 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, 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.

5. 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:

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 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.

6. 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
Correct 2021-02-24T16:58:27Z
Wrong 24-02-2021T16:58:27Z

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.

7. 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 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

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.

8. Not informing your reporting delegate of any addition/removal of liquidity providers

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 are not aware of the changes in our clients’ LPs.  Consequently, the hedge trades related to the new LP are not reported. 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 and section 2.2.7 of ASIC Reporting Rule. This helps to identify any missing hedged position.

If you are using a reporting delegate, you’ll need to inform your delegate promptly whenever there is any addition or removal 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.

9. Incorrectly rely on single sided relief

You are required to submit over-the-counter (OTC) derivative trades entered into between:

  • you vs clients/counterparties (compulsory reporting obligations); and
  • you vs hedging counterparties (unless single sided relief applies).

 

Often, we receive backloading requests from new 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.

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.

We encourage you to be aware of the errors above as it is not possible for our systems to detect the entire absence of LP transactions from the reporting submitted to us. If you have any questions, please do not hesitate to contact us.

Contact Us

Can’t find the answers you’re looking for? 

Reporting with TRAction

TRAction's Integrations

If you’re considering passing the burden of reporting over to a delegated third-party, like TRAction, you’re probably wondering, “Can they connect to our current trading platform?”
Find out about TRAction’s reporting integrations to automate your daily obligations.
LEARN More

SERVICES

Find out how TRAction can assist you and alleviate the burden on your team when it comes to regulatory reporting.
Learn how we can help you.
Learn more

PRICING

TRAction’s pricing is always competitive and it’s even better when the services are of high quality.
Download our pricing below.
LEARN MORE