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