9 common mistakes with EMIR reporting, do they look familiar to you?

We’ve identified 9 of the most common mistakes that investment firms make in their EMIR reporting. These simple tips aim to help you get it right from the start.

  1. Test accounts erroneously included with live data
  2. Buy vs Sell? Wrong Direction
  3. Wrong instrument classification
  4. Collateralisation
  5. One single deal ID/UTI shared by multiples separate trades
  6. Incorrect use of action type ‘Error’
  7. Incorrect notional amount
  8. Wrong information in Non-Reporting Party Country field
  9. Reporting Timestamp

Test accounts erroneously included with live data

Reporting the trades from test accounts on your trading platform is an easy-to-make mistake. Test trades are not reportable and should therefore be excluded.

What you should do
Ensure the test account trades are excluded when extracting data from your trading platform. Do another check before submitting your trade reports.

Buy vs Sell? Wrong Direction

Many investment firms are confused about whether they should report a particular trade as a buy or a sell, and hence report the direction of the transactions incorrectly.

What you should do
Always ensure the direction of the trade that you are reporting comes from the perspective of your firm and NOT from the perspective of your client. For example, when your client buys a CFD on oil on your platform, it may be recorded as ‘buy’. However, for the purpose of trade reporting as illustrated below, this ‘buy’ status has to be changed to ‘sell’ as the direction of the trade has to come from your perspective.

Wrong instrument classification

ISO 10962 provides guideline on the Classification of Financial Instruments (CFI) code format for financial instruments. Different instruments require different formats. We’ve noticed that many investment firms struggle to get the CFI codes correct.
The CFI codes are considered incorrect if the ‘ * part is substituted with an X. In the example of forwards below, the CFI code is in the format of -J-*-*-X-*-*-. The parts with * needs to be populated in accordance with ISO 10962.

What you should do
You should either:

  • purchase a copy of ISO 10962 and follow the guidelines for correct CFI generation; or
  • get your reporting service provider to populate this field accurately for you.

Collateralisation

The concept of collateralisation can sometimes be hard to understand. In many trade files we receive the collateralisation field is often populated with an incorrect collateralisation type. For example, in our experience, many clients put ‘PC’ when the nature of the trade should be U.

The 4 categories of collateralisation are listed below:

  • Uncollateralised (U)
    ‘U’ is used where no collateral agreement exists between the counterparties, or where the collateral agreement between the counterparties stipulates that the reporting counterparty does not post initial margin or variation margin.
  • Partially collateralised (PC)
    ‘PC’ is used where the collateral agreement between the counterparties stipulates that the reporting counterparty only posts variation margin.
  • One-way collateralised (OC)
    ‘PC’ is used where the collateral agreement between the counterparties stipulates that the reporting counterparty posts initial margin and variation margin and the other counterparty either posts only variation margin or does not post any margin.
  • Fully collateralised (FC)
    ‘FC’ is used where the collateral agreement between the counterparties stipulates that both counterparties post initial margin and variation margin.

What you should do
Ensure you read the description of each category and understand what each type means, then populate the correct type in the collateralisation field in your trade reports. Read our blog article for a further and detailed explanation – Collateral Reporting under EMIR – what is required?

One single deal ID/UTI shared by multiples separate trades

Each trade has its own deal ID/UTI. The deal ID/UTI cannot be shared among different trades, and if that happens, your trade report will be rejected by the Trade Repository.

What you should do
Ensure a particular deal ID/UTI is only reported as a ‘New’ trade once and used in the same trade at all times.

Incorrect use of action type ‘Error’

Often when reporting entities want to correct an error in a previously submitted trade report, they put E – Error under the Action field rather than R – Correction. E – Error should not be used unless you want to cancel a wrongly submitted trade. If you just want to correct an error in a previously submitted report, R – Correction is the right one to be used in the Action field.

What you should do
Familiarise yourself with the description of each action type below and choose the right action type when submitting a trade report.

VALUETITLEDESCRIPTION
NNewA derivative contract reported for the very first time.
MModificationA modification to the economic details of a previously reported contract.
Also applies to any previously reported positions to reflect new trades that are affecting that position.
RCorrectionA correction of erroneous data in a previously submitted report.
EErrorA cancellation of a wrongly submitted transaction (for example, UTI is wrong or the transaction never exists).
Once this has been used, the UTI can never be used again.
CEarly terminationAn early termination of an existing contract.
This is not required if the contract has reached its maturity.
VValuationAn update of a contract/position and/or collateral.
ZCompressionA compression of a previously reported trade.
PPosition componentA derivative contract reported as a new trade and then also included in a separate position report on the same day.

Incorrect notional amount

The contract size for the same financial instrument for different clients can be different. For example, 1 lot for CFD on oil can be 10 for client A, but 100 for client B. Some investment firms get the contract size wrong when populating the Contract Size field, and consequently the value under the Notional Amount field is wrong.

What you should do
Ensure you familiarise yourself with the products you offer to each client and keep your product information up to date.

Wrong information in Non-Reporting Party Country field

The Non-Reporting Party Country field has a default setting such as UK, CY or XX. Often this field is neglected and not updated to reflect the country of your client.

What you should do
Ensure this field is updated to reflect your client’s details.

Reporting Timestamp

We often see that trading time provided by investment firms are not in UTC time but in their local time zone or server time.

What you should do
Ensure you change the trading time from the local time/server time to UTC time before submitting your reports.

If any of these mistakes sound familiar to you, it’s time to improve your reporting process. Please contact us if you have any questions.


UK & Europe Trade Reporting - MiFID II

MiFID II extends the derivative transaction reporting obligations of MiFID to a larger group of businesses. Read More


UK & Europe Trade Reporting - EMIR

EMIR requires all market participants to report details of all derivative contracts (interest rate swaps, FX, credit, equity and commodity) to Trade Repositories. Read More


Australia Trade Reporting - ASIC

Find out more about the requirements for Australian OTC derivatives reporting under the ASIC regime. Read More


Singapore Trade Reporting - MAS

Find out more about the requirements for Singaporean OTC derivatives reporting under the MAS regime. Read More


Hong Kong Trade Reporting - HKMA

The Hong Kong Monetary Authority (HKMA) requires specified OTC derivative transactions to be reported to HKTR. HKMA reporting obligations in relation to retail OTC Derivatives will come into effect from 1 July 2017. Read More