EMIR Refit Gotcha: Client Codes Should Not Contain Personal Data
Key Takeaways
- Regime Divergence: EMIR Refit client-code construction differs materially from MiFIR, so firms cannot safely reuse identifier logic across both reporting regimes.
- Privacy Constraint: EMIR Refit requires client identifiers to be unique to the reporting counterparty while explicitly excluding personal data from the code itself.
- Cross-Functional Risk: Teams responsible for both EMIR and MiFIR face heightened error risk if they assume superficially similar fields follow identical conventions.
- Implementation Requirement: Client-code logic must be separated by regime to prevent sensitive data from leaking into EMIR Refit reports operationally.
- Control Priority: Firms should review identifier design early because client-code mistakes create both compliance exposure and direct data-protection concerns globally.
EMIR Refit client identifiers must be unique to the reporting counterparty and must not contain personal data. This differs from MiFIR conventions and requires firms to implement separate client code logic across regimes.
As preparation has started for EMIR Refit, many regulatory reporting teams are cross-functional and may be involved in implementation of various regimes including MiFIR and EMIR. Whilst familiarity of multiple reporting regimes may be of benefit in aiding understanding of the requirements, there are some distinct differences between seemingly similar fields and the expectations of the required data. Therefore, it is important to be aware of the differences when navigating the details.
Client Codes Should Not Contain Personal Data
Client Codes, in EMIR Refit, are internal identifiers used to identify individuals in transaction reporting.
The construction of those identifiers in EMIR Refit transaction reporting is different from the conventions adopted in MiFIR reporting. In MiFIR, the Client Code is a composition of various pieces of personal data, in EMIR Refit, however, the ESMA guidelines clearly state that the identifiers should be unique at the level of the reporting counterparty (Counterparty 1) and should not contain any personal data. Therefore, the same identifier created for MiFIR should not be used in EMIR Refit reporting. (220)
Regulatory reporting teams responsible for delivering both EMIR and MiFIR should ensure that the client codes are different between the two regimes and personal sensitive data are not included in EMIR Refit reports.
How Qomply can help
Qomply’s Regulatory Reporting Hub combines regulatory expertise with AI, automation and data analytics to deliver scalable, audit-ready reporting intelligence that reduces errors, lowers remediation costs, and minimises operational and regulatory risk.
Covering regimes including MiFIR, EMIR Refit, SFTR, CFTC, CSA, MAS, ASIC and HKMA, Qomply also offers a fully managed service and operates globally from London.
Frequently asked questions
-
The gotcha is that EMIR Refit client codes must not contain personal data. The article says the identifiers must instead be unique at the level of the reporting counterparty.
-
It differs because MiFIR client codes can be constructed from pieces of personal data, while EMIR Refit identifiers should not contain personal data. The article says firms should not reuse the same client-code logic across both regimes.
-
It says cross-functional reporting teams responsible for both EMIR and MiFIR need to pay attention. The article presents this as a regime-specific field difference that can easily be missed.
-
It warns against that because the EMIR Refit identifier should be unique to Counterparty 1 and should not include personal sensitive data. The article says using a MiFIR-style code would therefore be inconsistent with ESMA's EMIR Refit guidance.
-
They should make sure client codes used for EMIR Refit are different from MiFIR codes and contain no personal data. The article says firms need separate regime-specific logic for these identifiers.