UK EMIR Reporting Update 2025–26: What You Need to Know
The UK EMIR reporting regime is being updated to improve derivatives data quality and consistency, affecting not only banks but also brokers, platforms, fintechs, and crypto firms involved in derivatives reporting.
The UK EMIR reporting framework is undergoing further refinement following new policy statements and consultation materials issued by the Bank of England and the Financial Conduct Authority in 2025. These updates are intended to improve the completeness, accuracy, and consistency of derivatives reporting and affect a broad range of market participants beyond traditional banks, including retail brokers, trading platforms, fintechs, and crypto firms. Building on the UK’s post-Brexit EMIR regime, the changes seek to align data fields, validation rules, and reporting standards across counterparties, trade repositories, and technology providers.
Regulation Overview
Regulation Overview
The United Kingdom’s derivatives reporting framework is entering another phase of refinement. Following the August 2025 publication of the Bank of England (BoE) and Financial Conduct Authority (FCA) Policy Statement, along with a joint Consultation Paper on new reporting Q&As, the UK EMIR framework is shifting once again.
These updates aim to make derivatives data more complete, accurate, and consistent, and the impact extends well beyond banks or clearing firms. Retail brokers, multi-asset platforms, liquidity and bridge providers, and crypto and fintech companies that handle derivatives or margin products are all affected.
The changes build on the UK’s post-Brexit EMIR structure and are designed to ensure that trade repositories, counterparties, and technology intermediaries use aligned data fields, validation rules, and XML schemas when reporting derivatives activity.
Who Is Affected
While EMIR has always applied to counterparties entering derivative contracts, the latest changes have operational and technical implications for a wider ecosystem:
- Retail Brokers: Firms reporting under Article 9 must align systems with new field structures and ensure that execution data, counterparty identifiers, and transaction references meet the updated XML schema.
- Crypto and Digital Asset Firms: Those offering tokenised derivatives, perpetual swaps, or structured products linked to crypto assets must verify data consistency between platforms and TRs.
- Payment and Fintech Providers: Platforms offering embedded derivative exposure (e.g. FX hedging tools) must review whether the products and counterparties trigger EMIR obligations.
- Technology and Liquidity Providers: Reporting vendors, bridge providers, and market makers connecting to multiple brokers or TRs must adapt validation logic, reporting templates, and reconciliation APIs to meet the new XML formats effective January 26, 2026.
In short: anyone facilitating trade execution, clearing, or reporting in UK-linked derivatives must prepare for new data and message-format compliance requirements.
Key Changes Announced in 2025
1. New Reporting Field: Execution Agent
A new mandatory field now captures the identity of the execution agent, meaning the entity that executes the derivative trade on behalf of a counterparty. This affects brokers that rely on third-party liquidity providers or market makers. Reporting systems must ensure that the execution agent is clearly identified in every submission.
| Practical tip: |
| For brokers using external liquidity bridges, the reporting engine must determine whether the liquidity provider or the broker is the “execution agent.” Misreporting this field could trigger data rejection by the TR. |
2. Technical ISINs: Clarity for Complex Underlyings
The draft Q&As clarify when firms can use technical ISINs in derivatives reporting. These apply when the underlying equity has no official ISIN, such as:
- Pre-IPO shares, or
- Custom baskets with non-listed or unidentifiable components.
| Practical implication: |
| Retail trading platforms offering synthetic equity CFDs or custom indices must check whether each underlying has a valid ISIN. If not, a technical ISIN may be used, but only in the “underlying identification” field, not in the ISIN field itself. |
3. FX Swaps Reporting: One Transaction or Two?
The FCA/BoE Q&As also address a persistent industry issue: how to report FX swaps.
- If an FX swap is two FX forwards negotiated together (near and far legs), report them as two separate trades under one package transaction.
- If it’s a single FX swap contract, report it as one trade.
| Example: |
| A retail broker offering rolling FX swaps for margin accounts must check how its trading system classifies such contracts. Misalignment between internal booking logic and EMIR reporting logic can lead to duplicate or missing reports. |
4. Validation Rules and XML Schema Updates
The BoE has released final XML schemas and validation rules for messages to and from trade repositories. These replace earlier versions and ensure consistency between incoming trade submissions and outgoing reconciliation messages.
Timeline and Implementation
| Date | Comment |
|---|---|
| Policy Statement and final validation rules published |
| Consultation on Q&As closes |
| Finalised Q&As expected |
| Implementation date for new reporting standards |
Expert Opinion
“The changes introduced by the FCA and Bank of England represent a welcome improvement for EMIR Reporting in the UK. Subject to internal booking models, the FX Swap is a term that means different things to different firms. The new guidance acknowledges this, and, building on guidance issued in 2018, the changes align more closely with market practice of how FX Swaps, or FX ‘strategy’ derivatives are executed, whilst ensuring clarity for the regulator by providing an accurate view of derivative exposure in the industry.
“The introduction of a ‘Technical’ ISIN implemented with the latest Q&A release is a good example of the FCA and Bank of England listening to industry feedback and implementing practical changes in order to reflect scenarios where an ISIN may not be possible to source or generate. The controlled use of the Technical ISIN helps solve this reporting issue in a way that keeps the regulators and industry content.
“The addition of the Execution Agent into the Margin Tables and other validation rule updates are welcome improvements, which have been consulted on with the industry this year and should not provide a significant reporting challenge for the majority of reporting entities.” -Tim Hartley, EMIR Reporting Director, Kaizen
How the Changes Affect Different Participants
| FX/CFD and Multi-Asset Brokers |
Impact:
Brokers will need to update their EMIR reporting engines to incorporate the new field structures, manage technical ISINs for certain underlyings, and adjust workflows for FX swap reporting.
Key Challenges:
- Identifying the correct execution agent.
- Ensuring consistent data flow between trading platforms.
- Avoiding duplicate submissions for multi-leg transactions.
How to Prepare:
Run test submissions with TRs using the new XML schemas. Update static data mapping for underlying assets. Review client booking logic for FX swaps and synthetic equities.
| Technology, Liquidity, and Market-Making Providers |
Impact:
Firms providing execution or liquidity services to brokers are now more explicitly part of the reporting data chain. The addition of the Execution Agent field and the schema upgrades mean integration layers must transmit new data points accurately.
Key Challenges:
- Rebuilding message templates to support the updated XML.
- Handling reconciliation between broker-side and TR-side data.
- Ensuring seamless data handoff when acting as execution agents or intermediaries.
How to Prepare:
Coordinate early with broker clients to test new schemas. Update APIs and reconciliation dashboards. Validate counterparty identifiers and Legal Entity Identifiers (LEIs).
| Crypto and Tokenised Derivative Platforms |
Impact:
The clarification around technical ISINs matters for crypto-backed or bespoke derivative contracts. Some platforms issue structured products without listed underlyings, meaning custom identifiers must be properly created and documented.
How to Prepare:
Implement a consistent internal method to assign and maintain technical ISINs. Maintain traceability between derivative product codes and underlying identifiers. Ensure crypto-related exposures are properly classified under EMIR scope.
Checklist and Scenarios
- System Updates: Confirm your reporting engine or vendor will support BoE’s final XML schemas by January 2026.
- Field Mapping: Add “Execution Agent” and validate ISIN/technical ISIN logic.
- Reconciliation Testing: Run pre-migration data checks with TRs.
- Documentation: Update internal EMIR procedures and recordkeeping templates.
- Vendor Coordination: Ensure liquidity and tech providers’ data feeds match new formats.
- Training: Educate compliance and operations teams on new Q&A interpretations (FX swaps, ISINs).
Scenario 1. Execution Agent Confusion | |
| A retail FX broker uses an external liquidity bridge connected to a prime-of-prime provider. The broker reports trades to a TR but omits the execution agent field. The TR rejects the file. | |
| ✅ | Solution: Identify whether the prime-of-prime or the broker acts as execution agent and include its LEI in Field 30. Update reporting templates accordingly. |
Scenario 2. Custom Index CFD | |
| A broker offers CFDs based on a custom “Tech 10” index of private companies. No official ISINs exist for several components. | |
| ✅ | Solution: Use a technical ISIN for the underlying identification, not for the product ISIN field, per FCA/BoE Q&A guidance. |
Scenario 3. FX Swap Booking Misalignment | |
| A trading platform books FX swaps as single contracts, but the back office reports two forwards. | |
| ✅ | Solution: Align booking and reporting logic; ensure both sides agree on whether two separate reports or one are required. |
Final Thoughts: Preparing for 2026 and Beyond
The UK EMIR reporting overhaul is not a complete redesign, but it tightens technical standards and clears up long-standing ambiguities that previously led to data mismatches across trade repositories.
For UK brokers, fintech firms, and crypto platforms, the changes are less about a sudden regulatory shift and more about improving data quality and operational accuracy.
Key Takeaways:
Start testing with TRs now, don’t wait until January. Coordinate closely with tech and liquidity partners. Review every product line for proper ISIN handling. Treat the 2026 implementation as an opportunity to improve automation and reconciliation processes.