Since the updates to UK & EU EMIR in 2024, one of the main recurring issues in CFD reporting is in relation to how firms create and use client identifiers for ‘Counterparty 2’ clients. The confusion seems to be from mixing platform client login IDs with the client code required by EMIR. Also, using different local IDs for the same person across trading platforms adds to this problem.
Why does EMIIR require a ‘Unique’ Client Code or Identifier?
EMIR requires that counterparties that are legal entities have a legal entity identifier (LEI). For those counterparties that are natural persons and not eligible for an LEI, firms must generate a client code in line with the EMIR Implementing Technical Standards (ITS). The client code must consist of the reporting counterparty’s LEI with an internal identifier as allocated by the firm. The result should be that the same client is always reported under a single identifier, despite the platform, account or login used. This prevents duplication of Counterparty 2 in the trade reports.
What is EMIR’s approach to internal client identifiers?
Each counterparty must have a single and consistent identifier to avoid duplication and reconciliation breaks. Ultimately, the aim is to have greater data quality and transparency across multiple platforms and systems. EMIR’s approach to internal clients is also similar to that of ASIC (for more information, please see our article here).
How does this issue arise?
Below are examples of how a ‘Counterparty 2’ client may have various platform IDs and logins under their relevant Unique Client ID and legal name given they are using multiple trading platforms:
| Unique ID (master) | Legal name | Platform | Login / Platform ID |
|---|---|---|---|
| 456778882 | John Doe | MT4 Standard | 434543 |
| MT4 Pro | 434545 | ||
| MT5 | 566566 | ||
| cTrader | 777755 | ||
| IRESS | 867677 |
When should the Unique Client ID be created?
The Unique Client ID should ideally be created at the time when an account is first opened by a client (including the completion of their KYC). It is typically stored in a back-office system or customer relationship management (CRM) system.
It is important to note that the unique ID must come from the broker. TRAction cannot generate the MasterID from the platform-specific IDs previously received, since the linkage of multiple logins to a single individual is not possible.
TRAction’s approach to client identifiers
TRAction provides its clients with a template which links the back-office account (at the individual/entity level) with all of the individual/entity’s trading accounts. This template will likely be populated by firms exporting from their back-office system. This should also correct the issue where there are non-named data being reported in the name field like ‘ACC#2(USD)’ as such information would not be present in the back-office account level record for the relevant person.
How can TRAction assist?
If you require assistance in understanding the technical detail required for EMIR, SFTR or MiFIR or have any other questions regarding your trade reporting obligations, please contact us.
