CP25/32: Improving the UK transaction reporting regime

Consultation Paper
CP25/32
Improving the UK transaction reporting regime November 2025

How to respond
We are asking for comments on this Consultation Paper (CP) by 20 February 2026. You can send them to us using the form on our website. Or in writing to:
Markets Reporting Team
Financial Conduct Authority
12 Endeavour Square
London E20 1JN
Telephone:
0207 066 1000
Email:
cp25-32@fca.org.uk
Disclaimer
When we make rules, we are required to publish:

a list of the names of respondents who made representations
where those respondents consented to the publication of their names,
an account of the representations we receive, and
an account of how we have responded to the representations.
In your response, please indicate:
if you consent to the publication of your name. If you are
replying from an organisation, we will assume that the respondent is the organisation and will publish that name, unless you indicate that you are responding in an individual capacity (in which case, we will publish your name),
if you wish your response to be treated as confidential. We will
have regard to this indication, but may not be able to maintain confidentiality where we are subject to a legal duty to publish or disclose the information in question. By responding to this publication, you are providing personal data to the FCA, including your name, contact details (including, if provided, details of the organisation you work for), and any opinions expressed in your response. This data will be used by the FCA to inform regulatory policy and rulemaking, in the public interest and in the exercise of official authority under FSMA and other applicable legislation. The FCA may share personal data where necessary to perform their public tasks and to support regulatory cooperation and joint policy development. Please note that we will not regard a standard confidentiality statement in an email message as a request for non-disclosure. Irrespective of whether you indicate that your response should be treated as confidential, we are obliged to publish an account of all the representations we receive when we make the rules. Further information on about the FCA’s use of personal data can be found on the FCA website at: https://www.fca.org.uk/privacy. All our publications are available to download from www.fca.org.uk. Request an alternative format Please complete this form if you require this content in an alternative format. Or call 0207 066 1000 Sign up for our news and publications alerts See all our latest press releases, consultations and speeches.

Contents
Chapter 1 Summary Page 4
Chapter 2 The wider context Page 8
Chapter 3 The shape of the regime Page 13
Chapter 4 Scope Page 22
Chapter 5 Content of transaction reports Page 45
Chapter 6 Obligations on trading venues Page 70
Annex 1 Questions in this paper Page 83
Annex 2 Cost benefit analysis Page 89
Annex 3 Compatibility statement Page 120
Annex 4 Abbreviations in this document Page 126
Annex 5 List of non-confidential respondents Page 129
Appendix 1 Draft Handbook text Page 130

Chapter 1
Summary
Why we are consulting
1.1 Transaction reports are critical for our work to enhance market integrity. We use the
data for a range of functions, including detecting and investigating market abuse, preventing financial crime, monitoring the functioning of financial markets, supervising firms, shaping effective policies and supporting our response to crises.
1.2 The Markets in Financial Instruments Regulation (MiFIR) transaction reporting rules
were introduced in 2018 and onshored from the European Union (EU) on 31 December
2020. The Treasury has said it will repeal these rules, enabling us to deliver a streamlined
framework that will cut costs for business while ensuring effective regulatory oversight of our world-leading capital markets.
1.3 This Consultation Paper (CP) outlines our proposed changes to transaction reporting
requirements as part of this work. Among other things, these aim to reduce the regulatory burden on firms, support UK economic growth, increase our ability to fight financial crime and protect market integrity.
1.4 We also outline a cross-authority vision on a new long-term approach to streamlining
transaction reporting requirements across different regimes. These include requirements in the UK European Market Infrastructure Regulation (EMIR) and the UK Securities Financing Transactions Regulation (SFTR). Who this applies to
1.5 You should read this CP if you are:

A Markets in Financial Instruments Directive (MiFID) investment firm or credit
institution with transaction reporting obligations.
A UK branch of a third country investment firm with transaction reporting obligations.
The operator of a UK trading venue (recognised investment exchange (RIE),
multilateral trading facility (MTF) or organised trading facility (OTF)).
A systematic internaliser (SI).
An approved reporting mechanism (ARM) or approved publication arrangement (APA).
A counterparty subject to Article 9 of UK EMIR or Article 4 of UK SFTR.
A trade repository (TR) registered or recognised under UK EMIR.
A firm authorised under the Alternative Investment Fund Managers Directive (AIFMD)
or the Undertakings for Collective Investment in Transferable Securities (UCITS).
A market data service provider.
An investment firm employee responsible for making investment or
execution decisions.
A trade association representing any of the above groups.
A professional adviser to these groups.
What we want to change
1.6 Our proposals include:
Reducing the number of transaction reporting fields from 65 to 52.
Removing reporting obligations for 6 million financial instruments which are only
tradeable on EU trading venues.
Removing foreign exchange (FX) derivatives from the scope of reporting
requirements, reducing costs for over 400 UK firms.
Reducing the default back reporting period from 5 to 3 years. This will lower the
number of transaction reports that need to be resubmitted to us by a third.
Requiring trading venues to populate fewer fields in their transaction reports,
simplifying information provided by over 1,700 international firms when accessing UK markets.
Reducing the number of instrument reference data fields from 48 to 37.
Removing the obligation on systematic internalisers to submit instrument reference
data. Systematic internalisers currently submit more than a third of the instrument reference data we receive.
1.7 We also propose to give additional clarity about specific reporting requirements to
improve reporting efficiencies, cut costs and support better data quality.
1.8 Our proposed changes affect the following UK technical standards:
Commission Delegated Regulation (EU) 2017/590 (RTS 22)
Commission Delegated Regulation (EU) 2017/585 (RTS 23)
Commission Delegated Regulation (EU) 2017/580 (RTS 24)
1.9 We will replace these technical standards with new rules in our Market Conduct
Sourcebook (MAR). We have kept references to RTS 22, RTS 23 and RTS 24 in this CP to show how existing rules will be affected. Outcomes we are seeking Supporting growth
1.10 Our work aims to support growth through proportionate regulation and better data to
help us fight financial crime and strengthen market integrity.
1.11 Complete, accurate and timely transaction reports help us identify and disrupt financial
crime. We want to clarify and streamline transaction reporting requirements so firms can improve the quality of data they submit. We expect the proportion of complete, accurate and timely transaction reports to increase as a result.

1.12 This should make markets cleaner. Clean markets support economic growth by
improving trust, confidence and participation. They enable efficient capital allocation and better risk management. This reduces the cost of capital for firms in the real economy.
1.13 Transaction reports give us detailed information about financial markets. While we
aim to support growth by reducing the regulatory burden on firms, we are keeping requirements we need to:

Help our ongoing monitoring of the health and functioning of UK markets. This
means we can act where we identify potential harms or dysfunction.
Identify concentration risk and shape crisis responses.
Help us design policy and innovate.
Proportionate regulation
1.14 We are taking a more proportionate approach to the data we ask for. Proportionate
regulation aims to align firms’ regulatory costs with expected regulatory benefits. This should make the UK financial services industry more attractive to participate in. It should improve competition and support our secondary international competitiveness and growth objective.
1.15 We have assessed the proportionality of every aspect of the transaction reporting
regime. This includes the specific reporting fields firms must complete, which financial instruments they must report on and which firms the rules apply to. We propose to remove or adapt requirements we assess as adding costs on firms which may be disproportionate to our use of the data. We estimate this could lead to annual savings of over £100m for firms. Smarter regulation
1.16 The Treasury intends to repeal and replace existing firm-facing provisions on transaction
reporting with the rules proposed in this CP. We want to create a more agile framework for transaction reporting by consolidating requirements in one place. This will allow us to adapt more quickly in future to changes in markets and technologies.
1.17 We want to collect data from firms in a cost-efficient way. In some areas, this means
improving the relevance and quality of information in transaction reports. This will reduce how often we need to make ad hoc requests for data from firms. In other areas, we may use precise and targeted ad hoc requests for information instead of transaction reporting.
1.18 Many firms we supervise are subject to reporting regimes in other jurisdictions. We have
been mindful of this when making our proposals.
Measuring success
1.19 We need data to supervise firms and markets. In developing our proposals, we have
made difficult choices where data is valuable to us but the cost of reporting is high. Some of these choices rely on us getting insights from other available data. While

this supports our ambition to be smarter and make our systems and processes more efficient, we need to measure the impact of our proposed choices carefully. In some areas, we may require more data.
1.20 We will measure success by continuing our monitoring of data quality before and after
the changes. We will use existing analytical metrics and management information on data quality, such as report acceptance rate, error alert ratios and corrective reporting ratios. We will also track trends in data quality through our supervisory work.
1.21 We will monitor the ongoing value transaction reports provide. To do this, we will
evaluate outcomes from work using transaction reports, such as market abuse surveillance, investigations and firm supervision. We will seek feedback on how far our proposals have achieved their intended outcomes. Environmental, social & governance considerations
1.22 In developing this CP, we have considered the environmental, social and governance (ESG)
implications of our proposals and our duty under ss.1B(5) and s.3B(1)(c) of the Financial Services and Markets Act (FSMA) to have regard to contributing towards the Secretary of State achieving compliance with the net-zero emissions target under s.1 of the Climate Change Act 2008 and environmental targets under s. 5 of the Environment Act 2021. Overall, we do not consider our proposals are relevant to contributing to those targets.
1.23 We will keep this under review during the consultation period and when considering
whether to make the final rules. In the meantime, we welcome your input on this. Equality and diversity considerations
1.24 We have considered the equality and diversity issues that may arise from the proposals
in this CP. We do not consider the proposals materially impact any of the groups with protected characteristics under the Equality Act 2010 (in Northern Ireland, the Equality Act is not enacted but other antidiscrimination legislation applies).
1.25 We will continue to consider the equality and diversity implications of the proposals
during the consultation period and will revisit them when making the final rules. In the meantime, we welcome your input on this. Next steps
1.26 Annex 1 lists the questions we would like feedback on. Please send us your views and
comments by 20 February 2026. We will consider the feedback provided when we decide our final rules.
1.27 You can send us your comments using the form on our website. If you cannot use the
form, contact us at cp25-32@fca.org.uk to discuss other ways to respond.

Chapter 2
The wider context
Background
2.1 The integrity of our wholesale financial markets is supported by several transaction and
post-trade reporting regimes. These include the UK MiFIR transaction reporting regime and reporting requirements in UK EMIR and SFTR.
2.2 This data is key to our strategy to fight financial crime, support sustained economic
growth and be a smarter regulator. We use transaction reports to detect, investigate and prevent market abuse. Market participants have greater trust and confidence in clean markets, free from market abuse and financial crime. This leads to greater participation and investment, encouraging innovation and supporting sustained economic growth.
2.3 Complete, accurate and timely data also gives us the information we need to monitor
financial markets and firms. We share UK MiFIR transaction reports with the Bank of England to support their work to monitor liquidity in core markets. These capabilities are more important now than ever, with predictable volatility a fixture of global markets.
2.4 Transaction and post-trade reporting requirements are part of a wider group of data
firms submit. These include reporting requirements under the UK Alternative Investment Fund Managers Regulations (AIFMD) and UK Regulation on wholesale Energy Market Integrity and Transparency (REMIT). Where we can, we combine data to increase our coverage of markets, generate new insights and share these between public authorities.
2.5 However, we know that reporting data puts a high cost on firms. We estimate that firms
spend £493m every year meeting UK MiFIR transaction reporting requirements alone. These costs can increase when there is regulatory change and when changes result in divergence between reporting requirements in different regimes and jurisdictions. The drivers for change
2.6 We have identified opportunities to reduce the cost of reporting while maintaining
the value of the data. In November 2024, we published a Discussion Paper (DP24/2) to develop our understanding of these opportunities.

2.7 We received 55 responses from a range of market participants, supplemented by
discussions at our Transaction Reporting Forum in January 2025. A strong theme in the responses was to minimise duplicative reporting between UK MiFIR and EMIR. The MiFIR, EMIR and SFTR reporting regimes were developed to serve different regulatory purposes. Their implementation followed different timelines in the EU. This has led to several problems:

Some transactions must be reported several times, and to several regulators, each
fulfilling different regulatory purposes.
Different regimes define or apply similar reporting fields and guidelines inconsistently.
The types of firms which have reporting obligations under each regime is distinct
but overlapping. This creates duplication and confusion for some firms on their reporting obligations.
We do not regularly use some of the information we collect under these regimes,
creating a potentially disproportionate cost on firms.
Markets and technologies have evolved faster than reporting requirements.
This creates data gaps, which compromise our ability to carry out comprehensive market oversight. Our new long-term approach
2.8 We are establishing a new, long-term approach to address these issues. Along with the
Bank of England, we aim to:
Reduce unnecessary duplication in transaction and post-trade reporting, ensuring
all requirements are proportionate to their benefit.
Maintain our ability to gain actionable insights from data needed to support our
respective statutory objectives.
2.9 Our goal is to create a streamlined and harmonised framework for transaction reporting
across regimes, free from unnecessary duplication. This will involve future consultations alongside the Bank of England on the UK EMIR and SFTR regimes.
2.10 It will take time to achieve this. Transaction and post-trade reporting requirements are
complex. Legislation, regulatory technical standards and guidelines need to be reviewed carefully, across several regimes and by several authorities. Adequate implementation times must be provided to enable firms to make changes as efficiently as possible.
2.11 Together with the Bank of England, we have considered if we could achieve our aims
by replacing the transaction reporting regimes in UK MiFIR, EMIR and SFTR with a new, single-template reporting regime. This ‘report once’ principle could maximise reporting efficiency by ensuring that firms report data on all financial transactions once to a central data repository.

2.12 Our initial work suggests implementation costs for a major restructure of reporting
systems and processes would not be proportionate to the benefits of a more streamlined regime. The current regulatory framework for transaction and post-trade reporting requires some firms to report information more than once. But it also allows us to tailor requirements more efficiently to different firms, transactions and risks. For example, many reporting requirements for securities financing transactions in SFTR are distinct from those for derivatives under MiFID and EMIR.
2.13 Most firms do not have to meet reporting obligations under multiple regimes. These
firms are unlikely to support changes that lead to a more complex single reporting regime. Figure 1 shows the number of firms categorised by their reporting obligations under UK MiFIR, EMIR and SFTR based on 2024 data. Less than 8% of firms must report transaction and post-trade data under more than 1 regime. These firms are also many of the largest firms in the market, responsible for submitting 85% of the transaction and post-trade data we receive.
Figure 1: UK firms categorised by reporting obligations
2.14 So we propose a gradual transition towards a more streamlined framework for reporting
across regimes. We will reduce duplication, harmonise requirements and ensure our rules are proportionate, while maintaining the existing, well-established reporting structure under UK MiFIR, EMIR and SFTR. Our approach aims to minimise change costs for firms.

2.15 To ensure a coherent and predictable path towards this framework, we will approach this
work with a consistent set of principles:
Figure 2: Principles for the long-term collection of transaction and post-trade data
Data should only be collected where needed
A firm should only report data once
Data should be shared where appropriate
We will be clear when, where and why we need data. We will stop collecting data where it is disproportionate to do so. This principle will not stop us from collecting more data where there are gaps and regulatory needs. We must maintain our ability to get actionable insights from data to deliver our statutory objectives. We will use data smartly to serve multiple purposes. This will reduce the need for firms to report data more than once. We will enrich and supplement reports with publicly available data where possible to reduce reporting costs. We will continue to share data with public and overseas authorities where gateways and agreements exist, improving our oversight of markets and enabling us to reduce the burden on firms. We will harmonise data definitions and support alignment with international data standards for efficient data sharing.
2.17 We will apply these principles to our other work to improve the data we collect from
firms. For example, we want to transform our regulatory data model for asset managers and funds to make the regime more proportionate, remove unnecessary reporting and incorporate global data standards. Where gaps exist, we may require more data to monitor for concentration and leverage that could damage market integrity or financial stability. We want our requirements to be proportionate for firms of different sizes, and supplement the data we collect under UK MiFIR, EMIR and SFTR. Next steps
2.18 The proposals in this CP do not remove all duplication or achieve complete harmonisation
of requirements. This can only be addressed through a longer-term review of requirements across several regimes, involving the Treasury and Bank of England.
2.19 We plan to publish a Policy Statement finalising our new transaction reporting rules in
the second half of 2026. We will confirm an implementation period for the changes in our Policy Statement. Based on feedback received to date, we expect this to be around 18 months. We will consult on transitional provisions and consequential amendments to our Handbook in due course.
2.20 We will also be establishing a cross-authority and industry working group to inform the
design of our long-term approach. We will give further information about the terms of reference and application process for this group in 2026 Q1.

Question 1: Do you agree with the proposal to streamline and harmonise existing transaction and post-trade reporting regimes? Question 2: Do you agree with the 3 principles for the long-term collection of transaction and post-trade data? Question 3: Would you support an 18-month implementation period for the changes proposed in this Consultation Paper?

Chapter 3
The shape of the regime
Introduction
3.1 In DP24/2 we sought feedback on the overall shape of the transaction reporting regime.
Themes raised included harmonising and aligning with other reporting regimes, general problem areas for firms and new technologies. This chapter outlines our responses. Harmonising with other wholesale market reporting regimes
3.2 There are overlapping requirements in the transaction reporting regime and other
reporting regimes, such as UK EMIR and SFTR. We sought feedback on changes we could make to the transaction reporting regime to reduce duplication and align requirements. Feedback received
3.3 All respondents agreed that a firm should only report data once, with different
proposals for achieving this. One response recommended combining the UK MiFIR, EMIR and SFTR reporting requirements into a single template. Others recommended a sequenced approach to removing overlap and duplication between different regimes, with the ambition that transactions are not reported more than once.
3.4 Some respondents proposed removing the requirement for buy-side firms to submit
transaction reports. We discuss this further in Chapter 4.
3.5 Other requirements seen as duplicative included:

Requirements for financial instruments which can only be traded on EU trading
venues. We discuss the geographic scope of reportable instruments in Chapter 4.
Duplicative field content, such as the requirement to report information which can
be identified from the classification of financial instrument (CFI) code. We discuss this in Chapter 5.
Firms providing data to meet trading venues’ order record keeping requirements,
while also having to report some of the same information to us in their transaction reports. We cover this in Chapter 6.
3.6 Respondents supported aligning field names, definitions, guidance and validation rules
across UK EMIR and MiFIR. Examples included:
Reporting conventions and approaches for FX forwards and swaps. We explore FX
derivative reporting in Chapter 4.
The definition of a ‘complex’ or ‘package’ trade. We cover this in Chapter 5.
A consistent approach for reporting quantity and price notations. We discuss this in
Chapter 5.
3.7 One respondent said they would not want additional fields to be added to UK MiFIR to
align more with UK EMIR. Calls for alignment were generally for reporting fields that already exist in both regimes.
3.8 There was support for aligning, consolidating or simplifying identifiers used in UK
MiFIR and EMIR. As well as identifiers for financial instruments, covered in Chapter 4, respondents mentioned transaction identifiers such as the transaction reference number (TRN), unique transaction identifier (UTI) and trading venue transaction identification code (TVTIC). They felt there were too many identifiers and they should be simplified. Our proposal
3.9 There are clearly opportunities to reduce duplication and improve harmonisation
between different reporting regimes. Where we can address these as part of this review, we have done so.
3.10 We will keep other suggestions under review as we develop our longer-term approach to
reporting across different regimes.
Approved reporting mechanisms (ARMs) and trade repositories (TRs)
3.11 Transaction reports can be submitted to us via a UK-authorised ARM or directly by
investment firms and trading venues to our Market Data Processor (MDP). Post-trade reports under UK EMIR and SFTR must be submitted to a TR. Meanwhile, APAs publish post-trade transparency reports on behalf of investment firms.
3.12 Some respondents to DP24/2 suggested we should move from an ARM submission
model to a TR submission model. They argued this could lower costs for firms subject to reporting obligations under both UK MiFIR and EMIR and reduce perceived complexities with ARM connectivity. They also noted that TRs offer functionality such as pairing and matching.
3.13 We have also had feedback suggesting we should mandate the use of an ARM to prevent
unregulated firms and third-party service providers from submitting transaction reports to us on behalf of investment firms.
3.14 We would like to clarify that unregulated firms are not able to submit transaction reports
to us. This can only be done by an investment firm, trading venue or ARM. Additionally, unregulated firms cannot take responsibility for transaction reporting data quality. Investment firms that submit transaction reports directly to us are responsible for the completeness, accuracy and timely submission of the reports, regardless of any arrangements they have with third parties.

Our proposal
3.15 We know the current fragmented infrastructure between reporting regimes increases
costs for firms. However, the current regulatory framework gives firms a choice on how to meet their reporting obligations. We have an objective to promote competition because of the benefits effective competition gives consumers, firms and the wider economy. We view choice as important to encourage competition between firms and ensure high quality service provision to clients.
3.16 Under Article 26(7) of UK MiFIR, TRs can act as an ARM. Investment firms can fulfil their
obligations under both UK MiFIR and EMIR where they report a transaction to a TR in line with Article 9 of UK EMIR where the following conditions are met:

The TR is approved as an ARM.
The reports contain the details required to meet transaction reporting requirements.
3.17 We will add these rules to MAR 14.9. Currently, no TRs provide this service in the UK.
3.18 We do not propose any changes to the ARM or TR models at this stage. We will explore
why many market data infrastructure firms are not currently providing services across different reporting regimes. We will also continue to work closely with ARMs and TRs to ensure they provide a high quality of service to clients. Aligning with non-UK reporting regimes
3.19 In DP24/2 we discussed the balance between streamlining our transaction reporting
regime and maintaining alignment with similar regimes in other jurisdictions. We emphasised that data should only be reported where it is useful. Simpler rules should enable firms to provide higher quality information and reduce the time they spend resolving problems with data.
3.20 However, streamlined requirements could reduce alignment with other jurisdictions’
reporting obligations, potentially affecting system alignment and data quality. Feedback received
3.21 Many responses highlighted the benefits of regulatory alignment with the EU. They said
this would help reduce implementation costs and improve reporting efficiencies and data quality. Some firms encouraged us to consider potential EU changes when deciding an approach for the UK regime, especially for coordinating implementation timelines.
3.22 Some firms noted they operate a single transaction reporting system across the UK and
EU. For these firms, significant divergence would lead to increased costs, with changes likely to require a split of reporting systems and logic. However, more firms told us they already operate separate reporting systems and would be able to cope with divergence more comfortably.
3.23 Respondents also commented that harmonisation for its own sake would not be
beneficial. For example, some raised concerns with the potential implementation of

a chain identifier, or the possibility of reporting a TVTIC for trading venues outside of the UK or EU.
3.24 Respondents identified some areas as particularly sensitive to regulatory divergence.
These included messaging standards (such as the ISO 20022 XML) and identifiers for over-the-counter (OTC) derivatives.
3.25 When considering international alignment and competitiveness, many respondents
asked us to consider requirements in other major financial centres. They considered transaction reporting regimes in the United States, Japan, Hong Kong and Singapore to be effective. In some cases, these regimes were seen as placing a lower burden on firms, particularly where single-sided reporting was used.
3.26 Respondents said requirements should be defined and represented consistently where
the same data element is reported in multiple jurisdictions, in line with globally agreed standards. They felt alignment with IOSCO’s Committee on Payments and Market Infrastructure (CPMI) Critical Data Elements (CDE) was desirable.
3.27 On balance, most firms thought benefits from improving the UK regime would outweigh
potential costs from any resulting divergence with international reporting requirements. This was universally true amongst firms that did not have to meet transaction reporting obligations outside of the UK. Our proposal
3.28 We want to ensure close alignment with global data standards to increase transparency,
reduce reporting burdens, enable more effective market monitoring and efficient intelligence and data-sharing between public authorities.
3.29 We have considered the impact of divergence from reporting requirements in other
jurisdictions. In some areas, we intend to ensure continued alignment. In other areas, where we feel the benefits to UK market participants outweigh costs from divergence, we are pursuing changes.
3.30 In June 2025, the European Securities and Markets Authority (ESMA) published a
Call for Evidence on a comprehensive approach to simplifying financial transaction reporting. This highlighted many similar themes to those in this CP. We will review future developments to EU transaction and post-trade reporting requirements as we decide our final policy choices. This includes maintaining dialogue with EU regulatory authorities. Areas of challenge for firms
3.31 In DP24/2 we sought views on which areas of the transaction reporting regime firms
find most challenging. We explained that some requirements perceived as burdensome may be necessary to support our statutory objectives. However, where we get limited benefit from information which has a disproportionate reporting cost, we would remove or adapt requirements.

Feedback received
3.32 Some of the key technical challenges firms raised were discussed in DP24/2. We have
covered this feedback in Chapter 5. Examples include:

Complex trades.
Equity swap reporting.
Country of branch fields.
Name give-up broking.
3.33 Respondents also raised challenges in other areas of the transaction reporting regime:
Back reporting – operational costs from the current requirement to resubmit (‘back
report’) transaction reports affected by errors and omissions over a retrospective period of 5 years. Resubmitted transaction reports account for 9% of all reports submitted to us. Some respondents asked us to introduce a new ‘amend’ function to enable them to correct transaction reports more efficiently. Other respondents suggested we could apply more discretion around the requirement to back report. For example, by limiting back reporting requirements to specific fields or a shorter time-period.
Exclusions – complexity in deciding when an exclusion from the meaning of a
transaction applies. Corporate actions were highlighted as a complex area.
Systems and controls – calls for clearer guidance on when firms should submit
breach notifications for errors or omissions in transaction reports. Back reporting Our proposal
3.34 We are streamlining the transaction reporting regime to ensure we only collect
information we need. This will result in fewer reporting fields, reducing the cost of maintaining relevant data for back reporting.
3.35 We consider that all remaining reporting fields should be treated with equal importance
from a data quality perspective. It follows that back reporting requirements should be applied consistently to all fields to enable trust in complete and accurate data. The requirement to correct inaccurate reports also creates an incentive to report data accurately.
3.36 We have considered a new ‘amend’ function to enable more efficient back reporting.
While recognising this could reduce the cost of correcting transaction reports, it introduces some operational risk.
3.37 When a transaction report is submitted to us, we validate its content against a defined
set of validation rules. Some of these validation rules are conditional, meaning that a value in a field can affect how another field is validated. These validation rules support data quality and reduce costs by ensuring obvious data quality issues are addressed before the report is accepted.

3.38 Conditional validation rules would be difficult to apply where a single reporting field or
combination of reporting fields were amended after the transaction report has been accepted. An alternative would be to re-validate the entire transaction report when data point(s) are amended. We are concerned this would create operational challenges as complex as the existing process for back reporting.
3.39 We have also considered an approach where transaction reports are not re-validated
following amendment of a single data point. We consider this could lead to material data quality issues, compromising our ability to use the data.
3.40 So we do not propose to introduce a new ‘amend’ function to correct historic
transaction reports at this stage.
3.41 However, we believe we could lower the burden on firms by reducing the period for which
we require back reporting.
3.42 We need accurate historic transaction reports to support our market abuse enquiries.
Our investigations can be complex, involving detailed analysis of data submitted over multiple years. Historic data is also used to inform long-term views on market patterns, trends and behaviours. Back reporting ensures this work is not compromised by bad data.
3.43 Despite this, the cost of back reporting may sometimes be disproportionate to the value
of the corrected data, depending on the nature of the error or omission. Back reporting is often more challenging for older transactions, where static data has been updated, or where client relationships no longer exist.
3.44 We have analysed data to test the proportionality of the current default back reporting
period (5 years). In 2024, we received 653 million back reports. 215 million of these back reports contained a trade date more than 3 years earlier.
3.45 To strike a balance between the value of historic data and the cost imposed on firms, we
plan to apply a shorter default back reporting period of 3 years. We estimate this could reduce transaction reporting costs on firms by £11.9m per year.
3.46 We propose to keep our ability to require back reporting on an ad hoc basis for up to 5
years. We would reserve this for serious reporting failings which risk affecting market abuse enquiries or our ability to monitor key markets.
3.47 By keeping this choice, we are safeguarding our regulatory objectives against data
quality limitations, while demonstrating a proportionate approach. Firms will still be required to keep transaction and order records for 5 years. These record keeping obligations are outlined in COBS 11 and SYSC 9. Question 4: Do you agree with the proposal to apply a reduced default back reporting period of 3 years, whilst keeping the choice to require back reporting up to 5 years where needed?

Exclusions
Feedback received
3.48 We know it can be difficult for firms to decide when a corporate action is a reportable
event. Due to their bespoke nature, events often need to be reviewed on a standalone, ad hoc basis to decide if exclusions apply. Firms may also keep information about corporate actions in different systems to information about other financial transactions.
3.49 Respondents asked us to exclude all corporate actions from transaction reporting. One
respondent suggested we could do this by expanding the exemption in RTS 22 Article 2(5)(n). This exclusion applies to an exchange and tender offer on a bond or other form of securitised debt where the investor cannot unilaterally vary the terms of the transaction.
3.50 RTS 22 Article 2(5)(g) excludes transactions involving the creation or redemption of units
of a collective investment undertaking by the undertaking’s administrator or manager. Respondents suggested expanding this exemption to include where an investment firm executes a transaction with a broker, who then executes a transaction with the fund administrator or manager for the creation or redemption of units.
Figure 3: Transaction reporting chain for a firm creating or redeeming units of a
collective investment undertaking via a broker Investment firm Broker Fund adminstrator or manager Our proposal
3.51 We have reviewed the exclusions in RTS 22 to ensure they remain fit for purpose.
We propose the following changes in MAR 14.2.4R:

To expand the exclusion in Article 2(5)(g) to cover the creation or redemption of
units, regardless of whether it takes place directly with a manager or administrator of the collective investment undertaking.
To exclude corporate events and actions from transaction reporting requirements
regardless of whether an investment decision was made. We propose to expand the exclusion under Article 2(5)(i) and combine it with the exclusion currently under
Article 2(5)(n). Firms will still have to report initial public offerings (IPOs), secondary
public offerings or placings and debt issuance.
While we will not require firms to report most corporate actions, we propose to allow
firms to continue reporting them. This will give firms flexibility to limit the number of system changes required, where the cost of excluding the report is greater than the cost of submitting it.
Article 2(5)(m) excludes transactions under an employee share incentive plan or
residual instruments as a result of administrative action below a specific threshold. This threshold is capped at the equivalent of €1000 for a one-off transaction, or a cumulative value of €500 per calendar month where the arrangement involves

multiple transactions. We propose to simplify this by removing the one-off transaction cap and increasing the cumulative monthly limit. We also propose to change the currency to GBP. The proposed cumulative monthly limit is £1,500. We propose to allow firms to report activity under this threshold, if this is preferable to determining if the transaction is reportable. Question 5: Do you agree with our proposed changes to the exclusions from reporting in MAR 14.2.4R?
3.52 As well as expanding and streamlining existing exclusions, we propose to bring existing
guidance in the ESMA Guidelines into our rules. The proposed guidance can be found in MAR 14.3.1G(1)-(7). Question 6: Do you agree with the proposed guidance on exclusions from reporting in MAR 14.3.1G? Systems and controls
3.53 We receive regular questions from firms on our expectations for:

How often reconciliations should be conducted under Article 15(3) of RTS 22.
Materiality thresholds for submitting transaction reporting breach notifications
under Article 15(2) of RTS 22.
Timelines for remedial work and back reporting.
3.54 In Market Watch 81 and 82 we shared our observations on these topics. However, we
have not given prescriptive guidance on best practices. This is because best practices will differ between firms on a case-by-case basis. For example, when deciding on a reconciliation framework, firms need to consider factors such as the complexity of their business model and reporting systems, the nature and scale of order flows and asset classes traded, as well as the overall volume of transaction reports they submit.
3.55 Respondents to DP24/2 highlighted the importance of existing non-legislative materials
such as guidelines and examples. These help firms report accurately and efficiently. Many respondents asked for further guidelines on transaction reporting systems and controls. Our proposal
3.56 We have included sections from the ESMA Guidelines in our rules where needed to
clarify reporting requirements.
3.57 We intend to provide a new transaction reporting user pack to help firms understand their
reporting obligations. We will base some of this guidance on existing EU non-legislative materials. We will also add new examples for scenarios which are not currently covered.
3.58 We will consult on the new transaction reporting user pack in 2026. We will work with
firms to ensure guidelines reflect industry best practices and needs. We will consider adding guidance around transaction reporting systems and controls when preparing the new pack.

Accommodating new technologies
3.59 In DP24/2 we recognised our role in ensuring regulation adapts to the speed, scale and
complexity of developments in technology. We sought views on:

Adopting new or alternate messaging standards, such as JavaScript Object
Notation (JSON).
What role we could play in supporting the development of new and existing
technologies.
If our rules prevented the adoption of new technologies.
Feedback received
3.60 Many respondents had concerns about a change to JSON messaging standard.
Respondents said potential benefits would likely be offset by change costs. Most respondents preferred to maintain the existing global ISO 20022 XML standard, also used in UK EMIR and SFTR.
3.61 Some respondents saw long-term benefits to flexible messaging standards, enabling
firms to submit data in JSON, XML or other messaging standards developed in the future.
3.62 Respondents also offered suggestions to improve the MDP data extract facility. These
included enabling application programming interface (API) connections to support automation, enabling reports to be scheduled to run automatically and allowing firms to request more than one extract per day.
3.63 Respondents did not identify any rules that obstruct the use of Common Domain Model
(CDM) or Direct Regulatory Reporting (DRR). They asked us to take a global lead in developing and applying technology and data standardisation for regulatory reporting. Our proposal
3.64 We will retain ISO 20022 XML as the required messaging standard for transaction reporting.
3.65 We are currently building a single consolidated markets data platform within our Cloud
Centre. We will consider potential changes to improve the MDP user experience as part of this transformation. We will communicate any planned changes in due course. We do not think policy changes are needed to make these enhancements.

Chapter 4
Scope
Introduction
4.1 This chapter considers the scope of requirements in the UK transaction reporting
regime. We cover:

Reporting obligations on buy-side firms.
Conditional single-sided reporting.
The scope of reportable instruments.
OTC derivatives.
The meaning of a ‘transaction’ and ‘execution of a transaction’.
Reporting obligations for small firms.
Buy-side firms
Reporting obligations for buy-side firms
4.2 Buy-side firms and trade associations representing them felt strongly that buy-side
firms should be exempt from transaction reporting. These respondents felt requirements on buy-side firms were duplicative. Transaction reports submitted by buy-side firms mirror aspects of the transaction reports submitted by counterparties (other than the client details and the investment and execution decision maker details). Respondents also highlighted that jurisdictions other than the EU generally do not require buy-side transaction reports.
4.3 Two respondents proposed specific changes to remove buy-side firms from reporting
requirements. The first was based on activity. Specifically, if an investment decision is made under a discretionary mandate or power of representation then it should be excluded. The second was based on permissions. This would exclude firms that have permissions to carry on activities to manage or advise on investments but not to deal in investments as principal. We considered both proposals in our data analysis. While there were some differences in the firms covered, the overall coverage was largely consistent, both in terms of transaction count and value. International comparisons
4.4 In the US, buy-side firms are not required to submit transaction reports to regulators.
Instead, sell-side firms, such as broker-dealers and execution venues, are responsible for transaction reporting. Broker-dealers and execution venues report transactions and orders to the Consolidated Audit Trail (CAT), which captures detailed trade data, including transactions by buy-side firms via broker-dealers.

4.5 Some respondents argued the US model demonstrates that market monitoring and
surveillance for market abuse can be managed without requiring buy-side firms to report transactions.
4.6 Respondents also noted that most EU asset management firms operate under a UCITS
or AIFM licence, occasionally with a MiFID top-up permission. Over the last few years, this trend has been growing. The value of buy-side data
4.7 Buy-side reports are partially duplicative where the buy-side firm deals with a UK firm
that must meet transaction reporting obligations. However, this only occurred in 44% of transactions reported by buy-side firms in 2024. This means that a buy-side reporting exemption would result in complete loss of oversight for 56% of transactions executed by buy-side firms.
4.8 We recognise that our transaction reporting regime for non-banks is more
comprehensive than equivalent regimes in other major financial centres. This is partly due to the international nature and size of our markets, compared to other jurisdictions.
4.9 In the US and Japan, buy-side firms more often trade with brokers in the same
jurisdiction due to liquidity pools in those markets and focus on home market funds. This means regulators can get buy-side data directly from sell-side firms. The UK is more international, with many buy-side firms holding mandates for non-UK funds. Liquidity is not always available through other UK firms. So we often do not have oversight of transactions from a sell-side perspective.
4.10 Transaction reporting data has multiple purposes. As well as detecting and investigating
market abuse, we use the data to monitor the functioning of UK markets, the activities of firms and financial stability. This reduces the need to ask for the same data points elsewhere.
4.11 Buy-side firms are critical to the functioning of UK markets. Transaction reports from
buy-side firms have been vital for monitoring market functioning and integrity, especially in times of crisis. Both we and the Bank of England used this data extensively to inform our decisions during the UK government bond market dysfunction in September and October 2022. This data played an important role in identifying trades between buy-side participants.
4.12 Monitoring gilt markets is a priority for financial stability. Gilts finance government
spending, support the UK financial system as a safe and liquid asset (including as use as collateral), and act as a benchmark for valuing corporate debt, pension liabilities and annuities. Effective monitoring of gilt markets relies on oversight of the broader sterling market (SONIA swap, SONIA and gilt futures). Beyond banks, many key participants in these markets are buy-side firms such as hedge funds, pension funds, insurers and LDI funds
4.13 Understanding buy-side positions is critical to understanding market dynamics and
supporting market integrity. We need continuous oversight of these markets. We have implemented monitoring tools to identify potential harms at a macro, portfolio or

individual firm level. We use these tools widely. Losing these capabilities would damage our ability to be a smarter regulator.
4.14 Supervisors use transaction reports on a daily basis to monitor firms. The data regularly
contributes to firm evaluations, portfolio assessments and ‘Dear CEO’ letters.
4.15 Examples of past analyses conducted using this data include:

Hedge fund trading behaviour in gilt and futures markets following the tariff
announcements in early April 2025.
The role of commodity trading advisors (CTAs) in transmitting stress across global
markets during August 2024 when FX carry unwinds led to widespread selling in equities and other asset classes.
UK firms’ activity in Russia-linked financial instruments and counterparties in
February and March 2022, including those of UK buy-side firms.
4.16 In some cases, for associated core sterling markets, we get data directly from dealers,
prime brokers and other reporting regimes. But there are no other reporting regimes which cover the gilt market. Any loss of transaction reports from UK buy-side firms would create a significant information gap on transactions involving non-UK banks and dealers. Our analysis indicates this information gap would be exacerbated in times of stress, when this data is most powerful.
4.17 Exempting buy-side firms from transaction reporting would also have a material
impact on our and the Bank of England’s ability to monitor corporate debt markets. We estimate we would lose sight of 20-30% of total sterling corporate bond volumes (rising to 40-50% of volumes for specific buy-side sectors) were buy-side firms exempt from reporting. The Bank of England concluded the sterling corporate bond market could face a ‘ jump to illiquidity’ in stress, showing that maintaining coverage of these markets is important in supporting financial stability and market integrity.
4.18 Buy-side transaction reports also support analysis and research to understand the
health of our financial markets. For example:
In June 2021 the Bank of England published a financial stability paper on the
‘dash for cash’.
In March 2023 the Bank of England published a Staff Working Paper on Investor
behaviour during market disruptions in September and October 2022.
In November 2023 the Bank of England published a Quarterly Bulletin on the 2022
gilt market invention to support UK financial stability.
In July 2023 the Bank of England published a bank underground blog on liabilitydriven investment (LDI) and pension fund behaviour in Autumn 2022.
In May 2025 we published an occasional paper on liquidity in the UK corporate
bond market.
4.19 We recognise the significant potential cost savings for buy-side firms from a reporting
exemption. But given the range and importance of use cases for this information, we view our collection of this data as proportionate and necessary.

4.20 However, we believe we could reduce the burden of reporting on buy-side firms, in some
cases significantly, through conditional single-sided reporting.
Conditional single-sided reporting
Our proposal
4.21 The concept of ‘single-sided reporting’ refers to when a transaction involving 2 firms is
reported by 1 firm only. Article 4 of RTS 22 sets out requirements for conditional singlesided reporting where a ‘receiving firm’ submits its transaction report including details provided by a firm carrying out reception and transmission.
4.22 Most firms do not use this mechanism. Only 164 firms acted as a receiving firm in 2024.
0.38% of the transaction reports we received in the period were submitted with an LEI populated in the transmitting firm identification code for the buyer or seller fields.
4.23 Feedback to DP24/2 highlighted factors contributing to this:

The burden of transmitting all the required information to the receiving firm.
Receiving firms’ reluctance to take responsibility for the accuracy of transaction
reports where they rely on the transmitting firm for data.
Article 4 transmission can only take place where a firm has received and transmitted
an order to another firm for execution.
4.24 We want to enable more use of conditional single-sided reporting. When used
appropriately, it delivers efficient reporting, reducing costs for market participants, while ensuring that we do not lose critical oversight of financial transactions and their key details.
4.25 To do this, we are proposing to update and streamline the existing transmission
mechanism in Article 4 of RTS 22. These new rules are in MAR 14.10. Firms currently acting as a transmitting (or ‘sending’) firm or receiving firm should be able to continue doing so without making significant changes.
4.26 The transmission mechanism is currently only available to firms receiving and
transmitting orders. We propose removing this restriction to allow conditional singlesided reporting to take place in all trading capacities. To reflect this we will update the name of the transmission mechanism to ‘conditional single-sided reporting’. Information to be provided
4.27 Currently, Article 4(2) of RTS 22 requires a transmitting firm to provide a receiving firm
with the following information:
– The identification code of the financial instrument.
– Whether the order is for buying or selling the financial instrument. – The price and quantity indicated in the order. – The designation and details of the client of the transmitting firm for the order. – The designation and details of the decision maker for the client where the investment decision is made under a power of representation.

– A designation to identify a short sale.
– A designation to identify a person or algorithm responsible for the investment decision within the transmitting firm. – Country of the branch of the investment firm supervising the person responsible for the investment decision. – For an order in commodity derivatives, an indication whether the transaction is to reduce risk in an objectively measurable way. – The code identifying the transmitting firm.
4.28 We propose to streamline this information to make conditional single-sided reporting
more efficient for firms. We will remove the requirement to transmit information about the transaction that would already be known to the firm submitting the transaction report, including:
– The identification code of the financial instrument.
– Whether the order is for the acquisition or disposal of the financial instrument. – The price and quantity indicated in the order.
4.29 We propose to remove requirements for specific fields we want to remove from
transaction reporting (covered in Chapter 5).
4.30 We also propose removing the requirement to provide details about the persons or
algorithm responsible for the investment decision within the transmitting firm. This requirement creates an operational barrier for firms as the information is often seen as highly sensitive. While this information is valuable to us, we propose to get it directly from sending firms on an ad hoc basis when we need it. This will allow firms to maintain control over sensitive data related to traders and algorithms.
4.31 We know the requirement to provide a client identifier also creates operational barriers.
However, we believe we must keep this requirement to give us the necessary oversight of transaction participants.
4.32 Our proposed changes will reduce the volume of information that must be provided
from 10 to 4 data points. These are:

The designation and details of the client of the transmitting firm for the purposes of
the order.
The designation and details of the decision maker for the client where the
investment decision is made under a power of representation.
The code identifying the transmitting firm.
The trading capacity the transaction was executed in.
Question 7: Do you agree with the proposed information a firm should provide to meet the conditions for single-sided reporting?

4.33 Below we show examples of transaction reports submitted for different conditional
single-sided reporting scenarios.
Table 1: Transaction report submitted by Firm X (receiving firm) including
details provided by Firm Y (sending firm) who is making an investment decision on behalf of Client A. Firm X is acting in AOTC trading capacity. Executing entity Buyer Client indicator for the buyer Buyer decision maker Seller Client indicator for the seller Sending firm identification code for the buyer Sending firm identification code for the seller Trading capacity Firm X Client A False Firm Y Market False Firm Y AOTC
Table 2: Transaction reports submitted by Firm X (receiving firm) including
details provided by Firm Y (sending firm) who is making an investment decision on behalf of Client A. Firm X is acting in DEAL trading capacity. Executing entity Buyer Client indicator for the buyer Buyer decision maker Seller Client indicator for the seller Sending firm identification code for the buyer Sending firm identification code for the seller Trading capacity Firm X Client A False Firm Y Firm X False Firm Y DEAL
Table 3: Transaction reports submitted by Firm X (receiving firm) including
details provided by Firm Y (sending firm) who is dealing on its own account. Firm X is acting in DEAL trading capacity. Executing entity Buyer Client indicator for the buyer Buyer decision maker Seller Client indicator for the seller Sending firm identification code for the buyer Sending firm identification code for the seller Trading capacity Firm X Firm Y True Firm X False Firm Y DEAL
4.34 In Table 1 and 2, the ‘Client indicator for the buyer’ field should be populated from the
perspective of the executing entity. As Client A is not a client of Firm X, it is populated as False. In Table 3, as Firm Y is a client of Firm X, it is populated as True.

Responsibility for data quality
4.35 We believe a sending firm should be responsible for the completeness and accuracy of
information it gives to a receiving firm. The receiving firm should be responsible for all other data points in its transaction report. We propose to clarify this in our rules. Question 8: Do you agree with the proposed responsibility for data quality for transactions involving conditional single-sided reporting? Conditional single-sided reporting for different trading capacities
4.36 The transmission mechanism is currently only available to firms receiving and
transmitting orders. We propose removing this restriction to allow conditional singlesided reporting to take place in all trading capacities. This includes where a firm is dealing on their own account or in a matched principal trading capacity. In 2024, 54% of transaction reports were executed in a DEAL capacity, and 17% of transactions were executed in MTCH capacity. Question 9: Do you envisage any issues in conditional single-sided reporting applying to transactions executed in a DEAL or MTCH trading capacity? Collective Portfolio Management Investment (CPMI) firms
4.37 In DP24/2 we discussed whether the scope of firms who must meet transaction
reporting requirements should be based on the activity they undertake rather than authorisation status. This was in relation to fund managers subject to requirements in the UK Alternative Investment Fund Managers Directive (AIFMD) and Undertakings for Collective Investment in Transferable Securities (UCITS) (described as ‘CPMI’ firms in our Handbook).
4.38 We noted the number of transaction reports submitted by CPMI firms may be limited by
the exemption in Article 2 of UK MiFID. This exemption applies to firms managing their own funds. We said it was not clear if requiring these firms to submit transaction reports would be proportionate and asked for views on the potential cost. Feedback received
4.39 Feedback was mixed. Some respondents felt it would be more proportionate to set the
scope of reporting requirements based on activity rather than authorisation status. These respondents suggested that requiring CPMI firms to report would improve our ability to monitor markets. Some said that where CPMI firms execute transactions directly on trading venues, this placed the reporting burden on trading venues instead of the firm undertaking the activity.
4.40 Other respondents disagreed, highlighting that CPMI firms must meet separate
reporting requirements under AIFMD and UCITS, which MiFID investment firms do not.

These respondents argued it would be disproportionate to apply requirements on CPMI firms due to the high regulatory change cost for firms to submit a small amount of data. Some respondents said applying transaction reporting requirements to CPMI firms would put the UK at a competitive disadvantage internationally. Our proposal
4.41 We do not propose to apply transaction reporting requirements on CPMI firms. We
consider that the overall cost would not be offset by the benefit we would get from this data. We have also considered our secondary international competitiveness and growth objective. Scope of reportable instruments Geographic scope
4.42 UK MiFIR requires UK investment firms to submit transaction reports for transactions
executed in financial instruments admitted to trading or traded (‘tradeable’) on a trading venue in the UK or EU (or for which a request for admission has been made). This is the same scope that applied before Brexit. We kept this scope to ensure we have appropriate oversight over financial instruments which are in scope of the UK Market Abuse Regulation (UK MAR).
4.43 Respondents to DP24/2 said this broad geographic scope imposes disproportionate
reporting costs for financial instruments only tradeable in the EU. They pointed out that the EU does not require transaction reports for financial instruments which can only be traded in the UK. Some respondents highlighted these transaction reports as being duplicative. They noted that for transactions executed on EU trading venues, reports would also be received by the home competent authority of the trading venue. Our proposal
4.44 Our analysis shows that 30% of the financial instruments in our Financial Instrument
Reference Data System (FIRDS) are only there because they are admitted to trading or traded on an EU trading venue. We identified these financial instruments in 8% of the transaction reports we received in 2024.
4.45 We propose to limit the scope of the transaction reporting regime to financial
instruments tradeable on UK trading venues only. We estimate this could save firms approximately £31.5m annually.
4.46 We use transaction reports to investigate Suspicious Transaction and Order Reports
(STORs) received under UK MAR. Firms will still be required to report STORs for instruments which are admitted to trading or traded on EU trading venues. However, as our market abuse enquiries primarily focus on UK markets, we generally refer suspicious activity in non-UK financial instruments to the relevant overseas regulator. If we need more data for the enquiries we conduct with other regulators, we will require transaction

and order records on an ad hoc basis. We view this as proportionate given the overall reduction in reporting burden this proposal would deliver.
4.47 We also use transaction reports in our supervision of firms active in EU markets. Our
proposal would result in some loss of oversight of these activities. We may have to make more targeted requests for data in future to address key gaps in our oversight, as we do currently for transactions executed by UK firms in global (non-EU) markets.
4.48 Transaction reports for activities by UK firms on EU trading venues are received by
relevant EU National Competent Authorities (NCAs). We want to further strengthen the insights we get from data shared with EU NCAs as part of our new long-term approach.
4.49 Derivatives which are only tradeable on EU trading venues will still be reportable where
one or more underlying financial instrument(s) is admitted to trading or traded on a UK trading venue. Question 10: Do you agree with our proposal to remove instruments from the scope of the UK transaction reporting regime that can only be traded on EU trading venues?
4.50 We propose to remove all references to the ‘Union’ in our new rules. However, we
propose to retain the existing approach for national identifiers used in transaction reports. We will add these rules to MAR 14.13.5R. It would not be proportionate or beneficial to ask firms to report the national passport number for all EEA natural persons. Question 11: Do you agree with our proposal to remove reference to ‘Union’ in MAR 14 Annex 2 and retain the current approach to national identifiers? The ‘Traded on a trading venue’ (TOTV) concept
4.51 Following Brexit, we set out our approach to EU non-legislative materials. This stated
that we would continue to have regard to EU non-legislative material where and if they are relevant. ESMA’s TOTV opinion details the expectation on firms when determining reportability for OTC derivatives.
4.52 Derivatives which are not traded on a regulated market are classified as ‘OTC
derivatives’. For transactions in OTC derivatives that are not executed on a trading venue, firms must assess whether the OTC derivative shares the same reference data details as an exchange traded derivative. We define ‘reference data details’ as the attributes a financial instrument has under RTS 23 except for:

The issuer or operator of the trading venue.
The venue-related fields (trading venue, financial instrument short name, date of
request for admission to trading, date of admission to trading or date of first trade and termination date).

4.53 In DP24/2 we noted the complexity and associated cost of this due diligence for OTC
derivatives. We asked for more information about these, including if difficulties were concentrated in specific asset classes.
4.54 We also considered the treatment of financial instruments which are not derivatives but
which could be interpreted as having an ‘underlying’. This includes structured products which aim to deliver a return based on the performance of another instrument. Feedback received
4.55 Many respondents reported challenges with applying the ‘TOTV’ concept to derivatives.
Examples included:

The high cost of determining whether derivatives referencing baskets and indices
are reportable, particularly those with a non-UK focus.
The complex processes required to determine whether OTC interest rate and FX
derivatives are equivalent to comparable exchange-traded contracts.
4.56 Some respondents suggested TOTV determination would be simpler if the scope of the
transaction reporting regime was limited to financial instruments admitted to trading or traded on UK trading venues.
4.57 Respondents generally felt the current TOTV concept works well for equities, bonds
and other instruments reportable under Article 26(2)(a) of UK MiFIR. Some highlighted challenges from the delayed submission of instrument reference data. Our proposal
4.58 To provide more certainty for firms when determining their reporting obligations, we
propose new guidance in MAR 14.5.4G to support the definition of a reportable financial instrument. Firms will no longer need to have regard to ESMA’s TOTV opinion. We also believe there will be significantly less complexity based on our proposals for FX derivatives in this chapter. Question 12: Do you agree with the proposed guidance to clarify in our rules an equivalent regulatory concept to ESMA’s TOTV opinion?
4.59 We propose to provide clarity for instruments which are not derivatives which can be
brought into scope by Article 26(2)(b) or (c). To do this we will provide new guidance based on CFI codes to clarify when firms trading a product must consider the underlying for determining its reportability. This will include structured instruments and asset-backed securities. We will include this guidance in the new transaction reporting user pack. Question 13: Do you see any issues having to report transactions executed in instruments which are not derivatives but are brought into scope by the underlying?

Reporting financial instruments under UK MiFIR Article 26(2)(c)
4.60 Under Article 26(2)(c) investment firms must submit a transaction report where they
trade a financial instrument based on a basket or index that contains at least 1 financial instrument admitted to trading or traded on a UK, EU or Gibraltar trading venue.
4.61 Respondents to DP24/2 highlighted challenges in deciding whether index derivatives are
subject to transaction reporting obligations. Firms must first get reference data for the constituent parts of the index. They must then decide eligibility by assessing whether each constituent is in scope.
4.62 We understand this process is generally simpler for derivatives based on baskets, which
may have a smaller number of constituents.
Our proposal
4.63 Feedback suggests the cost of determining the reportability of index derivatives may
sometimes be greater than the cost of reporting the relevant transactions. We want to reduce the cost and complexity of due diligence processes while ensuring we have appropriate oversight of transactions to meet our objectives.
4.64 We propose to give firms the choice to ‘over report’ transactions executed in derivatives
where the underlying is an index. While this will increase the number of transaction reports some firms submit, we expect any additional costs to be offset by simplified eligibility assessment processes.
4.65 Our proposed approach will not require any firms to make changes. The transaction
reporting validation rules already accept transaction reports submitted for derivative transactions where the underlying index name is populated, regardless of the constituents of that index.
4.66 Firms must continue to submit transaction reports for financial instruments based on
an index that contains at least 1 financial instrument admitted to trading or traded on a UK trading venue. Question 14: Do you agree with our proposal to allow firms to report derivatives based on indices on a voluntary basis, irrespective of whether the derivative is in scope of the transaction reporting regime?
4.67 We will also provide more flexibility for reporting derivatives on a basket of instruments.
The current rules state that RTS 22 Field 47 (Underlying instrument code) should be reported as many times as necessary to list all reportable instruments in the basket. Our CON-472 validation rule rejects transaction reports when 1 or more ISIN reported in the underlying instrument field is not in FCA FIRDS.
4.68 We plan to relax this validation rule. We will only reject transaction reports submitted
where none of the ISINs reported in the underlying instrument field are in FCA FIRDS. This would allow firms to report ISINs for all instruments in a basket without first

checking whether they are in FCA FIRDS. Reporting ISINs for underlying instruments not in FCA FIRDS would be optional. Question 15: Do you agree with the proposed changes to allow all ISINs in a basket to be included in the underlying instrument field?
4.69 For reportable transactions where the underlying is an index, RTS 22 Field 48 (Underlying
index name) should contain a 4-letter code listed in RTS 22 Annex I Table 1 or the index name as free text.
4.70 The index list in RTS 22 is not the same as the index list in UK EMIR Table 2, Item 15.
We plan to update the list to align with the list in EMIR.
4.71 Firms take different approaches when reporting the underlying index with free text. In
some cases, the same instrument may be identified with different names. Our analyses would be supported by standardisation in this area. We will publish guidance on how to populate the underlying index name in our transaction reporting user pack. Fractional instruments
4.72 Investment in fractional shares represents a significant and growing part of the
consumer investment market in the UK.
4.73 Fractional shares allow consumers to invest in shares at a lower price point, where the
price of a full share may be unaffordable. This allows more consumers to participate in a market and may also enable them to diversify their investment portfolio.
4.74 The number of investment firms transacting in fractional shares has increased in recent
years. In 2022, 90 investment firms submitted over 97 million transaction reports in fractional shares. In 2024, 98 firms submitted over 156 million transaction reports in fractional shares.
4.75 While it appears that most firms which execute transactions in fractional shares report
details of those transactions to us, we believe our rules could clarify that fractional instruments are in scope of transaction reporting.
4.76 We propose to update the definition of a reportable financial instrument to:
(a) a financial instrument which is admitted to trading or traded on a qualifying trading venue or for which a request for admission to trading to a qualifying trading venue has been made; (b) a financial instrument where the underlying is a financial instrument traded on a qualifying trading venue; (c) a financial instrument where the underlying is an index or a basket composed of at least one financial instrument admitted to trading or traded on a qualifying trading venue; or

(d) an instrument which constitutes a right or interest under article 89 of the Regulated Activities Order in a financial instrument included in paragraph (a) above.
4.77 We will give examples of how different fractional instruments should be reported in
the new transaction reporting user pack. For fractional shares, we will confirm our expectation that transactions should be reported as equity transactions with the quantity field reflecting the fractional amount traded in units. Question 16: Do you agree with the proposal to provide clarity on the scope of reporting obligations for fractional instruments? OTC derivatives
4.78 Several respondents to DP24/2 suggested that we should remove OTC derivatives from
the UK transaction reporting regime. They highlighted overlapping requirements which require OTC derivatives to be reported under both UK MiFID and EMIR.
4.79 We want to reduce duplication across transaction and post-trade reporting regimes.
While OTC derivatives are subject to reporting obligations under both UK MiFID and EMIR, the data reported is not identical. The reporting fields under each regime were originally calibrated to their unique purposes. For example, the UK EMIR reporting regime does not require firms to provide personal identifying information (PII). But we need PII for market abuse enquiries.
4.80 So we cannot rely only on UK EMIR data for market abuse enquiries into OTC derivatives.
This includes products such as CFDs and spreadbets. Because they are leveraged, these products are highly susceptible to market abuse. Our work to support market integrity relies on our proactive surveillance of these products.
4.81 In June 2025 we secured convictions against 2 individuals for insider dealing and money
laundering offences. These individuals used CFDs to benefit from the drop in share prices using confidential, price-sensitive information. We proactively identified this activity using transaction reports, supplemented by additional data such as announcements from Primary Information Providers (PIPs) and information contained in STORs.
4.82 Subject to the Treasury repealing Article 9 of UK EMIR (the reporting obligation for
the regime), we want to consider policy changes in the future to support use of UK EMIR data for market abuse enquiries. These changes could lead to more streamlined reporting for OTC derivatives across regimes. However, changes to UK EMIR would affect a much larger population of reporting firms than currently have to submit data under UK MiFIR. We will review this as part of our long-term approach to streamlining transaction and post-trade data.

Foreign exchange (FX) derivatives
4.83 The UK is the largest centre for FX derivatives trading in the world, accounting for almost
40% of global turnover. We receive transaction reports for FX derivative transactions executed by UK firms where the derivative is admitted to trading or traded on a UK or EU trading venue.
4.84 In DP24/2 we noted that reporting for FX derivatives require some firms to develop
reporting logic which does not align with booking practices. We highlighted that these and other challenges unique to FX derivatives contribute to poor data quality.
4.85 We have also considered how to reduce duplication in transaction and post-trade
reporting for OTC derivatives. Our approach included analysing use cases and whether alternative data sources exist. Feedback received
4.86 Respondents highlighted challenges in submitting complete and accurate transaction
reports for FX derivatives, linked to:

Determining the base and quote currency.
Challenges in getting ISINs for FX swaps.
Inconsistent approaches to reporting of FX swaps and FX strategies.
Overreporting of spot FX through the reporting of short-dated forwards.
Diverging reporting requirements between UK MiFIR and EMIR.
4.87 Respondents made the following suggestions to improve data quality for
FX derivative reporting:
Develop guidelines for consistently determining the base and quote currency.
Align reporting requirements with booking practices.
Provide more prescriptive guidance on how to populate the price, price currency,
quantity and quantity currency fields.
Give examples on a range of trading scenarios covering FX forwards, options
and swaps.
Clarify the scope of reportable FX derivatives, especially for overnight or
rollover instruments.
Allow overreporting of FX spot.
4.88 Some respondents supported removing FX derivatives from the scope of the
transaction reporting regime due to the perceived limited risk of market abuse. Our proposal
4.89 We have considered the issues raised alongside the principles set out in Chapter 2.
Providing additional guidance would offer more clarity and potentially improve data quality. However, our analysis of relevant use cases suggests transaction reports do not currently capture specific data elements necessary for market abuse enquiries and market monitoring.

4.90 To materially improve the usefulness of this data, we would need to expand the number
of reporting fields to include:

Exchange rate.
Exchange rate basis (base currency).
Forward exchange rate.
Payer and receiver for legs 1 and 2.
4.91 This information is already reported under UK EMIR for all FX derivatives.
4.92 So we are considering removing FX derivatives from the scope of the UK transaction
reporting regime. We view UK EMIR data as a better source of information for monitoring risk in FX derivative markets. It includes additional relevant fields not captured by UK MiFIR and applies to all financial derivatives. UK MiFIR only applies to derivatives tradeable on a UK or EU trading venue.
4.93 Our market abuse enquiries into FX derivatives rely on a range of information. This
includes order book data and data we collect from firms on an ad hoc basis, including spot data. Unlike other asset classes, transaction reports are often supplementary to these other data collections.
4.94 We consider that removing FX derivatives from the scope of transaction reporting will
not affect our ability to detect, investigate and prevent market abuse in this asset class. However, we may need to send more ad hoc requests for data as part of our enquiries into FX derivative market abuse.
4.95 This would mean we have less oversight of FX activity by firms who are required to
report under UK MiFIR but not UK EMIR. This includes 95 UK branches of third country firms. We are reviewing the impact of this carefully and will consider whether new reporting requirements or data requests are required to address the gap. We expect to use the full implementation period for our proposals to address these issues and ensure we have appropriate data to support our work. Question 17: Do you agree with our proposal to remove FX derivatives from the scope of the UK transaction reporting regime? Question 18: For UK branches of third country firms: how could we address the data gap created for FX derivatives?
4.96 We will review whether to proceed with this exclusion after considering the
feedback we get.
OTC derivative identifiers
4.97 Financial instruments admitted to trading or traded on a UK trading venue must be
identified with an ISO 6166 ISIN. For OTC derivatives, including those traded on MTFs, OTFs and SIs, the Derivatives Service Bureau (DSB) issues ‘OTC ISINs’ with an EZ-prefix.

4.98 Unique OTC derivatives must be identified with a unique OTC ISIN. The ‘uniqueness’ of
an OTC derivative is decided by its reference data details. These are specific to the type of derivative but include attributes such as the contract’s expiry date.
4.99 For OTC derivatives with dynamic, daily changing attributes, investment firms and
trading venues must get and report new OTC ISINs every day. There are currently over 16 million active OTC ISINs in FCA FIRDS. These account for 75% of all active financial instruments on the system.
4.100 We explored different options for improving the identification of OTC derivatives in DP24/2.
Feedback received
4.101 Most respondents who trade OTC derivatives said the requirement to source and report
a high volume of ISINs affected them. These challenges were greatest in interest rate, credit, currency and equity derivatives.
4.102 For interest rate derivatives, challenges were caused exclusively by the standard term
and expiry date of the contract. For other asset classes, challenges were caused by other reference data details, such as the underlying instrument. Options for improvement
4.103 DP24/2 outlined 5 different approaches to identifying OTC derivatives in transaction reports:

Keep the OTC ISIN as the identifier for OTC derivatives and give additional guidance
on the ‘TOTV’ concept to clarify reporting requirements for derivatives not traded on a trading venue.
Propose modifications to specific OTC ISIN product definitions and templates. These
could reduce the sensitivity of the identifier to dynamic attributes. For example, removing the expiry date from the reference data details for interest rate derivatives.
Retire the OTC ISIN as an identifier for OTC derivatives in transaction reports, moving
to a new framework based on the ISO 4914 Unique Product Identifier (UPI). This identifier would need to be supplemented with additional data elements, reported in transaction reports and instrument reference data.
As above, with additional data elements reported in transaction reports only, and the
scope of reportable instruments covering UPIs admitted to trading or traded on a UK trading venue.
As above, with the scope of reportable instruments instead covering all derivative
contracts, in line with the scope of UK EMIR.
Feedback received
4.104 There was no consensus among respondents on which option was preferred. An equal
number of respondents favoured maintaining the current ISIN, moving to a modified ISIN and moving to a new framework based on the UPI.
4.105 All respondents asked for more clarity on the application of the TOTV concept to
derivatives traded away from a trading venue. We cover our response to this above.

4.106 Respondents who favoured the UPI had a marginal preference for additional data
elements to be reported in transaction reports only. Under this option, the scope of reportable instruments would cover all OTC derivatives with a parent UPI in FCA FIRDS.
4.107 Respondents did not support a change to the scope of reportable instruments to align
with UK EMIR. Many said this would result in a significant increase in the number of transaction reports submitted by firms trading OTC derivatives. This would increase duplication and reporting costs. While some recognised this would lower the complexity involved in determining the reportability of OTC derivatives, most preferred an alternative solution.
4.108 Responses highlighted challenges that could arise from divergence between OTC
derivative identification requirements in the UK and EU.
Our proposal
The UPI
4.109 We have considered different ways to implement the UPI as an identifier for OTC
derivatives in transaction reports. We believe a framework based on the UPI would support more efficient reporting and analysis for OTC derivatives. The UPI has already been implemented as an identifier for UK EMIR reporting and in other derivative reporting regimes across the world. Most firms who would be affected by this change are already sourcing UPIs to fulfil other reporting obligations.
4.110 However, any framework based on the UPI leads to complex challenges for deciding the
scope of reporting obligations for OTC derivatives. Transaction reporting obligations currently apply to OTC derivatives at instrument-level detail (OTC ISIN), not productlevel detail (UPI). To decide if an OTC derivative traded away from a trading venue was reportable, firms would need to assess whether the reference data details of the derivative match those of a TOTV derivative. Without an OTC ISIN in FCA FIRDS, we believe this due diligence would be more complex than the current determination required.
4.111 All respondents disagreed with aligning the scope of reporting obligations for OTC
derivatives under UK MiFIR with EMIR. Setting the scope of reporting obligations at the product-level of the derivative appears to be the most feasible approach of the options presented.
4.112 Under this approach, the UPI would be the identifier for OTC derivatives. Trading venues
would submit reference data including the UPI to FCA FIRDS. When an investment firm executes a transaction in a product with the same UPI as a product admitted to trading or traded on a UK trading venue, this would confer a transaction reporting obligation.
4.113 This is a wider reporting obligation. Figure 4 shows 3 OTC derivatives which share all
attributes other than the expiry date of the contract. As a result, they share a UPI but are identifiable with unique OTC ISINs.

Figure 4: Link between UPI and OTC ISIN
4.114 Transaction reporting obligations currently apply to ISIN 1 and ISIN 2 only. ISIN 3 is
not reportable as it is not traded on a UK trading venue (or equivalent to a derivative traded on a trading venue). Under a framework which calibrates the scope of reporting obligations to financial instruments sharing a UPI traded on a trading venue, ISIN 3 would become reportable.
4.115 We have tested the impact this could have on firms’ reporting obligations. Our analysis
identified over 23 million unique OTC ISINs which are not traded on a UK trading venue but share the same UPI as an OTC ISIN which is.
4.116 For asset classes such as rates, the instrument-level TOTV scope restricts transaction
reporting obligations to approximately 25% of the global universe of interest rate derivatives with an OTC ISIN. Should the TOTV scope be applied to instruments at a product-level, reporting obligations would be extended to approximately 75%. This reporting scope would be considerably closer to the current scope of UK EMIR than the current scope of UK MiFIR.
4.117 So we propose to retain the OTC ISIN as the identifier for OTC derivatives in transaction
reports. Our decision reflects the strong negative feedback to aligning the scope of reporting obligations with UK EMIR.
4.118 We intend to keep this under review as we develop our long-term approach for
streamlining transaction and post-trade reporting.
The Modified ISIN
4.119 In DP24/2 we noted that a modified ISIN would be easier to implement in the
transaction reporting regime than the UPI, particularly if only adopted for a subset of OTC derivatives. This was primarily because fewer changes would be needed. Investment firms would continue to report ISINs for OTC derivatives tradeable on a UK trading venue. We would still be able to validate those ISINs and enrich the content of transaction reports with instrument reference data.
4.120 We believe this could be a proportionate solution to reducing operational costs for firms
trading OTC derivatives. But we consider that a decision to modify OTC ISIN product definitions and templates should be made internationally, with involvement from public authorities and data-standard setting agencies. So we do not propose to make any changes at this stage to enable a modified OTC ISIN. However, we will support and participate in discussions on modifying OTC ISIN templates.

4.121 If policy changes are required to implement any future modified ISIN, we would
consult again.
Question 19: Do you agree with our proposed approach for identifying OTC derivatives? Meaning of a ‘transaction’
4.122 The definition of an ‘acquisition’, referred to in the meaning of a ‘transaction’ in RTS 22
Article 2, covers:
a. A purchase of a financial instrument. b. Entering into a derivative contract.
c. An increase in the notional amount of a derivative contract.
4.123 The definition of a ‘disposal’ is:
a. Sale of a financial instrument. b. Closing out a derivative contract.
c. A decrease in the notional amount of a derivative contract.
4.124 While our assessment is that most firms correctly interpret when a transaction
constitutes an acquisition or disposal, we have received questions about specific scenarios. To give further clarity we propose to add rules and guidance:
MAR 14.2.1R
For the purposes of MAR 14, a ‘transaction’ means:
(1) the conclusion of an acquisition or disposal of a reportable financial instrument; (2) a simultaneous acquisition and disposal of a reportable financial instrument where there is no change in the ownership of that reportable financial instrument but post-trade publication is required under Articles 6, 10, 20 or 21 of MiFIR; or (3) entering into or closing out a derivative contract. MAR 14.2.2R An acquisition referred to in MAR 14.2.1R includes:
(1) a purchase of a reportable financial instrument; and (2) an increase in the notional amount of a derivative contract. MAR 14.2.3R A disposal referred to in MAR 14.2.1R includes:
(1) a sale of reportable financial instruments; and (2) a decrease in the notional amount of a derivative contract.

MAR 14.3.1G
(7) When entering into a derivative contract, closing out a long derivative or entering into a short derivative should be considered as a disposal for the transaction report and entering into a long derivative or closing out a short derivative should be considered an acquisition. Question 20: Do you agree with the updated definition for ‘acquisition’ and ‘disposal’? Meaning of ‘execution of a transaction’
4.125 The regulation deems an investment firm as having executed a transaction where it
provides services or activities listed in Article 3 of RTS 22:
a. Reception and transmission of orders in relation to one or more financial instruments. b. Execution of orders on behalf of clients.
c. Dealing on own account.
d. Making an investment decision in accordance with a discretionary mandate given by a client. e. Transfer of financial instruments to or from accounts.
4.126 We propose to clarify in MAR 14.4.2G-14.4.6G that:

‘Execution’ is wider than finalisation.
‘Client’ is the immediate client of the executing entity.
Supervisory responsibility over an investment decision maker amounts to the
execution of a transaction.
All parties subject to reporting requirements must report in a chain.
4.127 For the transfer of financial instruments, the ESMA Guidelines currently provide
additional guidance. We propose to bring this into our rules as guidance. Question 21: Do you agree with the proposed guidance to the meaning of ‘execution of a transaction’ in MAR 14.4.2G-14.4.6G? Branch execution
4.128 We know it can be difficult for branches to assess whether they have ‘executed a
transaction’. We propose to add new rules and guidance in MAR 14.13.25R to MAR 14.13.31R to provide clarity.

Table 4: New rules and guidance for reporting transactions executed by branches
Reporting transactions executed by branches
14.13.25 R Where a transaction reporting firm executes a transaction wholly or partly
through its branch, it shall report the transaction to the FCA.
14.13.26 G A branch or branches and the parent are treated as single entity for
reporting purposes. The branch should report the client of the firm (which may be its client or the client of another branch or the parent) and the counterparty of the firm. Where the branch is sending the order to another firm or its parent the counterparty will be the counterparty of the other branch or parent.
14.13.27 G Where a transaction is executed through a non-UK branch of a UK
transaction reporting firm it is reportable since the branches are regarded as
part of the same entity.
14.13.28 R Where the branch received the order from a client or made an investment
decision for a client in accordance with a discretionary mandate given to it by the client it is deemed to have executed a transaction.
14.13.29 R Where the branch has supervisory responsibility for the person responsible
for execution of the transaction that results in the execution of a transaction, the branch should submit a transaction report.
14.13.31 R Where the transaction was executed on a trading venue or an organised
trading platform located outside the UK using the branch's membership of that trading venue or an organised trading platform, the branch should submit a transaction report. Question 22: Do you agree with our proposed new rules and guidance for branch execution? Reporting obligations for small firms
4.129 Our data shows that a third of firms subject to transaction reporting obligations submit
fewer than 1,000 transaction reports a year. In DP24/2 we noted costs for these firms may be disproportionately high. This was supported by a cost survey we conducted, suggesting the cost of reporting an individual transaction for a small firm may be up to 15 times higher than for a large firm.
4.130 To give small firms more clarity about their reporting options we suggested a potential
opt-in register of UK investment firms willing to act as a receiving firm. We felt this would support smaller firms looking to use the transmission mechanism under Article 4 of RTS
22. We also sought views more generally on ways to reduce the burden on small firms.

Feedback received
4.131 Most respondents did not support an opt-in register for receiving firms. Firms said this
would create pressure to offer services, while also making it difficult to act as a receiving firm on a case-by-case basis.
4.132 Many respondents suggested simplifying the transaction reporting regime to reduce
costs for small firms. They noted that remedial work for complex fields and reporting scenarios often involves high costs and effort. Respondents emphasised that reducing the number of reporting fields could lower costs for smaller firms.
4.133 Some respondents said fees charged by ARMs are a significant cost for smaller firms.
They suggested we should simplify access and reduce onboarding fees for firms submitting data directly to the MDP. Some firms felt this was not widely known as an alternative for reporting transactions.
4.134 Further targeted adjustments were also proposed:

Reviewing the requirement to report partial fills of an order.
Exempting small trades from reporting requirements.
Adopting single-sided reporting.
FCA-led training and guidance tailored to smaller firms.
Our proposal
4.135 We are making proposals to simplify the transaction reporting regime as part of our new
long-term approach. These changes are likely to reduce complexity and, in turn, lower costs for smaller firms.
4.136 We will not introduce an opt-in register of UK investment firms willing to act as a
receiving firm. We are instead proposing to update the transmission mechanism under
Article 4 of RTS 22. This should support smaller firms seeking to rely on this process to
reduce reporting burdens.
4.137 We will continue to support firms who want to submit transaction reports directly to us. Our
website gives further details on the process for onboarding and related fees: Market Data Processor (MDP). We set the one-off fee on a cost recovery basis and review it annually.
4.138 We considered several other suggestions from respondents. We cover these in the
following sections, as well as other parts of this CP where they involve specific areas of the regime. For example, we discuss the role of ARMs and back reporting in Chapter 3. Block and fill reporting
4.139 When an order is sent from one firm to another, it may be completed in one transaction
or multiple transactions. These transactions are referred to as ‘fills’.
4.140 Under current guidelines, individual transaction reports should be submitted for each
‘fill’. This applies to the ‘market side’ (the firm receiving the order) and the ‘client side’ (the firm sending the order). It can result in many transaction reports being submitted

for a single order. It also introduces challenges when details about fills are not passed by the market side to the client side.
4.141 We are considering whether reporting could instead take place at an aggregate or ‘block’
level. This would enable the client side to submit a single transaction report, reflecting the total quantity and average price of the fills executed by the market side.
4.142 While this could materially reduce the number of transaction reports some firms submit,
there are challenges with this approach. The transaction reports submitted by the client side would no longer match the transaction reports submitted by the market side, complicating our enquiries. New guidelines would also be required for specific fields in the block report, such as the trade date and time.
4.143 We will consider changes to guidelines around block and fill reporting when we consult
on our transaction reporting user pack next year.
Exempting small trades
4.144 We considered the idea of introducing a de minimis threshold for reporting transactions.
Respondents cited some international regimes as having exemptions based on individual and cumulative transaction counts and values. However, these regimes are generally focused on risk monitoring and oversight, rather than market abuse.
4.145 Market abuse risks are not exclusive to large firms. We have used transaction reports
from small firms as part of market abuse enquiries that resulted in enforcement actions. An exemption from transaction reporting for small firms could make small firms a target for bad actors looking to commit market abuse.
4.146 There would also be operational costs from monitoring compliance with any de minimis
threshold. Firms would still need to identify reportable transactions on an ongoing basis. Guidance would be needed on ways to measure value traded across asset classes, applying relevant currency conversions.
4.147 It is essential for us to have visibility of relevant transactions to monitor for market
abuse. Taking the above factors into account, we do not propose to introduce a de minimis threshold for reporting. Targeted training or guidance
4.148 We will provide targeted support for small firms in our transaction reporting user pack.
We encourage firms to refer to our improved transaction reporting webpages, which offer a range of resources to help firms navigate the regime and strengthen their reporting practices.

Chapter 5
Content of transaction reports
Introduction
5.1 This chapter covers the content of transaction reports. We propose changes to some
fields to improve data quality and make reporting more efficient. We propose to remove fields which we assess as placing a disproportionate burden on firms. Existing fields Trading venue transaction identification code (TVTIC)
5.2 In DP24/2 we highlighted data quality issues caused by inconsistent provision of TVTICs
by trading venues and investment firms failing to report them accurately. We sought views on 2 possible options to improve data quality:

Require trading venues to disseminate the TVTIC in a clearly labelled single piece
of information.
We publish information on the expected format and structure of the TVTIC for
each trading venue.
5.3 We also asked respondents to suggest other options for improving data quality.
Feedback received
5.4 Respondents were split on these options, with some suggesting both and some
suggesting neither. Some respondents suggested that we should create a standard syntax to be applied when the TVTIC is created. Others suggested harmonising requirements with data reported under UK EMIR, such as the Report Tracking Number (RTN) or UTI.
5.5 Some respondents suggested that current requirements are fit for purpose, and any
change would increase costs without guaranteeing better data quality. Others believed data quality has already improved through regulatory and industry focus in this area. Our proposal
5.6 In DP24/2 we noted that only 71% of TVTICs reported on UK trading venues from a
sample in Q2 2024 matched with another TVTIC. Following further supervisory work, the matching rate has increased to 83% (sample taken from Q2 2025). For venues with unusually low matching rates, we often find transaction reports with errors in the venue field. In some instances, the operating MIC rather than segment MIC has been populated and therefore the TVTIC will not match.

5.7 We have identified a positive correlation between data quality and trading venues
which provide the TVTIC in a clearly labelled, single piece of information. We have also identified a correlation between higher matching rates and trading venues which provide greater transparency to members on their TVTIC generation, dissemination and reporting processes.
5.8 We recognise that mandating these requirements would have a potentially significant
cost on trading venues that use different processes. Considering the improvement in data quality we have seen since DP24/2, we do not intend to require changes in this area now.
5.9 We will continue to monitor TVTIC data quality closely. We will follow up with specific
firms that are responsible for inaccurate or incomplete data. Should this monitoring underline a need for more prescriptive requirements, we will reconsider policy options.
5.10 We expect the TVTIC disseminated by trading venues to be consistent across RTS
22 and RTS 24.
Question 23: Do you agree with our proposal to maintain the status quo for reporting TVTICs?
5.11 We connect data reported under UK MiFIR and EMIR to support market monitoring. For
transactions executed on trading venues reportable under both regimes, the TVTIC and RTN can provide a useful link between the data. We encourage trading venues to harmonise their processes for generating TVTICs and RTNs where possible. We will not make this a requirement at this stage.
5.12 Currently the TVTIC must be reported for transactions executed on UK or EU trading
venues. In line with our proposed changes to the geographic scope of reportable financial instruments, we propose that the TVTIC should only be populated for transactions executed on UK trading venues.
5.13 We propose to update the CON-030 validation rule to reject transaction reports which
contain a TVTIC, and where the Market Identifier Code (MIC) reported relates to a non-UK trading venue. Question 24: Do you agree with our proposal to limit reporting of the TVTIC to transactions executed on UK trading venues only? Transaction reporting firms Definition of a transaction reporting firm
5.14 To simplify our new rules, we propose to add a new definition for firms subject to
transaction reporting requirements. This new definition will avoid repeated lengthy references in our rules to firms with different permissions.

Transaction reporting firm
A person who is either:
(a) a MiFID investment firm (excluding a collective portfolio management investment firm); or (b) a third country investment firm when it carries on MiFID or equivalent third country business from an establishment in the United Kingdom. Question 25: Do you agree with the proposed definition of a transaction reporting firm?
5.15 Where an executing entity is a UK branch of a third country investment firm, it should be
identified with the LEI for its head office. This applies even when the branch is eligible for an LEI. We propose to include this existing guidance as a new rule. Question 26: Do you agree with our proposal to require branches to be identified with the LEI of its head office or registered office? Investment Firm covered by Directive 2014/65/EU
5.16 We outlined our concern in DP24/2 that the name of RTS 22 Field 5 (Investment Firm
covered by Directive 2014/65/EU) and the associated reporting values are unclear. This may have led to misreporting by firms. We suggested we could update the field name and its content to make its intended purpose clearer. Feedback received
5.17 Most respondents agreed that updating the name of RTS 22 Field 5 would help improve
understanding of its purpose and associated data quality. In particular, this would help resolve challenges faced by UK branches of third country firms. Some respondents suggested new field names, including:

‘Self-reported indicator’.
‘Reporting firm covered by UK MiFIR’.
5.18 Some respondents said problems with RTS 22 Field 5 were caused by confusing
underlying requirements rather than the field name or reporting values. Our proposal
5.19 We propose to update the name of this field to ‘Executing entity is a transaction
reporting firm’. We are also proposing to update the ‘content to be reported’ table for this field.

Question 27: Do you agree with the proposed changes to RTS 22 Field 5? Buyer and seller fields Identifying trusts in transaction reports
5.20 In DP24/2 we discussed the problems with inconsistencies in identifying trusts in
transaction reports, and their impact on our ability to undertake effective market monitoring. The ESMA Guidelines state that where an investment firm knows the underlying client and sets up the trust arrangement, the firm should report the underlying client as the buyer or seller and not the trust LEI. In all other cases, firms should use an LEI.
5.21 This results in some unique trusts being identified in transaction reports with nonunique identifiers. It also requires some trusts to obtain an LEI after transactions have
been executed on its behalf by another investment firm, creating a high relative cost on small trusts.
5.22 We sought views on allowing firms to report the underlying client as the buyer or seller in
all cases where the firm knows the client’s identity and holds accurate national identifier(s). Feedback received
5.23 Some respondents supported this proposal. They argued that reporting using national
identifiers better reflects beneficial ownership and simplifies reporting in some scenarios.
5.24 Some respondents were uncertain about whether the term ‘underlying client’ should
apply to the trustee or the trust’s beneficiary. Some firms were also concerned about the confidentiality of underlying beneficiaries’ details and data protection. They warned of an additional burden if the trust’s underlying beneficiary changed and the investment firm was required to determine this (and get relevant national identifiers) on an ongoing basis.
5.25 A smaller number of responses had mixed views, suggesting that firms should be
given a choice.
Our proposal
5.26 We propose to introduce more flexibility in how trusts are identified in transaction
reports. Under our proposal, investment firms would be able to report either the trust (using an LEI) or underlying client(s) (using a national identifier, assigned in line with applicable rules), regardless of whether the firm has established the trust arrangement.
5.27 Where a firm chooses to report the underlying client, this should identify the
trust’s beneficiary.
5.28 As well as giving flexibility, this approach would reduce the administrative burden of
obtaining LEIs, particularly for small bare trusts with a single underlying beneficiary.

5.29 We recognise our proposal will maintain the baseline of some trusts being identified
using non-unique identifiers. However, our view is that the number of instances in which this applies will reduce. Where an investment firm executes a transaction for a trust it did not set up, it will now be able to use the same identifier for the underlying client(s) as the firm that established the trust. Question 28: Do you agree that investment firms should be allowed to report either a trust LEI or national identifier of the beneficiary when executing a transaction for a trust? Identifying clients in transaction reports
5.30 Identifying clients accurately is essential for market abuse enquiries, enabling
identification of abuse across multiple accounts and intermediaries. Inaccurate or inconsistent identifiers obscure the link between related trades, reduce the effectiveness of surveillance and increase the risk of undetected misconduct.
5.31 Article 13(2) of RTS 22 requires investment firms to get an LEI from clients eligible for
one before providing a service that triggers the obligation to submit a transaction report for that client. This is an important data quality control. We reject transaction reports submitted with LEIs that were not valid on the trade date.
5.32 We propose to extend this requirement to cover transactions executed for natural
persons. We propose to do this by amending the existing exclusion in Article 13(2) of RTS 22. The proposed exclusion is in MAR 14.13.24R. Question 29: Do you agree with our proposal to require firms to obtain national identifiers for natural persons before a service is provided for that client which triggers the obligation to submit a transaction report? Trading on a trading venue where the identity of the counterparty is not known at the point of execution
5.33 In DP24/2 we suggested the firm should report the segment MIC of the trading venue in
the buyer or seller identification code fields (RTS 22 Field 7 or Field 16) for all scenarios where it does not know the counterparties at the point of execution.
5.34 Some firms incorrectly consider settlement activity when submitting transaction
reports. This may be due to the requirement to report a central counterparty (CCP) LEI for transactions executed on a trading venue where the counterparty is not known and the trading venue uses a CCP.

Feedback received
5.35 Most respondents supported this approach, saying it could potentially reduce the
operational burden of identifying and validating CCP LEIs.
5.36 A small number of respondents did not support this change. They felt existing
requirements worked adequately and that the benefits would not offset the costs of the change. They also pointed out the CCP is the legal counterparty to cleared transactions.
5.37 Some respondents said this change would allow for additional data quality checks. It
would make reconciliation possible between the segment MIC reported in RTS 22 Field 7/16 (Buyer/seller identification code) and RTS 22 Field 36 (Venue).
5.38 We also received specific feedback suggesting that this approach should cover investment
firms trading on an OTF, where currently the OTF LEI is reported in RTS 22 Field 7/16. Our proposal
5.39 We propose to require the segment MIC of the trading venue to be reported in the buyer
and seller fields for all trading scenarios where the firm does not know the counterparty at the point of execution. This includes when trading on an OTF. This also includes transactions executed on an organised trading platform outside of the UK. Question 30: Do you agree with this proposal to report the segment MIC in these scenarios? Generation of a CONCAT
5.40 Article 6(4) of RTS 22 gives instructions for generating a concatenated identifier where
another priority identifier is not available. This is commonly referred to as a CONCAT. The ESMA Guidelines give more information on the CONCAT generation process.
5.41 We propose to consolidate existing guidelines for CONCAT generation in our rules.
The rules we are proposing are in MAR 14.13.6R-14.13.7R.
Question 31: Do you agree with our proposed rules for generating CONCATs in MAR 14.13.6R-14.13.7R? National identifiers for British Overseas Territories (BOTs)
5.42 We have received questions on how to identify natural persons from the Isle of Man,
Gibraltar, Channel Islands and other BOTs in transaction reports. These territories are not listed in the Annex II to RTS 22.
5.43 We have previously told firms to identify natural persons from these territories in line
with the requirements for “all other countries” in Annex II to RTS 22. The first priority

identifier for all other countries is a passport number. BOTs also have an ISO 3166-1 alpha-2 letter country code, which should be used as the prefix for the identifier.
5.44 We propose to confirm this approach in our updated rules.
Question 32: Do you agree with the proposal to require natural persons from the Isle of Man, Gibraltar, Channel Islands and other BOTs to be identified in accordance with the requirements of ‘all other countries’? Dual nationals
5.45 Article 6(3) of RTS 22 gives guidance on which national identifier should be used where a
person is of more than one nationality. However, the requirement does not specify how to identify a natural person who is a national of more than 1 non-European Economic Area (EEA) country.
5.46 We propose to clarify that the country code of the first nationality when sorted
alphabetically by its ISO 3166-1 alpha-2 code should be used. The proposed rule is in MAR 14.13.5R(6). Question 33: Do you agree with the proposed rule in MAR 14.13.5R(6) where a person is a national of more than 1 non-EEA country? Transmission of order indicator
5.47 We have seen persistent data quality issues with the transmission of order indicator
(RTS 22 Field 25). The use of the term ‘transmission’ may be a contributing factor, as it can be interpreted to refer to both the activity of transmitting an order and a firm meeting the conditions for ‘transmission’ in Article 4 of RTS 22. These concepts are not always the same.
5.48 We asked how data quality could be improved for transactions involving transmission.
Feedback received
5.49 Respondents generally agreed that data quality would be improved if the name of RTS
22 Field 25 was clearer. They agreed the term ‘transmission’ can be interpreted to mean different things. Several respondents said this should be supplemented with more comprehensive guidance to demonstrate how this field should be populated in different trading scenarios.
5.50 Respondents also highlight challenges specific to transmission meeting the conditions
of RTS 22 Article 4. We address this in Chapter 4 in the section on conditional singlesided reporting and later in this chapter.

Our proposal
5.51 We propose to remove the transmission of order indicator field. The purpose of this field
is to identify where an order received by a firm is routed to another firm but where the conditions in Article 4 of RTS 22 were not met. We have considered the value we gain from this information against the cost of this field to firms, exacerbated by the issues above. Overall, we believe it would be disproportionate to require changes to this field to improve data quality when we only use the information sporadically.
5.52 While some firms may face an initial implementation cost to stop reporting this
information, we believe this will be offset by future savings from streamlining reporting. Question 34: Do you agree with the proposal to remove RTS 22 Field 25 (transmission of order indicator)? Trading capacity
5.53 Under the ESMA Guidelines, firms are required to report the trading capacity and the
buyer and seller fields so the values are consistent when viewed together. We propose to incorporate these guidelines into our rulebook. In addition, we are considering the introduction of new validation rules in this area, to mitigate potential data quality issues and ensure consistent reporting.
5.54 We are proposing the following guidance:
MAR 14.13.32R
The population of this field must be consistent with the population of the buyer/ seller field in the transaction report:
(a) For a trading capacity of DEAL, either the buyer or seller must be the LEI of the executing entity. (b) For a trading capacity of AOTC/MTCH, the buyer and seller field must not be populated with the LEI of the executing entity. (c) For a trading capacity of MTCH, the buyer and seller can be 2 clients of the transaction reporting firm or a client and a market counterparty. Question 35: Do you agree with the proposed guidance for reporting the trading capacity?

Quantity and price
XML schema tags
5.55 In DP24/2 we discussed problems caused by the various tags for reporting the quantity
(RTS 22 Field 30) and price (RTS 22 Field 33) fields. These values need to be reported accurately and consistently to help our understanding of trading scenarios and the economics of a transaction.
5.56 For most asset classes, there is no requirement to use a specific tag. This gives firms
flexibility to choose the tag that most closely resembles the trade economics without having to convert values. However, we know this can also lead to inconsistency and uncertainty about the most appropriate value to use. This sometimes results in inaccurate transaction reports. Feedback received
5.57 Some respondents suggested we should add more prescriptive requirements to ensure
consistency. However, more respondents felt additional guidelines may be sufficient.
5.58 Much of the feedback was on the price type rather than the quantity type. Respondents
highlighted the following asset classes and products as posing specific challenges:

Equity derivatives, especially CFDs and swaps.
Interest rate swaps.
FX swaps, swaptions, straddle options.
Credit default swaps, including the coupon, spread and upfront payment.
Exotic and complex derivatives.
Derivatives with an underlying index.
5.59 Respondents also asked about:
How to report the price when it is quoted in the native token of a blockchain.
When to use the percentage price type rather than monetary value for bond futures
and interest rate futures.
The difference between monetary value and nominal value.
Package/complex trades.
5.60 Respondents also asked that guidance reflects standard market practice and is aligned
between UK MiFIR, EMIR and SFTR where relevant. They suggested industry working groups could help identify best practice to remove inconsistencies. Our proposal
5.61 We need to balance the need for consistent data collection and cross-regime alignment,
with giving firms flexibility to report according to market practice.

5.62 Where required, we propose to provide more guidance. To this end, we would ask firms
to provide detailed suggestions about where they see misalignment among regimes, or a lack of clarity.
5.63 While we ideally want more consistency for cross-regime alignment, we are limited by
MIFIR’s current fields. However, we do not feel it is proportionate to create additional fields.
5.64 For instance, unlike EMIR, we do not have the notional reported alongside quantity
and price, so need to rely on the 2 latter fields. This means we cannot deduce the price multiplier. The only other alternative would be to amend the basis of the price for derivatives to be the price/premium of the contract rather than the price/premium of the underlying. This would however involve considerable system changes and appears difficult to justify.
5.65 Listed below are specific instances we have considered and developed proposals for:

We consulted specifically on how to populate the price field for equity swaps. The
topic is covered later under the SwapIn and SwapOut section of this CP.
We have considered whether we could merge monetary and nominal value quantity
tags. However, we concluded the cost of change would be disproportionate to the potential benefits as the current separation does not affect our ability to use the data.
We considered applying price and quantity tags via instrument reference data. This
would mean firms would only need to submit the values for quantity and price in their transaction reports, without having to specify price and quantity types which would be taken from FCA FIRDS. However, we decided against this. Our view is it is not proportionate as it would create further fields in RTS 23. This would potentially create implications for TOTV determinations and only apply to transactions falling under Article 26(2)(a) of UK MiFIR, limiting coverage. Price field for equity swaps
5.66 The price field for an equity swap should reflect the spread on the financing rate. This
contrasts with the approach required for reporting equities and similar equity derivative products, such as single name forward contracts with a CFD payout trigger. For these instruments, the price field reflects the price of the underlying financial instrument.
5.67 In DP24/2 we asked for feedback on aligning reporting requirements for the price field
for single name equity swaps with the reporting of forwards with a CFD payout trigger. We asked if the same approach could be applied to swaps with multiple underlying instruments. Feedback received
5.68 Respondents were generally positive about using the underlying price for single name
equity swaps. Some respondents said it would create helpful harmonisation with UK EMIR. A few respondents said the spread on the financing rate provides more useful insight into the equity swaps market than the price of the underlying.

5.69 We received mixed feedback for equity swaps referencing multiple underlying
instruments, such as portfolio swaps. Some respondents pointed to increased complexity where the underlying price is not readily available and must be calculated. One respondent requested new reporting guidelines for a range of different equity swap instruments and trading scenarios.
5.70 One respondent raised the possibility of requiring different price values for different types
of equity swaps. They noted this would require more complex reporting logic than currently. Our proposal
5.71 We propose to change reporting requirements for equity swaps with a single underlying
instrument. For these instruments, we propose that the price field should be reported with the price of the underlying instrument, instead of the spread on the financing rate. This will create alignment between the reporting of single-name equity swaps and singlename equity CFDs. It will also create harmonisation with UK EMIR reporting requirements for the price field, derived from CDE Technical Guidance, for the same transactions. Question 36: Do you agree with our proposal to require the price of the underlying instrument to be reported in the price field for equity swaps with a single underlying?
5.72 We have considered existing reporting approaches for reporting derivatives with
multiple underlyings. Table 5 shows the number of transaction reports received in 2024 for equity swaps and equity forwards on indices and baskets, aggregated by the combination of values reported in the price and quantity fields.
Table 5: Price and Quantity types for specific equity derivatives
Description CFI Price Quantity No. of reports Forward with CFD payout trigger JEBXCC Monetary Unit 46,208 JEIXCC Basis points Unit 83,921,195 Monetary Unit 36,813,494 Equity basket swap with total return swap payout trigger SEBT Basis points or percent Monetary or nominal value 38,170,331 Equity index swap with CFD payout trigger SEIC Monetary Unit 3,069,311 Equity index swap with total return swap payout trigger SEIT Basis points or percent Monetary or nominal value 259,820 Monetary Unit 51,636
5.73 The data shows a range of approaches. For some instruments, such as index swaps with
a CFD payout trigger, there is general convergence around a single reporting approach. For others, such as forwards with a CFD payout trigger, we see several approaches.

5.74 We view the reference price of the underlying as a more valuable factor for our use of
the data. We also see benefits in creating consistency with the reporting of equity swaps regardless of the number of underlying financial instruments. However, we know there may be some instances where it is not reasonably practical to derive a single price for the underlying. In these cases, the spread of the financing rate may be a more valuable data attribute.
5.75 We propose that firms should report the price field with the price of the underlying
instrument(s) or index where available. Where the underlying price is not available, the spread of the financing rate should be reported. Question 37: Do you agree with our proposal to require the price of the underlying instrument to be reported in the price field for equity swaps with more than one underlying where available, and the spread of the financing rate in other cases? SwapIn and SwapOut
5.76 Section 5.35.7 of the ESMA Guidelines shows how to report swaps where there are
separate cash flows involved in the transaction. The guidelines suggest the use of a ‘+’ or ‘-’ sign in front of the underlying instrument code or the underlying index name. These signs are intended to indicate the direction the performance is paid. A ‘+’ sign indicates the buyer is receiving the performance of the underlying, while a ‘-’ sign indicates they are paying the performance of the underlying. These signs are represented as ‘SwpIn’ or ‘SwpOut’ in the XML text.
5.77 Wider feedback on equity swap reporting showed firms found it challenging to understand
the relationship between SwpIn/SwpOut components, the buyer/seller fields and the derivative notional increase or decrease field (RTS 22 Field 32). This was particularly true where an investor fluctuates between long and short exposure on a swap. Our proposal
5.78 For equity swaps, the buyer field should be reported as ‘the counterparty that gets the
risk of price movement of the underlying security and receives the security amount’. Where a security or index is reported against a rate, the SwpIn and SwpOut signs provide no additional insights, as the direction the performance is paid can be seen from the buyer and seller fields.
5.79 The primary use case for SwpIn/SwpOut signs is to cover equity swaps where equity
instruments are being exchanged for others equity instruments. These represented less than 0.01% of swaps reported in 2024. The SwpIn/SwpOut components also do not apply to derivatives traded on a trading venue. This is because the information is not required in the instrument reference data used to enrich the underlying instrument name in transaction reports.

5.80 Considering the limited additional value this information provides, the impact it has on
data quality and the additional complexity it brings to reporting logic, we propose to remove the SwpIn (+) and SwpOut (-) tags from the transaction reporting regime. Question 38: Do you agree with our proposal to remove the concept of SwpIn (+) and SwpOut (-) tags?
5.81 The derivative notional increase or decrease field is used to show whether a transaction
is an increase or a decrease of notional of a derivative contract. This information’s value is limited, as we cannot link the transaction report with previous transaction report(s) for the same derivative contract.
5.82 The direction of a derivative transaction can be determined from the buyer and seller
fields. So the only value of the derivative notional increase or decrease field is its indication of whether the derivative is a new contract or adjustment to an existing contract. While sometimes useful, we can get this information from UK EMIR data submitted for modified derivative contracts.
5.83 We propose to remove RTS 22 Field 32 (Derivative notional increase/decrease).
Question 39: Do you agree with our proposal to remove RTS 22 Field 32 (Derivative notional increase/decrease)? Venue
5.84 RTS 22 Field 36 (Venue) must be populated with the MIC of the trading venue on which
a transaction took place. This also applies to transactions which are negotiated away from but brought under the rules of a trading venue. We propose to make this clear in our rules.
5.85 RTS 22 Field 36 should also be populated with a MIC when a transaction is executed
with an SI. But we understand that firms do not always know whether the firm they are dealing with is acting as an SI for a transaction. We propose to update the venue field to specify that the MIC of the SI should be reported where known. We would expect this to be known in all cases where the executing entity is acting as the SI. Question 40: Do you agree with the proposed changes to RTS 22 Field 36 (Venue)? Instrument details
5.86 RTS 22 fields 50 (Option type), 53 (Option exercise style) and 56 (Delivery type) must be
populated for certain derivative which are not reported with an ISIN that exists in FCA FIRDS.

5.87 The information in these 3 fields can all be determined from the CFI code reported for
the instrument in RTS 22 Field 43 (Instrument classification). This is a mandatory field for all transactions. We see no purpose or value in duplicating the information. A small number of respondents to DP24/2 highlighted this duplication.
5.88 We propose to remove these fields to streamline the regime.
Question 41: Do you agree with the proposal to remove RTS 22 fields 50 (Option type), 53 (Option exercise style) and 56 (Delivery type)? Maturity date
5.89 RTS 22 Field 54 (Maturity date) must be populated with the financial instrument’s date of
maturity. The field only applies to debt instruments with a defined maturity date.
5.90 However, this field does not apply for transactions executed in TOTV debt instruments.
In these cases, the instrument reference data received for the instrument will specify the maturity date. We use this data to enrich the transaction reports we receive. 99.8% of debt transactions reported to us are in TOTV financial instruments.
5.91 This means RTS 22 Field 54 only applies to 0.2% of transaction reports submitted for debt
instruments. This covers financial instruments which are uTOTV only (undelying traded on a trading venue). For example, where the debt instrument traded is a convertible bond which is not TOTV but has an underlying which is TOTV. Our analysis shows the debt instrument’s maturity date is generally included in the instrument full name.
5.92 Given the limited use of the maturity date field in transaction reports, and appropriate
alternative data, we propose to remove the field from RTS 22. We will continue to enrich transaction reports with instrument reference data received for debt instruments. Question 42: Do you agree with the proposal to remove RTS 22 Field 54 (Maturity date)? Notional currency 2
5.93 Notional currency 2 (RTS 22 Field 45) should be populated for multi-currency swaps,
cross-currency swaps, and swaptions where the underlying swap is multi-currency.
5.94 We have not identified any data for these instruments where the financial instrument is
not TOTV. This means we use the notional currency 2 from instrument reference data in all cases where this field applies.
5.95 So we propose to remove the notional currency 2 field from RTS 22 as it appears to
provide no benefit. We will continue to enrich transaction reports with instrument

reference data for multi-currency swaps, cross-currency swaps and swaptions where the underlying swap is multi-currency. Question 43: Do you agree with the proposal to remove RTS 22 Field 45 (Notional currency 2)? Strike price
5.96 The strike price is the predetermined price at which the holder will have to buy or sell
the underlying instrument. Sometimes this price cannot be determined at the time of execution. We have seen some firms populate the strike price with ‘0’ in these cases.
5.97 We propose to introduce a new ‘NOAP’ value for the strike price field. This value
should only be used where the strike price cannot be determined. This will enable us to distinguish cases where the strike price cannot be determined from cases where the strike price is nil. Question 44: Do you agree with our proposal to make ‘NOAP’ a reportable value in the strike price field? Indicator fields
5.98 We refer to RTS 22 fields 61-65 as the ‘indicator fields’. In July 2023, we extended
supervisory flexibility to these fields. This confirmed that, on a temporary basis, we would not take action against firms which did not meet requirements for these fields. Despite this, 14 billion data points were reported to us in these fields in 2024.
5.99 In DP24/2 we highlighted limitations on the usefulness of data in the indicator fields. We
asked for feedback on removing the fields to help streamline requirements. Feedback received
5.100 All respondents were in favour of removing the indicator fields. They said this would
support simplification, reduce costs and avoid duplicative reporting.
5.101 Some respondents said removing these fields would require them to implement a new
schema and these implementation costs would offset some of the benefits. They suggested these fields could be maintained but made not applicable to achieve the same benefits we described but with a lower implementation cost. Our proposal
5.102 We propose to remove RTS 22 fields 61-65. We know removing these fields will require
firms to implement a new schema for transaction reporting. However, when considered

alongside other proposed changes in this CP, we consider the overall benefit of streamlining the regime will justify the implementation costs over a longer-term period. Question 45: Do you agree with the proposal to remove RTS 22 fields 61-65? Country of Branch fields
5.103 There are 5 country of branch fields in RTS 22:

Country of the branch for the buyer (RTS 22 Field 8).
Country of the branch for the seller (RTS 22 Field 17).
Country of the branch membership (RTS 22 Field 37).
Country of the branch supervising the person responsible for the investment
decision (RTS 22 Field 58).
Country of the branch supervising the person responsible for the execution (RTS 22
Field 60).
5.104 The primary purpose of these fields was to enable us to share relevant information
through ESMA’s Transaction Reporting Exchange Mechanism (TREM). We no longer share information through ESMA’s TREM.
5.105 We have considered our use of the information reported in these fields. For fields 37,
58 and 60, we have used the data to support supervisory activity and market abuse enquiries involving transactions executed by overseas branches of non-UK firms. However, we assess the frequency and scale of this benefit as disproportionate to the cost of reporting these fields.
5.106 We propose to remove RTS 22 fields 37 (Country of the branch membership), 58
(Country of the branch supervising the person responsible for the investment decision) and 60 (Country of the branch supervising the person responsible for the execution). Question 46: Do you agree with the proposal to remove RTS 22 fields 37, 58 and 60?
5.107 RTS 22 fields 8 and 17 give additional information as they show whether the buyer or
seller was a client of the executing entity. We use this information regularly as part of market abuse enquiries and analytical work involving order flow tracking and client relationship mapping. So we propose to maintain the obligation on transaction reporting firms to tell us whether the buyer or seller reported is the firm’s client.
5.108 However, this information could be provided in a more streamlined and efficient way
rather than via the existing values in fields 8 and 17. These fields have persistent data quality issues, with a range of problems, including:
Populating these fields when the buyer/seller is not a client of the firm.
Leaving these fields blank where the buyer/seller is a client of the firm, but no branch
was involved in receiving the order from the client.
Using these fields to show the geographic location of the buyer/seller.

5.109 We propose to remove RTS 22 fields 8 and 17. We propose to replace these fields with 2
new fields called the ‘client indicator for the buyer’ and ‘client indicator for the seller’.
5.110 In DP24/2 we looked at potentially introducing a new field in transaction reports
to capture a client’s MiFID categorisation. This would increase our ability to detect consumer harm. We also recognised there may be challenges where client categorisations change over time.
5.111 Some respondents supported the introduction of a new client category field. They
noted firms already capture this data within core systems, making implementation straightforward. They highlighted potential benefits to market integrity from closer monitoring and oversight of transactions executed by retail clients.
5.112 However, most respondents opposed the proposal. They argued it would introduce
unnecessary complexity, increase costs and add regulatory burden without clear benefits. Some questioned whether transaction reporting was the appropriate mechanism for collecting this information. Respondents also pointed out the dynamic nature of client categorisation, particularly for clients treated as professionals on request, making it difficult to maintain accurate data. We have also stated our plans to review client categorisation rules.
5.113 As a result, we propose that the new client indicator field would be a Boolean field, with
a mandatory ‘TRUE’ or ‘FALSE’ value required. The tables below demonstrate how this field would be reported in certain scenarios.
Table 6: Example of a DEAL transaction where the buyer is a client of the firm
Executing entity Buyer
Client indicator for the buyer Seller
Client indicator for the seller
Trading capacity
Firm X Client A TRUE Firm X FALSE DEAL
Table 7: Example of a AOTC transaction where the buyer and seller are both
clients of the firm
Executing entity Buyer
Client indicator for the buyer Seller
Client indicator for the seller
Trading capacity
Firm X Client A TRUE Client B TRUE AOTC
Table 8: Example of a transaction executed on venue where the seller is a client
and the counterparty is not known at the point of execution Executing entity Buyer Client indicator for the buyer Seller Client indicator for the seller Trading capacity Firm X MIC FALSE Client A TRUE AOTC

Question 47: Do you agree with the proposal to remove RTS 22 fields 8 and 17 (Country of the branch for the buyer/seller) and replace them with a new client indicator field? Direct electronic access (DEA) indicator
5.114 DEA is where a member, participant or client of a trading venue permits a person to use
its trading code so the person can electronically transmit orders relating to a financial instrument directly to the trading venue.
5.115 In DP24/2 we highlighted that RTS 22 does not have a unique field to indicate a
transaction executed through DEA. RTS 6 sets out specific rules in relation to DEA. We currently have a gap in our ability to monitor this area of the market. We outlined 2 options to improve oversight of DEA activity:

Adding a new DEA indicator field, to be populated in the transaction report
submitted by a DEA user or DEA provider. This would be a ‘TRUE’ or ‘FALSE’ field, similar to RTS 24 Annex Table 2 Field 2.
Adding a new reporting value in RTS 22 Field 59 (Execution within firm). Under this
option, a new reporting value would indicate that the execution decision maker was not within the firm and the transaction is a DEA transaction. This would only apply to the DEA provider’s transaction report. Feedback received
5.116 Most respondents supported Option 2 (using the existing execution within firm field).
One response supported Option 2 on the condition we provided more guidelines for when firms can use ‘NORE’ in RTS 22 Field 59. This is the default value that should be populated where the execution decision was made by a client or by another person from outside the investment firm reporting the transaction.
5.117 A few respondents preferred Option 1 (a new field). One respondent had concerns
about data quality resulting from the availability of multiple values for a single field, each with a slightly different meaning.
5.118 Two respondents did not support any changes, suggesting we do not need more
detailed information on DEA.
Our proposal
5.119 We propose to add a new reporting value to RTS 22 Field 59 to indicate where a firm
is providing DEA (Option 2). This new value, ‘DEAU’, would be reported instead of the existing ‘NORE’ value that is used to indicate that the DEA user decided how to execute the transaction. Table 9 shows a transaction reported by DEA provider Firm Y with DEA user Firm X. The DEA user would not need to make any changes.

Table 9: Transaction report submitted by DEA provider under our proposal
Executing entity Buyer Seller
Trading capacity Venue
Execution within firm
Firm Y Firm X Market AOTC XMIC DEAU
5.120 ‘NORE’ should still be used in other scenarios where the execution decision was made
outside the firm. We will give more examples on the use of ‘NORE’ and ‘DEAU’ in our transaction reporting user pack. Question 48: Do you agree with the proposal to add a new reporting value to RTS 22 Field 59 (Execution within firm) to identify where a firm is providing DEA? Complex trades
5.121 A ‘complex trade’ involves executing a transaction in multiple financial instruments for
a single price. Each leg of the transaction must be reported separately and linked with a unique complex trade component ID in RTS 22 Field 40.
5.122 We view the single complex trade price as crucial for understanding the economics
of these transactions. However, we could improve our monitoring capabilities by understanding individual leg prices as well as the complex trade price. This is not possible within the existing structure of transaction reports. In DP24/2 we discussed potentially introducing a second price field for complex trades, so both prices could be reported. Feedback received
5.123 Responses were split, with a slight majority in favour of 2 price fields. Most responses
suggested we should carry out little or no validation on the single leg price field, as the data may not always be available.
5.124 Those arguing against 2 price fields suggested that leg prices could often be derived
from the package transaction and would not be useful without additional context. Some respondents questioned if the change would add proportionate value compared to the cost involved.
5.125 Several responses suggested aligning the definition of a complex trade in UK MiFIR with
the definition of a 'package transaction' under UK EMIR.
Our proposal
5.126 We propose to replace the concept of a ‘complex trade’ in Article 12 of RTS 22
with the concept of a ‘package transaction’. This will harmonise with UK EMIR reporting requirements.

5.127 We do not intend to use the existing definition of a ‘package transaction’ in our Glossary
of definitions. This definition was designed for the transparency regime and requires package legs to be executed simultaneously. MAR 14.13.20R For the purposes of this chapter, a package transaction means either:
(1) a transaction involving 2 or more reportable financial instruments; or (2) two or more transactions negotiated together as a result of a single economic agreement. MAR 14.13.21R Where a transaction reporting firm executes a package transaction, the transaction reporting firm must submit a separate transaction report for each reportable financial instrument or transaction separately and must link these transaction reports with an identifier as specified in field 37 of Table 2 of MAR 14 Annex 1. MAR 14.13.21G A package transaction may include reportable financial instruments and instruments that are not reportable financial instruments. In these cases, a transaction reporting firm is only required to submit transaction reports for the reportable financial instruments in that package transaction.
5.128 The name of RTS 22 Field 40 will be amended to ‘Package identifier’. The content of field
will also specify that, where possible, the identifier reported should mirror the ‘package identifier’ for the same transaction(s) under UK EMIR.
5.129 We also propose to introduce 2 new fields:

‘Package transaction price’
‘Package transaction price currency’
5.130 As is the case under current rules, a package may include reportable and non-reportable
instruments and transactions. Transaction reports should only be submitted for transactions in reportable instruments. Question 49: Do you agree with the proposed definition of a package transaction? Price field for package transactions
5.131 We will introduce a second price field to capture the package price. We know the single
leg price may not always be available. Our validation rules will accommodate this. Below we provide 2 examples of reporting. 1 where the single leg price is available and 1 where it is not.

Table 10: Example of a package transaction where the leg price is available
Executing entity Price
Price currency
Package identifier
Package transaction price
Package transaction price currency
Firm X 50 GBP 12345A 10 GBP
Table 11: Example of a package transaction where the leg price is not available
Executing entity Price
Price currency
Package identifier
Package transaction price
Package transaction price currency
Firm X NOAP 12345A 10 GBP
Question 50: Do you agree with the proposal to capture the single leg prices of a package transaction? Are there any changes we should make to the proposed fields? Personal information for individuals responsible for making investment and execution decisions within a firm
5.132 We considered extending the obligation to report the full name and date of birth of
individuals to the investment and execution decision makers within the firm. In 2024, there were 35,316 unique persons identified as an investment decision maker (IDM) or execution decision maker (EDM) in transaction reports. Feedback received
5.133 Most respondents were against providing additional PII to identify a firm’s investment or
execution decision makers. Many felt the added visibility we would achieve would not be proportionate to the operational burden and costs to firms. Many also raised concerns around data security and heightened risk of cyber-attacks (both at a firm and ARM level) as this information would likely relate to high-wealth individuals. Firms noted the likelihood of duplicative CONCATs being low.
5.134 Some respondents questioned whether we could use existing information better in
these fields. Other respondents said these additional fields would add a new regulatory burden for firms who only have institutional clients. Our proposal
5.135 We have considered the potential cost of adding more detail to the investment and
execution decision maker within firm fields against the benefits. On balance, it is

not clear that we can justify the additional costs. So we do not propose to introduce these new fields. Aggregate client linking code
5.136 In DP24/2 we highlighted data quality problems with the aggregate client account
(‘INTC’) reporting convention. We outlined 2 potential options for improving data quality. Both options involved creating a new aggregate client linking code, either as a new field (Option 1), or to be used in place of INTC in the buyer or seller fields (Option 2). We also sought feedback on other ways to improve data quality for transactions which require using the INTC reporting convention. Feedback received
5.137 More respondents were in favour of Option 1 than Option 2. There were concerns about
the feasibility of adding additional free text values to the buyer and seller fields. Most respondents said both options had significant implementation costs. They asked us to carefully consider the cost-benefit of any potential change, noting the widescale use of the INTC reporting convention. In 2024, we received 342 million transaction reports from 447 investment firms that used INTC.
5.138 Many respondents asked for more guidance to help them understand how to use
the INTC reporting convention in more complex scenarios, including where orders are amended or cancelled. Some suggested regulatory alignment with the EU would be a key determining factor in deciding what proposal to support. Other responses suggested replacing the INTC code with an alternate standard, such as the RTN or UTI. Our proposal
5.139 We do not propose to introduce a new aggregate client linking code. While this may help
some firms improve data quality, implementation and change costs are likely to offset potential benefits. It is also likely that adding client linking codes would harm data quality, as it would increase the number of individual data points firms must report to us.
5.140 We plan to consult on additional guidance to give further clarity on the use of
INTC next year.
Question 51: Do you agree with the proposal to maintain existing requirements for the aggregate client linking code? Digital token identifier (DTI)
5.141 Tokenisation is a key component of future financial services. Tokenisation is a way
of representing an asset, or who owns an asset, by recording it on distributed ledger

technology (DLT). DLT is a digital system that records details of transactions in multiple locations at the same time, rather than on a centralised database.
5.142 In DP24/2 we said we expect to receive transaction reports for transactions executed
in tokenised securities that are a digital representation of a financial instrument which is in scope of the UK transaction reporting regime. This is irrespective of where the transaction took place.
5.143 However, when a transaction report is submitted for a transaction executed in a digital
representation of a financial instrument, the data does not allow us to differentiate between the traditional asset and the digital representation.
5.144 We considered whether we should add a new field for reporting the DTI. We noted this
could improve our market monitoring capabilities and allow us to monitor tokenised securities more effectively.
5.145 We also recognised that this is a developing market, which may not create a requirement
for this information. We also noted the burden of adding a new field may not be justified as it would only apply to a small subset of firms and transactions. Feedback received
5.146 Respondents were divided. Some supported using a recognised ISO standard to
identify tokenised securities and said this would support our monitoring capabilities in a developing area of the market.
5.147 Others were against a new field for reporting the DTI. They questioned the
proportionality of introducing a new field for all firms which would not apply to most transaction reports.
5.148 Some respondents said if we choose a DTI, we need to provide clear guidance on which
level of DTI firms should report and in what scenarios.
Our proposal
5.149 We recognise the important and rapidly developing nature of digital markets, as well as
the importance of international standards in creating standard reporting taxonomies. However, at this point, we believe the change cost required to implement a new reporting field for the DTI would be outweighed by the benefit this data provides.
5.150 We used data from the DTI Foundation Registry to identify there were 113 ISINs for DTIs
as of October 2025. But only 1 transaction report has been submitted to us involving the 113 ISINs. While we are unable to determine whether the ISIN traded was a tokenised version, we see it as disproportionate to require reporting a new field to identify these.
5.151 Through the Treasury’s repeal and replacement of provisions related to transaction
reporting, we want to create a more agile regulatory framework for the future. We expect this agile framework will allow us to consult quickly and efficiently on potential future requirements to cover new technologies and help us oversee this evolving market.

5.152 As highlighted in DP24/4, we may use the DTI to identify specific cryptoassets in
information disclosures. We will also continue to monitor the growth of this market closely, including through the Digital Securities Sandbox (DSS). The role of intermediary brokers in transaction reporting chains
5.153 In DP24/2 we noted a variety of reporting approaches where intermediation takes
place across a transaction chain. We observed some intermediary brokers submitting transaction reports while other firms, seemingly playing a similar role, were not. We also saw reporting inconsistencies from parties in the same chain. We wanted to better understand these intermediaries’ role in these transactions and any challenges within the reporting process for relevant trading scenarios, including block trading.
5.154 We invited respondents to provide recommendations on how to improve data quality for
chains that involve intermediary brokers.
Feedback received
5.155 Respondents generally agreed that chains with intermediary brokers can be treated
differently by markets participants which may lead to reporting inconsistencies. Some focus on the legal clearing arrangements, others consider the entity originating the transaction at desk-level, while others take an operational or systems-based view. Scenarios may vary based on the trading capacity of relevant parties.
5.156 Respondents explained that block trades tend to be privately negotiated between
participants, usually with an intermediary broker, away from the trading venue. At the point the trade is agreed, it is not considered to meet the definition of execution because it is only a contingent agreement to trade. Only when the block trade is submitted to the trading venue, and is validated and registered, does it become reportable under RTS 22. If any of the pre-trade validations fail, the trade is rejected, underscoring that an intermediary broker does not play a part in the transaction’s execution. Participants can arrange block trades directly and, in such cases, there is no intermediary broker in the chain.
5.157 Respondents explained that with the Direct Exchange Member (voice) trading model,
a broker arranges a block trade for 2 firms and submits it to the trading venue for validation and registration. On submission, the trade is booked as 2 separate executions, directly into each firm’s trading venue account. The firms who are party to the block trade may then clear the transaction through their respective arrangements.
5.158 Respondents said definitions for intermediary brokers, executing brokers, brokerage
activity and examples of relevant trading scenarios would help streamline the reporting approach. They would also welcome clarification on the type of activity that constitutes on-venue and off-venue execution for intermediated trades. In addition, providing scenarios that cover activity through which Article 26(5) of UK MiFIR reporting obligation arises would help clarify the role of trading venues in chains including non-UK investment firms.

5.159 Respondents called for guidelines including a range of scenarios on intermediated
activity that cover cross-jurisdictional chains, brokers in arranging and interposing capacities and chain participants acting in a range of trading capacities, on and off trading venues. Scenarios should also clarify circumstances where activity should be reported as 1 or 2 transactions especially when transmission of order might be taking place across the chain. Our proposal
5.160 We propose to provide clarity through additional examples on intermediated activity. We
will develop these scenarios with input from the industry. Scenarios will include reporting from all relevant participants in the chain. Question 52: Do you have any other feedback on the proposed changes in MAR 14?

Chapter 6
Obligations on trading venues
6.1 In this chapter, we cover changes we are proposing to:

Transaction reporting obligations that apply to trading venues under Article 26(5)
of UK MiFIR.
Instrument reference data reporting obligations under RTS 23.
Order book record keeping requirements under RTS 24.
Transaction reporting by trading venues
6.2 Under Article 26(5) of UK MiFIR, trading venues must report transactions executed
through their systems by firms that are not subject to UK transaction reporting requirements. This gives us oversight of all transactions on UK trading venues. Transaction reports submitted under Article 26(5) accounted for 6% of the total we received in 2024, identifying executing entities from 85 countries.
6.3 Trading venues have said this reporting obligation attaches a high burden, as they must
get and verify detailed information from their members while remaining responsible for data quality. We sought feedback in DP24/2 on specific fields or trading scenarios that are difficult to report accurately.
6.4 We also asked whether trading venues currently report negotiated transactions under
Article 26(5).
Feedback received
6.5 Respondents identified several fields they find particularly difficult to report accurately
under Article 26(5). These include:
Investment and execution decision makers (IDM/EDM) (RTS 22 fields 57 and 59).
Trading venue members are sometimes unwilling to provide sensitive PII required to meet reporting obligations for these fields.
Buyer/seller identification (RTS 22 fields 7 and 16). Similar sensitivities apply to
client identification and challenges around the INTC reporting convention for aggregated orders.
Trading capacity (RTS 22 Field 29). Members often confuse their role as an executing
entity with that of the client, giving venues incorrect information.
Short selling indicator (RTS 22 Field 62). Trading venues struggle to ensure accuracy
as they typically have no visibility over whether a trade is a short sale.
Country of branch fields (RTS 22 fields 8, 17, 37, 58 and 60). Identifying UK branches
remains complex, leading to challenges with the country of branch fields and potential under/over reporting of transactions.

6.6 Respondents raised concerns about the responsibility trading venues assume for errors
and omissions in data they do not control. Some called for clearer guidance on reporting requirements, particularly around fields that rely on client-supplied data. Others suggested removing or simplifying reporting fields to reduce compliance burdens, while maintaining effective regulatory oversight.
6.7 Most trading venues told us they report negotiated transactions under Article 26(5).
Half of respondents said they do not face any issues specific to them. However, some trading venues said there was ambiguity around whether the firms registering the trades are the only entities with transaction reporting obligations. Our proposal
6.8 Trading venues will still be required to submit transaction reports on behalf of clients,
members or participants of their venues under MAR 14.8. But we will propose changes to the content of these reports to ensure our rules remain proportionate.
6.9 10,663 unique natural persons were identified as an IDM or EDM in transaction reports
made under Article 26(5) in 2024. These individuals were employed by 1,710 firms.
6.10 Our work with trading venues suggests the requirement to collect this PII may be
discouraging firms from participating in UK markets, limiting liquidity. Data reported is also prone to frequent errors as trading venues do not have direct oversight of the PII.
6.11 While this information is useful to us, its value may not be proportionate to these costs.
So we propose disapplying the IDM/EDM fields from transaction reports submitted by trading venues where the IDM/EDM is a natural person. Where we require this information, we will obtain it directly from the executing entity. We will work with other public authorities where the entity is a non-UK firm.
6.12 Our validation rules currently allow for a blank value to be reported in the IDM field. We
will change our validation rules to allow for a blank value to be reported in the EDM field. We will maintain the existing requirement for algorithmic IDM/EDMs to be identified in transaction reports.
6.13 We considered going further and disapplying the requirement to report underlying client
details. However, we believe this would create an unacceptable loss of oversight. Over 20,000 natural persons and 18,000 legal entities access our markets through members of UK trading venues that are not subject to transaction reporting requirements. Question 53: Do you agree with our proposal to remove the requirement for trading venues to report the IDM/EDM in the transaction reports they submit?
6.14 We will also amend our rules to make it clear that negotiated transactions are in scope of
MAR 14.8 for the firm(s) that brings the negotiated transaction onto the exchange.

The operator of a qualifying trading venue must report to the FCA details of transactions in reportable financial instruments traded on its platform or which are executed through its systems by a firm that is not a transaction reporting firm. This includes negotiated transactions. Question 54: Do you agree with the updated text in MAR 14.8 to clarify that negotiated transactions are in scope?
Article 26(5) reporting for UK branches of third country firms
6.15 UK branches of third country firms must meet transaction reporting obligations when
they execute transactions in reportable financial instruments. Trading venues are not subject to transaction reporting obligations for these transactions. However, they are required to submit transaction reports for transactions executed on their venues by third country firms without involvement from a UK branch. It can be challenging for trading venues to make that determination.
6.16 We asked in DP24/2 whether there was support for expanding Article 26(5) reporting to
UK branches of third country firms.
Feedback received
6.17 A small majority of respondents supported the concept of trading venues reporting all
transactions executed on their venues by third country investment firms. They cited benefits such as improved data quality, clearer legal obligations and reduced burden.
6.18 However, some respondents argued that shifting branch reporting to trading venues
could reduce data quality due to a longer, more complicated flow of information. In particular, this was the view of investment firms, who would potentially need to transmit more information to multiple trading venues to meet reporting obligations.
6.19 Some respondents suggested trading venues should report all transactions executed
on their venues, noting duplication between existing RTS 22 reporting requirements and RTS 24 order record keeping requirements. Our proposal
6.20 We do not propose to require trading venues to report more transactions than they
are currently required to. We feel this could increase fragmentation of information flows necessary to fulfil reporting requirements, in turn leading to increased costs and reduced data quality. Trading venues would still need to determine whether a branch was involved in executing the transaction, to determine how to populate RTS 22 Field 5.
6.21 Under Article 26(7) of UK MiFIR, trading venues verified under the Data Reporting
Services Regulations 2024 can submit transaction reports for any transaction executed through its systems. We have seen limited take-up of this. We received feedback from

some respondents to suggest this may increase reporting efficiencies and streamline requirements. So we will conduct further work to understand the challenges which prevent trading venues from reporting transactions on behalf of investment firms that are subject to transaction reporting requirements (including UK branches of third country firms).
Article 26(5) reporting for natural persons executing directly
on a trading venue
6.22 The obligation for trading venues to report transactions executed through their systems
currently only applies where a firm executes those transactions.
6.23 Some trading venues have begun allowing natural persons to execute transactions
directly through their systems, with no involvement from an investment firm. This may be supported by distributed ledger technology (DLT). At present, our rules mean we do not necessarily have oversight of these transactions. Our supervision and effective oversight of financial markets rely on transaction reports being provided for all transactions executed on UK trading venues. Our proposal
6.24 We intend to explicitly include these transactions within the scope of transactions that
must be reported by trading venues.
6.25 Our existing validation rules do not allow for a national identifier or equivalent to be
populated in RTS 22 Field 4 (Executing entity identification code). While we could change these rules, it could lead to worse data quality.
6.26 Instead, we would expect trading venues to populate their own LEI in the executing
entity field. Our proposal for a revised RTS 22 Field 5 (Executing entity is a transaction reporting firm) would also be populated with a ‘FALSE’ value. Question 55: Do you foresee any difficulties with our suggested approach of reporting transactions where a natural person is the executing entity? FCA FIRDS
6.27 In DP24/2 we sought views from market participants on their use of FCA FIRDS.
Feedback received
6.28 Respondents told us that they use FCA FIRDS to:

Determine whether specific financial instruments are reportable.
Source and reconcile reference data needed to fulfil reporting obligations.
Enrich other regulatory reports, including those made under UK EMIR, the UK MiFIR
transparency regime and Short Selling Regulation.
6.29 Some firms also use our FIRDS Graphical User Interface (GUI) when investigating
exceptions and making ad hoc searches. Respondents said they access FCA FIRDS data through a variety of ways, including the GUI and file downloads.
6.30 Many respondents highlighted challenges accessing the full dataset. They suggested
we should aim to develop an easier way to access data in FCA FIRDS, enabling bulk and wildcard searches. This includes allowing access via an API.
6.31 Respondents proposed that FCA FIRDS should be treated as a ‘golden source’, allowing
firms to use it as the sole reference database when determining eligibility (as opposed to the current expectation that they should have alternative arrangements in place), noting several potential benefits:
Removing any doubt firms may have when using FCA FIRDS.
Providing firms with a single, easily accessible and free source to determine eligibility.
Small firms would particularly benefit, as implementing controls to determine
eligibility can be particularly onerous for these firms.
Our proposal
6.32 We will explore developing new functionality to improve the usefulness and accessibility
of FCA FIRDS. We will not need to make rule changes for these technical changes.
6.33 We propose to enable firms to treat FCA FIRDS as a ‘golden source’. This means
investment firms could exclusively use FCA FIRDS for determining whether a transaction is reportable. The only exception to this would be for transactions executed on a UK trading venue, where the instrument should automatically be considered in scope.
6.34 Once a transaction is executed, investment firms would have to determine whether
it is reportable using FCA FIRDS up to and including T+7 days following execution. If the transaction was not executed on a UK trading venue, and the instrument (or its underlying) is not in FCA FIRDS by T+7, firms would have no obligation to report.
6.35 We will not take action against firms where they reasonably determine an instrument is
in-scope despite not being available on FCA FIRDS and submit transaction reports which are subsequently rejected. This would be the case for pre-admission trading. Question 56: Do you agree with our proposal to treat FCA FIRDS as a ‘golden source’ for determining the reportability of financial instruments? Question 57: Do you agree with our proposal not to take action against firms where they would reasonably assume an instrument is in-scope despite not being available on FCA FIRDS?

Submitting instrument reference data
When firms should submit instrument reference data
6.36 In DP24/2 we asked trading venues whether they needed further guidance to clarify
when instrument reference data should be submitted.
6.37 We pointed out that how frequently we expect trading venues to report instrument
reference data differs between those operating a defined list and those who do not. Those operating a defined list must report instrument reference data every day the trading venue is open for trading. Those who do not, only report if there is an event that triggers a reporting obligation.
6.38 To streamline requirements, we suggested making instrument reference data
reportable only:

The first time an instrument is reportable.
When there is any subsequent change to underlying data.
Feedback received
6.39 Most respondents agreed there is sufficient clarity around when to submit instrument
reference data.
6.40 Most respondents supported a change to limit reporting instrument reference data to
the first time an instrument is reportable and for any subsequent changes. Respondents operating a defined list said this would simplify reporting flows.
6.41 One respondent suggested that implementing this proposal, if mandatory, would
represent a cost as they would need to amend their logic accordingly. Our proposal
6.42 We propose to only require trading venues to submit instrument reference data for the
following events:
The first time there is a reportable event.
Where there are subsequent changes to the instrument reference data reported
following the initial reportable event, including to correct any data quality issues.
6.43 Trading venues may choose to report instrument reference data more frequently,
should they wish to avoid system changes.
Question 58: Do you agree with the proposal to limit the obligation to report instrument reference data to the first time there is a reportable event and for any subsequent changes only?

6.44 Article 2 of UK RTS 23 currently states that daily files shall include ‘reference data for all
financial instruments that are admitted to trading or that are traded, including where orders or quotes are placed through their system, before 18.00 CET on that day’. We propose to maintain the current requirements but amend the stated time standard to UTC, bringing it in-line with a time standard more relevant to the UK.
6.45 We do not want to require firms to make technical changes to account for this. So we will
amend the time, aligning with the current timing requirement, but in UTC. Question 59: Do you agree with our proposal to amend the time standard used for the daily reference data file trading cut-off time from 18.00 CET to 17.00 UTC. Admission to trading
6.46 Under UK MiFIR, the concept of ‘admission to trading’ only applies to regulated markets.
Under UK MAR, the concept also applies to MTFs.
6.47 Some instrument reference data fields only apply to financial instruments for which the
concept of ‘admission to trading’ applies. This includes RTS 23 Field 10 (Date of request for admission to trading). This creates an information gap for financial instruments where a request for admission to trading is made on an MTF.
6.48 To close this gap and harmonise with UK MAR, in DP24/2 we suggested applying the
concept of ‘admission to trading’ to all types of trading venue.
6.49 While a request for admission being made will mean the relevant trading venue must
populate RTS 23 Field 10, the obligation to submit instrument reference data is only triggered once it is admitted to trading. We suggested changing this to require instrument reference data to be submitted from the date on which a request for admission is made.
6.50 We also asked if respondents needed further guidance on the meaning of ‘request for
admission’. We noted the range of days between the request for admission date and date of admission was consistently between 1 and 6 days, but that 77% of records had a difference of 1 day. This suggests some trading venues may be reporting a default value in RTS 23 Field 10. Feedback received
6.51 Several respondents had concerns that applying the concept of admission to all trading
venues would increase the regulatory burden on MTFs. Some underlined that the concept of admission to trading would never apply to certain asset classes. For example, derivative contracts which would be issued by the trading venue themselves, including when traded on a regulated market.

6.52 Most responses opposed the suggestion that instrument reference data should be
submitted from the date on which a request for admission is made. They argued that required information may not be held by trading venues at this point.
6.53 Respondents welcomed further clarity on the meaning of ‘request for admission to
trading’. They said this would help ensure a consistent approach to reporting instrument reference data across all trading venues. One respondent suggested this could be defined as the date requested on their admission form.
6.54 Responses highlighted different methods used for determining the request for
admission date. These include using the date when an issuer submits a request form, the relevant hearing date or the initial admission to trading date. Our proposal
6.55 We propose to extend the concept of ‘admission to trading’ to MTFs which undertake
primary market activities, such as initial public offerings, secondary public offerings, placings or debt issuance.
6.56 We believe this will ensure a more consistent and coherent approach across trading
venues, compared to the current differing standards. By providing a more complete view of pre-admission trading, widening the scope of ‘admission to trading’ will also help our ability to monitor market abuse in the earliest stages of an instrument’s lifecycle.
6.57 We also propose to remove derivative instruments from the concept of ‘admission to
trading’ where the trading venue is the issuer by specifying that in these cases:

RTS 23 Field 8 (Request for admission to trading by issuer) should be populated
as “false”.
RTS 23 Field 9 (Date of approval of the admission to trading) does not apply.
RTS 23 Field 10 (Date of request for admission to trading) does not apply.
6.58 We will allow firms to submit transaction reports for transactions executed in financial
instruments before they are admitted to trading without first determining the reportability of the instrument. This is because instrument reference data for these financial instruments will not appear on FCA FIRDS until the instrument is admitted to trading. Question 60: Do you agree with the proposal to expand the concept of admission to MTFs which undertake primary market activities, such as initial public offerings, secondary public offerings, placings, or debt issuance? Question 61: Do you agree with the proposal to remove derivative instruments from the scope of concept of admission to trading where a trading venue is the issuer?

Question 62: Do you agree with the proposed change to enable overreporting of transactions executed before the financial instrument is admitted to trading?
6.59 Considering the feedback, we propose to maintain the obligation to submit instrument
reference data when an instrument is admitted to trading, rather than when request for admission is made. Question 63: Do you agree with our proposal to maintain the current obligation to report instrument reference data when a request for admission is made?
6.60 We propose to clarify that UK RTS 23 fields 9 (Date of approval of the admission to
trading) and 10 (Date of request for admission to trading) only apply when there has been a formal request, either by an issuer directly, or a third-party acting on their behalf, to seek admission to trading for an instrument on a specific trading venue. Question 64: Do you agree with our proposal to clarify when we expect trading venues to populate RTS 23 fields 9 (Date of approval of the admission to trading) and 10 (Date of request for admission to trading)?
6.61 We also propose to clarify that we expect the ‘Date of request for admission to trading’
to be populated with the earliest date at which an issuer or third-party acting on their behalf formally initiates the process to seek the admission of an instrument on a specific trading venue.
6.62 We understand that different trading venues undertaking primary admission activities
may process such requests in different ways, and that adopting an overly stringent or restrictive definition may not be appropriate. As such, we believe our proposed principlebased definition will help clarify this. Question 65: Do you agree with our above proposal to clarify what is meant by ‘Date of request for admission to trading’? SI instrument reference data
6.63 DP24/2 noted we were considering removing the obligation for SIs to submit instrument
reference data. Our analysis showed that while 75% of all ISINs reported to FCA FIRDS in H1 2024 originated from SIs, these were highly concentrated in a small number of asset classes and accounted for just 2% of all transaction reports for the same period. We said this proposal could remove confusion around the submission of instrument reference data by market participants who are not considered trading venues.

Feedback received
6.64 Over 90% of respondents supported the proposal to remove the obligation for SIs to
report instrument reference data. They argued this would help simplify the use of FCA FIRDS. Some responses highlighted issues with the completeness and accuracy of SI instrument reference data, which further complicated use of this information.
6.65 Respondents noted that investment firms would need to populate RTS 22 fields 42-56 in
their transaction reports more frequently under the proposal. Many respondents told us firms should already have processes in place for identifying financial instrument where no ISIN is available for the instrument or present in FCA FIRDS. Our proposal
6.66 We propose to remove the obligation for SIs to submit reference data. We expect
instrument reference data already submitted by SIs would remain in FCA FIRDS to enable transactions to be back reported, without investment firms having to source additional reference data. Question 66: Do you agree with our proposal to remove the obligations for SIs to submit reference data? Instrument reference data fields
6.67 Our proposed rules for instrument reference data are in MAR 15. In line with the principles
outlined in Chapter 2, we have reviewed the reporting fields in RTS 23 to ensure we need all the information we currently collect. We propose to remove 11 fields we do not need:

Commodities or emission allowance derivative indicator (Field 4).
Financial instrument short name (Field 7).
Nominal value per unit/minimum traded value (Field 17).
Seniority of the bond (Field 23).
Option type (Field 30).
Option exercise style (Field 33).
Delivery type (Field 34).
Fixed rate of leg 1 (Field 43).
Fixed rate of leg 2 (Field 44).
Notional currency 2 (Field 47).
FX Type (Field 48).
6.68 We intend to use the CFI code of the financial instrument to derive some of the fields we
are removing and enrich relevant transaction reports.
6.69 These changes will help streamline the instrument reference data regime and reduce
the burden on trading venues. We expect the proposed changes to be forward-looking only. We will not be asking trading venues to update existing reference data for any of the fields we propose to remove.

6.70 Any submissions following implementation, including subsequent updates to existing
records, must conform to the new schema and validation rules. We will reject records that do conform to these. Question 67: Do you agree with the proposal to remove the above fields from RTS 23?
6.71 We also propose to clarify that instrument reference data should be updated when the
reported values change. This particularly affects the following fields in RTS 23:

Total issued nominal amount (Field 14).
Maturity date (Field 15).
Fixed rate (Field 18).
Identifier of the index/benchmark of a floating rate bond (Field 19).
Name of the index/benchmark of a floating rate bond (Field 20).
Term of the index/benchmark of a floating rate bond (Field 21).
Base point spread of the index/benchmark of a floating rate bond (Field 22).
Validation
6.72 We understand that INS-112 rejections where the issuer LEI is marked as invalid cause
difficulties for trading venues. In 2024, 57,533 records were rejected with this code, making it the second most common rejection reason (behind INS-104: duplicate records in a single file).
6.73 LEI requirements have proved difficult for venues to navigate where the issuer has not
and will not obtain an LEI. We set out our expectations for these scenarios in Market Watch 78, where we advised venues to use their own LEIs in these limited situations.
6.74 However, this could degrade the quality of data in submissions, by leading venues
to remove the LEI for an instrument’s actual issuer and replacing it with a less accurate data point.
6.75 Our analysis has found that the 57,533 INS-112 rejections listed 428 unique issuer LEIs.
Of those, 398 identifiers, representing 56,515 submissions, had ‘Retired’ status in Global Legal Entity Identifier Foundation (GLEIF), explaining why they were rejected.
6.76 We propose to include ‘Retired’ as a valid status for LEIs used in RTS 23 Field 5, alongside
‘Issued’, ‘Lapsed’, ‘Pending transfer’ and ‘Pending archival’. Had this been implemented in 2024, it would have avoided 98% of INS-112 rejections in that year.
6.77 We expect trading venues to continue monitoring data quality for this field. This includes
where GLEIF specifies that an entity whose LEI was retired has been replaced by a new one, at which point we expect this replacement LEI to be reported accordingly. Question 68: Do you agree with the proposal to add ‘Retired’ as a valid status for LEIs used in Field 5, alongside ‘Issued’, ‘Lapsed’, ‘Pending transfer’ and ‘Pending archival’?

6.78 Trading venues have raised the prevalence of INS-128 warning messages. These
highlight discrepancies between a submitted record and the relevant trading venue record for the same instrument.
6.79 We do not consider INS-128 warnings as a rejection or automatically view them as
a concern. We expect instrument reference data submitting entities to incorporate these warnings into their control and governance processes (for instance, ensuring that an increase in warnings is identified, investigated and understood). We outlined this expectation in Market Watch 78.
6.80 Some trading venues asked if we would consider ways to enable partial updates to
instrument reference data records. This would mean trading venues are able to update the values for an instrument by only sending details for the field(s) they want to amend, rather than a full new version of the record as is currently required.
6.81 We have investigated the feasibility of developing this. However, we conclude that the
CFI-based validation in place means this would not be possible without compromising the consistency and completeness of instrument reference data.
6.82 Under the current system, we validate the content of instrument reference data
submissions by ensuring the relevant fields are populated, based on the value provided in RTS 23 Field 3 (Instrument classification). This helps ensure that only those applicable underlying details are provided for an instrument.
6.83 We could not maintain this consistency if we allowed partial updates, given the CFI may
not be included in such an amendment, without referring to the previous version of the record. In such a scenario, non-applicable details risk being provided, or required information be missed. This would damage the consistency of instrument reference data published in FCA FIRDS. Question 69: Do you have any other feedback on the proposed changes in MAR 15? Order book data
6.84 Order book data collected under RTS 24 plays a key role in our fight against financial
crime. It underpins our ability to detect, investigate and prevent market abuse.
6.85 We use order book data daily to identity and investigate suspicious activity. For example,
in July 2025, the Upper Tribunal upheld our decision to ban Diego Urra, Jorge Lopez Gonzalez and Poojan Sheth from working in financial services. We found that the individuals had engaged in market manipulation based on their order activity in Italian Government Bond futures.
6.86 RTS 24 sets out the technical standards for trading venues to maintain records of
relevant data for orders in financial instruments. Under Article 25 of UK MiFIR, trading venues must keep detailed order book data to support market surveillance and regulatory oversight. We propose to add these rules to MAR 13.

6.87 We propose to align requirements for the investment decision with firm and execution
within firm fields with the corresponding order book data fields. Trading venues will not be required to populate these fields for orders submitted by firms which are not transaction reporting firms, where the investment and execution decision maker(s) are natural persons. Question 70: Do you agree with our proposal to remove the requirement for trading venues to identify natural person investment and execution decision makers for orders submitted by firms that are not transaction reporting firms?
6.88 We also propose to amend the standards in the Order restriction field, where the
current definitions of the acronyms SESR and VFCR do not align with their actual meaning. ‘SESR’ stands for ‘Session Restriction’ and should have the definition ‘Valid for Continuous Trading only’. ‘VFCR’ stands for ‘Valid For Closing Restriction’ and should have the definition “Good for Closing Price Crossing Session”. We will not update the acronyms to align with these definitions as this may require firms to make changes to reporting systems. Question 71: Do you agree with our proposal to amend the definitions for the acronyms of SESR and VFCR?
6.89 In DP24/2 we said we intended to consult on potential changes to RTS 24. We plan
to undertake a full consultation in due course. This will form part of our broader work to streamline and improve the order book data regime. Our focus will remain on improving data quality, reducing reporting burdens and ensuring the framework remains proportionate and fit for purpose in UK markets. Question 72: Do you have any other feedback on the proposed changes in MAR 13?

Annex 1
Questions in this paper
Question 1: Do you agree with the proposal to streamline and harmonise existing transaction and post-trade reporting regimes? 12 Question 2: Do you agree with the 3 principles for the longterm collection of transaction and post-trade data? 12 Question 3: Would you support an 18-month implementation period for the changes proposed in this Consultation Paper? 12 Question 4: Do you agree with the proposal to apply a reduced default back reporting period of 3 years, whilst keeping the choice to require back reporting up to 5 years where needed? 18 Question 5: Do you agree with our proposed changes to the exclusions from reporting in MAR 14.2.4R? 20 Question 6: Do you agree with the proposed guidance on exclusions from reporting in MAR 14.3.1G? 20 Question 7: Do you agree with the proposed information a firm should provide to meet the conditions for single-sided reporting? 26 Question 8: Do you agree with the proposed responsibility for data quality for transactions involving conditional single-sided reporting? 28 Question 9: Do you envisage any issues in conditional singlesided reporting applying to transactions executed in a DEAL or MTCH trading capacity? 28 Question 10: Do you agree with our proposal to remove instruments from the scope of the UK transaction reporting regime that can only be traded on EU trading venues? 30 Question 11: Do you agree with our proposal to remove reference to ‘Union’ in MAR 14 Annex 2 and retain the current approach to national identifiers? 30

Question 12: Do you agree with the proposed guidance to clarify in our rules an equivalent regulatory concept to ESMA’s TOTV opinion? 31 Question 13: Do you see any issues having to report transactions executed in instruments which are not derivatives but are brought into scope by the underlying? 31 Question 14: Do you agree with our proposal to allow firms to report derivatives based on indices on a voluntary basis, irrespective of whether the derivative is in scope of the transaction reporting regime? 32 Question 15: Do you agree with the proposed changes to allow all ISINs in a basket to be included in the underlying instrument field? 33 Question 16: Do you agree with the proposal to provide clarity on the scope of reporting obligations for fractional instruments? 34 Question 17: Do you agree with our proposal to remove FX derivatives from the scope of the UK transaction reporting regime? 36 Question 18: For UK branches of third country firms: how could we address the data gap created for FX derivatives? 36 Question 19: Do you agree with our proposed approach for identifying OTC derivatives? 40 Question 20: Do you agree with the updated definition for ‘acquisition’ and ‘disposal’? 41 Question 21: Do you agree with the proposed guidance to the meaning of ‘execution of a transaction’ in MAR 14.4.2G-14.4.6G? 41 Question 22: Do you agree with our proposed new rules and guidance for branch execution? 42 Question 23: Do you agree with our proposal to maintain the status quo for reporting TVTICs? 46 Question 24: Do you agree with our proposal to limit reporting of the TVTIC to transactions executed on UK trading venues only? 46 Question 25: Do you agree with the proposed definition of a transaction reporting firm? 47

Question 26: Do you agree with our proposal to require branches to be identified with the LEI of its head office or registered office? 47 Question 27: Do you agree with the proposed changes to RTS 22 Field 5? 48 Question 28: Do you agree that investment firms should be allowed to report either a trust LEI or national identifier of the beneficiary when executing a transaction for a trust? 49 Question 29: Do you agree with our proposal to require firms to obtain national identifiers for natural persons before a service is provided for that client which triggers the obligation to submit a transaction report? 49 Question 30: Do you agree with this proposal to report the segment MIC in these scenarios? 50 Question 31: Do you agree with our proposed rules for generating CONCATs in MAR 14.13.6R-14.13.7R? 50 Question 32: Do you agree with the proposal to require natural persons from the Isle of Man, Gibraltar, Channel Islands and other BOTs to be identified in accordance with the requirements of ‘all other countries’? 51 Question 33: Do you agree with the proposed rule in MAR 14.13.5R(6) where a person is a national of more than 1 non-EEA country? 51 Question 34: Do you agree with the proposal to remove RTS 22 Field 25 (transmission of order indicator)? 52 Question 35: Do you agree with the proposed guidance for reporting the trading capacity? 52 Question 36: Do you agree with our proposal to require the price of the underlying instrument to be reported in the price field for equity swaps with a single underlying? 55 Question 37: Do you agree with our proposal to require the price of the underlying instrument to be reported in the price field for equity swaps with more than one underlying where available, and the spread of the financing rate in other cases? 56

Question 38: Do you agree with our proposal to remove the concept of SwpIn (+) and SwpOut (-) tags? 57 Question 39: Do you agree with our proposal to remove RTS 22 Field 32 (Derivative notional increase/decrease)? 57 Question 40: Do you agree with the proposed changes to RTS 22 Field 36 (Venue)? 57 Question 41: Do you agree with the proposal to remove RTS 22 fields 50 (Option type), 53 (Option exercise style) and 56 (Delivery type)? 58 Question 42: Do you agree with the proposal to remove RTS 22 Field 54 (Maturity date)? 58 Question 43: Do you agree with the proposal to remove RTS 22 Field 45 (Notional currency 2)? 59 Question 44: Do you agree with our proposal to make ‘NOAP’ a reportable value in the strike price field? 59 Question 45: Do you agree with the proposal to remove RTS 22 fields 61-65? 60 Question 46: Do you agree with the proposal to remove RTS 22 fields 37, 58 and 60? 60 Question 47: Do you agree with the proposal to remove RTS 22 fields 8 and 17 (Country of the branch for the buyer/seller) and replace them with a new client indicator field? 62 Question 48: Do you agree with the proposal to add a new reporting value to RTS 22 Field 59 (Execution within firm) to identify where a firm is providing DEA? 63 Question 49: Do you agree with the proposed definition of a package transaction? 65 Question 50: Do you agree with the proposal to capture the single leg prices of a package transaction? Are there any changes we should make to the proposed fields? 65 Question 51: Do you agree with the proposal to maintain existing requirements for the aggregate client linking code? 67 Question 52: Do you have any other feedback on the proposed changes in MAR 14? 69

Question 53: Do you agree with our proposal to remove the requirement for trading venues to report the IDM/ EDM in the transaction reports they submit? 71 Question 54: Do you agree with the updated text in MAR 14.8 to clarify that negotiated transactions are in scope? 72 Question 55: Do you foresee any difficulties with our suggested approach of reporting transactions where a natural person is the executing entity? 73 Question 56: Do you agree with our proposal to treat FCA FIRDS as a ‘golden source’ for determining the reportability of financial instruments? 74 Question 57: Do you agree with our proposal not to take action against firms where they would reasonably assume an instrument is in-scope despite not being available on FCA FIRDS? 74 Question 58: Do you agree with the proposal to limit the obligation to report instrument reference data to the first time there is a reportable event and for any subsequent changes only? 75 Question 59: Do you agree with our proposal to amend the time standard used for the daily reference data file trading cut-off time from 18.00 CET to 17.00 UTC. 76 Question 60: Do you agree with the proposal to expand the concept of admission to MTFs which undertake primary market activities, such as initial public offerings, secondary public offerings, placings, or debt issuance? 77 Question 61: Do you agree with the proposal to remove derivative instruments from the scope of concept of admission to trading where a trading venue is the issuer? 77 Question 62: Do you agree with the proposed change to enable overreporting of transactions executed before the financial instrument is admitted to trading? 78 Question 63: Do you agree with our proposal to maintain the current obligation to report instrument reference data when a request for admission is made? 78

Question 64: Do you agree with our proposal to clarify when we expect trading venues to populate RTS 23 fields 9 (Date of approval of the admission to trading) and 10 (Date of request for admission to trading)? 78 Question 65: Do you agree with our above proposal to clarify what is meant by ‘Date of request for admission to trading’? 78 Question 66: Do you agree with our proposal to remove the obligations for SIs to submit reference data? 79 Question 67: Do you agree with the proposal to remove the above fields from RTS 23? 80 Question 68: Do you agree with the proposal to add ‘Retired’ as a valid status for LEIs used in Field 5, alongside ‘Issued’, ‘Lapsed’, ‘Pending transfer’ and ‘Pending archival’? 80 Question 69: Do you have any other feedback on the proposed changes in MAR 15? 81 Question 70: Do you agree with our proposal to remove the requirement for trading venues to identify natural person investment and execution decision makers for orders submitted by firms that are not transaction reporting firms? 82 Question 71: Do you agree with our proposal to amend the definitions for the acronyms of SESR and VFCR? 82 Question 72: Do you have any other feedback on the proposed changes in MAR 13? 82

Annex 2
Cost benefit analysis
Executive summary

The FCA receives over 7 billion transaction reports a year, covering transactions
executed by UK firms or on UK markets in over 20 million reportable financial instruments. We use this data to detect, investigate and prevent market abuse, combat financial crime and monitor the health, functioning and cleanliness of UK markets. This is in support of our operational objective to protect and enhance the integrity of the UK financial system.
While transaction reporting data is of significant benefit to the FCA, the
regime attaches a material cost on firms. We have estimated that firms spend approximately £493 million every year meeting transaction reporting requirements. We published DP 24/2 in November 2024, in which we noted that the market and our data needs have evolved since the transaction reporting regime was implemented in 2018, and that we believe there are opportunities to reduce reporting costs while maintaining the value of the data.
By streamlining the scope of the transaction reporting regime, clarifying
complex rules, and removing duplicative requirements where possible, we expect the current regulatory burden to reduce. The cost savings from these measures are expected to account for around one-quarter of the current annual costs of reporting. We also expect these changes to lead to an improvement in the completeness, accuracy and timeliness of transaction reports, which will benefit the FCA in terms of increased operational efficiency as a result of managing fewer erroneous submissions.
Stronger data quality does not just fulfil compliance requirements and lead to
greater operational efficiencies. It indirectly benefits the FCA through more effective market surveillance, supervision and policymaking, and benefits market participants through lower compliance risk, greater investor confidence and potentially more efficient and liquid markets. This in turn improves the UK’s attractiveness as a financial centre, supporting economic growth. These benefits are not captured in direct cost-benefit estimates but contribute materially to the overall positive impact of these proposals.
To gather data on the expected impact of our proposals on firms, we issued
voluntary surveys to a representative sample of 115 investment firms, trading venues and ARMs, receiving 55 responses. These contained quantitative estimates of the costs associated with implementing our proposals, as well as expected cost savings from reducing the regulatory burden. We have supplemented this data with estimates from our Standardised Cost Model (SCM).
Under our baseline, we assume that all current requirements of the transaction
reporting regime remain the same over the appraisal period. We also assume that the EU transaction reporting regime will evolve in future, following similar principles to those outlined in this Consultation Paper. As any further divergence would likely lead to a higher burden for firms in complying with transaction reporting regimes in the UK and other jurisdictions, this could have a significant bearing on the baseline from which we are assessing cost savings against.
The estimated present value (PV) cost of our proposals over a 10-year
appraisal period is approximately £197.3m. The vast majority of these costs are expected to be one-off costs incurred by investment firms implementing our proposed changes. We expect firms to incur additional costs from undertaking familiarisation and gap analysis, while we will incur implementation costs from updating systems to ingest transaction reports based on the new requirements. When considered in their entirety, our changes add up to an estimated material implementation cost of £148.8m.
The new costs resulting from our rules will be significantly outweighed by
expected ongoing cost savings to business of £115.3m per year. The most substantial cost savings will arise from our proposals to exempt FX derivatives and instruments only tradeable on EU venues from the scope of the regime. In total, we have quantified direct benefits to firms in scope of the proposed rule changes amounting to £942.8m over the 10-year appraisal period in PV terms, which represent a reduction in the direct cost of compliance compared to the counterfactual where reforms are not introduced.
In addition to the monetised benefits summarised above, we expect to directly
benefit from cost savings and efficiency gains resulting from the expected improvement in the accuracy and completeness of reports. While these savings are expected to be material, they are challenging to quantify accurately and have therefore not been included in our monetised assessment.
We expect the proposals to deliver a net benefit, with the net present value
(NPV) of benefits exceeding the NPV of costs by approximately £745.5m over the 10-year period. Therefore, we deem that our proposals are proportionate.
Following implementation of the proposed changes, we will monitor data quality
and the usefulness of reported data using existing analytical metrics (such as report acceptance rate and error alert ratios) and statistics on outcomes where the revised reports have been used. We will consider the intervention to be successful if we observe clear evidence that our changes are driving stronger outcomes across our market monitoring and surveillance capabilities.

Introduction
12. The Financial Services and Markets Act (2000) requires us to publish a cost
benefit analysis (CBA) of our proposed rules. Specifically, section 138I requires us to publish a CBA of proposed rules, defined as ‘an analysis of the costs, together with an analysis of the benefits that will arise if the proposed rules are made’.
13. This analysis presents estimates of the significant impacts of our proposal.
We provide monetary values for the impacts where we believe it is reasonably practicable to do so. For others, we provide a qualitative explanation of their impacts.
14. The CBA has the following structure:

The Market
Problem and rationale for intervention
Options assessment
Our proposed intervention
Baseline and key assumptions
Summary of impacts
Benefits
Costs
Wider economic impacts
Monitoring and evaluation
The Market

The obligation to report transactions predominantly sits with approximately
1,350 UK MiFID investment firms. These consist of asset managers, CFD providers, principal trading firms, wealth managers, wholesale banks and wholesale brokers amongst others. It also includes UK branches of third country investment firms.
While investment firms can submit their own transaction reports directly to the
FCA’s MDP, the vast majority choose to submit through an ARM due to the high fixed costs associated with setting up and maintaining a full reporting system.
ARMs are regulated entities which facilitate the submission of transaction
reporting data on behalf of investment firms. Although investment firms have ultimate responsibility for the completeness and accuracy of a transaction report, ARMs receive and process firms’ data and are required to identify obvious errors and omissions before reporting details of transactions to the FCA on behalf of the firm. ARMs also have an obligation to rectify errors which they introduce into a transaction report. There are 4 ARMs, 2 of which are responsible for approximately 97% of transaction reports submitted by ARMs.
ARMs primarily earn revenue through a combination of subscriptions and
transaction volumes (per-transaction fees) or tiered pricing. Because of high fixed technology and compliance costs, they benefit from economies of scale which in turn results in a relatively concentrated market amongst large providers.
In addition to investment firms and ARMs, trading venues are required to submit
transaction reports on behalf of approximately 3,000 entities who are not authorised as UK MiFID investment firms. Trading venues can also report on behalf of UK MiFID investment firms or third-country branches of investment firms that execute transaction through their systems, where an agreement is in place to do so. Trading venues may report transactions directly to us or via an ARM. We currently receive transaction reports from 40 trading venues.
Trading venues have full responsibility for the completeness and accuracy of the
transaction reports they submit, and as with ARMs, have an obligation to rectify errors which they introduce into a transaction report where the investment firm uses the trading venue to submit on their behalf.
Figure 1: Proportion of transaction reports received by type of
submitting entity
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
2021 2022 2023 2024 2025
ARM Investment Firm Trading Venue
Transaction reports are a crucial element in our strategy to detect, investigate
and prevent market manipulation, supporting investor confidence and encouraging greater liquidity and reduced price volatility. Additionally, transaction reports are vital for us and the Bank of England to monitor market functioning and integrity, especially in times of crisis.
While transaction reporting brings significant benefits, we have estimated that
firms spend around £493 million every year meeting existing requirements. Firms incur high costs by either by maintaining their own data infrastructure and reporting systems, or through fees paid to intermediaries who report on their behalf. These costs are often passed through to the same market participants that benefit from the resilience and orderliness of financial markets that the transaction reporting regime underpins, for example in the form of clients of investment firms facing higher transaction fees.
We therefore consider that reducing the cost of transaction reporting without
compromising the effectiveness of our market oversight will generate an improvement in economic efficiency. Problem and rationale for intervention Challenges under the current regime
Through our monitoring and supervision of the transaction reporting regime,
alongside responses to DP 24/2, we have identified inefficiencies whereby the burden on firms associated with certain existing reporting rules outweighs the regulatory value of the data.
We have established three key areas where the current reporting rules present
challenges to firms.
Technical reporting challenges
Evidence indicates that there are persistent problems with the quality of
submitted transaction reports. In 2024, over 22 million transaction reports were rejected by MDP. The most common reason for rejections is an inconsistency between the transaction report and the relevant instrument reference data (ie firms reporting transactions for financial instruments on a day where trading venues have not reported the instrument as valid for that day in FCA FIRDS).
In 2024, approximately half of UK investment firms required to report
transactions proactively disclosed errors in their reporting.
Figure 2 shows the proportion of transaction reports that have been submitted
with a ‘CANC’ (cancelled) value in RTS 22 Field 5 (Status) over the previous five years. Transaction reports must be cancelled when they are submitted to us in error or with inaccurate or incomplete information. The cancelled transaction report must be replaced with a corrected transaction report where there are errors or omissions in the data.

Figure 2: Proportion of cancelled transaction reports by submission date
0%
2%
4%
6%
8%
10%
12%
14%
16%
2021 2022 2023 2024 2025*

Data runs until 6 November 2025.

Firms have provided feedback on some of the key technical challenges which
mean that errors in their reporting are more likely to occur:

FX derivatives. The guidelines for reporting FX derivatives require some
firms to develop reporting logic which does not align with booking practice. FX derivatives account for 8% of errors and omissions reported to the FCA, despite making up just 3.8% of transaction reports in 2024. This asset class may be linked to particularly costly back reporting exercises.
Corporate actions. Due to their bespoke nature, each corporate event
needs to be reviewed individually to determine whether it is reportable. This can lead to either underreporting, overreporting or late reporting.
OTC derivatives. Firms find it costly and complex to conduct eligibility
checks for OTC derivatives, as they must assess whether the OTC derivative shares the same reference data details as a TOTV derivative in order to determine reportability.

Firms also highlighted complexities and costs associated with the current
requirement to back report transactions reports impacted by errors and omissions over a retrospective period of 5 years. Duplicative requirements
In addition to these challenges, some requirements in the transaction reporting
regime have been highlighted as overlapping or misaligned with other market reporting regimes, such as UK EMIR and SFTR. This means that some firms are in some cases required to report the same information multiple times.
We should note that we are limited in the actions we are able to take to address
this issue, given that we do not have the powers to unilaterally change UK EMIR or SFTR. As set out in Chapter 2, we are currently outlining a joint vision with HM Treasury and the Bank of England on a long-term, strategic approach to streamlining transaction reporting requirements across multiple regimes, including EMIR and SFTR.
Due to the long-term nature of these plans, we have not accounted for any
changes to EMIR or SFTR within our appraisal period. As it currently stands, 46% of MiFID firms are not subject to requirements under EMIR, and 90% of reporting firms under EMIR are not subject to requirements under MiFIR.
There is nonetheless an opportunity to align field names, definitions, guidance
and validation rules across EMIR and MiFIR. Examples of this include reporting the definition of a ‘complex’ or ‘package’ trade and a consistent approach for reporting quantity and price notations.
Responding to DP24/2, firms also highlighted further areas of the transaction
reports which require duplicative field content; for example, they are currently required to report information which can also be determined from the classification of financial instrument (CFI) code. They also noted that firms provide data to fulfil trading venues’ order record keeping requirements, while also having to report some of the same information to us in their transaction reports. Where feasible, we have attempted to eliminate this duplication through our proposals. High burden of reporting compared to other international jurisdictions
Responding to DP24/2, firms highlighted certain areas where the UK’s
transaction reporting system is more burdensome than equivalents in other jurisdictions. For example, some respondents noted that buy-side reporting is particularly demanding, citing international jurisdictions which do not require buy-side reports.
In addition, UK firms are required to submit transaction reports for financial
instruments tradeable on UK and EU trading venues. Trade associations have highlighted the additional cost this presents compared to EU rules, which only requires EU firms to report transactions in instruments tradeable on EU trading venues.
Respondents to DP24/2 also highlighted specific requirements contributing
to perceived anti-competitiveness of UK markets, such as rules which require international firms to provide personal data relating to their traders and clients when dealing on UK trading venues. International firms are required to provide equivalent data to EU trading venues, but not to trading platforms in jurisdictions such as the US.
In the section below, we outline how these challenges have resulted in harms
in the market.

Harms
Aspects of the regime place a large resource and cost burden on firms
40. Given the difficulty for firms to meet our data quality requirements and the
challenges highlighted by firms around data reporting, we consider that the current regime places a disproportionate burden on firms. This has a negative impact on firms’ and regulators’ efficiency and undermines the competitiveness and growth of UK markets.
41. The unnecessary complexity of the transaction reporting regime, alongside
duplicative requirements, increases the cost base for firms subject to it. This creates inefficiencies within firms, requiring time and resources which could be spent more productively on other matters. It can also lead to higher prices for clients as firms pass on relevant costs.
42. Reporting errors place additional burden on firms as incorrect data requires
costly back-reporting efforts. The cost of investigating and correcting accumulated errors can far exceed the initial cost of establishing proper controls. In addition, repeated errors can lead to more intensive monitoring and oversight by the FCA. Both firms and senior managers can face potential penalties resulting from inaccurate reports.
43. Increasing the cost base for firms subject to the transaction reporting
requirements has the potential to make UK business less competitive relative to other jurisdictions. This is underscored by feedback from firms, which highlighted that certain aspects of the UK regime are more onerous to comply with relative to overseas jurisdictions. Aspects of the regime place a large cost and resource burden on the FCA
44. In addition to the increased operational costs that firms face, the FCA also
requires additional time and resource which is needed to identify and address inconsistencies, reviewing erroneous data and demanding corrections.
45. We receive, review and follow up on approximately 140 queries per year from
internal data users, related to either the interpretation of transaction reports or potential data quality issues. Approximately 20% of these relate to areas where we are proposing policy changes in order to clarify or remove existing requirements.
46. We also respond to approximately 60 guidance queries per year from
investment firms, trading venues and advisers. We have identified specific aspects of the regime where we receive a disproportionate number of guidance requests, indicating that current rules can be improved.

Our ability to effectively monitor UK markets and reduce harm is hampered by persistent data quality issues
47. We rely on strong data quality to monitor and address risks in UK markets. If we
cannot effectively identify these risks and take timely action, we may not be able to meet our statutory objective to protect and enhance the integrity of the UK financial system. We provide detailed examples of our use of accurate data below.

We relied on transaction reporting data in our multi-firm review of share
buybacks in UK listed equities. We analysed transactions data on share buybacks executed by 7 banks over an 18-month period, representing 165 share buybacks collectively worth £40bn. We also carried out transactionspecific analysis on individual outcomes using UK MiFID transaction reporting data. This analysis found no material concerns about the outcomes banks delivered when restructuring but enabled us to provide firm-specific feedback and consider possible refinements to our rules.
The integrity of UK markets is supported by timely and accurate notification
and disclosure of major shareholding positions, directors’ dealing and net short positions. We monitor compliance across these regimes, relying on accurate and timely transaction reporting data to support our use of alerts. One example is the FCA’s enquiries into the trading of Mr. Neil Murphy, former CEO of Bytes Technology Group plc. Using alerts based on transaction reporting data, the FCA identified breaches of directors’ dealings rules. When approached, Mr. Murphy resigned from his role.
Furthermore, we rely on transaction reporting to research and monitor the
effect of major socio-economic events – such as Brexit, the coronavirus pandemic and substantial inflation – on UK markets. For example, our recent analysis on liquidity in the UK corporate bond market involved extensive use of transaction reporting data.

Completion of the above workstreams above was dependent on strong data
quality. Analysis and insights may not have been sufficiently clear had relevant underlying transaction reports been inaccurate, incomplete or missing entirely. Options assessment
By amending the current transaction reporting regime, we aim to address
the harms set out in the sections above. We will do this by improving the completeness and accuracy of transaction reports and removing or adapting disproportionate requirements.
In considering how best to achieve these aims, we assessed various policy options.
In this section, we describe key options and summarise our review of them.
There are additional changes to the reporting fields and the transaction
reporting schema which are not covered in our options assessment below. These are related to the removal of specific fields to reduce costs and addition of several fields to improve usability. A number of these additional proposals

represent small changes and are expected to have a marginal impact on firms. We outline these changes in the ‘Our proposed intervention’ section.
Table 1: Options assessment for changes to the shape of the regime
Option Assessment
Back reporting
Maintain existing back reporting obligation
This approach would maintain the high costs incurred to resubmit reports impacted by errors over a retrospective period of 5 years, which we do not consider proportionate relative to our use of historic data. Introduce a new ‘amend’ function to enable more efficient back reporting While pursuing this option could result in a reduction in the cost of resubmitting transaction reports, it would impact our ability to apply data validation, thereby creating complex operational challenges. Reducing the period for which back reporting is required from 5 to 3 years This would lead to a cost saving for firms whilst ensuring our access to accurate transaction reports throughout the most valuable time period, in order to support our market abuse enquiries and inform long-term views on market patterns and trends. This is our preferred option. Buy-side reporting Maintain reporting obligation on buy-side firms This approach would fail to avoid the harms we have identified related to disproportionate cost burden on buy-side participants due to the potentially duplicative nature of existing requirements. Completely remove reporting requirements on buy-side firms While pursuing this option would result in significant cost-savings, it would materially reduce oversight of markets and firm exposure, increasing data gaps. Retain buy-side reporting but create a conditional single-sided reporting framework allowing buy-side firms in particular to save on reporting costs Creating such a framework would facilitate dealers reporting on behalf of buy-side firms. A comparable model is already common under EMIR. This option would reduce reporting costs for buy-side firms whilst allowing us to retain oversight of UK markets. This is our preferred option. Instruments traded on EU venues only Retain instruments only tradeable on EU venues within the scope of the transaction reporting regime This option would not create any cost savings for firms. In addition, our need to ingest EU FIRDS data and continuously monitor for any changes ESMA makes means that this option is challenging and time consuming.

Option Assessment
Descope instruments only tradable on EU trading venues from the transaction reporting regime This would likely create a cost saving for reporting firms as it would lead to an approximate 8% reduction in the number of reportable transactions, equivalent to roughly 590m transactions in 2024. This is our preferred option. FX derivatives Maintain FX derivatives within the scope of the transaction reporting regime This approach would not allow us to address significant compliance costs and challenges aligning reporting fields with market practice. A potential benefit of maintaining the current regime is our oversight of trades by UK branches of third-country firms, which do not have a reporting obligation under EMIR. Descope FX derivatives from MiFID and leverage UK EMIR This would create significant cost savings for reporting firms by simplifying their processes and forego the need to submit transaction reports in FX derivatives. Our assessment shows that most elements necessary for market abuse and market monitoring are covered under EMIR. This is our preferred option. Trading venue obligations Retain current obligation placed upon trading venues to report on-venue transactions executed by firms that are not subject to UK transaction reporting requirements By retaining current obligations on trading venues, we are not able to address issues around international competitiveness of UK markets. This is because third country firms do not need to provide personal data in other jurisdictions (excluding the EU), rendering UK markets comparatively less attractive for entry. Significantly reduce the granularity of transaction reporting by trading venues by removing the requirement to supply underlying client details as well as investment and execution decision maker (“IDM/EDM”) data This level of data loss – particularly regarding underlying client details – will impact on our ability to detect and investigate market abuse and is therefore not acceptable. Partially reduce the granularity of transaction reporting by trading venues through only the removal of the information contained across the IDM/EDM fields This is our preferred option as it strikes the balance between reducing burden on trading venues and providing us with visibility of data necessary to investigate potential market abuse.
52. In designing our preferred approach, we considered that there were potential
trade-offs between retaining the current amount and granularity of reported data to aid our market monitoring on one hand and reducing the regulatory burden on firms on the other. We have sought to strike a balance that meets both objectives.

By striking this balance, we expect that some harms will persist in this market.
We believe that accepting some harms will continue is necessary to ensuring our regulation is proportionate, enabling us to reduce the burden, increase efficiency and improve the competitiveness and attractiveness of UK markets. We have provided a more detailed assessment of the impact that data loss will pose in the ‘Costs’ section. Our proposed intervention
To address the harms we have identified, we have assessed the proportionality
of every aspect of the transaction reporting regime, ensuring that regulatory costs are aligned with the wider expected regulatory benefits. We seek to deliver an intervention which delivers greater operational efficiency and cost savings to firms whilst ensuring that we have access to key data which allows us to fulfil our operational objectives.
We have structured the proposed rule changes into three core areas: the shape
of the regime, the scope of the regime and the content of transaction reports.
Below we outline the key regime changes within the three core areas that are
expected to give rise to costs, cost savings, or both. There are a number of proposed changes to the regime which we expect to have little or no impact on firms; for example, we are proposing to mandate the reporting of fractional shares, but we have observed firms already reporting these in practise. For a full list of proposals, see Chapters 3, 4 and 5 of the CP.
Shape of the regime (detailed proposals set out in Chapter 3 of the CP):

Exempt the reporting of corporate actions, apart from those related to IPOs
and secondary capital rising.
Reduce the default back reporting period from 5 to 3 years.

Scope of the regime (detailed proposals set out in Chapter 4 of the CP):

Introduce a conditional single-sided reporting mechanism.
Remove foreign exchange (FX) derivatives from the scope of
reporting requirements.
Remove reporting obligations for over 6 million financial instruments
only tradeable on EU trading venues.
Remove reporting obligations for instrument reference data from
systematic internalisers.
Trading venues will report fewer fields under Article 26(5) of UK MiFIR,
impacting over 3,000 international firms which execute transactions directly on UK trading venues.

Content of transaction reports (detailed proposals set out in Chapter 5 of the CP):

Reduce the overall number of transaction reporting fields from 65 to 52.
Reduce the overall number of instrument reference data fields from 48 to 37.

We are also providing additional clarity regarding specific reporting requirements
to improve reporting efficiencies, cut costs and support better data quality. Baseline and key assumptions Baseline
In our CBA, we assess the costs and benefits of our proposals against a
baseline. In this baseline, we assume that all current requirements of the transaction reporting remain the same over the appraisal period.
If no policy changes are implemented, firms would continue to face a significant
compliance burden, data quality issues would persist, and duplication across reporting channels would not be addressed.
We have considered the potentially positive contribution of technology,
improved data analytics and organisational processes on firms’ reporting mechanisms and practices. However, as most of the harms identified stem directly from the challenges firms face in complying with the current rules, we assume that the data quality issues set out in the ‘Challenges under the current regime’ section will persist without intervention.
Under our baseline, we assume that the EU will proceed with implementing
a similarly streamlined transactions reporting regime. As there is benefit for industry in alignment between different transaction reporting regimes, any further divergence would likely lead to a higher burden for firms in complying with these regimes in the UK and other jurisdictions. This could have a significant bearing on the baseline from which we are assessing cost savings against. However, as there is uncertainty as to the outcome of ESMA’s review, we believe the most appropriate approach is to assume that the UK and EU regimes will remain broadly aligned. Key assumptions
The key assumptions underpinning the analysis of costs and benefits are
described in this section. We make further assumptions informed by evidence to quantify impacts, which we discuss in detail in the ‘Costs’ and ‘Benefits’ sections of our assessment.
We assume full compliance with our new rules. In cases where we propose giving
firms the option to report fields or instruments which are currently mandatory, we assume that all firms will choose to no longer report these. Although there may be some costs involved in implementing requisite system changes,

we consider this to be a valid assumption because of the burden of reporting transactions on an ongoing basis, and because there is no direct benefit to individual firms for doing so.
67. The benefits case relies on us being able to proactively and productively use the
data we receive to better manage risks and prevent them from arising in the first place. We will continue to maintain, monitor and regularly analyse transaction reporting data.
68. We assume that in instances where we are removing requirements or
exempting certain instruments from reporting requirements, firms will incur a one-off cost to familiarise and align themselves with the new rules but will incur no further ongoing costs. Where we are adding requirements or placing new obligations on firms, we assume both one-off and ongoing costs, which are reflected in the ‘Costs’ section.
69. We surveyed a range of firms who would be impacted by our proposals. When
analysing the survey responses, we made the following assumptions:

As we did not request responses from the entire population of firms
impacted by our proposals, an element of uncertainty in our estimates exists. Our methodology largely mitigates this uncertainty as it adjusts for response bias.
Qualitative responses received to our surveys indicate that some firms
found it difficult to provide accurate estimates. For example, some firms found it difficult to segregate costs associated with reporting particular instruments. Others found it challenging to segregate costs borne by UK MiFIR to those borne under EU MiFIR. After excluding clearly erroneous responses, we assumed that the costs and cost savings are an accurate reflection of the actions that firms will be taking to implement our proposals.
Further assumptions regarding our survey methodology are explained in the
Technical Appendix.

We have used responses to our firm surveys to guide our cost and benefit
estimations. Alongside this, we have drawn upon size classifications and ‘core’ assumptions from our Standardised Cost Model (SCM). We set out further information on our SCM in Appendix 1 of our Statement of Policy on Cost Benefit Analysis.
Finally, we have applied the standard assumptions set out in Chapter 7 of our
Statement of Policy on Cost Benefit Analysis. Consistent with the HM Treasury Green Book, the impacts are assessed over a 10-year appraisal period and a discount rate of 3.5% is applied to estimate present value stream of costs and benefits over the appraisal period. All costs are expressed in 2025 prices unless otherwise stated.

Data
72. The estimated cost savings and implementation costs associated with our
proposals are primarily based on firm surveys undertaken between June and September 2025. These surveys were sent to a total of 115 firms, composed of 99 investment firms, 12 trading venues and 4 ARMs.
73. We received 55 responses, made up of 40 investment firms, 11 trading venues,
and 4 ARMs. The responses came from a broad variety of sized firms. This is illustrated by surveyed investment firms reporting a median average of 497,584 transaction reports over 2024, in contrast to a mean average of 55,007,337. Firms were asked to provide estimates of their current costs as well as qualitative feedback on the impact they expect the proposed changes to have.
74. As not all our proposals will impact every firm, not all respondents provided
quantitative responses to every section. As a result, there is an element of uncertainty around our estimates. We mitigated this by undertaking further engagement with investment firms, trading venues and ARMs to better understand responses.
75. We used survey data to estimate cost savings for our most significant
proposals, including in the areas of FX derivatives, instruments only tradeable on EU trading venues and changes to the granularity of transaction reporting by trading venues.
76. Where our policy proposals had not been finalised by the time that the surveys
were sent out, we based our cost estimations on the assumptions of the standardised cost model.
77. To address possible response bias, we have implemented weighting
adjustments whereby we reweighted survey responses using known population characteristics. We have also performed sensitivity analysis.
78. For more detail on our survey methodology, see the Technical Appendix.
Summary of Impacts
79. Our proposals are expected to generate the following benefits:

More efficient, less burdensome and less costly compliance process for firms.
Reduced burden for the FCA, due to less time and resource spent
investigating transaction reporting errors.
More effective market abuse detection, supporting market integrity.
More effective market monitoring capabilities, leading to better-informed
decision making and supporting financial stability.

Over a 10-year appraisal period, we estimate net benefits of £745.5m to the
UK economy in present value terms. The annualised saving to businesses is estimated at £86.6m. These figures correspond to the Net Present Social Value (NPSV) and Equivalent Annual Net Direct Cost to Business (EANDCB) in Tables 3 and 4 below. To calculate these we consider the “flow” of costs and benefits over a 10-year appraisal period, applying a discount rate of 3.5% per year. Further explanation on how we calculate these is set out on p67-68 of our Statement of Policy on Cost Benefit Analysis. As the FCA is funded by an industry levy, we have included costs to the FCA in our calculation of the EANDCB.
The rules will introduce new one-off costs to firms of £148.8m. The majority
of these will fall on investment firms, due to cost of adjusting IT systems and associated governance for changing or revisiting existing internal processes. We assume these costs will all be incurred in the first year following the introduction of the rules.
The rules will also introduce new ongoing costs of compliance of £6.8m per
year, relating to our proposals on package transactions, a new DEA indicator value, and the client indicator fields.
However, the new costs will be significantly outweighed by expected ongoing
cost savings to business of £115.3m per year. These arise through lower operational and compliance burdens. Firms will face fewer data collection, validation and submission requirements, leading to lower ongoing cost and fewer reporting errors. This could result in reducing the use of internal systems and staff time as well as lessening the need for ongoing IT maintenance, data reconciliation and external vendor support.
There are additional benefits which we deem to be significant, but we have
been unable to quantify. This includes our proposals for conditional single-sided reporting and the benefits of several removed fields, which are only material when considered together. We take a proportionate approach to cost benefit analyses, which means that we carry out additional analysis only up to the point where it can realistically deliver additional and reliable knowledge that can materially inform our decision on the appropriate course of action. Additionally, the time and resources necessary to obtain and deliver that knowledge must be reasonable considering the benefits that knowledge is likely to deliver.
There will be potential cost savings to the FCA as a result of reduced resources
spent on identifying and correcting errors in transaction reports. Fewer inaccuracies mean less supervisory intervention, fewer queries to firms and more efficient allocation of regulatory resources. These efficiency gains would allow us to redirect capacity to other supervisory and policy activities, thereby strengthening overall regulatory effectiveness. While these savings are expected to be material, they are difficult to quantify and have therefore not been included in our monetised assessment.
Through better data quality, we will gain more accurate insights into market
behaviour, enabling us to support market integrity. This enhances investor confidence, making our markets more attractive. These benefits are not captured in direct cost-benefit estimates but contribute materially to overall market integrity and financial stability.
The main benefits and costs are summarised in Tables 2 to 4 below.
Table 2 - Summary table of benefits and costs
Impact
Benefits (£) Costs (£)
One off Ongoing One off Ongoing
All in-scope firms (c.1,352)
Familiarisation & gap analysis £12.3m
Section 1: Shape of the regime
Exempting all corporate actions £8.8m Insignificant (not quantified) Reducing back reporting requirement from 5 to 3 years (c. 333 firms) £11.9m Insignificant (not quantified)
Section 2: Scope of the regime
Descoping FX derivatives
(c. 424 firms)
£56.7m £1.3m
Descoping instruments traded on EU venues only (c. 1,110 firms) £31.5m £2.8m Removing obligation for SIs to submit reference data (c. 24 firms) £5.6m Insignificant (not quantified) Removing obligation for TVs to report decision maker details (c. 50 firms) £0.8m £0.3m
Section 3: Content of
transaction reports
Adding 2 price fields and adopting
“package transaction” definition
(c. 242 firms)
£10.3m £6.8m
Schema and accompanying changes (c. 1,352 firms) Not quantified £118.7m Removing 11 fields from instrument reference data (c. 74 firms) £0.3m

Impact
Benefits (£) Costs (£)
One off Ongoing One off Ongoing
FCA
Loss of data Not quantified
RTS22/RTS23 changes; MDP changes and warranty £1m ARMs Implementation costs (fields and schema) £1.8m Market benefits (improved ability to monitor markets, prevent crime and market abuse, protect market integrity and support market confidence) Not quantified Total - £115.3m £148.8m £6.8m
Table 3 - Present Value and Net Present Social Value
PV Benefits PV Costs NPSV (10 yrs)
Total impact £942.8m £197.3m £745.5m
-of which direct £942.8m £197.3m £745.5m
-of which indirect -
Table 4 - Net direct costs to firms
Total (Present Value)
Net Direct Cost to
Business (10 yrs) EANDCB
Total net direct cost to business
(costs to businesses - benefits to businesses) -£745.5m -£86.6m Benefits Direct benefits to firms (investment firms, trading venues and ARMs)
88. The main benefits to firms are cost savings they will incur due to our proposed
streamlined reporting regime.

The table below sets out the estimated cost savings for the key policy changes
that we expect to have the greatest impact on firms and have been able to quantify.
As it is not always possible to clearly identify whether a transaction report
relates to a corporate action, we have been unable to estimate the number of firms impacted by the change.
Table 5 – Breakdown of estimated cost savings
Proposed change
Number of firms impacted
Total annual cost saving
Annual cost saving per firm
Exempting corporate actions
Not quantified £8.8m High reporters - £141k
Mid reporters - £5k
Low reporters - £2k
Reducing back reporting requirement
c. 333 £11.9m High back reporters -
£1.3m
Mid back reporters -
£26k
Low back reporters -
£2k
Descoping FX derivatives
c. 424 £56.7m High reporters - £908k
Mid reporters - £45k
Low reporters - £16k
Descoping instruments traded on EU venues only
c. 1,110 £31.5m High reporters - £155k
Mid reporters – £52k
Low reporters - £1k
Removing obligation for SIs to submit reference data
c. 24 £5.6m High reporting SIs -
£900k
Low reporting SIs -
£123k
Removing obligation for venues to report decision makers’ details
c. 29 £0.8m Typical trading venue -
£26k
Removing 11 fields from RTS 23
c. 74 Not quantified N/A
Schema and accompanying changes
c. 1,352 Not quantified N/A
Not all firms will be affected by our proposed regime changes equally. For
example, while our proposal to exempt FX derivatives from reporting will impact approximately 424 investment firms will report fewer transactions going forward, our changes to instrument reference data reporting by SIs will only impact the 24 SIs.
Based on our survey of firms, we estimate that ongoing cost savings to firms
amount to £115.3m per year.
Some of the regime changes yield direct cost savings for firms that are difficult
to quantify in practice. For example, we intend to reduce costs imposed on firms by proposing conditional single-sided reporting. We anticipate that this could alleviate burden on buy-side firms in particular, whilst allowing us to maintain our oversight of relevant transactions. We are also proposing a change to our reporting schema, as we intend to reduce the number of reportable fields from 65 to 52. Due to practical challenges, we have not been able to quantify the benefits arising from these proposals.
We expect that the most substantial costs savings will arise due to our
proposals on excluding (i) FX derivatives and (ii) ‘EU only’ instruments under
Section 2: Scope of the Regime. These cost savings are estimated at £56.7m
and £31.5m per year respectively.
Further cost savings are related to several of our proposals under Section 2:
Scope of the Regime. We expect that our proposal to remove the obligation for SIs to report instrument reference data will amount to cost savings of £5.6m per year for the relevant SIs. Our proposals to remove the obligation for trading venues to report details of the investment and execution decision makers of firms they report on behalf of are expected to save the affected trading venues £0.8m per year.
Significant cost savings are expected to arise due to our proposals under
Section 1: Shape of the Regime. Affected firms are expected to benefit from
cost reduction of £11.9m per year from our proposals to reduce the period for which back reports should be submitted (from 5 to 3 years). Our proposals related to exemption of corporate actions are expected to result in £8.8m cost savings per year. The cost savings arising from the corporate actions exemption are conditional upon the assumption that all firms choose to stop reporting corporate actions, even though they may continue to do so. We believe this is a reasonable assumption due to the relatively high costs of preparing these reports. Direct benefits to the FCA
We spend significant operational resource on reviewing and analysing the
data that is ingested from transaction reports. This includes identifying and addressing inconsistencies and engaging with firms to ensure that errors are corrected. It is not possible to reasonably quantify the current costs which result from inaccurate and incomplete transaction reports and its impact on

our ability to prevent market abuse and financial crime. As we cannot quantify this particular harm, we are not able to quantify the reduction in harm that we expect our interventions to lead to.
98. However, it is reasonable to infer that because we expect our proposed rule
changes to lead to improved data quality, there will be potential cost savings to us due to reduced time and resources spent on identifying and correcting mistakes. Fewer inaccuracies mean less supervisory intervention, fewer queries to firms and more efficient allocation of regulatory resources. These efficiency gains would allow us to redirect capacity to higher-value supervisory and policy activities, thereby strengthening overall regulatory effectiveness. Indirect benefits to the FCA and market participants
99. We will gain more accurate and timely insights into market behaviour, enabling
us to detect market abuse more effectively, enhancing investor confidence and benefitting market participants. In addition, stronger data reduces gaps in surveillance, improving our supervisory efficiency.
100. We share transaction reports with the Bank of England, which is used to support
the work we conduct to monitor risk and liquidity in core markets such as gilts. We therefore expect the Bank of England to also benefit from higher quality data in the form of greater operational efficiency and oversight.
101. These benefits are not captured in direct cost-benefit estimates but contribute
materially to overall market integrity and financial stability.
Costs
Costs to firms
Familiarisation and gap analysis costs
102. Firms will incur costs to familiarise themselves with the requirements and complete
gap analysis to understand what they need to do to meet new requirements.
103. We have used our SCM to estimate the costs to firms to familiarise themselves
with the proposals and complete gap analysis. We assume that costs occur to firms according to their size in the SCM, as defined by number of transaction reports submitted.
104. The daily labour cost of a member of compliance staff is estimated to be
between £350 and £390 depending on the size of the firm, including salary (from our SCM) and a non-wage labour cost uplift. This is then adjusted for the time taken to read the CP and legal documentation.
105. Firms in scope of transaction reporting under MiFID will be expected to read
approximately 80 pages of the CP and 200 pages of legal documentation.

We assume that between 1.5 and 6 FTE staff will be required to read the CP (excluding the instrument). We also assume that a legal team reviewing relevant documentation will consist of between 1.5 and 3 FTE staff. In total, we estimate there are 1,352 firms affected by our proposals. This includes:

99 ‘large’ firms (includes 91 investment firms, 6 trading venues and 2 ARMs)
469 ‘medium’ firms (includes 459 investment firms, 8 trading venues and
2 ARMs)
784 ‘small’ firms (includes 750 investment firms and 34 trading venues)

The estimated costs from familiarisation and gap analysis are £40,000 per firm for
large firms, £14,000 per firm for medium firms and £2,400 per firm for small firms. The total one-off cost of familiarisation and gap analysis for all firms is £12.3m. Compliance costs
The main categories of one-off costs that could arise from firms’
implementation of the proposals are:

IT development costs - costs related to adapting existing IT systems. There
may also be additional costs of maintaining these adapted IT systems on an ongoing basis.
Training costs - costs associated with briefing or training staff on new
procedures. This may encompass formal training as well as informal dissemination via email or staff meetings.

There will also be some additional ongoing costs to firms. Some of our changes
will require firms to implement new reportable fields. Firms will incur ongoing costs associated with accompanying reporting flows associated with new fields. For example, firms will need to reconcile internal records with FCA submissions, with potential errors requiring reconciliation. These costs include vendor, staff and operational and tech support costs.
Nonetheless, we expect that the total ongoing cost of compliance will
be lower as a result of our proposed changes, as we are simplifying and streamlining the regime.
Survey respondents were not asked about for cost estimates on additional
reporting, other than for package transactions. This is because as at the time the data request was sent to firms, proposals had not been finalised. Other cost estimates are based on the assumptions of the FCA’s SCM. Cost to firms per section
Section 1: Shape of the regime
The main costs associated with Section 1 are familiarisation and gap analysis
costs. We have not monetised any costs under this section as they are not mandated under our proposals. We recognise that within this section there

are categories where we expect very small costs and others where firms are likely to continue reporting as this reflects standard industry practice. We also expect that some firms may choose to implement certain changes voluntarily to achieve operational efficiencies. These potential cost savings are reflected in the benefits section of our analysis.

Corporate actions: No additional costs as we propose to exempt all
corporate actions but allow them to be reported.
Exclusion under Article 2(5)(m): No additional costs as we propose to
simplify the threshold subject to exemption under an employee share incentive plan and we are not mandating any additional reporting.
Exclusion under 2(5)(I) Dividend Reinvestment Plan (DRIP): No additional
costs as we propose to allow these to be reported.
Back reporting: We are reducing the default period for which back
reports should be submitted from 5 to 3 years. We expect no additional costs as firms already have processes in place to submit these reports. This adjustment should streamline reporting requirements and reduce unnecessary administrative effort.
Section 2: Scope of the regime

Our assessment of the costs related to each proposal under Section 2: Scope of
the regime is presented in Table 6 below. Whilst many one-off implementation costs arising from our proposals will not be significant, our major rule changes are likely to require code changes at firms. Specifically, there are likely to be one-off implementation costs arising from the following 3 proposals: descoping FX derivatives; descoping ‘EU only’ instruments; and removing the obligation for trading venues to report investment and execution decision maker details. We estimate these to amount to £4.4m in total. These costs have been estimated using SCM and relate to IT change project costs and training costs.
Table 6: Cost breakdown – changes to the scope of the regime
Change
Number of firms impacted
Method for cost estimation One-off costs
Descoping FX derivatives c. 424 SCM £1.3m
Descoping ‘EU only’ instruments
c. 1,110 SCM £2.8m
Relaxing Article 26(2)(c) to allow reporting any Index Not quantified N/A Insignificant (not quantified) Including fractional shares within the scope of reporting regime
c. 65 N/A Insignificant
(not quantified)
Clarifying Structured products in scope of the regime
c. 673 N/A Not quantified

Change
Number of firms impacted
Method for cost estimation One-off costs
Removing reference data reporting obligation for SIs
c. 24 N/A Insignificant
(not quantified)
Creating an enhanced conditional single-sided reporting mechanism Not quantified N/A Not quantified Removing the obligation for TVs to report decision makers’ details
c. 50 SCM £0.3m
Requiring that negotiated transactions are reported by TVs under 26(5)
c. 50 N/A Insignificant
(not quantified)
Section 3: Content of transaction reports
113. We asked a sample of firms to report anticipated costs for reporting a “single
leg” price for package transactions. Reporting a “single leg” means firms will additionally be asked to provide the price of one component of a multi-leg transaction, rather than only the price of the entire package. We received around 20 responses from our firm survey for both one-off costs and ongoing costs. These estimates are provided in Table 7 below and amount to £10.3m in one-off costs and £6.8m per year in ongoing costs. Schema and accompanying changes
114. The transaction reporting regime requires that firms submit a transaction
report for all transactions executed in relevant financial instruments. To do this, firms populate a schema which maps to the 65 fields as set out in RTS 22.
115. We propose the removal and addition of several fields. It is only when considered
in their entirety that these changes add up to a material implementation cost. We expect that total ongoing compliance cost will be lower because of our proposed changes. This is because we are removing more complexity and volume of reported data than we are adding.
116. Whilst our overall changes represent net benefit, the schema changes will be
a one-off cost. We estimate these costs in relation to 14 changes we propose under the subsection Schema and accompanying changes in Section 3: Content of transaction reports.
117. These changes are explained in Chapter 5 of the CP. The total one-off cost of
our proposed changes under Schema and accompanying changes is £118.7m.
118. In addition, we are proposing changes to instrument reference data reported
under RTS 23. We propose to remove 11 fields. We expect the cost of implementing our proposals will amount to a one-off cost of £0.3m.

Our assessment is provided in Table 7 below.
Table 7 – Cost breakdown – changes to the content of transaction reports
Change
Number of firms impacted
Method for cost estimation
One-off costs
Ongoing cost
Allowing natural persons to be identified as an executing entity for on‑venue transactions Not quantified N/A Insignificant costs (not quantified) N/A Allowing firms to report either LEI of the trust or the underlying beneficiary
c. 468 N/A Insignificant
costs (not quantified)
N/A
Reporting a “single leg” price for package transactions
c. 212
investment firms
c. 30 trading
venues
Surveys £10.3m £6.8m
Schema and accompanying changes
c. 1,352 SCM £118.7m N/A
Removing 11 fields from
RTS 23
c. 74 SCM £0.3m N/A
Indirect impact on ARMs
The following proposals may impact ARMs’ business models:

Changes to the scope of reportable financial instruments. This may
materialise through a potential loss of revenue due to a lower volume of transaction reports. The scale of the impact will depend on the proportion of transaction fees within each ARM’s overall revenue stream.
Back reporting. The proposal to limit back reporting to 3 years may reduce
revenues, as ARMs typically charge higher rates for back-dated reporting.
Conditional single-sided reporting. The proposal would consolidate what
are currently two separate transaction reports into a single submission. The consolidation of reports would reduce the total number of reportable transactions, thereby potentially impacting ARM income. However, as the extent to which firms may adopt conditional single-sided reporting is uncertain, it is not possible to quantify the likely impact on ARMs.

However, our assessment shows that our proposed changes will not result
in a material impact on ARMs. Payments to ARMs for compliance-related services fall under the category of resources devoted to meeting regulatory requirements, rather than representing broader economic effects. The concept of “resources used in complying with regulation” refers to direct compliance

costs borne by regulated entities. These are distinct from indirect impacts, such as changes in market behaviour or redistribution of income.
122. When such payments cease, the services provided by ARMs — previously
utilised solely for regulatory compliance — are no longer required. This creates a potential societal benefit, as resources (financial and operational) that were tied up in compliance activities can now be redirected elsewhere.
123. Because these payments do not constitute indirect impacts, they are not
factored into EANDCB or NPV metrics. Instead, their removal is considered a reallocation of compliance resources, which may contribute to efficiency gains at the macroeconomic level. Costs to the FCA
124. The most significant of costs to the FCA will be a one-off implementation
cost, as we will be required to update MDP to systematically ingest transaction reports based on the new requirements. Costs also include resource that may be required to create and publish the updated XML schemas.
125. We estimate the one-off implementation costs of these proposals to be
approximately £1m. As the FCA is funded by an industry levy, we have counted these costs as a direct cost to business and so they are included in our estimate of the EANDCB (see Table 4).
126. There may be costs associated with potential loss of information for the FCA.
For example, relying on EMIR data for FX derivatives may create a data gap for transactions executed by UK branches of third-country firms, which could in turn reduce our oversight. We plan to bridge this gap by exploring data sharing agreements with third country regulators. Our assessment is that in the medium to long term, the cost of data loss in this area will be very small.
127. Similarly, removing financial instruments only tradable on EU trading venues
from the scope of reportable financial instruments risks impairing our ability to monitor derivative contracts relevant to global markets. However, our assessment is that alternative means of gathering data to monitor such instruments are feasible. Therefore, we expect the cost of data loss to be relatively insignificant. Unintended consequences
128. Some divergence between UK and EU transaction reporting requirements is
likely as a result of these proposals. Multinational firms operating across both jurisdictions may therefore need to maintain compliance with two separate regimes. This could require investment in systems and processes to meet EU requirements, even where UK rules are streamlined. As a result, these firms may not realise the full cost savings that would apply if they were trading solely under UK rules.

However, we expect the UK regime to remain more efficient and proportionate
overall. Our proposed changes reduce duplication, simplify reporting obligations, and improve data quality. While firms with cross-border operations may face incremental complexity, the net effect of our proposals is still expected to be positive, as they lower compliance costs for UK activity and enhance the attractiveness of UK markets. Wider economic impacts, including on the secondary international competitiveness and growth objective
Our proposals aim to strengthen market integrity and confidence by improving
the quality and usability of transaction reporting data. High-quality data both enables effective surveillance, reducing the risk of market abuse and financial crime, and strengthens our market monitoring capabilities. These factors support trust in UK markets, which is a foundation for investment and growth.
Beyond these direct regulatory objectives, the proposals contribute to
productivity growth through proportionate regulation – one of the seven key drivers of productivity set out in our statement introducing our secondary international competitiveness and growth objective.
By streamlining reporting requirements and removing duplicative obligations,
firms may spend less on compliance and could spend more on productive activities. Resources currently tied up in maintaining complex reporting systems can be reallocated to innovation, client service, and research and development. These changes could reduce operational friction, allowing firms to deploy capital and talent more efficiently.
Lower compliance costs can also lead to broader economic benefits. Cost
savings for investment firms and trading venues may be passed through to end-investors in the form of lower fees, freeing budget for consumption or reinvestment elsewhere in the economy. This multiplier effect enhances overall economic efficiency.
The proposals also improve the UK’s international competitiveness. Responses
to DP24/2 highlighted that the UK’s reporting regime is more onerous than those in other jurisdictions. Disproportionate obligations risk deterring crossborder activity and reducing market attractiveness. By reducing the granularity of reporting by trading venues on behalf of overseas firms, for example, we make UK markets more appealing for international participants, supporting liquidity and growth.
Finally, these changes reflect the UK’s post-EU regulatory context. The EU
has indicated it wants to create a more streamlined framework for financial transaction reporting. Our proposals ensure that UK rules remain proportionate and tailored to domestic market needs while maintaining sufficient alignment to avoid unnecessary divergence costs for global firms.

Monitoring and evaluation
136. We expect to receive more accurate, timely and consistent data from firms
through our proposed changes. This should enable us to better monitor markets as well as to reduce costly burdens on firms.
137. We will measure success by continuing our close monitoring of data quality
before and after our changes. We will use existing analytical metrics such as report acceptance rate, error alert ratios and corrective reporting ratios. We will supplement this work by detecting trends in data quality through supervisory engagement. Success in this area would take the shape of sustained efficiencies in these metrics and positive supervisory experiences.
138. We will also monitor the ongoing usefulness of transaction reporting data. We
intend to do this by gathering statistics on outcomes of workstreams where the data has been used, including where that workstream has relied on our changes. In addition, we will speak to data users to seek feedback on the degree to which the data has become more useful. Success here would be clear evidence that our changes are driving stronger outcomes across our market monitoring and surveillance capabilities. Technical Appendix – Methodology for calculations
139. To determine the majority of one-off costs, ongoing costs and ongoing cost
savings caused by our proposed changes, we requested estimated figures from representative samples of investment firms, trading venues and ARMs who operate in the transaction reporting and instrument reference data space. In total, we collected 788 unique datapoints through this engagement, which took place between July and September 2025. Methodology for data cleansing
140. We undertook data cleansing where we identified obvious errors. As an
example, one firm who does not operate a SI provided figures for a question specifically posed to SIs. Other responses indicated that it had been too challenging to segregate costs borne under EU MiFIR to those borne under UK MiFIR. These responses were excluded for consistent analysis.
141. In addition, there were particular areas where we found that firms had
misinterpreted the queries posed in our data requests. For example, when reviewing qualitative responses together with transaction reports submitted to MDP, it became clear that firms were overestimating the proportion of their trading taking place in instruments only admitted to trading on an EU venue. As a result, we used their general reported cost of submitting a transaction report when calculating cost savings in this area, rather than the reported cost of a transaction report in instruments only tradeable on EU venues.

Methodology for scaling up survey responses to the population of affected firms
142. We dealt with potential response bias by undertaking a weighting approach.
Specifically, we grouped responses for each policy area into multiple buckets of firms, based on an analysis of reported figures and real transaction reporting data. After calculating average figures for each relevant bucket and question, we applied a multiplier to each bucket based on the proportion of transaction reports submitted by firms in that bucket. We provide an example of this methodology below:
Table 8 – Example calculations – cost savings from descoping
FX derivatives*
Bucket
Weighted average cost per FX TR
(from firm survey)
Total FX TRs submitted by all firms in bucket (2024) (from MDP) Annual cost saving for all firms in bucket High-reporting firms (>100k FX TRs) (2024) £0.67 57,175,089 £38,153,452.51 Mid-reporting firms (3k-100k FX TRs) (2024) £1.74 3,439,568 £5,980,527.00 Low-reporting firms (1-3k FX TRs) (2024) £25.87 153,224 £3,963,941.99 All firms - - £48,097,922.51 *For simplicity, this table only demonstrates the methodology used to calculate cost savings from descoping transaction reporting for FX derivatives. The cost savings for FX trading venues of supplying instrument reference data was calculated similarly.
143. Whilst we believe this methodology has worked well for our most significant
changes, we were also pragmatic given the nature of each change. For example:

Instrument reference data reporting by trading venues and SIs: Survey
responses for instrument reference data reporting were scaled and weighted according to the degree of instrument reference data which reporting entities submit, rather than transaction reports.
Corporate actions: Due to impracticalities assessing the degree of
transaction reports we receive due to corporate actions, we did not scale survey responses based on transaction reports specific to corporate actions but rather by numbers of firms submitting specific ranges of transaction reports broadly.
IDM/EDM reporting under Article 26(5): We did not identify any correlation
between either the number of transaction reports submitted under Article 26(5) of UK MiFIR, nor the amount of PII that trading venues collect, with the monetary amount that trading venues said they incurred collecting PII to comply with their obligations. In this instance, we took a flat average of costs and multiplied by the number of trading venues. We believe this is

reasonable considering the mean and median responses for this query were only 4% different. Use of the SCM
144. Alongside responses to our surveys, we have made assumptions on the cost for
firms of a schema change based on our SCM. We do the same to identify the one-off implementation cost of descoping FX derivatives and instruments only tradeable on EU trading venues. We set out further information on our SCM in
Appendix 1 of our Statement of Policy on Cost Benefit Analysis.
Consultation with the FCA Cost Benefit Analysis Panel
145. We have consulted the CBA Panel in the preparation of this CBA in line with
the requirements of s138IA(2)(a) FSMA. A summary of the main group of recommendations provided by the CBA Panel and the measures we took in response to Panel advice is provided in the table below. In addition, we have undertaken further changes based on wider feedback from the CBA Panel on specific points of the CBA. The CBA Panel publishes a summary of their feedback on their website, which can be accessed here.
Table 9 – CBA Panel recommendations
CBA Panel Main Recommendations Our Response Simplify the analysis and presentation. The Panel recommends that the CBA be shortened and simplified to reflect the relatively straightforward nature of the proposed change. At its current length, the analysis is disproportionately detailed for a deregulatory measure. The Panel further recommends removing or streamlining the causal chain analysis, which appears unnecessary given that the policy primarily reduces regulatory burden rather than addressing market failures and changing behaviour. We have identified, shortened and simplified areas with excessive detail and duplication. We have reviewed the necessity of all charts in the ‘Market’ section and removed several of them. We have removed our causal chains of current and reduced harms to streamline our analysis and reflect that our proposals are primarily based on reducing the regulatory burden on firms.

CBA Panel Main Recommendations Our Response Strengthen the discussion of how benefits are expected to be realised.The Panel recommends expanding the assessment of how and when cost savings are expected to materialise. In particular, the CBA should address whether asset managers are likely to realise actual cost reductions as a result of the changes, to ensure the credibility of the estimated net benefits. In the same vein, the CBA should clarify how its estimates of economic benefits from cost-savings relate to its analysis of the use of ARMs by reporting firms. The Panel also recommends improving transparency by summarising the key benefit figures upfront and ensuring consistency across tables and text. We have made a more explicit link between evidence from our data request and the impact on the broader population of MiFID investment firms and trading venues. We have better explained the role of ARMs and drawn out the reasons for the relatively limited impact of our policy proposals on them. We have ensured that figures are consistent throughout the CBA and summarised in the CBA’s Executive Summary. Emphasise the pro-growth effects of the proposed intervention. Given that the estimated cost savings to firms, and the resulting impacts on growth and competitiveness, are significant, the Panel recommends that these impacts are identified in the CBA as one of the primary outcomes of the proposals. The impact on growth and competitiveness should therefore be presented more prominently in the Executive Summary. We have emphasised the impact on growth and competitiveness in the Executive Summary section.

Annex 3
Compatibility statement
Compliance with legal requirements

This Annex records the FCA’s compliance with a number of legal requirements
applicable to the proposals in this consultation, including an explanation of the FCA’s reasons for concluding that our proposals in this consultation are compatible with certain requirements under the Financial Services and Markets Act 2000 (FSMA).
When consulting on new rules, the FCA is required by section 138I(2)(d) FSMA
to include an explanation of why it believes making the proposed rules (a) is compatible with its general duty, under section 1B(1) FSMA, so far as reasonably possible, to act in a way which is compatible with its strategic objective and advances one or more of its operational objectives, (b) so far as reasonably possible, advances the secondary international competitiveness and growth objective, under section 1B(4A) FSMA, and (c) complies with its general duty under section 1B(5)(a) FSMA to have regard to the regulatory principles in
section 3B FSMA. The FCA is also required by s 138K(2) FSMA to state its
opinion on whether the proposed rules will have a significantly different impact on mutual societies as opposed to other authorised persons.
This Annex also sets out the FCA’s view of how the proposed rules are
compatible with the duty on the FCA to discharge its general functions (which include rule-making) in a way which promotes effective competition in the interests of consumers (section 1B(4)). This duty applies in so far as promoting competition is compatible with advancing the FCA’s consumer protection and/ or integrity objectives.
In addition, this Annex explains how we have considered the recommendations
made by the Treasury under s 1JA FSMA about aspects of the economic policy of His Majesty’s Government to which we should have regard in connection with our general duties.
Under the Legislative and Regulatory Reform Act 2006 (LRRA) the FCA is
subject to requirements to have regard to a number of high-level ‘Principles’ in the exercise of some of our regulatory functions and to have regard to a ‘Regulators’ Code’ when determining general policies and principles and giving general guidance (but not when exercising other legislative functions like making rules). This Annex sets out how we have complied with requirements under the LRRA.

The FCA’s objectives and regulatory principles:
Compatibility statement
6. The proposals set out in this consultation are primarily intended to advance
the FCA’s operational objective to protect and enhance the integrity of the UK financial system. They are also relevant to the FCA’s secondary objective to facilitate the international competitiveness and growth of the UK economy in the medium to long term.
7. We consider these proposals are compatible with the FCA’s strategic objective
of ensuring that the relevant markets function well. For the purposes of the FCA’s strategic objective, “relevant markets” are defined by s. 1F FSMA.
8. We have had regard to the recommendations made by the Treasury in its 2025
remit letter throughout the development of these proposals. In particular, the proposals support the government’s objectives of promoting growth, international competitiveness, and innovation in UK financial services by streamlining regulatory requirements, reducing unnecessary burdens, and ensuring that the regime remains proportionate and agile. The consultation also reflects the Treasury’s emphasis on maintaining high regulatory standards while enabling the UK to respond flexibly to market developments and international changes. Where relevant, the FCA has considered the Treasury’s recommendations in its assessment of policy options, ensuring that the final proposals are consistent with the government’s broader economic policy aims and the FCA’s statutory objectives. These changes also support the FCA’s strategic goal of maintaining the UK’s position as a leading global financial centre, as set out in our 2025–2030 Strategy.
9. We consider these proposals advance the FCA’s market integrity objective
because they are designed to enhance the quality, reliability and utility of transaction reporting data, which is fundamental to the FCA’s ability to detect, investigate, and prevent market abuse and financial crime. By streamlining the reporting regime—removing duplicative and low-value requirements, clarifying the scope of reportable instruments and focusing on the collection of data that is proportionate to regulatory need—the proposals ensure that the FCA continues to receive timely, accurate and comprehensive information necessary for effective market oversight. The changes support more granular visibility of trading activity, enabling the FCA to generate actionable insights, inform policy development and respond swiftly to emerging risks or market events. The proposals also maintain or strengthen requirements that are critical for market monitoring, such as the retention of buy-side reporting and the continued collection of data relevant to market abuse detection. Where requirements are being reduced or removed, the FCA has carefully assessed the impact to ensure that the integrity of UK markets is not compromised, and that alternative mechanisms (such as targeted data requests or international cooperation) are available to address any potential gaps. In summary, these reforms are intended to support clean, orderly, and resilient markets, fostering trust and confidence

among market participants and underpinning the FCA’s statutory objective to protect and enhance the integrity of the UK financial system.
10. We consider these proposals comply with the FCA’s secondary objective in
advancing competitiveness and growth because they are designed to make the UK’s financial services sector more attractive, efficient, and internationally competitive, while supporting sustainable growth over the medium to long term. The proposals streamline and simplify the transaction reporting regime by reducing unnecessary and duplicative requirements, such as removing reporting obligations for instruments only traded on EU venues and for FX derivatives, and by reducing the number of reportable fields. This is expected to deliver substantial cost savings for firms—estimated at over £100 million annually—freeing up resources for innovation and productive investment. The FCA has also prioritised alignment with international standards and best practices, maintaining close engagement with global bodies such as ESMA and IOSCO, and ensuring that UK rules remain compatible with evolving global frameworks. Where divergence from other jurisdictions is proposed, the FCA has carefully weighed the benefits to UK market participants against potential costs and has chosen options that maximise net benefits for the UK economy as a whole. The approach ensures that any divergence is justified by clear regulatory or economic benefits, and that sufficient alignment is maintained to avoid unnecessary complexity or barriers for cross-border firms.
11. In preparing the proposals set out in this consultation, the FCA has had regard
to the regulatory principles set out in s 3B FSMA. The FCA has sought to ensure that any burdens or restrictions imposed by the revised transaction reporting regime are proportionate to the expected regulatory benefits, as evidenced by the streamlining of reporting requirements, the removal of duplicative or low-value fields and the targeted reduction in the scope of reportable instruments and firms. The principle of using resources in the most efficient and economic way is reflected in the drive for smarter, more agile regulation, including the consolidation of requirements and the adoption of a more proportionate approach to data collection. Where a regulatory principle is not directly relevant—such as the general principle that consumers should take responsibility for their decisions, or the responsibilities of senior management— the FCA has noted that the proposals do not depart from these principles or undermine them. The consultation also demonstrates transparency and accountability by setting out the rationale for each proposal, inviting feedback, and providing a detailed cost-benefit analysis. Where environmental, social, and governance (ESG) considerations or equality and diversity issues are not materially impacted by the proposals, this is explicitly stated, and the FCA commits to keeping these issues under review. The need to use our resources in the most efficient and economic way
12. This aligns with the FCA’s strategic priority to be a smarter regulator, one that is
proportionate, purposeful, and predictable. By streamlining rules that no longer

serve their intended purpose, the proposals reduce unnecessary burdens on firms, focus regulatory attention on areas of greatest risk and value, and enable both the FCA and industry to allocate resources more efficiently. This approach supports a more agile and responsive regulatory framework, ensuring that requirements remain fit for purpose as markets evolve, and that the FCA can continue to deliver its objectives effectively in a rapidly changing environment. The principle that a burden or restriction should be proportionate to the benefits
13. These proposals apply the principle that a burden or restriction should be
proportionate to the benefits by carefully assessing the regulatory value of each reporting requirement and removing or adapting those that impose costs disproportionate to their utility. For example, the regime reduces the number of reportable fields, removes obligations for instruments only traded on EU venues and FX derivatives, and tailors requirements for small firms—ensuring that firms’ compliance efforts and costs are aligned with the FCA’s actual data needs and statutory objectives. This proportionate approach is intended to support a more efficient, competitive, and growth-oriented regulatory environment. The general principle that consumers should take responsibility for their decisions
14. The proposals do not depart from the general principle that consumers take
responsibility for their decisions.
The responsibilities of senior management
15. Our proposals do not specifically relate to the responsibilities of senior
management. Nevertheless, we have had regard to this principle and do not consider that our proposals undermine it. The desirability of recognising differences in the nature of, and objectives of, businesses carried on by different persons including mutual societies and other kinds of business organisation
16. When making our proposals we have considered the nature and size of the firms
that those proposed requirements would apply to.
The desirability of publishing information relating to persons subject to requirements imposed under FSMA, or requiring them to publish information
17. The consultation process itself, the publication of the Consultation Paper, and
the commitment to publish responses and feedback, all support transparency. The FCA also proposes to provide more guidance and examples.

The principle that we should exercise of our functions as transparently as possible
18. By explaining the rationale for each of our recommendations and the anticipated
outcomes the FCA has regard to this principle.
In formulating these proposals, the FCA has had regard to the importance of taking action intended to minimise the extent to which it is possible for a business carried on (i) by an authorised person or a recognised investment exchange; or (ii) in contravention of the general prohibition, to be used for a purpose connected with financial crime (as required by s 1B(5)(b) FSMA). The proposals are specifically designed to enhance the FCA’s ability to detect, investigate, and prevent market abuse and financial crime by ensuring the continued collection of high-quality, timely and relevant transaction data. By clarifying and streamlining reporting requirements, the FCA aims to improve the accuracy and completeness of the data it receives, which is essential for effective market surveillance and the identification of suspicious activity. Where reporting obligations are reduced, the FCA has carefully assessed the impact to ensure that the integrity of the market and the FCA’s ability to combat financial crime are not compromised, with alternative mechanisms in place to address any potential gaps. Expected effect on mutual societies
19. The FCA does not expect the proposals in this paper to have a significantly
different impact on mutual societies. Our proposed rules will apply according to the powers exercised and to whom they are addressed, equally regardless of whether it is a mutual society or another authorised body. Compatibility with the duty to promote effective competition in the interests of consumers
20. In preparing the proposals as set out in this consultation, we have had regard to
the FCA’s duty to promote effective competition in the interests of consumers.
21. In preparing the proposals in this consultation, we have had regard to our duty to
promote effective competition in the interests of consumers.
22. We consider that by streamlining the transaction reporting regime, we will
reduce barriers to entry for investment firms, promoting effective competition for consumers, who may face lower fees to undertake transactions.
23. We have also kept the competition objective in mind when framing how these
proposals should be implemented, with a particular focus on whether there is a risk of weakening competitive pressure, disadvantaging smaller firms and potential new entrants.

Equality and diversity
24. We are required under the Equality Act 2010 in exercising our functions to ‘have
due regard’ to the need to eliminate discrimination, harassment, victimisation and any other conduct prohibited by or under the Act, advance equality of opportunity between persons who share a relevant protected characteristic and those who do not, to and foster good relations between people who share a protected characteristic and those who do not.
25. As part of this, we ensure the equality and diversity implications of any new
policy proposals are considered. The outcome of our consideration in relation to these matters in this case is stated in paragraph 1.24 of the Consultation Paper. Legislative and Regulatory Reform Act 2006 (LRRA)
26. We have had regard to the principles in the LRRA for the parts of the proposals
that consist of general policies, principles or guidance and consider that comprise general policies, principles, or guidance. Specifically, we have ensured that our approach is in line with the five LRRA principles, which state that regulatory activities must be:

transparent,
accountable,
proportionate,
consistent, and
targeted only at cases in which action is needed.
We acknowledge there is some overlap between these principles and the regulatory principles set out in FSMA. Throughout the development of these proposals, we have aimed to ensure that our regulatory activities are carried out in a manner that is open and clear to stakeholders, that we remain answerable for our actions, that our requirements are appropriate and not excessive, that we maintain uniformity in our approach, and that intervention is focused solely where necessary. This approach underpins our commitment to effective, fair, and responsible regulation.

We have had regard to the Regulators’ Code for the parts of the proposals that
consist of general policies, principles or guidance.

Annex 4
Abbreviations in this document
AIFMD Alternative Investment Fund Manager Directive APA Approved publication arrangement API Application programming interface ARM Approved reporting mechanism BOTs British Overseas Territories CBA Cost benefit analysis CCP Central counterparty CDE Critical Data Elements CDM Common Domain Model CFD Contracts for difference CFI Classification of financial instrument CON Content error CONCAT Concatenated code used to identify natural persons CP Consultation Paper CPMI Collective Portfolio Management Investment CPMI-IOSCO Committee on Payments and Market Infrastructures - International Organization of Securities Commissions CSDs Central Securities Depositories DEA Direct electronic access DEAL Dealing on own account DEAU Direct Electronic Access User DECR Decrease DP Discussion Paper DRR Direct Regulatory Reporting DSB Derivatives Service Bureau DSS Digital Securities Sandbox DTI Digital token identifier EANDCB Equivalent Annual Net Direct Cost to Business EDM Execution decision maker EEA European Economic Area

EMIR European Market Infrastructure Regulation ESG Environmental, social and governance ESMA European Securities and Markets Authority ETDs Exchange Traded Derivatives EU European Union FCA Financial Conduct Authority FIRDS Financial Instrument Reference Data System FSMA Financial Services and Markets Act FX Foreign exchange GBP Pound sterling GDPR General Data Protection Regulation GLEIF Global Legal Entity Identifier Foundation GUI Graphical user interface H1 First half of the year IDM Investment decision maker INCR Increase INS Instrument level validation error INTC Internal client account – aggregated client account IPO Initial public offering IRS Interest rate swap ISIN International Securities Identification Number ISO International Organization for Standardization IT Information Technology JSON JavaScript Object Notation LDI Liability-driven investment LEI Legal Entity Identifier MAR Market Conduct Sourcebook MDP Market Data Processor MIC Market Identifier Code MiFID Markets in Financial Instruments Directive MiFIR Markets in Financial Instruments Regulation MTF Multilateral trading facility NCA National Competent Authority NOAP Not applicable

NORE No one responsible for execution (within the firm) NPV Net Present Value OTC Over-the-counter OTF Organised trading facility PII Personal identifying information PIP Primary information provider PRA Prudential Regulation Authority PV Present Value REMIT Regulation on wholesale Energy Market Integrity and Transparency RIE Recognised investment exchange RNS Regulatory News Services RTN Report Tracking Number RTS Regulatory Technical Standard RTS 22 The Regulatory Technical Standards for transaction reporting:
Commission Delegated Regulation (EU) 2017/590 RTS 23 The Regulatory Technical Standards for instrument reference data:
Commission Delegated Regulation (EU) 2017/585 RTS 24 The Regulatory Technical Standards for the maintenance of relevant data relating to orders in financial instruments: Commission Delegated Regulation (EU) 2017/580 SFTR Securities Financing Transactions Regulation SI Systematic Internaliser STORs Suspicious Transaction and Order Reports TOTV Traded on a trading venue TR Trade repository TREM Transaction Reporting Exchange Mechanism TRN Transaction reference number TVTIC Trading venue transaction identification code UCITS Undertakings for Collective Investment in Transferable Securities UK EMIR The UK version of the European Market Infrastructure Regulation UK MAR The UK version of the Market Abuse Regulation UK MiFIR The UK version of the Markets in Financial Instruments Regulation UK SFTR The UK version of the Securities Financing Transactions Regulation UPI Unique Product Identifier UTI Unique transaction identifier XML Extensible markup language

Annex 5
List of non-confidential respondents
Association for Financial Markets in Europe (AFME) AJ Bell Securities Limited Alternative Investment Management Association (AIMA) Blackrock International Limited BVI (German Fund Industry) CBOE Europe Limited City of London Law Society (CLLS) ControlNow Limited Derivatives Service Bureau (DSB) Limited Electronic Debt Markets Association European Venues and Intermediaries Association (EVIA) FIX Trading Community Futures Industry Association (FIA) Global Digital Finance Global Legal Entity Identifier Foundation (GLEIF) Invesco Fund Managers Limited International Swaps and Derivatives Association, Inc. (ISDA) Managed Funds Association (MFA) MAP FinTech PIMFA - Personal Investment Management and Financial Advice Association Retail Derivative Forum Standards Advisory Group (SAG) UK Finance

Appendix 1
Draft Handbook text

FCA 202X/YY
MARKETS IN FINANCIAL INSTRUMENTS (RECORD KEEPING, TRANSACTION REPORTING AND FINANCIAL INSTRUMENT REFERENCE DATA) INSTRUMENT 202X Powers exercised A. The Financial Conduct Authority (“the FCA”) makes this instrument in the exercise of the powers and related provisions in or under:
(1) the following sections of the Financial Services and Markets Act 2000 (“the Act”):
(a) section 137A (The FCA’s general rules);
(b) section 137T (General supplementary powers); (c) section 139A (Power of the FCA to give guidance); and (d) section 300H (Rules relating to investment exchanges and data reporting service providers); (2) regulation 11 (FCA rules) of the Financial Services and Markets Act 2000 (Recognition Requirements for Investment Exchanges, Clearing Houses and Central Securities Depositories) Regulations 2001 (SI 2001/995); and (3) the other rule and guidance making powers listed in Schedule 4 (Powers exercised) to the General Provisions of the FCA’s Handbook. B. The rule-making powers listed above are specified for the purpose of section 138G(2) (Rule-making instruments) of the Act. Commencement
C. This instrument comes into force on [date].
Amendments to the Handbook
D. The modules of the FCA’s Handbook of rules and guidance listed in column (1) below are amended in accordance with the Annexes to this instrument listed in column (2). (1) (2) Glossary of definitions Annex A Market Conduct sourcebook (MAR) Annex B Supervision manual (SUP) Annex C [Editor’s note: changes to other modules in the Handbook, and to material outside the Handbook, will be consulted on in a later consultation.] Notes

FCA 202X/YY
E. In the Annexes to this instrument, the notes (indicated by “Note:” or “Editor’s note:”) are included for the convenience of readers, but do not form part of the legislative text. Citation F. This instrument may be cited as the Markets in Financial Instruments (Record Keeping, Transaction Reporting and Financial Instrument Reference Data) Instrument 202X. By order of the Board [date]

FCA 202X/YY
Annex A
Amendments to the Glossary of definitions
In this Annex, underlining indicates new text and striking through indicates deleted text, unless stated otherwise. Insert the following new definitions in the appropriate alphabetical position. The text is not underlined. financial instrument reference data in MAR 14, MAR 15 and SUP 17A, the details referred to in MAR 15
Annex 1 (Details to be reported as financial instrument reference data) in
relation to a reportable financial instrument. legal entity identifier a 20-character alphanumeric code which uniquely identifies legally distinct entities that engage in financial transactions. LEI legal entity identifier. negotiated transaction in MAR 14, a transaction in a reportable financial instrument which is negotiated privately but reported under the rules of a qualifying trading venue and where any of the following apply:
(a) two members, participants or clients of that qualifying trading venue are involved in any of the following capacities:
(i) one is dealing on own account when the other is acting on behalf of a client; (ii) both are dealing on own account; or (iii) both are acting on behalf of a client; or (b) one member, participant or client of that qualifying trading venue is either of the following:
(i) acting on behalf of both the buyer and seller; or (ii) dealing on own account against a client order. qualifying trading venue (a) a UK trading venue; or (b) an MTF or OTF operated by an overseas firm from an establishment in the UK. receiving firm has the meaning given in MAR 14.10.1R. request for admission to trading in MAR 14 and MAR 15, where a request for admission to trading has been initiated in accordance with the rules of that qualifying trading venue. sending firm has the meaning given in MAR 14.10.1R.

FCA 202X/YY transaction reporting firm a person who is either:
(a) a MiFID investment firm (excluding a collective portfolio management investment firm); or (b) a third country investment firm when it carries on MiFID or equivalent third country business from an establishment in the United Kingdom. Amend the following definitions as shown. branch … (b) (in relation to an investment firm and a transaction reporting firm):
(i) a place of business other than the head office which is part of an investment firm or transaction reporting firm, which has no legal personality and which provides investment services and/or activities and which may also perform ancillary services for which the firm has been authorised; … [Note: article 4(1)(3) of MiFID] … client … (B) in the FCA Handbook:
…
(12) …
(13) (in MAR 13, MAR 14 and MAR 15) has the meaning in
Article 2(7) of MiFIR (ie, any natural or legal person to
whom an investment firm provides investment or ancillary services). reportable financial instrument in SUP 17A, MAR 13, MAR 14 and MAR 15 those financial instruments in article 26(2) of MiFIR, namely:
(a) financial instruments which are a financial instrument which is admitted to trading or are is traded on a qualifying trading venue, or for which a request for admission to trading request for admission to trading to a qualifying trading venue has been made;

FCA 202X/YY
(b) financial instruments a financial instrument where the underlying is a financial instrument traded on a qualifying trading venue; and (c) financial instruments a financial instrument where the underlying is an index or a basket composed of financial instruments at least one financial instrument traded on a qualifying trading venue.; or (d) an instrument which constitutes a right or interest under article 89 of the Regulated Activities Order in a financial instrument included in paragraph (a), but excluding options, futures, swaps, forward rate agreements and any other derivative contracts relating to currencies which may be settled physically or in cash. securities financing transaction … (1B) (in CASS and, MIFIDPRU and MAR 14) a securities financing transaction as defined in article 3(11) of the SFTR. [Note: article 1(3) of the MiFID Delegated Directive] … trade repository … (2) … (3) (in MAR 14) a legal person registered in accordance with Article 55 of EMIR that centrally collects and maintains the records of derivatives. transaction report a report of a transaction:
(a) …
(b) which meets the requirements imposed by and under article 26 of MiFIR is required by MAR 14. [Editor’s note: the definition of ‘working day’ takes into account the changes set out in the Commodity Derivatives (Position Limits, Position Management and Perimeter) Instrument 2025 (FCA 2025/4) and the Prospectus Instrument 2025 (FCA 2025/30).] working day (1) (in PRM, MAR 5-A, MAR 9 and, MAR 10, MAR 13, MAR 14 and MAR 15) (as defined in section 103 of the Act) any day other than a Saturday, a Sunday, Christmas Day, Good Friday or a day which is a bank holiday under the Banking and Financial Dealings Act 1971 in any part of the United Kingdom. …

FCA 202X/YY
Annex B
Amendments to the Market Conduct sourcebook (MAR) In this annex, underlining indicates new text and striking through indicates deleted text, unless otherwise indicated. Insert the following new chapter, MAR 13, after MAR 12 (Post-trade risk reduction services). The text is all new and is not underlined. 13 Record keeping – orders and transactions
13.1 Purpose, application and interpretation
Purpose
13.1.1 G The purpose of this chapter is to set out the requirements for keeping
records of orders and transactions for transaction reporting firms and operators of qualifying trading venues.
13.1.2 G This chapter should be read in conjunction with the other chapters of the
Handbook that cover record keeping requirements, including COBS 11.5A and SYSC 9. Application
13.1.3 R This chapter applies to:
(1) transaction reporting firms; and
(2) operators of qualifying trading venues, in relation to orders and transactions in financial instruments. Interpretation
13.1.4 G References in this chapter to ‘transaction’ and ‘execution’ should be
interpreted in accordance with MAR 14.2 to MAR 14.4 (inclusive).
13.1.5 G A reference in this chapter to ‘ISO’, followed by a reference number, is to
a standard published by the International Organization for Standardization.
13.2 Records to be maintained by transaction reporting firms in relation to
orders and transactions in financial instruments
13.2.1 G Transaction reporting firms should make themselves familiar with the
existing record keeping obligations that relate to orders and transactions in the Handbook that apply to them – for example, COBS 11 and SYSC 9.
13.2.2 G Transaction reporting firms should ensure their records of orders and
transactions in financial instruments comply with their requirements under the Money Laundering Regulations.

FCA 202X/YY
13.3 Records of orders to be maintained by operators of qualifying trading
venues
13.3.1 R (1) Operators of qualifying trading venues must keep, for at least 5
years, records of the relevant data relating to all orders in financial instruments which are advertised on their venue. (2) The relevant data is the information set out in MAR 13 Annex 1 (Trading venue records). (3) The records must be maintained in accordance with:
(a) the form and structure of MAR 13 Annex 1; and (b) the requirements of MAR 13.4. (4) The records must include details which link an order with the executed transaction that stems from that order, the details of which are required to be reported in accordance with MAR 14.
13.4 Additional provisions relating to the records of orders to be maintained by
operators of qualifying trading venues
Identification of the relevant parties
13.4.1 R (1) For all orders, operators of qualifying trading venues must maintain
records of:
(a) the member, participant or client of the qualifying trading venue who submitted the order to the qualifying trading venue, identified as specified in field 1 of Table 2 of MAR 13 Annex 1 (Trading venue records); (b) where the member, participant or client of the qualifying trading venue who submitted the order is a transaction reporting firm, the person or algorithm responsible for the investment decision in relation to the order identified as specified in field 4 of Table 2 of MAR 13 Annex 1; (c) where the member, participant or client of the qualifying trading venue who submitted the order is a not a transaction reporting firm, the algorithm if any within the firm that is responsible for the investment decision in relation to the order, identified as specified in field 4 of Table 2 of MAR 13
Annex 1. Where an algorithm is not responsible for the
investment decision this field must be left blank; (d) where the member, participant or client of the qualifying trading venue who submitted the order is a transaction reporting firm, the person or algorithm responsible for the execution of the order identified as specified in field 5 of
Table 2 of MAR 13 Annex 1;

FCA 202X/YY
(e) where the firm submitting the order is not a transaction reporting firm, the algorithm if any within the firm that is responsible for the execution of the order, identified as specified in field 5 of Table 2 of MAR 13 Annex 1. Where an algorithm is not responsible for an execution of the order this field must be left blank; (f) the member, participant or client of the qualifying trading venue who routed the order on behalf of and in the name of another member, participant or client of the qualifying trading venue, identified as a non-executing broker as specified in field 6 of Table 2 of MAR 13 Annex 1; and (g) the client on whose behalf the member, participant or client of the qualifying trading venue submitted the order to the qualifying trading venue, identified as specified in field 3 of
Table 2 of MAR 13 Annex 1.
(2) Where a member, participant or client of the qualifying trading venue is authorised under UK legislation to allocate an order to its client following submission of the order to the qualifying trading venue and has not yet done so, that order must be identified as specified in field 3 of MAR 13 Annex 1. (3) Where several orders are submitted to the qualifying trading venue together as an aggregated order, the aggregated order must be identified as specified in field 3 of Table 2 of MAR 13 Annex 1. Trading capacity of members, participants or clients of the qualifying trading venue and liquidity provision activity
13.4.2 R (1) The trading capacity in which the member, participant or client of
the qualifying trading venue submits an order must be described as specified in field 7 of Table 2 of MAR 13 Annex 1 (Trading venue records). (2) The following orders must be identified as specified in field 8 of
Table 2 of MAR 13 Annex 1:
(a) an order submitted to a qualifying trading venue by a member, participant or client as part of a market-making strategy; and (b) an order submitted to a qualifying trading venue by a member, participant or client as part of any other liquidity provision activity carried out on the basis of terms predetermined either by the issuer of the instrument which is the subject of the order or by that qualifying trading venue. Date and time recording

FCA 202X/YY
13.4.3 R (1) Operators of qualifying trading venues must maintain a record of
the date and time of the occurrence of each event listed in field 21 of Table 2 of MAR 13 Annex 1 with the level of accuracy specified by Article 2 of MiFID RTS 25 as specified in field 9 of Table 2 of MAR 13 Annex 1. (2) Except for the date and time of the rejection of orders by qualifying trading venue systems, all events referred to in field 21 of Table 2 of MAR 13 Annex 1 must be recorded using the business clocks used by qualifying trading venue matching engines. (3) Operators of qualifying trading venues must maintain a record of the date and time for each data element listed in fields 49, 50 and 51 of Table 2 of MAR 13 Annex 1, with the level of accuracy specified by Article 2 of MiFID RTS 25. Validity period and order restrictions
13.4.4 R (1) Operators of qualifying trading venues must keep a record of the
validity periods and order restrictions that are listed in fields 10 and 11 of Table 2 of MAR 13 Annex 1 (Trading venue records). (2) Records of the dates and times in respect of validity periods must be maintained as specified in field 12 of Table 2 of MAR 13 Annex 1, for each validity period. Priority and sequence numbers
13.4.5 R (1) Operators of qualifying trading venues which operate trading
systems on a price-visibility-time priority must maintain a record of the priority time stamp for all orders as specified in field 13 of
Table 2 of MAR 13 Annex 1. The priority time stamp must be
maintained with the level of accuracy specified by MAR 13.4.3R(1). (2) Operators of qualifying trading venues which operate trading systems on a size-time priority basis must maintain a record of the quantities which determine the priority of orders as specified in field 14 of Table 2 of MAR 13 Annex 1 as well as the priority time stamp referred to in (1). (3) Operators of qualifying trading venues which use a combination of price-visibility-time priority and size-time priority and display orders on their order book in price-visibility-time priority must comply with (1). (4) Operators of qualifying trading venues which use a combination of price-visibility-time priority and size-time priority and display orders on their order book in size-time priority must comply with (2).

FCA 202X/YY
(5) Operators of qualifying trading venues must assign and maintain a sequence number for all events as specified in field 15 of Table 2 of MAR 13 Annex 1. Identification codes for orders in financial instruments
13.4.6 R (1) Operators of qualifying trading venues must maintain an individual
identification code for each order as specified in field 20 of Table 2 of MAR 13 Annex 1 (Trading venue records). (2) The identification code required by (1) must be unique for each:
(a) order book;
(b) trading day; and
(c) financial instrument.
(3) The identification code must apply from the receipt of the order by operators of qualifying trading venues until the removal of the order from the order book. (4) The identification code must also apply to rejected orders irrespective of the ground for their rejection. Strategy orders with implied functionality
13.4.7 R (1) Operators of qualifying trading venues must maintain the relevant
details of strategy linked orders with implied functionality that are disseminated to the public as specified in MAR 13 Annex 1 (Trading venue records). (2) Field 33 of Table 2 MAR 13 Annex 1 must include a statement that the order is an implicit order. (3) Upon execution of a strategy linked order with implied functionality, an operator of a qualifying trading venues must maintain its details as specified in MAR 13 Annex 1. (4) A strategy linked order identification must be indicated using the same identification code for all orders connected to the particular strategy. (5) The strategy linked order with implied functionality identification code must be as specified in field 46 of Table 2 of MAR 13 Annex 1. Routed orders
13.4.8 R Orders submitted to a qualifying trading venue allowing for a routing
strategy must:

FCA 202X/YY
(1) be identified as ‘routed’ as specified in field 33 of Table 2 of MAR 13 Annex 1 (Trading venue records) when they are routed to another qualifying trading venue; and (2) retain the same identification code for their lifetime, regardless of whether any remaining quantity is reposted on the order book of entry. Events affecting orders in financial instruments
13.4.9 R Operators of qualifying trading venues must maintain a record of the
details referred to in field 21 of Table 2 of MAR 13 Annex 1 (Trading venue records) in relation to new orders. Types of order in financial instruments
13.4.10 R Operators of qualifying trading venues must:
(1) maintain a record of the order type for each order received using their own classification as specified in field 22 of Table 2 of MAR 13 Annex 1 (Trading venue records); and (2) classify each received order either as a limit order or as a stop order as specified in field 23 of Table 2 of MAR 13 Annex 1. Prices relating to orders
13.4.11 R Operators of qualifying trading venues must maintain a record of all pricerelated details referred to in section I of Table 2 of MAR 13 Annex 1
(Trading venue records) insofar as they relate to orders.
Order instructions
13.4.12 R Operators of qualifying trading venues must maintain records of all order
instructions received for each order as specified in section J of Table 2 of MAR 13 Annex 1 (Trading venue records). Trading venue transaction identification code
13.4.13 R Operators of qualifying trading venues must maintain an individual
transaction identification code for each transaction resulting from the full or partial execution of an order as specified in field 48 of Table 2 of MAR 13 Annex 1 (Trading venue records). Trading phases and indicative auction price and volume
13.4.14 R Operators of qualifying trading venues must maintain a record of the order
details as specified in section K of Table 2 of MAR 13 Annex 1 (Trading venue records).
13.5 Records of transactions to be maintained by operators of qualifying trading
venues

FCA 202X/YY
13.5.1 R (1) Operators of qualifying trading venues must keep, for at least 5
years, records of the relevant data relating to all transactions in reportable financial instruments which are executed on their venue. (2) The relevant data is the information set out in MAR 14 Annex 1 (Details to be reported in transaction reports).
13.5.2 G Operators of qualifying trading venues should ensure they keep records of
transactions executed on behalf of a firm that is not a transaction reporting firm in accordance with MAR 14.8.
13.6 Obligation to provide records to the FCA
13.6.1 R (1) Upon written request, operators of qualifying trading venues must
provide any of the records required by MAR 13.3 and MAR 13.5 to the FCA promptly. (2) Where the FCA requests any of the records referred to in MAR 13.3, operators of qualifying trading venues must provide such details using the standards and formats prescribed in MAR 13.4 and the tables in MAR 13 Annex 1 (Trading venue records). (3) Where the FCA requests details referred to in section K of MAR 13
Annex 1, the details referred to in fields 9 and 15 to 18 of Table 2
of the annex are also to be considered as details pertaining to the order to which that request relates, and the operator must provide this information to the FCA promptly. 13 Annex Trading venue records [Editor’s note: This annex will consist of the two tables previously located in the Annex of the UK version of Commission Delegated Regulation (EU) 2017/580 supplementing MiFIR with regard to regulatory technical standards for the maintenance of relevant data relating to orders in financial instruments, which is part of UK law by virtue of the European Union (Withdrawal) Act 2018. Where amendments are to be made, underlining indicates new text and striking through indicates deleted text. Terms that are to be defined in the Handbook Glossary will be set out in future consultation.]
Table 1: standards and formats of the order details to be used when providing
the relevant order data to the FCA
13 Annex
1.1
R
SYMBOL DATA TYPE DEFINITION
…

FCA 202X/YY
{NATIONAL_ID} 35 alphanumerical characters
The identifier is that set out in
Article 6 and Annex II to
Commission Delegated Regulation
(EU) 2017/590 MAR 14 Annex 2
(National client identifiers for natural persons to be used in transaction reports).
Table 2 Details of orders: relevant data for the purposes of MAR 13.4
13 Annex
1.2
R
N. Field Content of the order details to be maintained at the disposal of the competent authority Standards and formats of the order details to be used when providing the relevant order data to competent authority upon request the FCA
Section A – Identification of the relevant parties
…
2 Direct
Electronic
Access
(DEA)
“true” where the order was submitted to the trading venue using DEA as defined in
Article 4(1)(41) of Directive 2014/65/EU
DEA.
“false” where the order was not submitted to the trading venue using DEA as defined in Article 4(1)(41) of Directive 2014/65/EU DEA. “true” “false” Client identification code … In case of aggregated orders, the flag “AGGR” as specified in Article 2(3) of this Regulation MAR 13.4.1R(4). In case of pending allocations, the flag “PNAL” as specified in Article 2(2) of this Regulation MAR 13.4.1R(2). … …

FCA 202X/YY
4 Investment decision within firm
Code used to identify the person or the algorithm within the member or, participant or client of the trading venue who is responsible for the investment decision in accordance with Article 8 of Delegated Regulation (EU) 2017/590 MAR 14.13.11R to MAR 14.13.14R inclusive. Where a natural persons person within the member or, participant or client of the trading venue is responsible for the investment decision, the person who is responsible or has primary responsibility for the investment decision must be identified with the {NATIONAL_ID} in accordance with the priorities in MAR 14.13.5R. Where an algorithm was responsible for the investment decision the field shall must be populated as set out in Article 8 of Delegated Regulation (EU) 2017/590 MAR 14.13.11R to MAR 14.13.164R inclusive. Where more than one trade or a combination of persons and algorithms are involved in the investment decision, the member, participant or client of the trading venue must determine the person or algorithm primarily responsible as specified in and populate this field in accordance with MAR 14.13.12R with the identity of that trader or algorithm. This field shall must be left blank when the investment decision was not made by a person or algorithm within the member or, participant or client of the trading venue. This field must be left blank for orders submitted by firms which are not transaction reporting firms and where the investment decision was not made by an algorithm. … {ALPHANUM-50} — Algorithms “NORE” — No one responsible within the firm 5 Execution within firm Code used to identify the person or algorithm within the member or, participant or client of the trading venue who is responsible for the execution of the transaction resulting from the order in accordance with Article 9 of Delegated Regulation (EU) 2017/590 MAR 14.13.15R to MAR 14.13.18R inclusive. … {ALPHANUM-50} — Algorithms “NORE” — No one responsible within the firm

FCA 202X/YY
Where a natural person is responsible for the execution of the transaction, the person shall must be identified by {NATIONAL_ID} in accordance with the priorities in MAR 14.13.5R. Where an algorithm is responsible for the execution of the transaction, this field shall must be populated in accordance with
Article 9 of Delegated Regulation (EU)
2017/590 MAR 14.13.15R to MAR
14.13.18R inclusive.
Where more than one person or a combination of persons and algorithms are involved in the execution of the transaction, the member or, participant or client of the trading venue shall must determine the trader or algorithm primarily responsible as specified in Article 9(4) of Delegated Regulation (EU) 2017/590 MAR 14.13.18R and populate this field with the identity of that trader or algorithm. If no person or algorithm in the firm was responsible, “NORE” must be populated. This field must be left blank for orders submitted by firms which are not transaction reporting firms and where the execution decision was not made by an algorithm. 6 Nonexecuting broker In accordance with Article 2(d) MAR 13.4.1R(1)(d). This field shall must be left blank when not relevant. …
Section B – Trading capacity and liquidity provision
7 Trading capacity
Indicates whether the order submission results from the member or, participant of the trading venue is carrying out matched principal trading under Article 4(1)(38) as defined by Directive 2014/65/EU, or dealing on its own account as defined by
Article 2(1)(5) of Regulation
600/2014/EU.
Indicates the trading capacity of the member, participant or client of the trading venue that submitted the order. This should be either matched principal trading, …

FCA 202X/YY dealing on own account, or any other capacity.
Where the order submission does not result from the member or, participant or client of the trading venue carrying out matched principal trading or dealing on its own account, the field shall must indicate that the transaction was carried out under any other capacity. 8 Liquidity provision activity Indicates whether an order is submitted to a trading venue as part of a market-making strategy pursuant to Articles 17 and 48 of Directive 2014/65/EU or UK law corresponding to these provisions market making strategy, or is submitted as part of another activity in accordance with Article 3 of this Regulation MAR 13.4.2R. … …
Section D – Validity period and order restrictions
…
11 Order restriction
… “SESR” – Good For
Closing Price Crossing
Session Valid for
Continuous Trading only
“VFCR” – Valid for
Continuous Trading only Good for Closing
Price Crossing Session
12 Validity period and time
…
Good till tim time: the date of entry and the time to that specified in the order … … …
Section G
21 New order, order modification, order cancellation, … … … Cancelled by market operations. This includes a protection …

FCA 202X/YY order rejections, partial or full execution mechanism provided for investment firms carrying out a market-making activity as laid down in Articles 17 and 48 of Directive 2014/65/EU strategy … … …
Section J – Order instructions
…
46 Strategy
Linked Order identification
The alphanumerical code used to link all connected orders that are part of a strategy pursuant to Article 7(2) MAR 13.4.7R. … … 48 Trading venue transaction identification code Alphanumerical code assigned by the trading venue to the transaction pursuant to
Article 12 of this Regulation MAR
13.4.13R.
…
…
…
Insert the following new chapter, MAR 14, after MAR 13 (Record keeping – orders and transactions). The text is all new and is not underlined. 14 Transaction reporting
14.1 Purpose, application and interpretation
Purpose
14.1.1 G (1) The purpose of this chapter is to set out the rules and requirements
for reporting transactions in reportable financial instruments.
(2) This chapter should be read in conjunction with SUP 9, SUP 17A, COBS 11.5A, MAR 13 and MAR 15. (3) Transaction reports are used by the FCA to detect, investigate and prevent market abuse.

FCA 202X/YY
(4) Transaction reports are also used by the FCA to monitor the functioning of financial markets, supervise firms and shape effective policies. Application
14.1.2 R This chapter applies to the following persons in relation to reportable
financial instruments:
(1) a transaction reporting firm;
(2) an operator of a qualifying trading venue where it has an obligation to submit a transaction report to the FCA under MAR 14.8; (3) an ARM; and (4) a person that has been verified by the FCA under the DRS Regulations to submit transaction reports. Interpretation
14.1.3 G A reference in this chapter and the related annex to ‘ISO’, followed by a
reference number, is to a standard published by the International Organization for Standardization.
14.2 Meaning of ‘transaction’
14.2.1 R For the purposes of MAR 14, a ‘transaction’ means:
(1) the conclusion of an acquisition or disposal of a reportable financial instrument; (2) a simultaneous acquisition and disposal of a reportable financial instrument where there is no change in the ownership of that reportable financial instrument but post-trade publication is required under Articles 6, 10, 20 or 21 of MiFIR; or (3) entering into or closing out a derivative contract.
14.2.2 R An acquisition referred to in MAR 14.2.1R includes:
(1) a purchase of a reportable financial instrument; and (2) an increase in the notional amount of a derivative contract.
14.2.3 R A disposal referred to in MAR 14.2.1R includes:
(1) a sale of a reportable financial instrument; and (2) a decrease in the notional amount of a derivative contract.
14.2.4 R A transaction for the purposes of MAR 14 does not include:

FCA 202X/YY
(1) securities financing transactions as defined in Article 3(11) of UK SFTR; (2) a contract arising exclusively for clearing or settlement purposes; (3) a settlement of mutual obligations between parties where the net obligation is carried forward; (4) an acquisition or disposal that is solely a result of custodial activity; (5) a post-trade assignment or novation of a derivative contract that is a reportable financial instrument where one of the parties to the derivative contract is replaced by a third party; (6) a portfolio compression; (7) the creation or redemption of units of a collective investment undertaking; (8) the exercise of a right embedded in a reportable financial instrument, or the conversion of a convertible bond and the resultant transaction in the underlying reportable financial instrument; (9) the creation, expiration or redemption of a reportable financial instrument or an exchange and tender offer of a reportable financial instrument, which occurs as a result of pre-determined contractual terms, or as a result of mandatory events which are beyond the control of the investor; (10) a decrease or increase in the notional amount of a derivative contract that is a reportable financial instrument, as a result of predetermined contractual terms or mandatory events where no investment decision by the investor takes place at the point in time of the change in the notional amount; (11) a change in the composition of an index or a basket that occurs after the execution of a transaction; (12) an acquisition under a dividend reinvestment plan; (13) an acquisition or disposal under an employee share incentive plan, or arising from the administration of an unclaimed asset trust, or of residual fractional share entitlements following corporate events or as part of shareholder reduction programmes where all the following criteria are met:
(a) the dates of acquisition or disposal are pre-determined and published in advance;

FCA 202X/YY
(b) the investment decision concerning the acquisition or disposal that is taken by the investor amounts to a choice by the investor to enter into the transaction with no ability to unilaterally vary the terms of the transaction; (c) there is a delay of at least ten working days between the investment decision and the moment of execution; and (d) the cumulative value of transactions for the particular investor in the particular reportable financial instrument in that calendar month does not exceed £1500; and (14) an acquisition or disposal that is solely a result of a transfer of collateral.
14.3 Guidance on the meaning of ‘transaction’
14.3.1 G The examples and guidance in this section are intended to provide
additional details on common examples of transactions and how they fit within the obligations to report in MAR 14. (1) The exclusions provided for in MAR 14.2 do not apply to initial public offerings or secondary public offerings or placings, or debt issuance. (2) In relation to MAR 14.2.4R(2), the clearing or settlement counterparties also do not have an obligation to submit a transaction report in this situation as delivery instructions and payment instructions are not considered to be a transaction. (3) In relation to MAR 14.2.4R(4), the following actions are not considered to be a transaction:
(a) a custodian or nominee decides to move reportable financial instruments from one depositary bank to another depositary bank; or (b) a client transfers reportable financial instruments to a custodian or nominee to hold in its custodial or nominee account. No transaction reporting obligation is generated in these cases because the movement has occurred purely for custodial purposes. (4) In relation to MAR 14.2.4R(5), the early termination of a contract due to clearing or the subsequent novation of the same contract which results in replacement of an original party to the contract does not constitute a transaction. (5) In relation to MAR 14.2.4R(9), this exclusion includes the termination of reportable financial instruments at their maturity or expiry date.

FCA 202X/YY
(6) In relation to MAR 14.2.4R(10), automatic increases or decreases of notional amounts stemming from amortisation schedules are not transactions because the conditions have been already set at the point in time of the initial contract. No new decision is made at the time of decrease or increase of a notional amount. (7) When entering into a derivative contract, closing out a long derivative or entering into a short derivative should be considered as a disposal for the transaction report and entering into a long derivative or closing out a short derivative should be considered an acquisition.
14.4 Meaning of ‘execution of a transaction’
14.4.1 R A transaction reporting firm executes a transaction where it provides any
of the following services or performs any of the following activities that result in a transaction:
(1) reception and transmission of orders in relation to one or more financial instruments; (2) execution of orders on behalf of clients; (3) dealing on own account; (4) making an investment decision in accordance with a discretionary mandate given by a client; or (5) transfers of financial instruments to or from accounts.
14.4.2 G The definition of ‘execution’ is wider than the finalisation of a transaction
on a qualifying trading venue or with a market counterparty at the end of a chain. This means it is possible that multiple transaction reporting firms may execute the same transaction.
14.4.3 G For the purposes of MAR 14.4.1R(2), the client means the immediate
client of the executing transaction reporting firm.
14.4.4 G Further guidance on receipt, transmission and execution is given in PERG
13. See for example Q13 to Q15.
14.4.5 G For the purposes of MAR 14.4.1R(4), making an investment decision
includes the situation where a transaction reporting firm has supervisory responsibility for the person responsible for the investment decision.
14.4.6 G For the purposes of MAR 14.4.1R(5):
(1) Transfers to or from accounts are reportable transactions when the transfer:
(a) results in a transaction; and

FCA 202X/YY
(b) incurs a change in ownership of the reportable financial instrument. (2) A transfer between one account to another account for the same client will not be reportable as no change in ownership would occur. However, transfers from a sole client account to a joint client account which result in a transaction would be as these transfers incur a change in ownership. (3) This principle also applies to:
(a) transfers from joint portfolios to sole portfolios; (b) distributions from trusts to beneficiaries; (c) transfers from parents holding accounts for minors when the minors reach majority; (d) transfers (or sales back) to a company name owned by an individual from said individual; (e) transfers to charity and resulting from auctions; or (f) from a transaction reporting firm matching a buyer with a seller. (4) Transfers in relation to movements involved in managing a probate for a deceased client or inheritances, auctions or gifts are all reportable since these transactions constitute acquisitions and disposals where a change of ownership occurs, even though there is no price, including the change of ownership of a securities account from one beneficiary to another.
14.4.7 R Where a transaction reporting firm hits its own order on the order book of
a trading venue, this transaction is reportable even though no change in ownership occurs.
14.5 Transaction reporting: when?
14.5.1 R A transaction reporting firm which executes a transaction in a reportable
financial instrument must report complete and accurate details of such transaction to the FCA as quickly as possible, and no later than 23:59:59 UTC of the following working day.
14.5.2 G The obligation in MAR 14.5.1R applies to transactions in reportable
financial instruments irrespective of whether such transactions are carried out on a qualifying trading venue.
14.5.3 G A transaction reporting firm should use the financial instrument reference
data published by the FCA to determine whether an instrument is a reportable financial instrument. Where an instrument or any underlying instrument is not present in the financial instrument reference data within

FCA 202X/YY
7 days of the execution of a transaction, a transaction reporting firm may conclude that the instrument is not a reportable financial instrument.
14.5.4 G (1) Where the transaction relates to an OTC derivative, the transaction
reporting firm should compare the financial instrument reference data for that derivative with the financial instrument reference data published by the FCA. (2) Where the OTC derivative shares the same instrument classification (field 3) and applicable derivative fields (fields 20-
37) to an instrument in the financial reference data published by
the FCA, it should be considered to be a reportable financial instrument. (3) For the purpose of determining whether an instrument is a reportable financial instrument, the guidance set out in the ESMA opinion, dated 22 May 2017, titled “OTC derivatives traded on a trading venue” (which constitutes FCA guidance by virtue of the guidance “Brexit: our approach to EU non-legislative materials”) does not apply.
14.5.5 G A transaction reporting firm may elect to submit a transaction report in
the following situations:
(1) Transactions in reportable financial instruments that have not yet been admitted to trading and included in the list of financial information reference data published by the FCA but for which a request for admission has been made. (2) Transactions in reportable financial instruments that would otherwise fall under the exceptions in MAR 14.2.4R(9) and MAR 14.2.4R(13). (3) Transactions in financial instruments where the underlying is an index composed of multiple instruments and the transaction reporting firm has not confirmed that at least one of those instruments is traded on a qualifying trading venue.
14.6 Transaction reporting: what?
14.6.1 R A transaction report required to be submitted to the FCA by MAR 14.5
must:
(1) include all details referred to in Table 2 of MAR 14 Annex 1 that relate to that transaction in the reportable financial instrument; (2) be submitted in accordance with the standards and formats specified in MAR 14 Annex 1 and MAR 14 Annex 2; and (3) be submitted to the FCA in:
(a) an electronic and machine-readable form; and

FCA 202X/YY
(b) a common XML template in accordance with the ISO 20022 methodology.
14.7 Transaction reporting: who?
14.7.1 R A transaction reporting firm that executes a transaction in a reportable
financial instrument must submit a transaction report unless MAR 14.10 applies.
14.7.2 G Where a transaction reporting firm has an obligation to submit a
transaction report, it may submit the transaction report directly to the FCA or through an ARM or a person verified by the FCA under the DRS Regulations.
14.8 Transactions executed on qualifying trading venues by firms not subject
to MAR 14
14.8.1 R The operator of a qualifying trading venue must report to the FCA details
of transactions in reportable financial instruments traded on its platform which are executed through its systems by a member, participant or client of the qualifying trading venue that is not a transaction reporting firm. This includes negotiated transactions.
14.8.2 R Transaction reports required under MAR 14.8.1R must be submitted in
accordance with the requirements of MAR 14.5 and MAR 14.6.
14.8.3 R The operator of a qualifying trading venue must not provide a service
triggering the obligation to submit a transaction report under MAR 14.8.1R prior to obtaining the legal entity identifier from that firm.
14.8.4 G Where the member, participant or client of the qualifying trading venue
under MAR 14.8.1R is a natural person, the qualifying trading venue should use their own LEI for the executing entity field.
14.8.5 R The operator of a qualifying trading venue must, at all times, maintain
adequate resources and have back-up facilities in place to offer and maintain its ability to submit transaction reports under MAR 14.8.1R.
14.9 Trade repositories approved as ARMs
14.9.1 R The obligations of a transaction reporting firm under MAR 14.5 will be
considered met where:
(1) the transaction reporting firm has reported its executed transactions to a trade repository in accordance with Article 9 of EMIR; (2) that trade repository has been approved as an ARM; (3) the transaction reporting firm provides the trade repository with the information required by MAR 14.6; and

FCA 202X/YY
(4) the trade repository reports the transactions to the FCA within the time limit specified in MAR 14.5.
14.10 Conditional single-sided reporting
14.10.1 R When one transaction reporting firm (the sending firm) provides any of
the services or performs any of the activities set out in MAR 14.4.1R that result in a transaction with another transaction reporting firm (the receiving firm), the sending firm does not need to submit a transaction report for that transaction where the following conditions are met:
(1) both the sending firm and the receiving firm are transaction reporting firms; (2) the sending firm provides the information specified in MAR 14.10.2R to the receiving firm; and (3) a written agreement exists between the sending firm and the receiving firm, specifying at least the time limit for the provision of the information specified in MAR 14.10.2R.
14.10.2 R The sending firm must provide the following information to the receiving
firm (where applicable):
(1) the designation and details of the client of the sending firm for the purposes of the order; (2) the designation and details of the decision maker for the client of the sending firm where the investment decision is made under a power of representation; (3) the trading capacity of the sending firm; and (4) the LEI for the sending firm.
14.10.3 R Where there are multiple receiving firms and sending firms in relation to a
transaction, the client details referred to in MAR 14.10.2R(1) must be the details of the client of the first sending firm or the details of the first sending firm.
14.10.4 R Where a transaction is aggregated for several clients, the sending firm
must provide the receiving firm with the information in MAR 14.10.2R(1) for each client.
14.10.5 R Where a sending firm complies with the requirements of MAR 14.10.1R,
when it executes a transaction, it is not considered to have executed a transaction for the purposes of MAR 14.7.1R and does not need to submit a transaction report for that transaction.
14.10.6 G Where a sending firm has failed to meet the conditions of MAR 14.10.1R
in relation to a transaction the sending firm should submit a transaction report.

FCA 202X/YY
14.10.7 G The provisions of MAR 14.10 can be used when a sending firm is acting in
its capacity as such, including on a matched principal trading basis.
14.10.8 G The agreement required by MAR 14.10.1R(3) should be in place before the
sending firm transacts with the receiving firm.
14.11 Responsibility for reports
14.11.1 R Subject to MAR 14.11.2R and MAR 14.12, transaction reporting firms are
responsible for the completeness, accuracy and timely submission of the transaction reports which are submitted to the FCA.
14.11.2 R (1) Where a transaction reporting firm uses an ARM or person verified
by the FCA under the DRS Regulations to comply with its obligations to report transactions under MAR 14, that transaction reporting firm is not responsible for failures in the completeness, accuracy or timely submission of the reports which are attributable to the ARM or person verified by the FCA under the DRS Regulations. (2) In those cases, and subject to data reporting service rules (within the meaning of regulation 2(1) of the DRS Regulations) the ARM or person verified by the FCA under the DRS Regulations is responsible for those failures.
14.12 Responsibility for reports in conditional single-sided reporting
14.12.1 R Sending firms are responsible for the accuracy and completeness of the
information provided to the receiving firm under MAR 14.10.2R and used in a transaction report, unless the error in a transaction report can be attributed to an action of a receiving firm.
14.12.2 R Where a receiving firm uses information received from a sending firm in a
transaction report, the receiving firm is not responsible for failures in the accuracy and completeness of that information.
14.13 Additional provisions in relation to transaction reporting fields
Transaction reference number
14.13.1 R The transaction reference number required under field 2 of Table 2 of
MAR 14 Annex 1 must be generated by the transaction reporting firm that executed the transaction.
14.13.2 G Where the transaction reporting firm is using an ARM, the transaction
reference number must be unique and generated by the transaction reporting firm and not the ARM. Identification of the transaction reporting firm executing a transaction
14.13.3 R A transaction reporting firm which executes a transaction in a reportable
financial instrument must ensure that it is identified with a validated,

FCA 202X/YY issued and duly renewed ISO 17442 legal entity identifier code in the transaction report submitted for that transaction.
14.13.4 R A transaction reporting firm which executes a transaction must ensure that
the reference data related to its legal entity identifier is renewed in accordance with the terms of any of the accredited local operating units of the Global Legal Entity Identifier System. Designation to identify natural persons
14.13.5 R (1) A transaction report must identify a natural person using the
designation resulting from the concatenation of the ISO 3166-1 alpha-2 (2 letter country code) of the nationality of the person, followed by the national client identifier listed in MAR 14 Annex 2 based on the nationality of the person. (2) A transaction report must assign the national client identifier referred to in (1) in accordance with the priority levels provided in MAR 14 Annex 2 using the highest priority identifier that a person has regardless of whether that identifier is already known to the transaction reporting firm. (3) Where a natural person is a national of the UK and of an EEA State, or is a national of more than one EEA State, the transaction report must use the country code of the first nationality when sorted alphabetically by its ISO 3166-1 alpha-2 code and the identifier of that nationality assigned in accordance with (1). (4) Where a natural person is not a national of the UK or any EEA State, the transaction report must use the highest priority identifier in accordance with the field referring to ‘all other countries’ provided in MAR 14 Annex 2. (5) Where a natural person is a national of both the UK and a non-EEA State, or is a national of both an EEA State and a non-EEA State other than the UK, the transaction report must use the country code of the UK or, as the case may be, the EEA State nationality and the highest priority identifier of that other nationality assigned in accordance with (1). (6) Where a natural person is a national of more than one non-EEA State other than the UK, the transaction report must use the country code of the first nationality when sorted alphabetically by its ISO 3166-1 alpha-2 code along with the highest priority identifier for ‘all other countries’ in accordance with MAR 14
Annex 2.
(7) When identifying a natural person from any of:
(a) the Isle of Man;
(b) the Channel Islands;

FCA 202X/YY
(c) Gibraltar; or
(d) any other British overseas territory, a transaction reporting firm must use the country code of that country along with the highest priority identifier for ‘all other countries’ in accordance with MAR 14 Annex 2.
14.13.6 R Where the identifier assigned in accordance with MAR 14.13.5R and MAR
14 Annex 2 refers to ‘CONCAT’, the transaction report must identify the natural person using the concatenation of the following elements in the following order:
(1) the date of birth of the person in the format YYYYMMDD; (2) the first 5 characters of the first name; and (3) the first 5 characters of the surname.
14.13.7 R For the purposes of MAR 14.13.6R:
(1) prefixes to names should be excluded and first names and surnames shorter than 5 characters should be appended by ‘#’ so as to ensure that references to names and surnames in accordance with MAR 14.13.6R contain 5 characters. All characters should be in upper case. No apostrophes, accents, hyphens, punctuation marks or spaces should be used; (2) the transaction reporting firm should ensure that the spelling of the person’s full name is correct and does not make use of short forms and abbreviations; (3) any prefixes to the names that denote titles, positions, professions or academic qualifications should be removed. This includes: atty, coach, dame, dr, fr, gov, honorable, madam(e), maid, master, miss, monsieur, mr, mrs, ms, mx, ofc, ph.d, pres, prof, rev, sir, am, auf, auf dem, aus der, d, da, de, de l’, del, de la, de le, di, do, dos, du, im, la, le, mac, mc, mhac, mhíc, mhic giolla, mic, ni, ní, níc, o, ó, ua, ui, uí, van, van de, van den, van der, vom, von, von dem, von den, von der (this list is not case sensitive or exhaustive); and (4) prefixes to surnames that are not included in MAR 14.13.7R(3) above, or prefixes attached to the name such as McDonald, MacChrystal, O’Brian, O’Neal, should not be removed (this list is not case sensitive or exhaustive), but note that the apostrophes are to be removed as in (1). Details of the identity of the client and identifier and details for the decision maker
14.13.8 R A transaction report relating to a transaction executed on behalf of a client
who is a natural person must include the full name and date of birth of the

FCA 202X/YY client as specified in fields 8, 9, 10, 17, 18 and 19 of Table 2 of MAR 14
Annex 1.
14.13.9 R Where the client is not the person taking the investment decision in
relation to that transaction, the transaction report must identify the person taking the investment decision on behalf of the client, as specified in fields 12 to 15 for the buyer and in fields 21 to 24 for the seller in Table 2 of MAR 14 Annex 1.
14.13.10 G (1) The client is the immediate client of the executing entity. It can be
a legal entity or a natural person.
(2) Where executing a transaction on behalf of a trust, a transaction reporting firm may report the client as either the trust (using an LEI) or the beneficiary of that trust (using a national identifier, assigned in accordance with MAR 14.13.5R). The transaction reporting firm is not required to have established the trust arrangements before doing so. Identification of person or algorithm within a transaction reporting firm responsible for the investment decision
14.13.11 R Where a person or algorithm within a transaction reporting firm makes the
investment decision to acquire or dispose of a reportable financial instrument, that person or algorithm must be identified as specified in field 51 of Table 2 of MAR 14 Annex 1. The transaction reporting firm must only identify such a person or algorithm where that investment decision is made either on behalf of the transaction reporting firm itself, or on behalf of a client in accordance with a discretionary mandate given to it by the client.
14.13.12 R (1) Where more than one person or algorithm within the transaction
reporting firm takes the investment decision, the transaction reporting firm must determine the person taking the primary responsibility for that decision. (2) The transaction reporting firm must establish criteria for determining the person taking primary responsibility for the investment decision.
14.13.13 G The criteria to determine who is responsible for an investment decision are
at the discretion of the transaction reporting firm. However, the person assigned primary responsibility for the decision by such criteria would be expected to have a level of practical involvement in the decisions. It may not be appropriate to assign responsibility to members of the senior management of the firm who have limited practical involvement in the relevant decisions at a transactional level.
14.13.14 R Where an algorithm within the transaction reporting firm is responsible
for the investment decision in accordance with MAR 14.13.11R, the transaction reporting firm must assign a designation for identifying the algorithm in a transaction report. That designation must be:

FCA 202X/YY
(1) unique for each set of code or trading strategy that constitutes the algorithm, regardless of the reportable financial instruments or markets that the algorithm applies to; (2) used consistently when referring to the algorithm or version of the algorithm once assigned to it; and (3) unique over time. Identification of person or algorithm responsible for execution of a transaction
14.13.15 R Where a person or algorithm within the transaction reporting firm which
executes a transaction determines:
(1) which trading venue, systematic internaliser or organised trading platform located outside the United Kingdom to access; (2) which firms to transmit orders to; or (3) any conditions related to the execution of an order, that person or algorithm must be identified in field 52 of Table 2 of MAR 14 Annex 1.
14.13.16 R Where a person within the transaction reporting firm is responsible for the
execution of the transaction, the transaction reporting firm must assign a designation for identifying that person in a transaction report in accordance with MAR 14.13.5R to MAR 14.13.7R inclusive.
14.13.17 R Where an algorithm within the transaction reporting firm is responsible
for the execution of the transaction, the transaction reporting firm must assign a designation for identifying the algorithm in accordance with MAR 14.13.16R.
14.13.18 R (1) Where more than one person or algorithm within the transaction
reporting firm takes the execution decision, the transaction reporting firm must determine the person taking the primary responsibility for that decision. (2) The transaction reporting firm must establish criteria for determining the person or algorithm taking primary responsibility for the execution decision.
14.13.19 G The criteria to determine who is responsible for an execution decision are
at the discretion of the transaction reporting firm. However, the person assigned primary responsibility for the decision by such criteria would be expected to have a level of practical involvement in the decisions. It may not be appropriate to assign responsibility to members of the senior management of the firm who have limited practical involvement in the relevant decisions at a transactional level. Reporting a package transaction

FCA 202X/YY
14.13.20 R For the purposes of this chapter, a package transaction means either:
(1) a transaction involving two or more reportable financial instruments; or (2) two or more transactions negotiated together as a result of a single economic agreement.
14.13.21 R Where a transaction reporting firm executes a package transaction, the
transaction reporting firm must submit a separate transaction report for each reportable financial instrument or transaction separately and must link these transaction reports with an identifier as specified in field 37 of
Table 2 of MAR 14 Annex 1.
G A package transaction may include reportable financial instruments and instruments that are not reportable financial instruments. In these cases, a transaction reporting firm is only required to submit transaction reports for the reportable financial instruments in that package transaction. Reporting a transaction in a reportable financial instrument where the underlying is a basket
14.13.22 R (1) Where the transaction relates to a reportable financial instrument
where the underlying is a basket of financial instruments, a transaction reporting firm must include the ISIN of each constituent of the basket that is admitted to trading or is traded on a qualifying trading venue in the transaction report. (2) Field 45 of MAR 14 Annex 1 must be reported as many times as necessary to list all reportable financial instruments in the basket.
14.13.23 G Where a basket includes financial instruments not included in the list of
financial instrument reference data published by the FCA, the transaction reporting firm may include ISINs for these financial instruments in the relevant transaction report. This will not cause the transaction report to be rejected. Provision of service to a client without ID
14.13.24 R (1) A transaction reporting firm must not provide a service triggering
the obligation to submit a transaction report for a transaction entered into on behalf of a client prior to obtaining the legal entity identifier or client details from that client. (2) Where the identifier is a legal entity identifier, the transaction reporting firm must ensure that the length and construction of the code are compliant with the ISO 17442 standard and that the code is included in the Global LEI system and pertains to the client concerned. Reporting transactions executed by branches

FCA 202X/YY
14.13.25 R Where a transaction reporting firm executes a transaction wholly or partly
through its branch, it must report the transaction to the FCA.
14.13.26 G A branch or branches and the head office are treated as a single entity for
reporting purposes. The branch should report the client of the firm (which may be its client or the client of another branch or the head office) and the counterparty of the firm. Where the branch is sending the order to another branch or its head office, the counterparty will be the counterparty of the other branch or head office.
14.13.27 G Where a transaction is executed through a non-UK branch of a transaction
reporting firm, it is reportable since the branch is regarded as part of the same authorised entity.
14.13.28 G Where the branch of a transaction reporting firm received the order from a
client or made an investment decision for a client in accordance with a discretionary mandate given to it by the client, that transaction reporting firm is deemed to have executed a transaction.
14.13.29 G Where the branch of a transaction reporting firm has supervisory
responsibility for the person responsible for the investment decision concerned that results in the execution of a transaction, the transaction reporting firm should submit a transaction report.
14.13.30 G Where the branch of a transaction reporting firm has supervisory
responsibility for the person responsible for execution of a transaction, the transaction reporting firm must submit a transaction report.
14.13.31 G Where the branch of a transaction reporting firm has executed a
transaction on a trading venue or an organised trading platform located outside the United Kingdom using the branch’s membership of that trading venue or an organised trading platform, the transaction reporting firm must submit a transaction report. Trading capacity
14.13.32 R The population of this field must be consistent with the population of the
buyer/seller field in the transaction report:
(1) For a trading capacity of DEAL, either the buyer or seller must be the LEI of the executing entity. (2) For a trading capacity of AOTC/MTCH, the buyer and seller field must not be populated with the LEI of the executing entity. (3) For a trading capacity of MTCH, the buyer and seller can be 2 clients of the transaction reporting firm or a client and a market counterparty. Trading venue transaction identification code

FCA 202X/YY
14.13.33 R As specified in field 3 of Table 2 of MAR 14 Annex 1, operators of
qualifying trading venues must:
(1) maintain an individual transaction identification code for each transaction resulting from the full or partial execution of an order; and (2) provide this code to the parties to the transaction, where they are a transaction reporting firm. Submitting entity identification code
14.13.34 R The submitting entity identification code (field 6) must be reported as
follows:
Person who submits the transaction report
Submitting entity identification code
The transaction reporting firm that executed the transaction The LEI of that transaction reporting firm A receiving firm when reporting a transaction that meets the requirements of MAR 14.10 The LEI of that receiving firm A qualifying trading venue under MAR 14.8 The LEI of the operator of the qualifying trading venue An ARM The LEI of the ARM A trading venue that has been verified by the FCA under the DRS Regulations to submit transaction reports The LEI of the operator of the trading venue
14.14 Methods and arrangements for reporting financial transactions
14.14.1 R

The methods and arrangements by which transaction reports are generated and submitted by transaction reporting firms and qualifying trading venues in accordance with MAR 14.8 must include:
(1) systems to ensure the security and confidentiality of the data reported; (2) mechanisms for authenticating the source of the transaction report; (3) mechanisms to minimise the risk of data corruption;

FCA 202X/YY
(4) precautionary measures to enable the timely resumption of reporting in the case of a failure of the reporting system; (5) mechanisms for identifying errors and omissions within transaction reports; (6) mechanisms to avoid the reporting of duplicate transaction reports; (7) subject to MAR 14.5.5R, mechanisms to avoid reporting any transaction where there is no obligation to report under MAR 14 either because:
(a) there is no transaction within the meaning of MAR 14.4; or (b) subject to MAR 14.5.5R, the instrument which is the subject of the transaction concerned is not a reportable financial instrument; and (8) mechanisms for identifying unreported transactions for which there is an obligation to report under MAR 14.
14.14.2 G Unreported transactions in MAR 14.14.1R(8) include, but are not limited
to, cases where transaction reports that have been rejected by the FCA have not been successfully resubmitted.
14.14.3 R Transaction reporting firms must have arrangements in place to ensure
that their transaction reports, when viewed collectively, reflect all changes in their position and in the position of their clients in the reportable financial instruments concerned at the time transactions in the reportable financial instruments are executed.
14.14.4 G The obligation in MAR 14.14.3R applies to all transaction reporting firms
regardless of whether they submit the transaction reports to the FCA directly or through an ARM.
14.14.5 G The obligation in MAR 14.14.3R does not include where a sending firm
complies with MAR 14.10. Where a sending firm complies with the requirements of MAR 14.10 it is not considered to have executed a transaction and is not required to submit a transaction report.
14.15 Reconciliation, cancellations and amendments of transaction reports
Reconciliation of transaction reports
14.15.1 R (1) Transaction reporting firms and qualifying trading venues must
have arrangements in place to ensure that transaction reports they are responsible for are complete and accurate. (2) Those arrangements must include regular testing of their reporting process and regular reconciliation of their records of transactions

FCA 202X/YY they have executed against a sample of the transaction reports that they have submitted to the FCA.
14.15.2 G For the purposes of reconciliation testing:
(1) A transaction reporting firm should request data samples of its transaction reports from the FCA via the market data processor system. (2) Where a qualifying trading venue submitting transaction reports under MAR 14.8 is unable to access the market data processor system, it should reconcile the information contained in the transaction reports it has submitted to the FCA against its own records. Errors, omissions, amendments and cancellations of transaction reports
14.15.3 R Where a transaction reporting firm or an operator of a qualifying trading
venue that has submitted a transaction report under MAR 14.8:
(1) becomes aware of any error or omission within a transaction report submitted to the FCA, it must cancel that transaction report and submit a new transaction report including the correct information for that transaction; (2) becomes aware of a failure to submit a transaction report including any failure to resubmit a rejected transaction report for a transaction that is reportable, it must submit a transaction report for the transaction; or (3) becomes aware, subject to MAR 14.5.5R, the reporting of a transaction for which there is no obligation to report, it must cancel the transaction report.
14.15.4 R Where a transaction reporting firm submits or cancels a transaction report
under MAR 14.15.3R, it must notify the FCA promptly.
14.15.5 G Where a transaction reporting firm or operator of a qualifying trading
venue has used an ARM to submit its transaction reports, the ARM will be responsible for cancelling the incorrect transaction reports and submitting a new transaction report.
14.15.6 G To cancel a transaction report under MAR 14.15.3R, a transaction
reporting firm or operator of a qualifying trading venue should submit a new transaction report for the transaction to the FCA, providing only the data in fields 1, 2, 4 and 6 in Table 2 of MAR 14 Annex 1. Field 1 should be populated with ‘CANC’. If any more fields are populated, the submission will be rejected.
14.15.7 R (1) After cancelling the transaction report containing the errors or
omissions, the transaction reporting firm or operator of a

FCA 202X/YY qualifying trading venue must submit a new and correct transaction report to the FCA promptly. (2) The replacement transaction report must include all the fields that are applicable to the transaction reported, and field 1 must be populated with ‘NEWT’. (3) The replacement transaction report must include the date and time of the original transaction, not the date and time the corrected report was submitted.
14.15.8 G (1) If a transaction reporting firm or qualifying trading venue tries to
submit a replacement transaction report without first submitting a report cancelling the original erroneous transaction report, the replacement transaction report will be rejected by the FCA. (2) Where a further error in a transaction report is identified, a transaction reporting firm or qualifying trading venue should cancel the replacement transaction report before resubmitting a further replacement transaction report. (3) A cancellation may be made by a different entity to the one that submitted the original erroneous report. For example, a transaction reporting firm that used an ARM to submit the original report may cancel the report itself or use another ARM to cancel and resubmit the affected transaction report.
14.15.9 G (1) Where a transaction reporting firm makes a post trade publication
in relation to a transaction and cancels the post-trade publication before any transaction report is made, then no transaction report is required to be made. (2) Where a transaction reporting firm makes a post-trade publication that is amended before any transaction report is submitted to the FCA, the transaction report should reflect the information on the last post-trade publication. 14 Annex Details to be reported in transaction reports [Editor’s note: The table titled ‘Table 1 Legend for Table 2’, which was previously located in
Annex 1 of the UK version of Commission Delegated Regulation (EU) 2017/590
supplementing MIFIR with regard to with regard to regulatory technical standards for the reporting of transactions to competent authorities, which is part of UK law by virtue of the European Union (Withdrawal) Act 2018, is inserted into this annex. Where amendments are to be made to the content of the table, underlining indicates new text and striking through indicates deleted text. Terms that are to be defined in the Handbook Glossary will be set out in future consultation.]
Table 1: Legend for Table 2 (Format and standards to be used for reporting)

FCA 202X/YY
14 Annex
1.1
R
SYMBOL DATA TYPE DEFINITION
…
{NATIONAL_ID} 35 alphanumerical characters
The identifier is derived in accordance with Article 6 and the Table of Annex II set out in MAR 14 Annex 2 (National client identifiers for natural persons to be used in transaction reports). Insert the following table into MAR 14 Annex 1. The text is all new and is not underlined.
Table 2: Details to be reported in transaction reports
14 Annex
1.2
R
N Field Content to be reported Format and standards to be used for reporting 1 Report status Indication as to whether the transaction report is new or a cancellation. “NEWT” - New “CANC” - Cancellation 2 Transaction reference number (TRN) Identification number that is unique to the executing entity for each transaction report. Where, pursuant to MAR 14.8, a qualifying trading venue submits a transaction report on behalf of a firm that is not a transaction reporting firm, the qualifying trading venue must populate this field with a number that has been internally generated by the trading venue and that is unique for each transaction report submitted by the trading venue. The TRN must not be reused except where the original transaction report is being corrected or cancelled. In this case, the same TRN must be used for the {ALPHANUM-52}

FCA 202X/YY replacement report as for the original report that is being replaced. 3 Trading venue transaction identification code This is a number generated by qualifying trading venues and provided to both the buying and the selling parties in accordance with MAR 14.13.33R. This field is only required for the market side of a transaction executed on a qualifying trading venue. {ALPHANUM-52} 4 Executing entity identification code Code used to identify the entity executing the transaction. Where a qualifying trading venue is submitting a report under MAR 14.8 for a natural person the qualifying trading venue must use their LEI to populate this field. {LEI} 5 Executing entity is a transaction reporting firm “True” must be populated where the executing entity identified in field 4 of this table is a transaction reporting firm. “False” must be populated where the executing entity identified in field 4 of this table is not a transaction reporting firm. “true”- yes “false”- no 6 Submitting entity identification code Code used to identify the entity submitting the transaction report to the FCA in accordance with MAR 14.13.34R. {LEI} Buyer details

For joint accounts, fields 7-11 must be repeated for each buyer.
Where the transaction for a buyer has met the conditions set out in MAR 14.10, the
information in fields 7-11 must be populated by the receiving firm in the receiving firm’s report from the information provided by the sending firm. 7 Buyer identification code Code used to identify the acquirer of the reportable financial instrument. Where the acquirer is a legal entity, the LEI code of the acquirer must be used. Where the acquirer is a UK branch, it must be identified with the LEI of its head office, even if it may be considered eligible for an LEI. {LEI} {MIC} {NATIONAL_ID} “INTC”

FCA 202X/YY
Where the acquirer is a non-legal entity, the identifier specified in MAR 14.13.5R to MAR 14.13.7R must be used. Where the transaction was executed on a UK trading venue or on an organised trading platform outside of the United Kingdom and where the identity of the acquirer is not disclosed prior to execution, the MIC code of the UK trading venue or of the organised trading platform outside of the United Kingdom must be used. Where the acquirer is acting as a systematic internaliser (SI), the LEI code of the SI must be used. “INTC” must be used to designate an aggregate client account within the transaction reporting firm in order to report a transfer into or out of that account with an associated allocation to the individual client(s) out of or into that account respectively. In the case of options and swaptions, the buyer is the counterparty that holds the right to exercise the option and the seller is the counterparty that sells the option and receives a premium. In the case of futures and forwards, the buyer is the counterparty buying the instrument and the seller is the counterparty selling the instrument. In the case of swaps relating to securities, the buyer is the counterparty that gets the risk of price movement of the underlying security and receives the security amount. The seller is the counterparty paying the security amount. In the case of swaps relating to interest rates or inflation indices, the buyer is the counterparty paying the fixed rate. The seller is the counterparty receiving the fixed rate. In the case of basis swaps (float-to-float interest rate swaps), the buyer is the counterparty that pays the spread and the seller is the counterparty that receives the spread.

FCA 202X/YY
In the case of swaps relating to dividends, the buyer is the counterparty receiving the equivalent actual dividend payments. The seller is the counterparty paying the dividend and receiving the fixed rate. In the case of derivative instruments for the transfer of credit risk except options and swaptions, the buyer is the counterparty buying the protection. The seller is the counterparty selling the protection. In the case of derivative contracts relating to commodities, the buyer is the counterparty that receives the commodity specified in the report and the seller is the counterparty delivering the commodity. In the case of forward rate agreements, the buyer is the counterparty paying the fixed rate and the seller is the counterparty receiving the fixed rate. In the case of contracts for difference and spreadbets, the buyer is the counterparty which goes long on the contract, and the seller is the counterparty that goes short on the contract. For an increase in notional, the buyer is the same as the acquirer of the reportable financial instrument in the original transaction and the seller is the same as the disposer of the reportable financial instrument in the original transaction. For a decrease in notional, the buyer is the same as the disposer of the reportable financial instrument in the original transaction and the seller is the same as the acquirer of the reportable financial instrument in the original transaction. The FCA is interested in the underlying client for market abuse purposes rather than the owner of the legal title. Therefore, where there is a movement that results in a change in ownership for a client, the client should be reported as the buyer/seller as appropriate rather than

FCA 202X/YY any custodian/nominee that may hold the legal title.
With the exception of transaction reports submitted by a receiving firm, transaction reporting firms should report their direct client. The transaction reporting firm is not expected to look behind their client or counterparty to try to determine the ultimate client. For example, where a transaction reporting firm does not have the details of the underlying client(s), it is not required to look through the trust to the underlying client(s) of the trust but just report the trust as the buyer/seller (which should be identified by its LEI). Where a transaction reporting firm does have the details of the underlying client(s) of the trust it can choose to report the underlying client(s) (which is the beneficiary rather than the trustee) or report the LEI of the trust. Additional details

Fields 8-15 are only applicable if the buyer is a client.
Fields 9-11 are only applicable if the buyer is a natural person.
8 Client indicator for the buyer
This field should be populated “TRUE” where the buyer is a client of the executing entity. This field should be populated “FALSE” where the buyer is not a client of the executing entity. “true” “false” 9 Buyer - first name(s) Full first name(s) of the buyer. Where the buyer has more than one first name, all names must be included in this field separated by a comma. First names include middle names. {ALPHANUM-140} 10 Buyer - surname(s) Full surname(s) of the buyer. Where the buyer has more than one surname, all surnames must be included in this field separated by a comma. {ALPHANUM-140}

FCA 202X/YY
11 Buyer - date of birth
Date of birth of the buyer {DATEFORMAT}
Buyer decision maker

Fields 12-15 are only applicable if the decision maker acts under a power of
representation.
12 Buyer decision maker code
Code used to identify the person who makes the decision to acquire the reportable financial instrument. Where the decision is made by an investment firm, this field must be populated with the identity of the investment firm rather than the individual within the firm making the investment decision. Where the decision maker is a legal entity, the LEI must be used. Where the decision maker is a non-legal entity, the identifier specified in MAR 14.13.16R must be used. {LEI} {NATIONAL_ID} Buyer decision maker details
Fields 13-15 are only applicable if the decision maker is a natural person.
13 Buy decision maker - first name(s)
Full first name(s) of the decision maker for the buyer. Where the decision maker for the buyer has more than one first name, all names must be included in this field separated by a comma. {ALPHANUM-140} 14 Buy decision maker - surname(s) Full surname(s) of the decision maker for the buyer. Where the decision maker for the buyer has more than one surname, all surnames must be included in this field separated by a comma. {ALPHANUM-140} 15 Buy decision maker - date of birth Date of birth of the decision maker for the buyer. {DATEFORMAT} Seller details and decision maker
For joint accounts, fields 16-19 must be repeated for each seller.
Where the transaction for a seller has met the conditions set out in MAR 14.10R, the
information in fields 15-23 must be populated by the receiving firm in the receiving firm’s report from the information received from the sending firm.

FCA 202X/YY
16 Seller identification code
Code used to identify the disposer of the reportable financial instrument. Where the disposer is a legal entity, the LEI code of the disposer must be used. Where the acquirer is a UK branch, it must be identified with the LEI of its head office, even if it may be considered eligible for an LEI. Where the disposer is a non-legal entity, the identifier specified in MAR 14.13.5R to MAR 14.13.7R must be used. Where the transaction was executed on a UK trading venue or on an organised trading platform outside of the United Kingdom and where the identity of the disposer is not disclosed prior to execution, the MIC code of the UK trading venue or of the organised trading platform outside of the United Kingdom must be used. Where the disposer is an SI, the LEI code of the SI must be used. “INTC” must be used to designate an aggregate client account within the transaction reporting firm in order to report a transfer into or out of that account with an associated allocation to the individual client(s) out of or into that account respectively. In the case of options and swaptions, the buyer is the counterparty that holds the right to exercise the option and the seller is the counterparty that sells the option and receives a premium. In the case of futures and forwards, the buyer is the counterparty buying the instrument and the seller is the counterparty selling the instrument. In the case of swaps relating to securities, the buyer is the counterparty that gets the risk of price movement of the underlying security and receives the security amount. The seller is the counterparty paying the security amount. In the case of swaps relating to interest rates or inflation indices, the buyer is the {LEI} {MIC} {NATIONAL_ID} “INTC”

FCA 202X/YY counterparty paying the fixed rate. The seller is the counterparty receiving the fixed rate. In the case of basis swaps (float-to-float interest rate swaps), the buyer is the counterparty that pays the spread and the seller is the counterparty that receives the spread. In the case of swaps relating to dividends, the buyer is the counterparty receiving the equivalent actual dividend payments. The seller is the counterparty paying the dividend and receiving the fixed rate. In the case of derivative instruments for the transfer of credit risk except options and swaptions, the buyer is the counterparty buying the protection. The seller is the counterparty selling the protection. In the case of derivative contracts relating to commodities, the buyer is the counterparty that receives the commodity specified in the report and the seller is the counterparty delivering the commodity. In the case of forward rate agreements, the buyer is the counterparty paying the fixed rate and the seller is the counterparty receiving the fixed rate. In the case of contracts for difference and spreadbets, the buyer is the counterparty which goes long on the contract, and the seller is the counterparty that goes short on the contract. For an increase in notional, the buyer is the same as the acquirer of the reportable financial instrument in the original transaction and the seller is the same as the disposer of the reportable financial instrument in the original transaction. For a decrease in notional, the buyer is the same as the disposer of the reportable financial instrument in the original transaction and the seller is the same as the acquirer of the reportable financial instrument in the original transaction.

FCA 202X/YY
The FCA is interested in the underlying client for market abuse purposes rather than the owner of the legal title. Therefore, where there is a movement that results in a change in ownership for a client, the client should be reported as the buyer/seller as appropriate rather than any custodian/nominee that may hold the legal title. With the exception of transaction reports submitted by a receiving firm, transaction reporting firms should report their direct client. The transaction reporting firm is not expected to look behind their client or counterparty to try to determine the ultimate client. For example, where a transaction reporting firm does not have the details of the underlying client(s), it is not required to look through the trust to the underlying client(s) of the trust but just report the trust as the buyer/seller (which should be identified by its LEI). Where a transaction reporting firm does have the details of the underlying client(s) of the trust it can choose to report the underlying client(s) (which is the beneficiary rather than the trustee) or report the LEI of the trust. Fields 17 to 24 mirror all buyer related fields numbered 8 to 15 (buyer details and decision maker) for the seller. Report under MAR 14.10

Fields 25 and 26 must only be populated in transaction reports submitted by a
receiving firm where all the conditions in MAR 14.10 are met.
25 Sending firm identification code for the buyer Code used to identify the sending firm. This must be populated by the receiving firm within the receiving firm’s report with the identification code provided for the sending firm. {LEI} 26 Sending firm identification code for the seller Code used to identify the sending firm. This must be populated by the receiving firm within the receiving firm’s report {LEI}

FCA 202X/YY with the identification code provided for the sending firm. Transaction details 27 Trading date time Date and time when the transaction was executed. For transactions executed on a trading venue, the level of granularity must be in accordance with the requirements of Commission Delegated Regulation (EU) 2017/574. For transactions not executed on a trading venue, the date and time are when the parties agree the content of the following fields: quantity, price, currency, instrument identification code, instrument classification and underlying instrument code, where applicable. For transactions not executed on a UK trading venue the time reported must be at least to the nearest second. Where the transaction results from an order transmitted by the executing firm on behalf of a client to a third party, this shall be the date and time of the transaction rather than the time of the order transmission. {DATE_TIME_FOR MAT} 28 Trading capacity Indication of whether the transaction results from the executing entity carrying out matched principal trading or dealing on own account. Where the transaction does not result from the executing entity carrying out matched principal trading or dealing on own account, the field must indicate that the transaction was carried out under any other capacity. Where the trading capacity is DEAL, either the buyer or seller must be the LEI of the executing entity. Where the trading capacity is AOTC/MTCH the buyer and seller fields must not be populated with the LEI of the executing entity. Where the trading capacity is MTCH the buyer and seller can be 2 clients of the “DEAL” - Dealing on own account “MTCH” - Matched principal “AOTC” - Any other capacity

FCA 202X/YY firm or a client and a market counterparty.
29 Quantity The number of units of the financial instrument, or the number of derivative contracts in the transaction. The nominal or monetary value of the financial instrument. For an increase or decrease in the notional amount of a derivative contract, the number must reflect the absolute value of the change and must be expressed as a positive number. The information reported in this field must be consistent with the values provided in fields price (31) and price multiplier (44) (if field 44 is populated). {DECIMAL-18/17} in case the quantity is expressed as number of units {DECIMAL-18/5} in case the quantity is expressed as monetary or nominal value 30 Quantity currency Currency in which the quantity is expressed. Only applicable if quantity is expressed as nominal or monetary value. {CURRENCYCODE _3} 31 Price The traded price of the transaction excluding, where applicable, commission and accrued interest. In the case of option contracts, it must be the premium of the derivative contract per underlying index point. In the case of spread bets, it must be the reference price of the underlying instrument. For credit default swaps, it must be the coupon in basis points. In the case of contracts for difference and equity swaps, it must be the reference price of the underlying, where possible. Where price is reported in monetary terms, it must be provided in the major currency unit. Where price is currently not available but pending, the value “PNDG” must be populated. Once the price becomes known, the transaction report should be updated with the accurate price. {DECIMAL-18/13} in case the price is expressed as monetary value {DECIMAL-11/10} in case the price is expressed as percentage or yield {DECIMAL-18/17} in case the price is expressed as basis points “PNDG” in case the price is not available “NOAP” in case the price is not applicable

FCA 202X/YY
Where price is not applicable the value
“NOAP” must be populated. This applies where there is a transfer of reportable financial instruments, and no price is paid. For example, gifts or transfers between funds or portfolios. The information reported in this field must be consistent with the values provided in fields quantity (29) and price multiplier (44) (if field 44 is populated). 32 Price currency Currency in which the price is expressed (applicable if the price is expressed as monetary value). {CURRENCYCODE _3} 33 Net amount The net amount of the transaction means the cash amount which is paid by the buyer of the debt instrument upon the settlement of the transaction. This cash amount equals to: (clean price * nominal value) + any accrued coupons. As a result, the net amount of the transaction excludes any commission or other fees charged to the buyer of the debt instrument. This field only applies when the reportable financial instrument is a debt instrument. {DECIMAL-18/5} 34 Venue Identification of the venue where the transaction was executed. Use the ISO 10383 segment MIC for transactions executed on a UK trading venue, a UK SI or organised trading platform outside of the UK. This includes negotiated transactions and applies to the reporting by both counterparties, not just to the counterparty that brought the transaction under the rules of the UK trading venue or organised trading platform outside of the UK. Where the segment MIC does not exist, use the operating MIC. For trading on an SI, both the SI and the firm trading with the SI should report the MIC of the SI. {MIC}

FCA 202X/YY
Use MIC code “XOFF” for transactions in reportable financial instruments, where the transaction in that reportable financial instrument is not executed on a UK trading venue, UK SI, or organised platform outside of the UK, or where an investment firm does not know it is trading with another investment firm acting as a UK SI. Use MIC code “XXXX” for financial instruments that are not admitted to trading or traded on a UK trading venue or for which no request for admission has been made and that are not traded on an organised trading platform outside of the UK but where the underlying is admitted to trading or traded on a qualifying trading venue. 35 Up-front payment Monetary value of any up-front payment received or paid by the seller. Where the seller receives the up-front payment, the value populated is positive. Where the seller pays the up-front payment, the value populated is negative. {DECIMAL-18/5} 36 Up-front payment currency Currency of any up-front payment in field 35. {CURRENCYCODE _3} 37 Package identifier An identifier for all reports related to the same package transaction in accordance with MAR 14.13.21R. The internal code must be unique at the level of the executing entity for the group of reports. Where possible, the identifier should mirror the ‘package identifier’ reported for the same transaction(s) under EMIR. This field only applies when the conditions specified in MAR 14.13.21R apply. {ALPHANUM-35} 38 Package transaction price Traded price of the entire package in which the transaction is a component. This field only applies when the conditions specified in MAR 14.13.21R apply. {DECIMAL-18/13} in case the price is expressed as monetary value

FCA 202X/YY
The traded price of the transaction excluding, where applicable, commission and accrued interest. Where price is reported in monetary terms, it must be provided in the major currency unit. Where price is currently not available but pending, the value “PNDG” must be populated. Where price is not applicable the value “NOAP” must be populated. This applies where there is a transfer of reportable financial instruments, and no price is paid. For example, gifts or transfers between funds or portfolios. {DECIMAL-11/10} in case the price is expressed as percentage or yield {DECIMAL-18/17} in case the price is expressed as basis points “PNDG” in case the price is not available “NOAP” in case the price is not applicable 39 Package transaction currency Currency in which the package transaction price is expressed. This field only applies when the conditions specified in MAR 14.13.21R apply. {CURRENCYCODE _3} Instrument details 40 Instrument identification code Code used to identify the reportable financial instrument. This field applies to all reportable financial instruments for which a request for admission to trading has been made, that are admitted to trading or traded on a qualifying trading venue. It also applies to reportable financial instruments which have an ISIN and are traded on an organised trading platform outside of the UK where the underlying is a reportable financial instrument traded on a qualifying trading venue. {ISIN} Fields 41-52 are not applicable where field 40 (Instrument identification code) is populated with an ISIN that exists on the financial instrument reference data list. The FCA will not reject the transaction report where any of the fields 41 to 52 are populated but the ISIN exists on the financial instrument reference data list published by the FCA. In such cases the FCA will utilise the data in the financial instrument reference data list rather than the instrument reference data reported in fields 41 to 52 to enhance the transaction report.

FCA 202X/YY
41 Instrument full name
Full name of the financial instrument. {ALPHANUM-350} 42 Instrument classification Taxonomy used to classify the financial instrument. A complete and accurate CFI code must be provided. {CFI_CODE} 43 Notional currency 1 Currency in which the notional is denominated. In the case of an interest rate contract, this is the notional currency of leg 1. In the case of swaptions where the underlying swap is single-currency, this is the notional currency of the underlying swap. For swaptions where the underlying is multi-currency, this is the notional currency of leg 1 of the swap. {CURRENCYCODE _3} 44 Price multiplier Number of units of the underlying instrument represented by a single derivative contract or monetary value covered by a single swap contract where the quantity field indicates the number of swap contracts in the transaction. For a future or option on an index, the amount per index point. For spreadbets, the movement in the price of the underlying instrument on which the spreadbet is based. The information reported in this field must be consistent with the values provided in fields quantity (29) and price (31). {DECIMAL-18/17} 45 Underlying instrument code ISIN code of the underlying instrument. For American depository receipts and global depository receipts and similar instruments, the ISIN of the financial instrument on which those instruments are based. For convertible bonds, the ISIN of the instrument the bond can be converted to. For derivatives or other instruments which have an underlying, the underlying instrument ISIN, when the underlying is {ISIN}

FCA 202X/YY admitted to trading, or traded on a qualifying trading venue. Where the underlying is a stock dividend, the ISIN of the related share entitling the underlying dividend. For credit default swaps, the ISIN of the reference obligation must be provided. In case the underlying is an index and has an ISIN, the ISIN code for that index. Where the underlying is a basket, include the ISIN of each constituent of the basket that is admitted to trading or is traded on a qualifying trading venue. This field (45 must be reported as many times as necessary to list all reportable instruments in the basket. ISINs may be reported for financial instruments which are not reportable financial instruments, where they exist. 46 Underlying index name Where the underlying is an index, the name of the index. {INDEX} Or {ALPHANUM-25} - if the index name is not included in the {INDEX} list 47 Term of the underlying index In case the underlying is an index, the term of the index. {INTEGER-3}+ “DAYS” - days {INTEGER-3}+ “WEEK” - weeks {INTEGER-3} + “MNTH” - months {INTEGER3}+”YEAR” - years 48 Strike price Pre-determined price at which the holder will have to buy or sell the underlying instrument, or an indication that the price cannot be determined at the time of execution. Field only applies to an option or warrant where strike price is applicable and can be determined at the time of execution. {DECIMAL-18/13} in case the price is expressed as monetary value {DECIMAL-11/10} in case the price is expressed as percentage or yield {DECIMAL-18/17} in case the price is

FCA 202X/YY
Where strike price is currently not available but pending, the value shall be “PNDG”. Where strike price is not applicable the value “NOAP” must be populated. expressed as basis points “PNDG” in case the price is not available “NOAP” in case the strike price is not applicable 49 Strike price currency Currency of the strike price. {CURRENCYCODE _3} 50 Expiry date Expiry date of the reportable financial instrument. Field only applies to derivatives with a defined expiry date. The expiry date should be the unadjusted date at which obligations under the derivative transaction stop being effective, as included in the confirmation. {DATEFORMAT} Traders and algorithms 51 Investment decision within firm Code used to identify the person or algorithm within the firm who is responsible for the investment decision. For natural persons, the identifier specified in MAR 14.13.5R to MAR 14.13.7R must be used. If the investment decision was made by an algorithm, the field must be populated as set out in MAR 14.13.17R. This field only applies for investment decisions within the firm. If there is no one within the firm responsible, then the field must be left blank. This field is not applicable for a transaction report submitted by a qualifying trading venue on behalf of firms which are not transaction reporting firms under MAR 14.5 where the investment decision was made by a natural person. {NATIONAL_ID} - Natural persons {ALPHANUM-50} - Algorithms 52 Execution decision within firm Code used to identify the person or algorithm within the firm who is responsible for the execution. {NATIONAL_ID} - Natural persons {ALPHANUM-50} – Algorithms

FCA 202X/YY
The term ‘algorithm’ means any system that automatically executes transactions without human intervention. For natural persons, the identifier specified in MAR 14.13.5R to MAR 14.13.7R must be used. If the execution was made by an algorithm, the field must be populated as set out in MAR 14.13.17R. If no person or algorithm in the firm was responsible, “NORE” must be populated. This field is not applicable for transaction reports submitted by qualifying trading venues on behalf of firms which are not transaction reporting firms under MAR 14.5R where the execution decision was made by a natural person. “NORE” – No one responsible within the firm “DEAU” – No one responsible within the firm and the executing entity has provided DEA Insert the following new annex, MAR 14 Annex 2, after MAR 14 Annex 1 (Details to be reported in transaction reports). 14 Annex Details to be reported in transaction reports [Editor’s note: This annex will consist of the table previously located in Annex 2 of the UK version of Commission Delegated Regulation (EU) 2017/590 supplementing MIFIR with regard to with regard to regulatory technical standards for the reporting of transactions to competent authorities, which is part of UK law by virtue of the European Union (Withdrawal) Act 2018. Where amendments are to be made to the content of the table, underlining indicates new text and striking through indicates deleted text. Terms that are to be defined in the Handbook Glossary will be set out in future consultation.] National client identifiers for natural persons to be used in transaction reports 14 Annex 2.1 R ISO 3166 alpha 2 Country Name 1st priority identifier 2nd priority identifier 3rd priority identifier …

FCA 202X/YY
LI Liechtenstein National Passport
Number
National
Identity Card
Number
CONCAT1
… in accordance with paragraph 31bazg of Annex IX (Financial Services) to the EEA Agreement, the entry for Liechtenstein in this Annex shall be replaced by the following:
LI Liechtenstein CONCAT
The European Union (Withdrawal) Act 2018 provides that the Annexes to the EEA Agreement, as they have effect in EU law immediately before IP completion day, form part of UK law on and after IP completion day – to the extent that they refer to or adapt any EU regulation, EU decision or EU tertiary legislation which is retained by section 3 of the Act. The 2018 Act also provides that Protocol 1 to the EEA Agreement, as it has effect in EU law immediately before IP completion day, forms part of UK law on and after IP completion day. Insert the following new chapter, MAR 15, after MAR 14 (Transaction reporting). The text is all new and is not underlined. 15 Financial instrument reference data
15.1 Purpose and application
Purpose
15.1.1 G (1) The purpose of this chapter is to set out the rules relating to the
submission of financial instrument reference data to the FCA.
(2) Financial instrument reference data provides the FCA with information and details on instruments which are admitted to trading, which is utilised by the FCA to monitor the functioning of financial markets and supervise firms. (3) The FCA also publishes financial instrument reference data to help firms understand which financial instruments are reportable financial instruments and when they must submit a transaction report. Application
15.1.2 R This chapter applies to operators of qualifying trading venues in relation to
reportable financial instruments.
Guidance

FCA 202X/YY
15.1.3 G A reference in this chapter and the related annex to ‘ISO’, followed by a
reference number, is to a standard published by the International Organization for Standardization.
15.2 Obligation to supply financial instrument reference data
15.2.1 R Operators of qualifying trading venues must provide to the FCA financial
instrument reference data for all:
(1) reportable financial instruments admitted to trading on their venue; and (2) reportable financial instruments traded on their venue.
15.2.2 R Operators of qualifying trading venues must submit financial instrument
reference data to the FCA in the following circumstances:
(1) the first time a reportable financial instrument is admitted to trading on their venue; (2) the first time there is a quote, order or trade in a reportable financial instrument on their venue; (3) when there are any changes to any financial instrument reference data previously submitted to the FCA; and/or (4) where a reportable financial instrument under (1), (2) or (3):
(a) ceases to be tradable or admitted to trading on the trading venue; or (b) is cancelled.
15.3 Content, standards, form and format of financial instrument reference
data
15.3.1 R The financial instrument reference data to be provided under MAR 15.2.1R
must contain all the details set out in MAR 15 Annex 1 (Financial instrument reference data) and must comply with the requirements of this
chapter.
15.3.2 R All financial instrument reference data must be submitted:
(1) in accordance with the standards and formats specified in MAR 15
Annex 1 (Financial instrument reference data);
(2) in an electronic and machine-readable form; (3) in a common XML template; and (4) in accordance with the ISO 20022 methodology.
15.4 Timing for provision of financial instrument reference data to the FCA

FCA 202X/YY
15.4.1 R An operator of a qualifying trading venue must send the financial
instrument reference data required by MAR 15.2 to the FCA on or before 17:00 UTC on each day the qualifying trading venue is open for trading.
15.4.2 R When any of the circumstances specified in MAR 15.2.2R occurs after
17:00 on a day on which the qualifying trading venue is open for trading, the financial instrument reference data must be provided to the FCA by 17:00 UTC on the next day on which that qualifying trading venue is open for trading.
15.4.3 G Daily submission of financial instrument reference data by operators of
qualifying trading venues may no longer be required. The obligation to submit financial instrument reference data will be dependent on the occurrence of any of the events specified in MAR 15.2.2R. However, if an operator of a qualifying trading venue would prefer to submit financial instrument reference data to the FCA on a daily basis they may continue to do so.
15.5 ISINs and LEIs
15.5.1 R The operator of a qualifying trading venue must obtain the ISIN for a
reportable financial instrument before the commencement of trading in that reportable financial instrument.
15.5.2 R Operators of qualifying trading venues must ensure that the LEI included in
the financial instrument reference data:
(1) relates to the issuer of the reportable financial instrument; (2) complies with ISO 17442; and (3) is listed in the Global Legal Entity Identifier System.
15.5.3 R Operators of qualifying trading venues must ensure that they have a valid
LEI at all times.
15.6 Methods and arrangements for supplying reference data
15.6.1 R Operators of qualifying trading venues must ensure that they provide
complete and accurate financial instrument reference data to the FCA.
15.6.2 R Operators of qualifying trading venues must put in place methods and
arrangements that enable them to identify incomplete or inaccurate financial instrument reference data previously submitted.
15.6.3 R Operators of qualifying trading venues must have methods and
arrangements in place that enable them to monitor, review and resolve incidents where a submission of financial instrument reference data has been rejected by the FCA and has not yet been successfully resubmitted.

FCA 202X/YY
15.6.4 R When an operator of a qualifying trading venue detects that submitted
financial instrument reference data is incomplete or inaccurate, it must promptly:
(1) notify the FCA; and
(2) transmit to the FCA complete and correct financial instrument reference data.
15.6.5 R Where an operator of a qualifying trading venue detects that it has
submitted financial instrument reference data that was not required, it must promptly notify the FCA and cancel that financial instrument reference data.
15.7 Reconciliation of reference data
15.7.1 R Operators of qualifying trading venues must regularly reconcile their
internal records of financial instrument reference data with the consolidated financial instrument reference data published by the FCA.
Annex 1
Details to be reported as financial instrument reference data [Editor’s note: This annex will consist of the three tables previously located in the Annex of the UK version of Commission Delegated Regulation (EU) 2017/585 supplementing MIFIR with regard to regulatory technical standards for the data standards and formats for financial instrument reference data and technical measures in relation to arrangements to be made by the European Securities and Markets Authority and competent authorities, which is part of UK law by virtue of the European Union (Withdrawal) Act 2018. Where amendments are to be made, underlining indicates new text and striking through indicates deleted text. Terms that are to be defined in the Handbook Glossary will be set out in future consultation.]
Table 1 Legend for Table 3: Field descriptions for Table 3 (Details to be
reported as financial instrument reference data) 15 Annex 1.1 R SYMBOL DATA TYPE DEFINITION … [Editor’s note: No changes are proposed to be made to the content of this table. It is proposed that Table 1 of the Annex to the UK version of Commission Delegated Regulation (EU) 2017/585 is replicated in full.]

FCA 202X/YY
Table 2: Classification of commodity and emission allowances
derivatives for Table 3 (Fields 35 28 to 37 30).
15 Annex
1.2
R
Base product Sub product Further sub product … [Editor’s note: No changes are proposed to be made to the content of this table. It is proposed that Table 2 of the Annex to the UK version of Commission Delegated Regulation (EU) 2017/585 is replicated in full.]
Table 3: Details to be reported as financial instrument reference data
15 Annex
1.3
R
N. FIELD CONTENT TO BE
REPORTED
FORMAT AND
STANDARDS TO BE
USED FOR
REPORTING
General Fields
…
4 Commodities or emission allowance derivative indicator Indication as to whether the financial instrument falls within the definition of commodities derivative under
Article 2(1)(30) of Regulation
(EU) No 600/2014 or is a derivative relating to emission allowances referred to in paragraph 4 of Part 1 of
Schedule 2 to the Regulated
Activities Order.
“true” - Yes
“false” - No
Issuer related fields
5 4 Issuer or operator of the qualifying trading venue identifier LEI of issuer or qualifying trading venue operator. {LEI} Venue related fields

FCA 202X/YY
6 5 Trading venue Segment MIC for the trading venue or systematic internaliser, where available, otherwise operating MIC. … 7 Financial instrument short name Short name of financial instrument in accordance with ISO 18774. {FISN} 8 6 Request for admission to trading by issuer … … 9 7 Date of approval of the admission to trading Date and time the issuer has approved admission to trading or trading in its financial instruments on a trading venue. Where the financial instrument is a derivative issued by the qualifying trading venue this field does not need to be completed. … 10 8 Date of request for admission to trading Date and time of the request for admission to trading on the trading venue. Where the financial instrument is a derivative issued by the qualifying trading venue this field does not need to be completed. … 11 9 Date of admission to trading or date of first trade … … 12 10 Termination date … … Notional related fields 13 11 Notional currency 1 … … Bonds or other forms of securitised debt related fields 14 12 Total issued nominal amount … … 15 13 Maturity date … …

FCA 202X/YY
16 14 Currency of nominal value
… …
17 Nominal value per unit/minimum traded value Nominal value of each instrument. If not available, the minimum traded value shall be populated. {DECIMAL-18/5} 18 15 Fixed rate … … 19 16 Identifier of the index/benchmark of a floating rate bond … … 20 17 Name of the index/benchmark of a floating rate bond … … 21 18 Term of the index/benchmark of a floating rate bond. … … 22 19 Base Point Spread of the index/benchmark of a floating rate bond … … 23 Seniority of the bond Identify the type of bond:
senior debt, mezzanine, subordinated or junior.
“SNDB” - Senior Debt
“MZZD” - Mezzanine
“SBOD” - Subordinated
Debt
“JUND” - Junior Debt
Derivatives and Securitised Derivatives related fields 24 20 Expiry date … … 25 21 Price multiplier … … 26 22 Underlying instrument code ISIN code of the underlying instrument. For ADRs American depositary receipts, GDRs global depositary receipts and similar instruments, the ISIN code of the financial instrument on which those instruments are based. For convertible bonds, the ISIN code of the instrument …

FCA 202X/YY in which the bond can be converted.
For derivatives or other instruments which have an underlying, the underlying instrument ISIN code, when the underlying is admitted to trading, or traded on a trading venue. Where the underlying is a stock dividend, then the ISIN code of the related share entitling the underlying dividend. For Credit Default Swaps credit default swaps, the ISIN of the reference obligation shall be provided. In case the underlying is an Index and has an ISIN, the ISIN code for that index. Where the underlying is a basket, include the ISINs of each constituent of the basket that is admitted to trading or is traded on a trading venue. Fields 26 22 and 27 23 shall be reported as many times as necessary to list all instruments in the basket. 27 23 Underlying issuer In case the instrument is referring to an issuer, rather than to one single instrument, the LEI code of the Issuer issuer. … 28 24 Underlying index name … … 29 25 Term of the underlying index … … 30 Option type Indication as to whether the derivative contract is a call (right to purchase a specific underlying asset) or a put (right to sell a specific underlying asset) or whether it cannot be determined “PUTO” - Put “CALL” - Call “OTHR” - where it cannot be determined whether it is a call or a put

FCA 202X/YY whether it is a call or a put at the time of execution. In case of swaptions it shall be:
“Put”, in case of receiver swaption, in which the buyer has the right to enter into a swap as a fixed-rate receiver. “Call”, in case of payer swaption, in which the buyer has the right to enter into a swap as a fixed-rate payer. In case of Caps and Floors it shall be:
“Put”, in case of a Floor.
“Call”, in case of a Cap. Field only applies to derivatives that are options or warrants. 31 26 Strike price … … 32 27 Strike price currency … … 33 Option exercise style Indication as to whether the option may be exercised only at a fixed date (European and Asian style), a series of prespecified dates (Bermudan) or at any time during the life of the contract (American style). This field is only applicable for options, warrants and entitlement certificates. “EURO” - European “AMER” - American “ASIA” - Asian “BERM” - Bermudan “OTHR” - Any other type 34 Delivery type Indication as to whether the financial instrument is settled physically or in cash. Where delivery type cannot be determined at time of execution, the value shall be “OPTL”. This field is only applicable for derivatives. “PHYS” - Physically Settled “CASH” - Cash settled “OPTL” - Optional for counterparty or when determined by a third party Commodity and emission allowances derivatives 35 28 Base product … …

FCA 202X/YY
36 29 Sub product … …
37 30 Further sub product … …
38 31 Transaction type … …
39 32 Final price type … …
Interest rate derivatives

The fields in this section shall only be populated for instruments that have non-financial
instrument of type interest rates as underlying.
[Editor’s note: the hyphen at the start of the sentence above is to be removed.] 40 33 Reference rate … … 41 34 IR Term of contract … … 42 35 Notional currency 2 … … 43 Fixed rate of leg 1 An indication of the fixed rate of leg 1 used, if applicable. {DECIMAL -11/10} Expressed as a percentage (e.g. 7.0 means 7 % and
0.3 means 0,3 %)
44 Fixed rate of leg 2 An indication of the fixed rate of leg 2 used, if applicable {DECIMAL -11/10} Expressed as a percentage (e.g. 7.0 means 7 % and
0.3 means 0,3 %)
45 36 Floating rate of leg 2 … …
46 37 IR Term of contract of leg 2
… …
Foreign exchange derivatives
The fields in this section shall only be populated for instruments that have non-financial
instrument of type foreign exchange as underlying.
47 Notional currency 2 Field shall be populated with the underlying currency 2 of the currency pair (the currency one will be populated in the notional currency 1 field 13). {CURRENCYCODE_3} 48 FX Type Type of underlying currency ”FXCR” - FX Cross Rates ”FXEM” - FX Emerging Markets

FCA 202X/YY
”FXMJ” - FX Majors

FCA 202X/YY
Annex C
Amendments to the Supervision manual (SUP)
In this Annex, underlining indicates new text and striking through indicates deleted text. 17A Transaction reporting and supply of reference data 17A.1 Application 17A.1.1 R This chapter applies to:
(1) a MiFID investment firm (excluding a collective portfolio management investment firm) which: a transaction reporting firm; (a) executes transactions in a reportable financial instrument; and (b) is required under article 26(1) of MiFIR to report its transactions to the FCA; (2) an operator of a qualifying trading venue:
(a) through whose systems and platforms a transaction in a reportable financial instrument is executed by a person not subject to MiFIR MAR 14; and (b) which is required under article 26(5) of MiFIR MAR 14.5 to report such transactions to the FCA; and (3) a third country investment firm which executes transactions in a reportable financial instrument; and [deleted] (4) a systematic internaliser or an operator of a qualifying trading venue which is required under article 27 of MiFIR MAR 14 to supply identifying reference data relating to reportable financial instruments traded on its system or trading venue to the FCA. [Note: article 26 of MiFIR and MiFID RTS 22 contain requirements regarding transaction reporting that are directly applicable to a firm in SUP 17A.1.1R(1) or (2), and to an ARM or an operator of a trading venue which acts on behalf of a MiFID investment firm subject to article 26(1) of MiFIR] 17A.1.2 G GEN 2.2.22AR has the effect of requiring third country investment firms to comply with the transaction reporting requirements in in article 26 of MiFIR and MiFID RTS 22 as though they were MiFID investment firms. [deleted] [Note: article 27 of MiFIR and MiFID RTS 23 contain requirements about the supply of reference data that are directly applicable to a systematic internaliser in relation to financial instruments traded on its system or a

FCA 202X/YY trading venue in relation to financial instruments admitted to trading on a regulated market or traded on an MTF or OTF] 17A.2 Connectivity with FCA systems 17A.2.1 R The following firms or operators of trading venues must deal with the FCA in an open and co-operative way when establishing a technology connection with the FCA for the submission of transaction reports and/or the supply of reference data:
(1) a firm in SUP 17A.1.1R(1) or 17A.1.1R(3) transaction reporting firm that chooses to submit its reports directly to the FCA instead of using an ARM ARM; (2) an operator of a qualifying trading venue in SUP 17A.1.1R(2), other than a UK RIE that is not itself an ARM ARM; and (3) a firm or an operator of a qualifying trading venue in SUP 17A.1.1R(4), other than a UK RIE. 17A.2.1A G The FCA expects a systematic internaliser that will be supplying the FCA with financial instrument reference data in respect of a financial instrument traded on its system that is not admitted to trading on a regulated market or traded on an MTF or OTF to establish a technology connection with the FCA for the supply of that reference data. [deleted] 17A.2.1B G A firm An operator of a qualifying trading venue in SUP 17A.1.1.R(4) may use a third party technology provider to submit to the FCA financial instrument reference data in respect of a financial instrument traded on its system provided that it does so in a manner consistent with MiFID and MiFIR MAR 15. Firms Operators of a qualifying trading venue will retain responsibility for the completeness, accuracy and timely submission of the data. A firm The operator of a qualifying trading venue should be the applicant for, and should complete and sign, the FCA MDP on-boarding application form. 17A.2.2 R To ensure the security of the FCA’s systems, a transaction reporting firm or operator of a qualifying trading venue in SUP 17A.2.1R must:
(1) sign the MIS confidentiality agreement at MAR 9 Annex 10D; and (2) send it by email to MDP.onboarding@fca.org.uk or post an original signed copy to the FCA addressed to:
The Financial Conduct Authority
FAO The Markets Reporting Team
12 Endeavour Square
London, E20 1JN.

FCA 202X/YY
17A.2.3 G Once the FCA receives the MIS confidentiality agreement from the transaction reporting firm or operator of a qualifying trading venue, the FCA will:
(1) provide the firm or operator with the Market Interface Specification (MIS); and (2) request the firm or operator to:
(a) confirm to the FCA that it can satisfy these specifications by completing the FCA MDP on-boarding application form at MAR 9 Annex 7D; and (b) provide the completed form and any relevant documents to the FCA together with the associated fee in FEES 3.2.7R. 17A.2.4 R The transaction reporting firm or operator of a qualifying trading venue must confirm to the FCA that it can satisfy the FCA’s technical specifications before it can establish a technology connection with the FCA for the submission of transaction reports and/or the supply of financial instrument reference data. 17A.2.5 G Where an ARM ARM is used to satisfy a MiFID investment firm’s or a third country investment firm’s transaction reporting firm’s transaction reporting obligations in accordance with article 26 of MiFIR MAR 14 or GEN GEN 2.2.22AR, MAR 9 applies.

© Financial Conduct Authority 2025
12 Endeavour Square London E20 1JN
Telephone: +44 (0)20 7066 1000
Website: www.fca.org.uk
All rights reserved
Pub ref: 1-009012
All our publications are available to download from www.fca.org.uk. Request an alternative format Please complete this form if you require this content in an alternative format. Or call 0207 066 1000 Sign up for our news and publications alerts

Lineage

Timeline

Similar documents from other regulators