PS26/15: Improving the UK transaction reporting regime

Policy Statement PS26/15 Improving the UK transaction reporting regime August 2026

This relates to Consultation Paper 25/32 which is available on our website at www.fca.org.uk/publications Telephone: 0207 066 1000 Email: CP25-32@fca.org.uk Sign up for our news and publications alerts See all our latest press releases, consultations and speeches. 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

3 Contents Chapter 1 Summary Page 4 Chapter 2 Our long-term approach to harmonisation . . . . . . . . . . . . . . . . . Page 8 Chapter 3 Scope Page 10 Chapter 4 Content of transaction reports Page 22 Chapter 5 Obligations on trading venues . . . . . . . . . . . . . . . . . . . . . . . . Page 37 Chapter 6 Our supervisory approach Page 46 Annex 1 List of non-confidential respondents Page 52 Annex 2 Cost benefit analysis Page 54 Annex 3 Abbreviations used in this paper Page 56 Appendix 1 Derivation and Changes Table Appendix 2 Made rules (legal instrument) Appendix 3 Handbook tables

4 Chapter 1 Summary Who this affects 1.1 This Policy Statement affects investment firms, operators of trading venues, approved reporting mechanisms (ARMs), and other market participants involved in submitting transaction reports, instrument reference data and order book data. Our changes are not aimed at consumers. The wider context of this policy statement Our consultation 1.2 UK Markets in Financial Instruments Regulation (MiFIR) transaction reports are critical for our work to monitor financial markets, conduct market abuse surveillance and support supervisory activities. We make extensive use of the data every day. 1.3 The Treasury plans to repeal UK MiFIR transaction reporting legislation, enabling us to deliver a new, streamlined framework. The framework will cut costs for business while ensuring effective regulatory oversight of our world-leading capital markets. In Consultation Paper (CP) 25/32, we consulted on new rules to support this. 1.4 This Policy Statement sets out the final rules and guidance. It explains the feedback we received, our responses and implementation arrangements. How it links to our objectives 1.5 These changes primarily advance our market integrity objective. High-quality transaction reports help us: • Detect and investigate market abuse. • Monitor the functioning of financial markets. • Supervise firms, shape effective policies and support our response to crises. 1.6 We also aim to support effective competition in consumers’ interests. We will do this by reducing unnecessary regulatory burden and making reporting obligations clearer and more proportionate. Our changes should lead to annual savings of over £100m for firms. 1.7 These measures support our long-term vision for a streamlined and harmonised transaction reporting framework across multiple regimes, free from unnecessary duplication. This supports our secondary international competitiveness and growth objective by reducing unnecessary cost and complexity.

5 What we are changing 1.8 We are making targeted changes to the scope, content and operation of the transaction reporting regime. The changes include: • Reducing the number of transaction reporting fields from 65 to 52. • Removing reporting obligations for 7 million financial instruments which are only tradeable on European Union (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. • Exempting most corporate actions from reporting obligations. • Requiring trading venues to populate fewer fields in their transaction reports, simplifying information provided by over 2,200 international firms when accessing UK financial markets. • Creating a new framework for Conditional Single-Sided Reporting (CSSR). Outcome we are seeking 1.9 We want to capture data that is accurate, proportionate and necessary for our work, while reducing firms’ costs by more than £100m annually. We expect the changes to simplify firms’ reporting obligations, reduce duplicative or low-value reporting and improve consistency in how key fields are populated. 1.10 These changes complement our work to transform our regulatory data model for asset managers (CP26/26). We want transaction reporting requirements to be proportionate for all firms and supplement the data we collect under other regimes. 1.11 We will monitor the effectiveness of the changes through our supervisory work, the quality and usability of transaction reports and instrument reference data, and intelligence from firms, trading venues, ARMs and other stakeholders. Summary of feedback and our response 1.12 We received support for most of our proposals. In particular, for those that reduce scope, remove reporting fields and aim to clarify firms’ obligations. Respondents supported our long-term approach to harmonising transaction reporting across regimes. They welcomed the creation of a joint FCA and Bank of England Transaction and Post-trade Reporting Industry Harmonisation Taskforce. 1.13 Respondents asked for early sight of schemas and validation rules, guidelines, proportionate back reporting arrangements and sufficient implementation time. We have taken this feedback into account. In some areas we are proceeding as consulted.

6 In others, we are making targeted adjustments, clarifying points, or using supervisory flexibility to support proportionate implementation. 1.14 In Appendix 1, we set out a rule-by-rule description of the retained EU law derivation of new or amended Handbook provisions. We also briefly explain the changes made to the Handbook. The changes we have made do not impact our assessment of the cost benefit analysis or equality and diversity considerations. Equality and diversity considerations 1.15 We have considered the equality and diversity issues that may arise from the rules and guidance in this Policy Statement. Overall, we do not consider that the changes materially impact any of the groups with protected characteristics under the Equality Act 2010. The changes are directed principally at firms’ reporting obligations and the systems and controls they use to meet them. Environmental, social & governance considerations 1.16 In developing this Policy Statement, we have considered the environmental, social and governance implications of our changes and our duty under the Financial Services and Markets Act (FSMA) to have regard to contributing towards the Secretary of State achieving compliance with relevant environmental targets. Overall, we do not consider that these changes are relevant to contributing to those targets. Next steps What we will do next 1.17 We are making the rules set out in Appendix 2. Most respondents supported an 18-month implementation period. This recognises the scale and complexity of the amendments and the associated system, process and governance changes required. Firms also suggested this period should only start once supporting documents are available, including schemas, validation rules and guidelines. 1.18 We will publish a draft schema, validation rules and new guidelines in October 2026. These new guidelines will form part of a new Transaction Reporting User Pack. Our consultation will also cover transitional provisions and consequential amendments to our Handbook. 1.19 The new regime will come into force on 3 April 2028. We will take a flexible supervisory approach from 3 August 2026 until this date (the ‘implementation period’) to some areas. This should help firms benefit before 3 April 2028. Chapter 6 explains our approach.

7 What you need to do next 1.20 If your firm is affected by these changes, you should begin planning now. This includes: • Reviewing your reporting logic. • Considering the impact of changes to the scope of reporting requirements and data fields. • Preparing for the revised schema, validation rules and guidance.

8 Chapter 2 Our long-term approach to harmonisation 2.1 The integrity of our wholesale financial markets is supported by several wholesale transaction and post-trade reporting regimes. These include the UK MiFIR transaction reporting regime and reporting requirements in UK European Market Infrastructure Regulation (EMIR) and Securities Financing Transactions Regulation (SFTR). 2.2 This data is key to our strategy to fight financial crime, support sustained economic growth and be a smarter regulator. 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. 2.3 In CP25/32, we outlined a new, long-term approach to create a streamlined and harmonised framework for transaction reporting across regimes, free from unnecessary duplication. We proposed a gradual transition, maintaining the existing, well-established reporting structure under UK MiFIR, EMIR and SFTR. 2.4 To ensure a coherent and predictable path towards this framework, we will approach this work with a consistent set of principles: • Data should only be collected where needed. • A firm should only report data once. • Data should be shared where appropriate. 2.5 We committed to establishing a cross-authority and industry working group to inform the design of our long-term approach. Summary of feedback 2.6 Feedback overwhelmingly supported our long-term approach to harmonising reporting across the UK MiFIR, EMIR and SFTR regimes. There was widespread agreement that duplication across regimes creates unnecessary operational burden. 2.7 Most respondents supported the overall direction of travel, favouring incremental change rather than wholesale redesign. Respondents highlighted the need to balance simplification benefits with industry investment and implementation costs. They agreed that the cost of change must not materially erode benefits realised. 2.8 Respondents emphasised that any simplification should remain proportionate and maintain data quality. Several highlighted the importance of robust validation, reconciliation and supervisory access to the data. They cautioned against approaches that could weaken market integrity monitoring or reduce accountability. 2.9 The principles proposed to guide this work also received strong support. Respondents noted that their effectiveness will depend on clear governance and careful implementation.

9 2.10 Some respondents suggested an additional principle of international alignment. They noted that meaningful burden reduction will depend on avoiding divergence from global standards. Our response: We established the Transaction and Post-trade Reporting Industry Harmonisation Taskforce with the Bank of England. The inaugural meeting was in July 2026. Through its 3 working groups (Policy, Strategy and Architecture) the Taskforce will inform the design of our long￾term approach to harmonising transaction and post-trade reporting requirements. We will publish minutes from these meetings. We are working closely with the Treasury and Bank of England to repeal and replace the reporting requirements on over-the-counter (OTC) derivatives set out in Title II of UK EMIR. This work will transfer detailed firm-facing requirements into regulatory rule books where appropriate and aims to ensure the regime remains proportionate while supporting economic growth. On international alignment, we recognise that many firms report across multiple jurisdictions and that unnecessary divergence can increase costs without improving outcomes. In July 2026, ESMA published a Final Report on a comprehensive approach for the simplification of financial transaction reporting. The report highlighted similar issues to those covered in this Policy Statement. We will seek to align with global data standards where appropriate to reduce reporting burdens and support effective market monitoring and data sharing. We welcome regulatory cooperation to improve outcomes for firms on transaction reporting. However, we will pursue changes where we consider the benefits to UK market integrity, growth and data quality outweigh the costs of divergence.

10 Chapter 3 Scope Geographic scope Summary of our proposal 3.1 We proposed to limit the scope of the transaction reporting regime to financial instruments tradeable on trading venues in the UK only. We estimated this would save firms approximately £31.5m annually. 3.2 We highlighted that our proposal may create data gaps, limiting our ability to monitor some EU financial markets. However, transaction reports for activities by UK firms on EU trading venues are received by EU National Competent Authorities (NCAs). We are strengthening our data sharing capabilities with EU NCAs as part of our approach to reducing duplication. 3.3 We also proposed to remove references to the European ‘Union’ in our new rules. We proposed to retain the existing approach to EU national identifiers used in transaction reports. Summary of feedback 3.4 All respondents supported our proposal. They view this change as a high-impact scope reduction that materially reduces regulatory burden while delivering limited loss of supervisory value. Respondents highlighted that transactions in financial instruments tradeable on EU trading venues are already subject to EU transaction reporting requirements and oversight by EU NCAs. It was noted that we can require data from UK regulated firms on an ad hoc basis where necessary to support enquiries. 3.5 A key operational theme was the need for alignment with the FCA Financial Instrument Reference Data System (FIRDS). Respondents strongly emphasised that FCA FIRDS should be the ‘golden source’ for determining the reportability of a financial instrument. They highlighted that financial instruments only traded on EU trading venues (with an EU ‘Upcoming RCA’ in FIRDS) should be terminated or removed from FCA FIRDS. Some firms suggested this be done immediately to start realising benefits as soon as possible. 3.6 Respondents also stressed the importance of pragmatic back reporting treatment. They called for confirmation that firms will not be required to retrospectively cancel historical transaction reports submitted correctly under the previous framework, as such obligations would undermine the intended cost savings. 3.7 All respondents supported removing the term ‘Union’ from Market Conduct Sourcebook (MAR) 14 Annex 2 and retaining the existing national identifier hierarchy. They viewed this proposal as proportionate and operationally desirable, avoiding divergence from

11 established onboarding processes. Some noted that our approach maintains alignment with EU reporting requirements for all nationalities other than the UK, minimising complexity for cross-border firms. Our response: We will implement our proposal to reduce the scope of the transaction reporting regime to financial instruments tradeable on UK trading venues only. The scope of the transaction reporting regime is set in legislation, which the Treasury has confirmed they will repeal ahead of our new rules coming into effect on 3 April 2028. During the implementation period, we will take a flexible supervisory approach and not take action against firms which do not submit transaction reports for reportable financial instruments only tradeable on EU trading venues. We recognise this will provide limited relief for many firms who use FCA FIRDS to determine the scope of their reporting obligations. We will consider making changes to FCA FIRDS to stop ingesting EU instrument reference data before April 2028. Firms would need to update reporting processes from this point to avoid receiving transaction reporting rejections. We need to understand whether this would create issues for firms who elect not to take advantage of our planned supervisory flexibility. We will engage further with market participants and provide an update in October 2026. We will remove reference to ‘Union’ including in MAR 14 Annex 2 and retain the current approach to national identifier hierarchy. Foreign exchange (FX) derivatives Summary of our proposal 3.8 We proposed to remove FX derivatives from the scope of the transaction reporting regime. We have seen persistent data quality challenges with transaction reports for FX derivatives and, unlike other asset classes, transaction reports are often supplementary to other data collections for our work. 3.9 We noted that transaction reports for FX derivatives are partially duplicative of data we receive under UK EMIR. We consider this to be a more appropriate and reliable source of information for monitoring FX derivative markets. 3.10 We also highlighted that removing FX derivatives from scope would create a data gap for UK branches of third country firms, which are not currently required to report under UK EMIR. We sought views on how this could be addressed.

12 Summary of feedback 3.11 All respondents supported our proposal to remove FX derivatives from the scope of the transaction reporting regime. Respondents broadly agreed that the current framework creates unnecessary duplication and operational burden. They also agreed that the UK EMIR data is a more appropriate source for monitoring FX derivative markets. 3.12 On the data gap for UK branches of third country firms, respondents identified several potential approaches to address this, including: • Substituted compliance, whereby firms would not be required to report in the UK where they are subject to equivalent requirements in their home jurisdiction. • Data sharing agreements with third country regulators, although respondents noted that this would be operationally complex and would require multiple bilateral arrangements. • Direct information requests to UK branches, which respondents considered workable on an ad hoc basis, but not suitable for ongoing supervisory use. 3.13 Respondents generally did not support expanding UK EMIR reporting requirements to include UK branches of third country firms at this time. They cited implementation complexity and costs. Our response: We will proceed with our proposal to remove FX derivatives from the scope of the UK transaction reporting regime. We maintain that UK EMIR data is a more appropriate and effective source for monitoring these markets. This change is also consistent with our long-term approach to harmonising transaction and post-trade reporting requirements. We acknowledge this will create a data gap for UK branches of third country firms. We will explore how to address this gap as part of the work to repeal and replace reporting requirements on OTC derivatives in Title II of UK EMIR. We will not take supervisory action against firms that do not submit transaction reports for FX derivatives during the implementation period (from 3 August 2026 until the new rules come into force on and including 3 April 2028), provided these firms submit UK EMIR data for the same transactions. These firms may therefore be able to realise significant cost savings ahead of the implementation date. Firms which do not submit UK EMIR data, such as UK branches of third country firms, must continue to meet applicable requirements during the implementation period. This change applies to options, futures, swaps, forward rate agreements and any other derivative contracts relating to currencies which may be settled physically or in cash. It does not apply to derivative contracts relating to cryptoassets.

13 The ‘Traded on a trading venue’ (TOTV) concept Summary of our proposal 3.14 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 instrument reference data details as an exchange traded derivative. 3.15 To provide more certainty for firms when determining their reporting obligations, we proposed new guidance to support the definition of a reportable financial instrument. MAR 14.5.4G

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 instrument reference data published by the FCA, it should be considered to be a reportable financial instrument. Summary of feedback 3.16 Respondents generally supported our proposed guidance on the reportability of derivatives not tradeable on a trading venue, noting the additional clarity provided. Many emphasised that firms must be able to rely on FCA FIRDS as a golden source. 3.17 However, several warned that the proposed guidance may not materially simplify scope determination, as complex reference data checks remain. Some requested more explicit definitions, public lists of in-scope instruments and examples. Our response: We will proceed with the proposed guidance. We note requests for examples and will consider these in the Transaction Reporting User Pack.

14 Reporting financial instruments under UK MiFIR Article 26(2) (c) Summary of our proposal 3.18 We wanted to reduce the cost and complexity of determining the reportability of derivatives where the underlying is an index. So, we proposed to simplify eligibility assessment by permitting firms to voluntarily ‘over-report’ such transactions. 3.19 We also proposed more flexibility for reporting basket derivatives by allowing firms to report International Securities Identification Numbers (ISINs) for all underlying instruments in the basket, irrespective of whether these are in FCA FIRDS. Currently, only ISINs in FCA FIRDS should be included in the underlying instrument field. Summary of feedback 3.20 Respondents overwhelmingly supported these proposals. Some questioned whether indices should remain in scope where the UK ‘nexus’ is limited. Others suggested we could maintain and publish a list of selected reportable indices. Our response: We will proceed with the additional guidance as consulted. We believe this is a pragmatic approach to reducing disproportionate costs on firms conducting due diligence. Where transactions are reported on a voluntary basis, they should be reported in line with applicable requirements for transactions in similar reportable financial instruments. In this case, derivatives where the underlying index contains one or more reportable financial instruments. We are not introducing a prescribed list of reportable indices. It would be difficult to define and maintain to provide meaningful simplification. Conditional single-sided reporting Summary of our proposal 3.21 Article 4 of Regulatory Technical Standard (RTS) 22 sets out conditions where a ‘receiving firm’ submits its transaction report including details provided by a firm carrying out reception and transmission. Most firms do not make use of these arrangements. Only 138 firms acted as a receiving firm in 2025, down from 164 in 2024. 3.22 In CP25/32, we proposed changes to enable more firms to benefit from CSSR. These changes included:

15 • Reducing the number of information points that need to be provided by the sending firm from 10 to 4. • Enabling CSSR to be used by a firm acting in DEAL and MTCH trading capacities. • Designating clearer responsibility for the completeness and accuracy of information reported by the receiving firm. Summary of feedback 3.23 Most respondents viewed the proposed CSSR model as unworkable and unlikely to achieve meaningful simplification. They argued that the proposal would shift responsibility and operational risk from buy-side firms to sell-side firms. This would increase workload and reconciliation efforts for receiving firms. 3.24 While recognising that fewer data fields would be transmitted, most firms considered that practical difficulties remain. The model still requires sensitive data exchange, contractual agreements and controls around personal data. These conditions have previously limited the uptake of the transmission regime and are unlikely to change under the new proposal, stakeholders argue. 3.25 It was noted that the model would likely benefit a small subset of market participants, including buy-side firms trading exclusively with UK brokers. However, as many firms operate globally and regularly trade with non-UK counterparties, they would still need to maintain reporting infrastructure, reducing cost savings. Some warned that CSSR may even increase overall complexity by forcing participants to maintain parallel models depending on counterparty jurisdiction. 3.26 Respondents recommended alternatives such as unconditional single-sided reporting, based on clear waterfall logic, or an exemption from reporting for buy-side firms. These alternatives were recommended by most buy-side stakeholders, who referenced disproportionate burdens and limited supervisory value in duplicated transaction reports. Some respondents also expressed concern that CSSR could become commercialised, leading to uneven access. 3.27 Most respondents recognised the theoretical logic of splitting responsibilities for data quality in conditional single-sided reporting, where the sending firm is accountable for the data it transmits, and the receiving firm is responsible for the remaining fields it reports. However, many expressed practical concerns for receiving firms, specifically: • Liability for back reporting if the sending firm’s data is wrong. • Need for reconciliation and validation controls that erode anticipated savings. • Data inconsistencies due to differing interpretations of fields. 3.28 Respondents did not express major concerns to extending CSSR to DEAL and MTCH trading capacities. However, many requested additional guidance and examples. They noted the absence of an order-transmission chain in many DEAL/MTCH scenarios, making it unclear who is the ‘sending firm’.

16 Our response: We recognise the concerns raised by market participants. However, CSSR was not intended to provide comprehensive relief from transaction reporting to buy-side firms. Buy-side data is critical for our monitoring of market functioning, firm activities and financial stability. We require data on transactions executed by transaction reporting firms with firms that are not subject to transaction reporting requirements in the UK. This data can only be provided by transaction reporting firms. Our aim was to enable more firms to benefit from the existing transmission mechanism. We consider it can represent an efficient way to reduce the overall number of transaction reports submitted to us, while maintaining the provision of critical information. We believe the proposed framework has the potential to benefit many firms, including those already relying on transmission under RTS 22 Article 4. So, we intend to proceed with the proposed CSSR framework. We understand that CSSR is unlikely to be a workable model for transactions involving natural persons. However, 92% of transaction reports submitted in 2025 did not contain personally identifiable information (PII) in the buyer, seller or buyer/seller decision maker fields. CSSR may also simplify reporting of transactions executed between transaction reporting firms within the same group (eg for risk￾management purposes), where contractual challenges may be easier to navigate. A key feature of the CSSR model is its optionality. Transaction reporting firms will have discretion when and where to act as a receiving firm, if at all. We did not include cost savings from CSSR in our cost benefit analysis, recognising that take-up would be difficult to predict. However, we will monitor market developments closely to identify any unintended commercial consequences of our proposals leading to harm. Our proposals for the responsibility of data quality operate more effectively in theory than in practice. However, we do not view it as appropriate or proportionate for either the sending or receiving firm to be fully responsible for the data submitted. While receiving firms may face operational costs to correct inaccurate data received from sending firms, this risk could be mitigated by contractual arrangements between the parties. We will take a pragmatic supervisory approach in these cases, recognising that receiving firms may be reliant on co-operation by sending firms to ensure remediation. We will include examples for CSSR in different trading capacities in the Transaction Reporting User Pack. This should reduce the risk of data inconsistencies arising due to different interpretations of reporting fields.

17 Exclusions Summary of our proposal 3.29 We reviewed the exclusions from the definition of a transaction to ensure they remain fit for purpose. This included expanding the scope of exclusions for corporate actions, regardless of whether an investment decision on the part of the investor is required. Our expectations for initial public offerings (IPOs), secondary public offerings, placings and debt issuance remain unchanged. 3.30 We also proposed to expand the exclusion in RTS 22 Article 2(5)(g) and amend Article 2(5)(m) to simplify the rules. 3.31 We proposed to allow firms flexibility to continue to report corporate event activity. This will benefit firms who consider that the cost and complexity of excluding these reports is greater than the cost of submitting them. Summary of feedback 3.32 There was support for our proposals. Respondents welcomed the reduction in complexity when determining reporting obligations for corporate event activity. 3.33 However, respondents highlighted the need to clarify ambiguous wording in MAR 14 related to these changes. Some requested further consideration of exclusions relating to post-trade risk reduction services. Our response: We have amended MAR 14.2.4R(9) to clarify our intended objective for corporate actions. The exclusions provided for in MAR 14.2 apply to all corporate event activity except for IPOs, secondary public offerings, placings or debt issuance. We have widened the scope of exclusions under MAR 14.2.4R(6) to include all eligible post-trade risk reduction services. Currently, only portfolio compressions are exempt. We agree that a wider exemption would streamline reporting requirements without compromising our data needs. Fractional instruments Summary of our proposal 3.34 We proposed to clarify the treatment of fractional instruments within the transaction reporting regime. The proposal was intended to provide clarity and improve consistency in reporting, given the growth in fractional trading activity.

18 Summary of feedback 3.35 Respondents showed strong support for the proposal to clarify the treatment of fractional instruments. No respondents disagreed. 3.36 Respondents broadly agreed that additional clarity is needed and would improve consistency across firms. They highlighted that firms are already reporting fractional instruments, but with divergent interpretations. Clearer rules would improve consistency across firms and support better data quality. 3.37 Some respondents requested further guidance on implementation, specifically on how fractional quantities should be represented (including decimals and rounding) and the inclusion of examples in the Transaction Reporting User Pack. Our response: We will proceed with the proposal as consulted. We recognise respondents’ requests for implementation clarity. We will provide examples in the Transaction Reporting User Pack to support consistent application. OTC derivative identifiers Summary of our proposal 3.38 Financial instruments tradeable on a UK trading venue must be identified with an International Organization for Standardization (ISO) 6166 ISIN. For OTC derivatives, including those traded on multilateral trading facilities (MTFs) and organised trading facilities (OTFs), the Derivatives Service Bureau (DSB) issues ‘OTC ISINs’ with an EZ-prefix. 3.39 For OTC derivatives with dynamic, daily changing attributes, investment firms and trading venues must get and report new OTC ISINs every day. There are nearly 12 million active OTC ISINs in FCA FIRDS. These account for 66% of all active financial instruments on the system. 3.40 We examined different options to improve outcomes for market participants in this area. The ISO 4914 Unique Product Identifier (UPI) represents a more appropriate identifier for OTC derivatives in UK EMIR. But its use within the Markets in Financial Instruments Directive (MiFID) transaction reporting regime would risk adding complexity or increasing the number of reportable transactions materially. 3.41 We proposed to maintain the OTC ISIN as the identifier for OTC derivatives, while supporting work to modify relevant OTC ISIN templates to create a more stable identifier for derivatives in asset classes such as rates.

19 Summary of feedback 3.42 Most respondents supported our proposed approach to retain the OTC ISIN, mainly to avoid added complexity and unintended scope expansion. A strong recurring theme was that international harmonisation would be necessary to avoid additional burden. Several respondents said any change to OTC ISIN templates should be coordinated with other regulators and standards bodies. 3.43 Around a third of respondents disagreed with our proposal. Most of these respondents argued for adopting UPI, reiterating that the OTC ISIN is ill-suited for OTC derivatives. Respondents suggested that the UPI could be reported with a small set of additional reference data fields to prevent expanding scope. Our response: We will maintain the OTC ISIN as the identifier for OTC derivatives in transaction reports. We do not consider it proportionate to implement the UPI as an identifier for OTC derivatives in MAR 14 while we are reviewing the scope of reporting obligations for OTC derivatives as part of our long-term harmonisation review. It may result in wasted effort, if changes proposed to reduce duplication between MAR 14 and UK EMIR result in OTC derivatives being reported under UK EMIR only. The DSB Product Committee intends to review and modify OTC ISIN templates to address the daily rolling ISIN issue. We continue to support and engage with this work. Changes to OTC ISIN templates may require additional changes to be made to transaction and instrument reference data reporting requirements. Any such changes would be consulted on separately. Meaning of a ‘transaction’ Summary of our proposal 3.44 We proposed clarifying the definition of a transaction by linking acquisitions and disposals to changes in economic exposure. For derivatives, increases in notional are treated as acquisitions, and decreases as disposals. We also clarified reportability for entering into, closing out and modifying derivative positions. Summary of feedback 3.45 There was broad agreement that our revised definitions improve clarity for firms, aligning with existing interpretations for delivery lifecycle events. 3.46 Some respondents expressed qualified support, highlighting the need for practical examples related to edge-case and complex scenarios. There were also requests to

20 clarify that our proposal codified existing expectations rather than broadened reporting obligations. Our response: We will proceed with the proposal. Our expectations for firms have not changed and the addition of the guidance is not expected to bring about an increase in scope of firms’ reporting obligations. We will add examples in the Transaction Reporting User Pack. Meaning of ‘execution of a transaction’ Summary of our proposal 3.47 We proposed introducing guidance in MAR 14.4.2G–14.4.6G to explain when an investment firm is deemed to have executed a transaction. Our proposal aimed to codify existing practice and improve consistency without expanding the scope of reporting obligations. Summary of feedback 3.48 Respondents agreed that the proposed guidance was helpful and should reduce inconsistent reporting practices. There were some concerns that the guidance could amount to a policy change, rather than clarifying existing expectations. Our response: Our expectations for firms have not changed. The addition of this guidance is not expected to increase the scope of reporting obligations. We will proceed with the additional guidance. Branch execution Summary of our proposal 3.49 We proposed to add new rules and guidance in MAR 14.13.25R to MAR 14.13.31G to provide clarity on when branches have executed a transaction.

21 Summary of feedback 3.50 Respondents supported the proposed changes, viewing them as a helpful step towards greater clarity and consistency for firms operating branches. Many highlighted that additional examples would aid consistent implementation, principally for firms operating complex cross-border entity booking models. In particular, some respondents called for further guidance on when a non-UK firm’s trader is physically located in a UK branch but supervised by the non-UK parent firm. Our response: We will proceed with the new rules and guidance on branch execution. We will add more examples on branch execution to the Transaction Reporting User Pack. Due to the varied and bespoke nature of corporate structures and operating models, these are likely to be principles based.

22 Chapter 4 Content of transaction reports Trading venue transaction identification code Summary of our proposal 4.1 In CP25/32, we noted data quality issues caused by inconsistent provision of trading venue transaction identification codes (TVTICs) by trading venues and investment firms failing to report them accurately. However, these data quality issues were concentrated in a subset of firms’ reporting. So, we did not propose any changes to our rules, other than to limit reporting of the TVTIC to transactions executed on UK trading venues. Summary of feedback 4.2 Views were mixed, with generally opposing views between trading venues and investment firms. Some respondents supported our proposal, highlighting potential costs from mandating firms to make changes. Trading venues emphasised that mandating a single TVTIC format could be operationally disruptive and that flexibility is needed to accommodate different system architectures. 4.3 Other respondents disagreed. They emphasised persistent inconsistency and complexity in TVTIC formats across trading venues, leading to errors, remediation and increased reporting costs. Many called for us to create more standardisation, ideally requiring trading venues to provide a single, fully formed TVTIC in a clearly labelled field. Other suggestions included replacing the TVTIC with a global identifier such as the ISO 23897 unique transaction identifier (UTI). 4.4 Respondents expressed qualified support for our proposal to limit reporting of the TVTIC to transactions executed on UK trading venues only. While agreeing this would be welcome, we were encouraged not to prevent firms from reporting a TVTIC for transactions executed on EU trading venues. It was suggested this may be easier for some firms with reporting obligations in the EU. Our response: We are not making any changes to our proposal at this stage. We recognise that some firms believe changes would improve the completeness and accuracy of reporting. However, we intend to monitor data quality in this area closely and conduct targeted supervisory work before deciding whether to make changes. We note that matching rates for the TVTIC have improved further since we published CP25/32 from 83% in the sample taken from Q2 2025 to 87% for a sample taken in Q2 2026.

23 Transaction reporting firms Summary of our proposal 4.5 To simplify our new rules, we proposed 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. 4.6 We suggested updating the name of RTS 22 Field 5 (Investment Firm covered by Directive 2014/65/EU) to ‘Executing entity is a transaction reporting firm’, noting this may make its intended purpose clearer and improve data quality. Summary of feedback 4.7 Most respondents supported our proposal. One respondent suggested clarifying that a third country investment firm carrying on MiFID or equivalent third country business from an establishment in the UK would only be a transaction reporting firm in respect of activities conducted by the establishment in the UK. 4.8 Some respondents disagreed with the proposal not to include collective portfolio management investment (CPMI) firms in the definition. They noted this would result in more comprehensive data being submitted, reducing the risk of market abuse. 4.9 All respondents agreed with our proposal for RTS 22 Field 5. Our response: We will proceed with the proposed definition of a 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. We are considering reporting obligations for some MiFID investment firms, including CPMI firms, as part of our Fund Reporting for Asset Management Entities review (CP26/26). We will proceed with our proposed change to RTS 22 Field 5. Identifying trusts in transaction reports Summary of our proposal 4.10 Trusts must currently be identified with a Legal Entity Identifier (LEI) in all cases other than where an investment firm knows the underlying client and set up the trust arrangement. This leads to inconsistent identification of trusts in transaction reports.

24 It also adds costs for trust beneficiaries in cases where a national identifier may be used appropriately. 4.11 We proposed to allow investment firms to report either a trust LEI or national identifier of the beneficiary when executing a transaction for a trust. Our aim was to introduce more flexibility in this area to reduce costs on market participants and facilitate more consistent identification of trusts. Summary of feedback 4.12 Most respondents supported our proposal. They viewed this flexibility as a practical and proportionate solution. In particular, given the inconsistent LEI adoption across different types of trusts and the operational difficulty of obtaining LEIs in all cases. Many noted that the option avoids unnecessary administrative burden, especially for simpler trust structures with a single beneficiary. 4.13 Some respondents suggested introducing a waterfall logic for reporting. This would require investment firms to use an LEI where one already exists, and the beneficiary of the trust in other cases. They highlighted this would ensure consistent identification of trusts that already have an LEI, while enabling new trusts to benefit from more flexibility. 4.14 Other respondents emphasised that the LEI remains the preferred global standard. They said this should be used whenever available to promote consistency, data quality and cross-border alignment. A smaller number raised concerns that offering dual options may introduce system complexity, increase implementation costs or fragment internal controls. Our response: We have updated our proposal in MAR 14.13.10G(2) to require the use of a trust LEI where one already exists. A transaction reporting firm may identify the beneficiary or beneficiaries of that trust only when a trust LEI does not already exist. Identifying clients in transaction reports Summary of our proposal 4.15 Transaction reporting firms are required 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. We proposed to extend this requirement to cover transactions executed for natural persons (MAR 14.13.24R). 4.16 If a natural person is identified as a buyer or seller in a transaction report (including as a buyer or seller decision maker), it must include their details. This includes the full name and date of birth of the individual as well as a national identifier.

25 4.17 Firms should ensure that no transaction is executed for a client until the relevant national identifier has been obtained, internally reviewed, and validated. Where available, first-priority national identifiers must be used to identify natural persons in transaction reports. Summary of feedback 4.18 There was broad agreement with the proposal. Respondents noted that the change aligns with standard industry practice and that it would support data quality at source, reducing post-trade operational burden. 4.19 Respondents sought clarification whether the proposal covered transaction reporting by a trading venue for transactions executed through its systems. Respondents also queried how to treat exceptional cases where transactions need to be executed for a client which has not provided a national identifier. For example, contractual asset sales to cover fees owed by a non-responsive client. Our response: We have made the rule as consulted. We believe this will provide an important data quality control and should not be operationally challenging or burdensome for transaction reporting firms. MAR 14.13.24R applies to transaction reporting firms. Our expectations for trading venues reporting transactions executed through their systems are reflected in MAR 14.8. Trading venues are not subject to an identical pre-trade obligation to obtain national identifiers. However, they are expected to have arrangements with their member, participant or client to make sure complete and accurate underlying client information is provided. Trading venues should also check that national identifiers provided do not contain obvious errors or omissions. Trading on a trading venue where the identity of the counterparty is not known at the point of execution Summary of our proposal 4.20 We proposed that firms should report the segment Market Identifier Code (MIC) of the trading venue in the buyer or seller identification fields for all scenarios where it does not know the counterparties at the point of execution.

26 Summary of feedback 4.21 Respondents noted that the proposal could simplify reporting for some firms. But some were cautious around potential divergence with EU MiFIR. They questioned whether the implementation cost would be justified by proportionate additional supervisory value. Our response: We will not proceed with our proposal based on the feedback received. We will instead codify the existing practice of using a central counterparty (CCP) LEI for transactions executed on a trading venue where the identity of the counterparty is not known at the point of execution. The segment MIC of the trading venue should be used when the trading venue does not use a CCP. Firms should not need to make any changes to existing reporting processes. Identifying natural persons in transaction reports Summary of our proposal 4.22 We set out 3 proposals on the identification of natural persons. Our aim was to consolidate existing guidance and market practice into our rules. • We proposed to incorporate existing guidance for generating a concatenated identifier, commonly referred to as CONCAT, into our rules. • We proposed a new rule to confirm that natural persons from the Isle of Man, Gibraltar, the Channel Islands and other British Overseas Territories should be identified using the MAR 14 Annex 2 approach for ‘all other countries’. • We clarified that, where a natural person holds more than one non-European Economic Area (EEA) nationality, the national identifier should use the country code of the first nationality in alphabetical order, based on the ISO 3166-1 alpha-2 code. Summary of feedback 4.23 There was significant and widespread support for the proposals. Respondents expressed strong consensus in favour of deterministic CONCAT rules to improve consistency. They were widely seen as straightforward to implement and beneficial in enhancing consistency across firms. Our response: We will proceed with the new rules and guidance for the identification of natural persons.

27 Transmission of order indicator Summary of our proposal 4.24 We proposed removing the transmission of order indicator, noting the limited value we receive from the information and the cost of the field to firms to populate. Summary of feedback 4.25 96% of respondents agreed with the proposal, often citing that populating the field is counterintuitive and confusing. One respondent queried the impact of removing the field on CSSR. Our response: We will proceed with the change to remove the transmission of order indicator. We do not expect the proposal to impact CSSR. ‘Sending’ firms benefitting from CSSR will be identified through the sending firm identification code for the buyer/seller fields. Trading capacity Summary of our proposal 4.26 Under existing guidelines, firms are required to report the trading capacity and the buyer and seller fields so the values are consistent when viewed together. We proposed to incorporate these guidelines as new rules: MAR 14.13.32R 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. Summary of feedback 4.27 Most respondents supported our proposal. Stakeholders broadly agreed that the rule improves clarity, reduces ambiguity and promotes more consistent reporting, while not impacting current approaches.

28 4.28 Several respondents questioned MAR 14.13.32R(3), and specifically the distinction between MTCH and AOTC trading capacity. Some suggested there was no need to introduce this rule. They noted there may be MTCH or AOTC trading scenarios where neither the buyer nor seller are clients of the firm. Our response: We will remove MAR 14.13.32R(3) as a result of the feedback received. We will make MAR 14.13.32R(1) and (2) as final rules. Price field for equity swaps Summary of our proposal 4.29 For equity swaps with a single underlying, we proposed that firms should report the price of the underlying instrument in the price field (rather than the spread on the financing rate). 4.30 For equity swaps with multiple underlyings, we proposed a flexible approach. Firms should report the reference price of the underlying instrument(s) or index where this can reasonably be derived. Where this is not practicable, firms may instead report the spread on the financing rate. This recognises the challenges in deriving a single meaningful price for more complex products. Summary of feedback 4.31 Respondents expressed broad support. They emphasised that the underlying price would help simplify reporting and improve comparability across firms, provided it is applied consistently. Many also highlighted the importance of alignment across economically equivalent products and regimes. 4.32 However, respondents requested clearer guidance on how the underlying price should be determined, including reference sources and timing. For swaps with multiple underlyings, the overall approach was supported. However, respondents highlighted that the ‘where available’ feature of the rule could lead to inconsistent application without further examples or detailed guidance. Our response: We will proceed with the proposal and add additional examples in the Transaction Reporting User Pack. We will engage with industry to understand areas of operational complexity. We will confirm expectations for the use of ‘NOAP’ where the reference price of the underlying is not available.

29 SwpIn and SwpOut Summary of our proposal 4.33 We proposed to remove the SwpIn (+) and SwpOut (-) reporting tags, which add complexity and provide limited additional insight into the direction of equity swaps. Summary of feedback 4.34 There was overall support for the proposal. Swp tags are widely seen as confusing and of limited value. Respondents requested additional clarity and guidance for reporting equity swaps where equity instruments are being exchanged for other equity instruments. Our response: We will proceed with the proposal. We will include new examples in the Transaction Reporting User Pack. Venue Summary of our proposal 4.35 We proposed to confirm in our rules that the trading venue MIC must be populated in the venue field for transactions which are negotiated away from but brought under the rules of a trading venue. 4.36 The venue field should be populated with a systematic internaliser (SI) MIC when a transaction is executed with an SI. We understand that firms do not always know whether the firm they are dealing with is acting as an SI for a transaction. We proposed 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. Summary of feedback 4.37 Most respondents agreed with the proposed changes to the venue field. They noted that the rules codified existing practices and demonstrated a pragmatic approach. A minority suggested that transactions with an SI could be reported with XOFF in the venue field as a more efficient alternative.

30 Our response: SI MIC reporting helps us understand market dynamics. We will proceed with the change, while highlighting that the SI regime no longer applies for bonds, derivatives, structured finance products and emission allowances, following the changes in Policy Statement (PS) 25/17. We expect this to materially reduce the number of transactions for which firms must determine whether they are dealing with an SI. Instrument details Summary of our proposal 4.38 We proposed to remove RTS 22 fields 50 (Option type), 53 (Option exercise style) and 56 (Delivery type). These fields must be populated for certain derivatives which are not reported with an ISIN that exists in FCA FIRDS. However, the information can be derived from the ISO 10962 Classification of Financial Instruments (CFI) code reported for the instrument. Summary of feedback 4.39 All respondents agreed, welcoming the proposal as a positive step to reduce duplication. Several respondents requested immediate supervisory flexibility for these fields so they could benefit earlier. Some highlighted that validation rule changes would be required to avoid rejections where these fields are mandatory. Our response: We will proceed with the proposal to remove these fields. We intend to take a pragmatic approach to delivering these changes, as set out in Chapter 6. Maturity date Summary of our proposal 4.40 We proposed to remove RTS 22 Field 54 (Maturity date). For financial instruments with a defined maturity, we consider this information can be sourced and maintained more reliably in instrument reference data, rather than being reported at transaction level.

31 Summary of feedback 4.41 Feedback was strongly supportive, with no respondents opposing the proposal. They agreed that the field is duplicative and contributes to data quality issues and operational burden. Respondents again noted that immediate supervisory flexibility for these fields would be beneficial. Our response: We will proceed with the proposal to remove RTS 22 Field 54. We describe our approach to implementation in Chapter 6. Notional currency 2 Summary of our proposal 4.42 We proposed to remove RTS 22 Field 45 (Notional currency 2). The proposal was intended to simplify transaction reporting by removing a field that provides limited additional supervisory value. Summary of feedback 4.43 Feedback was overwhelmingly supportive, with no respondents opposing the proposal. They agreed that the field is duplicative, noting that currency information can already be sourced from other elements of the reporting framework. 4.44 Respondents also highlighted that the field has been a source of data quality issues, generating operational complexity and supervisory queries without commensurate benefit. A small number raised alignment with UK EMIR as an implementation consideration rather than an objection to removal. Our response: We will proceed with the proposal to remove RTS 22 Field 45. We acknowledge feedback on alignment with UK EMIR and will consider cross-regime consistency as part of our broader harmonisation work.

32 Strike price Summary of our proposal 4.45 We proposed to allow ‘NOAP’ to be reported in the strike price field where the strike price cannot be determined at the point of execution. Summary of feedback 4.46 All respondents agreed with the proposal, noting this would provide more clarity than where ‘0’ is reported. Respondents asked for additional examples to support consistent use and validation. Our response: We have made the rule as consulted. We will include examples in the Transaction Reporting User Pack. Indicator fields Summary of our proposal 4.47 We proposed to remove RTS 22 fields 61-65 (the waiver indicator, short selling indicator, OTC post-trade indicator, commodity derivative indicator and securities financing transaction indicator). These fields provide limited supervisory value, and we have been taking a flexible supervisory approach to reduce costs for firms. Summary of feedback 4.48 All respondents supported the proposal, recognising that data quality for these fields has been challenging and the data is not consistently used. Our response: We will proceed with the removal of RTS 22 fields 61 to 65. In Chapter 6, we confirm that our existing supervisory flexibility in this area will apply until the fields are removed.

33 Client indicator field Summary of our proposal 4.49 We proposed to remove RTS 22 fields 8 and 17 (country of the branch for the buyer and seller) and replace them with new Boolean client indicator fields for the buyer and seller. We have seen persistent data quality issues with these fields, with inconsistent use across firms. Our aim was to provide a more targeted capture of client relationship information. Summary of feedback 4.50 Feedback was largely supportive. Respondents agreed that a client indicator would be a simpler way to report this information, improving clarity, data quality and alignment with supervisory use cases. A small number of respondents questioned whether this information is necessary and proportionate to the cost of implementation. 4.51 Some respondents raised challenges focused on implementation (for example, in obtaining client information) and requested clearer definitions and guidance. One respondent queried our approach to defining the term ‘client’ in MAR 14. Our response: We will proceed with removing RTS 22 fields 8 and 17 and introducing Boolean client indicator fields for the buyer and seller. We consider this approach more proportionate and better aligned with our supervisory needs. We will include examples in the Transaction Reporting User Pack. We have chosen not to italicise terms in the annexes to MAR 13, 14 and 15. Any intended policy changes have been addressed in the consultation paper and policy statement. Direct electronic access indicator Summary of our proposal 4.52 We proposed to add a new reporting value to indicate where a firm is providing direct electronic access (DEA). This new value, ‘DEAU’, would be reported in the execution within firm field instead of the existing ‘NORE’ value. DEA users would not need to make any changes. Summary of feedback 4.53 Most respondents supported the proposal. Some requests were made to define ‘DEA’ to ensure consistent application by market participants.

34 Our response: We will proceed with the proposal. Our Glossary of definitions includes a definition for ‘direct electronic access’. While this term is not italicised for these rules, where it is used, firms can understand the term to have the same meaning. Package transactions Summary of our proposal 4.54 We proposed replacing RTS 22 Field 40 (Complex trade component id) with a new field (Package identifier) which would reference a new definition of a ‘package transaction’. Our aim was to harmonise requirements with UK EMIR by moving away from the stricter definition of a ‘complex trade’, which requires one price and simultaneous execution. 4.55 We proposed that the content of the field would also specify that, where possible, the identifier reported should mirror the ‘package identifier’ for the same transaction(s) under UK EMIR. 4.56 We did not reference the existing definition of a ‘package transaction’ in our Glossary of definitions. This definition was designed for the transparency regime and differs from UK EMIR, as it requires package legs to be executed simultaneously. Summary of feedback 4.57 Most respondents strongly supported our approach. However, a significant number opposed maintaining different definitions for a package transaction between the transparency regime and others. 4.58 Some respondents requested clarity on the practical impact of the change, and how a ‘package transaction’ would differ from a ‘complex trade’. Our response: We will proceed with the proposal. We recognise the operational synergies that could be gained by further harmonising transaction reporting and UK EMIR definitions with the transparency regime. We may consult on changes in due course to further harmonise definitions.

35 Price field for package transactions Summary of our proposal 4.59 We proposed introducing a second price field to enable us to capture both the leg and package prices of package transactions. We noted we would not always expect both prices to be reported, as they may not always be available. Summary of feedback 4.60 Most respondents supported the proposal, noting that the change would provide more comprehensive execution details. Some requested guidance on the trading scenarios in which we would expect package-level and leg-level prices to be reported, respectively. Others stressed the importance of ensuring validation rules do not require both prices to be reported in every package transaction. Our response: We will proceed with the proposal. Our validation rules will permit the use of ‘NOAP’ where a price cannot be derived. We will provide examples in the Transaction Reporting User Pack. Aggregate client linking code Summary of our proposal 4.61 We proposed not to introduce a new aggregate client linking code. We stated that while this may help some firms improve data quality, implementation and change costs would likely offset potential benefits. Summary of feedback 4.62 Views on maintaining these requirements were generally supportive, though with varying levels of enthusiasm. Most respondents agreed, describing the current approach as well understood, operationally stable, and preferable to avoid system changes. 4.63 Some respondents expressed support while emphasising the need for clearer guidance to support data quality for ‘INTC’, especially for edge cases and complex trading chains to prevent inconsistent application across firms. Our response: We will proceed with the proposal. We will review guidelines for use of ‘INTC’ when preparing the Transaction Reporting User Pack.

36 Systems and controls for transaction reporting Summary of our proposal 4.64 We did not propose any changes to the rules and guidance around systems and controls for transaction reporting. The existing requirements in RTS 22 Article 15 were recreated in MAR 14.14. 4.65 We asked whether market participants had any other feedback on our proposed changes in MAR 14. Summary of feedback 4.66 Several respondents called for more guidance on our expectations for transaction reporting systems and controls, including materiality thresholds for the submission of breach notifications. Our response: We will add new guidance to provide clarity regarding our expectations for a transaction reporting incident management framework. This guidance aligns with best practice observations made in Market Watch 81 and 82. We are not proposing to add a materiality threshold for the submission of breach notifications at this stage. MAR 14.15.5G A transaction reporting firm or the operator of a qualifying trading venue that has submitted a transaction report under MAR 14.8 should establish and maintain a robust incident management framework to address any errors or omissions in any such transaction report. This incident management framework should be adequate and proportionate to the nature, scale, and complexity of the business of the transaction reporting firm or the qualifying trading venue and enable the firm or operator to: • triage, assess and manage incidents of errors and omissions; • undertake an analysis of the cause of the error or omission; • implement and monitor the progress of remedial actions to prevent the error or omission reoccurring; • operate an internal escalation protocol; and • notify the FCA under MAR 14.15.6R.

37 Chapter 5 Obligations on trading venues Transaction reporting by trading venues Summary of our proposal 5.1 Our work with trading venues suggests the requirement to collect PII for investment and execution decision makers (IDM/EDM) may be discouraging non-UK firms from participating in UK financial markets. This data is also prone to errors because trading venues do not directly oversee the individuals it relates to. While this information is useful to us, its value may not be proportionate. 5.2 So, we proposed disapplying the ‘investment decision within firm’ and ‘execution within firm’ fields for MAR 14.8 transaction reporting by trading venues, where the IDM/EDM is a natural person. If we require this information, we proposed to obtain it directly from the executing entity, or work with other public authorities if the entity is a non-UK firm. 5.3 We also proposed to make it clear that negotiated transactions are in scope of MAR 14.8 transaction reporting by trading venues, on behalf of the firm(s) who brings the negotiated transaction onto the exchange. Summary of feedback 5.4 Most respondents agreed with our proposal, noting potential benefits to the international competitiveness of UK financial markets. Some trading venues cited the burden of transaction reporting more widely. They noted that they must collect, validate and assume compliance risk for third-party data without practical means to compel timely or accurate information. Some called for broader reforms. For example, removing the requirement for trading venues to identify the underlying clients of its members. Our response: We will proceed with our proposal to reduce information requirements for trading venues. We will introduce a new code (‘NPEX’) to be used by trading venues in the IDM/EDM fields to indicate that the investment or execution decision was made by a natural person, but that there is no requirement to identify them. Existing requirements will continue to apply where the investment or execution decision was made by an algorithm. We considered different options to further reduce burden on trading venues. However, we felt that all of these would lead to an unacceptable loss of market oversight and strongly hinder our ability to detect market abuse and conduct effective market monitoring.

38 Article 26(5) reporting for natural persons executing directly Summary of our proposal 5.5 Some trading venues allow natural persons to execute transactions directly through their systems. We proposed to explicitly include these transactions within the scope of transactions that must be reported by trading venues. Trading venues would populate their own LEI in the executing entity field for these transactions. Summary of feedback 5.6 No concerns were raised with our proposed approach. It was noted that trading venues which allow natural persons to execute transactions directly through their systems already report these transactions. Our response: We will proceed with the change. Our proposal for a revised RTS 22 Field 5 (Executing entity is a transaction reporting firm) would be populated with a ‘FALSE’ value in this scenario. FCA FIRDS Summary of our proposal 5.7 We said we would explore developing new functionality to improve the usefulness and accessibility of FCA FIRDS. We noted we will not need to make rule changes for these technical changes. 5.8 We proposed to enable firms to treat FCA FIRDS as a ‘golden source’. This would mean investment firms could exclusively use FCA FIRDS for determining whether a transaction is reportable. The only exception to this was for transactions executed on a UK trading venue, where the financial instrument should automatically be considered in scope. 5.9 Once a transaction is executed, we proposed that 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. 5.10 We proposed to 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 then rejected. This would be the case for pre-admission trading.

39 Summary of feedback 5.11 Most respondents agreed with the proposal to make FCA FIRDS a golden source. Responses argued that it will make it easier for firms to understand and fulfil their reporting obligations and determine instrument eligibility by nominating it as a single reference database. 5.12 Some respondents said recognising FCA FIRDS as a golden source will reinforce the importance of data quality and trading venues reporting instrument reference data in a complete and timely manner. 5.13 A number of responses noted that making FCA FIRDS more easily and readily searchable would help in fulfilling their reporting obligations. Some mentioned that we should be explicit in our expectations for transactions where relevant instrument reference data is only reported after 7 days. 5.14 Respondents supported our proposal to not take action against firms where they reasonably assume an instrument is in scope despite not being available on FCA FIRDS. Our response: We will move ahead with our proposal to make FCA FIRDS a golden source. We will also limit a firm’s obligation to determine whether a transaction is reportable based on FCA FIRDS to T+7, irrespective of where the transaction was executed. If the instrument (or its underlying) is not in FCA FIRDS by T+7, there would be no obligation to report. This is clarified in MAR 14.5.3G. We will proceed with our proposal to not take action against firms where they reasonably assume an instrument is in scope despite not being available on FCA FIRDS. We are exploring new functionality to improve the usefulness and accessibility of FCA FIRDS. Submitting instrument reference data Summary of our proposal 5.15 We proposed requiring trading venues to submit instrument reference data only 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.

40 5.16 We clarified that trading venues may choose to report instrument reference data more frequently, should they wish to avoid system changes. We also proposed to update references to Central European Time (CET) with Coordinated Universal Time (UTC), while maintaining applicable submission times to avoid requiring changes from trading venues. Summary of feedback 5.17 Most respondents agreed with the proposal to limit the obligation to submit instrument reference data. Some noted this would help reduce the regulatory burden by removing the need to send the same data multiple times. 5.18 While agreeing with our policy aim, a number of responses highlighted that the proposed rule in MAR 15.4.1 mistakenly adjusted the deadline for the submission of instrument reference data to 17:00 UTC. Our response: We will proceed with our proposal to only require trading venues to submit instrument reference data for the events listed above. Trading venues may still choose to report instrument reference data more frequently. We will proceed with our proposal to replace references to CET with UTC. We have corrected the deadline to submit instrument reference data in MAR 15.4.1 to align with current requirements (20:00 UTC). Admission to trading Summary of our proposal 5.19 We proposed to extend the concept of ‘admission to trading’ to MTFs which undertake primary market activities. For example, IPOs, secondary public offerings, placings or debt issuance. 5.20 We also proposed to remove derivative instruments from the concept of ‘admission to trading’ where the trading venue is the issuer. We said 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. 5.21 We proposed to 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.

41 5.22 For financial instruments where a request for admission has been made, we proposed to maintain the current trigger for an obligation to submit instrument reference data only when the instrument is admitted to trading. 5.23 We also proposed to clarify when RTS 23 fields 9 and 10 would apply. Namely, when there has been a formal request by an issuer or a third party acting on their behalf to admit an instrument for trading on a specific trading venue. 5.24 Lastly, we proposed to clarify how we expect the ‘Date of request for admission to trading’ to be populated. This should be with the earliest date at which an issuer or third party acting on their behalf initiates the admission process. Summary of feedback 5.25 Most respondents supported our proposal to expand the concept of admission to trading to MTFs involved in primary market-style activities (such as IPOs, secondary issuances, placings, or debt issuance). Some respondents emphasised the need for clear criteria defining which MTFs fall within scope. 5.26 Respondents broadly agreed with our proposal to remove derivative instruments from the concept of ‘admission to trading’. They noted this would help simplify regulatory requirements and obligations for trading venues. 5.27 Most responses agreed with our proposal to 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. It was noted this would help firms report ‘grey market’ activity in a timely manner. 5.28 Some respondents highlighted this may not align with our proposal to make FCA FIRDS a golden source. They queried how to handle scenarios where the relevant instrument reference data is not submitted within T+7. 5.29 Respondents agreed with our proposal to maintain the current trigger for an obligation to submit instrument reference data for financial instruments where a request for admission has been made. Support for our proposal to clarify expectations for how the ‘Date of request for admission’ field should be populated was broad, with a majority in support, noting that this would help support consistency. Our response: We will move ahead with our proposals to: • Extend the concept of ‘admission to trading’ to MTFs which undertake primary market activities, such as IPOs, secondary public offerings, placings or debt issuance. • Remove derivative instruments from the concept of ‘admission to trading’ where the trading venue is the issuer, specifying that MAR 13 fields 6, 7 and 8 would no longer apply to such instruments. • Allow firms to submit transaction reports for transactions executed in financial instruments before they are admitted to trading without first

42 determining the reportability of the instrument. • Maintain the current trigger for an obligation to submit instrument reference data for financial instruments where a request for admission has been made (ie when the instrument is admitted to trading, rather than when the request for admission was made). • Clarify that MAR 13 fields 7 and 8 only apply when there has been a formal request, either by an issuer directly, or a third party acting on their behalf, to admit an instrument to trading on a specific trading venue. • 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 admission process. SI instrument reference data Summary of our proposal 5.30 We proposed to remove the obligation for SIs to submit instrument reference data. We said we would keep the instrument reference data already submitted by SIs in FCA FIRDS to enable back reporting without firms having to source additional reference data to populate the instrument details. Summary of feedback 5.31 Most respondents were either supportive or neutral toward removing the obligation for SIs to submit instrument reference data. They noted it would simplify FCA FIRDS, reduce low-value or duplicative submissions, and have limited operational impact for firms whose SI-related activity is minimal or non-existent. 5.32 A minority opposed the change, warning that removing SI-submitted ISIN data could materially reduce market traceability and transparency. Our response: The SI regime is no longer applicable for bonds, derivatives, structured finance products and emission allowances, following the changes made in PS25/17. Before this, instrument reference data obligations for SIs only applied to financial instruments reportable under Article 26(2)(b) or (c) of UK MiFIR (as outlined in Market Watch 70). These instruments are no longer in scope of the SI regime. We will remove the obligation for SIs to submit instrument reference data. However, we recognise that this obligation no longer exists in practice due to changes made in PS25/17.

43 Instrument reference data fields Summary of our proposal 5.33 In CP25/32, we proposed to remove the following 11 fields from RTS 23: • 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). 5.34 We also proposed to clarify that instrument reference data should be updated when reported values change. This issue is particularly relevant to the following fields: • 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). 5.35 We also proposed to include ‘Retired’ as a valid status for LEIs reported for the issuer or operator of the trading venue identifier (Field 5). Summary of feedback 5.36 Most respondents agreed with our proposal to remove the fields above from RTS 23. Some noted that many could be derived from CFI codes, meaning they were effectively duplicative. Removing them would help reduce the regulatory burden, allowing trading venues to focus on more impactful data points. It was highlighted that this would increase the importance of data quality for the CFI. 5.37 Most respondents agreed with our proposal to include ‘Retired’ as a valid status for LEIs used in RTS 23 Field 5. Some noted it would help reduce instances where instrument reference data submissions are rejected.

44 Our response: We will move forward with our proposal to remove the 11 fields identified earlier from RTS 23, and to include ‘Retired’ as a valid status for LEIs used in RTS 23 field 5. We have changed remaining field numbers for clarity. Instrument reference data in FCA FIRDS shows the Currency of nominal value (Field 16) can be determined from Notional currency 1 (Field 13). We will remove the Currency of nominal value field to reduce duplicative reporting. Order book data Summary of our proposal 5.38 We proposed to align requirements for the ‘investment decision within 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. 5.39 We also proposed to amend the order restriction field, where the definitions of the terms ‘SESR’ and ‘VFCR’ do not align with their actual meaning. We outlined plans to consult further on the order book regime, as part of our long-term work to harmonise reporting requirements across regimes. Summary of feedback 5.40 Most respondents agreed with our proposal to align requirements for the ‘investment decision within firm’ and ‘execution within firm’ fields with the corresponding order book data fields. They argued this would help reduce regulatory burden. 5.41 Some suggested we should go further, by extending it to all orders and transactions, rather than restricting it to those submitted by firms that are not transaction reporting firms. They argued this data was burdensome to collect, sensitive to store and could be obtained from the member on request. 5.42 Respondents agreed with our proposal to address the discrepancies in RTS 24 field 11 (Order restriction) definitions for SESR and VFCR. Our response: We will proceed with our proposal to align requirements for the ‘investment decision within firm’ and ‘execution within firm’ fields with the corresponding order book data fields.

45 A number of responses suggested we should remove the obligation for trading venues to collect this data in all instances (as opposed to restricting it to firms with a transaction reporting obligation). We believe it is proportionate to continue collecting this data for orders involving firms that are required to provide this information in transaction reports, enabling us to link data. We will amend the standards in the order restriction field for the definitions of ‘SESR’ and ‘VFCR’.

46 Chapter 6 Our supervisory approach 6.1 This chapter summarises our supervisory approach to the regime during and after the implementation period. Back reporting Summary of our proposal 6.2 We proposed a change to our supervisory expectations, reducing the default back reporting period for correcting transaction reporting errors from 5 years to 3 years. Our aim was to reduce the burden on firms by lowering the volume of corrective transaction reports required, while continuing to ensure the integrity of data for our regulatory use cases. 6.3 We proposed to keep our ability to require back reporting for up to 5 years, on an exceptional basis, for serious reporting failings that could affect market abuse investigations or our ability to monitor key financial markets. Summary of feedback 6.4 Most respondents supported the proposal as a proportionate measure that would better reflect operational realities and reduce remediation burdens. Some requested clarity on the application of the proposal and how this would interact with implementation timelines. Many respondents said the reduced back reporting period should be applied as soon as possible. 6.5 Several respondents emphasised the importance of moving to a single schema following implementation. They raised concerns with the prospect of a parallel run to facilitate back reporting. 6.6 Some noted that our retained ability to require up to 5 years of back reporting could limit the intended simplification benefits of the proposal. Others called for us to set out the circumstances under which 5 years of data would be required. 6.7 A smaller number of respondents suggested that the back reporting period should be reduced further to 2 years to align with the Commodity Futures Trading Commission’s (CFTC) No-Action Letter No.25-43. 6.8 Others suggested that any reduction in the back reporting period should also be considered across UK EMIR and SFTR. These respondents considered that a consistent approach across regimes would reduce divergence and generate efficiency gains for globally active firms.

47 6.9 A small number of respondents suggested additional operational changes. This included the introduction of an ‘amend’ functionality to correct historical errors. Our response: Accurate transaction reports are essential to support our market abuse enquiries, which are often complex and require detailed analysis of data submitted over multiple years. Historical data also informs our longer￾term assessment of market patterns, trends and behaviours. We have considered reducing the default back reporting period further. Our analysis indicates that 3 years of data represents the most important period for supporting market abuse investigations and long-term market analysis. Reducing the period further would increase the risk of impeding our work. It could also result in more ad hoc data requests for accurate historical information. Respondents indicated that could be more burdensome for firms than applying a clearly defined back reporting period. So, we will proceed with our proposal to reduce the default back reporting period to 3 years. We have made this expectation explicit with new guidance in MAR 14.15.4G. The requirement to correct inaccurate transaction reports provides an important incentive for firms to invest appropriately in accurate reporting. Removing the cost of fixing errors risks firms under-investing at implementation, worsening data quality. We will also be able to require firms to provide 5 years of back reports on an exceptional basis. Firms are required to retain transaction and order records for 5 years under existing record keeping requirements in the Conduct of Business Sourcebook (COBS) 11 and Senior Management Arrangements, Systems and Controls (SYSC) 9. Our proposal does not amend those obligations. We will use established communications, including Market Watch, to provide transparency around the volume and nature of exceptional requests made to provide more than 3 years of back reports. We note respondents’ suggestions to apply the same back reporting period to UK EMIR and SFTR. We intend to consider requirements for back reporting across these regimes as part of our longer-term approach to harmonisation. We also considered proposals to introduce an amend functionality. This would require major system changes for firms, ARMs and us. We did not identify clear evidence that an amend-only functionality would deliver ongoing cost savings that outweigh the implementation cost. We may consider this as part of our long-term approach to harmonisation. We note respondents’ emphasis on moving to a single reporting schema. We will reflect this in our approach when we publish our new schema. The new reporting schema will be backwards compatible with the current schema. This will enable firms to resubmit transaction reports for transactions executed under the current regime using the new schema

48 after the new regime has been implemented. We will use the trade date to determine whether new or historical validation rules apply to a report. We have considered feedback requesting clarity on back reporting for fields that have been changed, added, or removed, and where the scope of reportable instruments has changed. Our approach is set out in the next section. Supervisory flexibility 6.10 The changes we are making in this Policy Statement will be implemented on 3 April 2028. We know firms need time to prepare for, test and implement new reporting systems and processes. 6.11 Firms should assess whether their data governance, ownership and control frameworks are ready to support the changes. This includes the completeness, accuracy and lineage of reporting data sources across internal systems, trading venues, ARMs and vendors. 6.12 Firms may also find it useful to map trading scenarios against the revised requirements to understand which flows remain reportable, which may fall out of scope, and where field population, controls or supporting rationale need to change. 6.13 We intend to enable firms to make certain changes before 3 April 2028 if they are ready to start benefiting from our proposals. We will do this by taking a flexible supervisory approach in some areas from 3 August 2026 until 3 April 2028. We do not expect firms to correct errors or omissions and notify us about issues affecting areas where we are taking a flexible supervisory approach during this period. 6.14 The table below shows our planned approach for each key area during the implementation period. We will relax some current transaction reporting validation rules to support our approach in October 2026.

49 Table 1: Our approach to supervision during the implementation period Area Expectations Back reporting Our new supervisory approach for back reporting will apply immediately from 3 August 2026. Firms will only be required to submit 3 years of back reports, unless otherwise instructed. EU-only financial instruments We will not take action against firms which do not report transactions in financial instruments which are only tradeable on EU trading venues during the implementation period. These instruments can be identified by their ‘Upcoming RCA’ value in FCA FIRDS. EU-only financial instruments have a non-GB value in this field. FX derivatives We will not take action against firms which do not report transactions in FX instruments during the implementation period, provided these firms are subject to UK EMIR reporting requirements. Firms which are not subject to UK EMIR reporting requirements must continue to meet applicable MiFIR transaction reporting requirements. Corporate event activity We will not take action against firms which fail to report corporate event activity which is not in scope of the new regime during the implementation period. Our expectations for IPOs, secondary public offerings, placings and debt issuance remain unchanged. Derivatives based on indices We will not take action against firms which over-report transactions where the underlying is an index and none of the financial instruments in the index are reportable Derivatives based on baskets We will not take action against firms which report underlying financial instruments within a basket which are not in FCA FIRDS, provided that at least one of the underlying financial instruments reported is in FCA FIRDS. We will amend the CON-472 validation rule. Transmission of order indicator The transmission of order indicator must be populated in every transaction report. However, we will not take action against firms which do not report the transmission of order indicator in line with applicable requirements during the implementation period. We will turn off the CON-251 validation rule. Swp Tags We will not take action against firms which do not report the Swp Tags in line with applicable requirements during the implementation period. We will turn off the CON-473 validation rule. Derivative notional increase/decrease We will not take action against firms which do not report the derivative notional increase/decrease field in line with applicable requirements during the implementation period. Option type We will not take action against firms which do not report the option type in line with applicable requirements during the implementation period. We will turn off the CON-500 validation rule. Option exercise style We will not take action against firms which do not report the option exercise style in line with applicable requirements during the implementation period. We will turn off the CON-530 validation rule. Delivery type We will not take action against firms which do not report the delivery type in line with applicable requirements during the implementation period.

50 Maturity date We will not take action against firms which do not report the maturity date in line with applicable requirements during the implementation period. We will turn off the CON-540 validation rule. Notional currency 2 We will not take action against firms which do not report the notional currency 2 in line with applicable requirements during the implementation period. We will turn off the CON-452 validation rule. Indicator fields We will not take action against firms which do not report the indicator fields (RTS 22 Field 61 to 65) in line with applicable requirements during the implementation period. Identifying trusts in transaction reports We will not take action against firms which choose to apply our new guidance on identifying trusts during the implementation period. Country of the branch for the buyer/ seller Firms should continue to report the country of the branch for the buyer/ seller fields to indicate whether the buyer/seller was a client of the executing entity. We will not take action against firms which fail to report the correct country code as determined by applicable requirements. Country of the branch membership We will not take action against firms which do not report the country of the branch membership in line with applicable requirements during the implementation period. We will turn off the CON-370 validation rules. Country of the branch responsible for the person making the investment decision Firms should continue to report the ‘Country of the branch responsible for the person making the investment decision’ field where applicable. However, we will not take action against firms which fail to report the correct country code as determined by existing requirements. Country of the branch supervising the person responsible for the execution Firms should continue to report the ‘Country of the branch supervising the person responsible for the execution’ field where applicable. However, we will not take action against firms which fail to report the correct country code as determined by existing requirements. 6.15 We will not take action against trading venues which do not report the IDM or EDM in line with applicable requirements during the implementation period where these fields would be populated with a national identifier. 6.16 Trading venues must continue to meet applicable requirements where the investment or execution decision was made primarily by an algorithm. The ‘execution within firm’ field will remain a mandatory field during the implementation period. 6.17 We will relax validation rules to allow trading venues to stop reporting instrument reference data fields that we will be removing. Once these validation rules have been amended, we will not take action against trading venues which fail to meet applicable requirements for the following fields: • Financial instrument short name • Currency of nominal value • Nominal value per unit/minimum traded value • Seniority of the bond • Option type

51 • Option exercise style • Delivery type • Fixed rate of leg 1 • Fixed rate of leg 2 6.18 There may be exceptional circumstances in which we may request information from firms covering the areas in this section during the implementation period. Our expectations for areas not covered in this section remain unchanged.

52 Annex 1 List of non-confidential respondents We are obliged to include a list of the names of respondents to our consultation who have consented to the publication of their name. That list is as follows: Equiniti Financial Services Limited SmartStream RWE Supply Trading GmbH Retail Derivative Forum Limited Futures Industry Association (FIA) REGIS-TR UK Ltd International Swaps and Derivatives Association (ISDA) International Securities Lending Association International Capital Market Association (ICMA) Depository Trust & Clearing Corporation (DTCC) European Venues and Intermediaries Association (EVIA) Alternative Investment Management Association (AIMA) TP ICAP London Stock Exchange Group Managed Funds Association (MFA) UK Finance FIX Trading Community Association for Financial Markets in Europe (AFME) Personal Investment Management and Financial Advice Association (PIMFA) Investment Company Institute (ICI) Digital Token Identifier Foundation (DTIF) Derivatives Service Bureau (DSB)

53 ISO Standards Advisory Group AJ Bell Capital Group BlackRock OSTTRA The Investment Association (IA) German Investment Funds Association (BVI) Mercer Risk Management Limited The Approved Reporting Mechanism Association (TARMA) ABN AMRO Clearing Bank NV Global Financial Markets Association (GFMA) Global Foreign Exchange Division Electronic Debt Markets Association (EDMA) Association of National Numbering Agencies (ANNA) ICE Futures Europe

54 Annex 2 Cost benefit analysis

1. In CP25/32, we published a cost benefit analysis (CBA) assessing the expected costs and benefits of our proposals. As a result of our proposed changes, we estimated expected ongoing cost savings to business of £115.3m per year. We expect these cost savings to arise through lower operational and compliance burdens from fewer data collection, validation and submission requirements. There may be additional benefits to firms which could be significant, but we did not quantify these. These included our proposals for CSSR and the benefits of numerous removed fields, which are only material when considered together.
2. We took a proportionate approach to the CBA, meaning we carried out additional analysis only up to the point where it could realistically deliver additional and reliable knowledge that could materially inform our decision on the appropriate course of action. Hence, we did not quantify all identified benefits. In CP25/32, we set out that 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 appraisal period.
3. Our final policy position does not involve material changes to the scope or design of the proposals that were subject to quantified analysis. Similarly, no additional changes that would materially alter costs or benefits have been introduced. Summary of CP feedback
4. 52 firms provided feedback to the CP. However, only 9 firms included specific feedback on the CBA. Most of these related to our proposal to introduce CSSR. We noted in the CBA that CSSR was likely to lead to cost savings, but that we were unable to quantify this benefit due to uncertainty around take-up. However, a few firms argued that CSSR could lead to only minimal cost savings in practice. They also noted that it could, instead, lead to increased costs and regulatory risk as it could create data ownership ambiguities. However, no respondent provided quantified estimates of what they anticipated the costs could be.
5. There was minimal feedback on other aspects of the CBA. Firms generally approved of other measures proposed, not commenting specifically on our estimates but rather agreeing that our changes will lead to cost savings for investment firms and trading venues. It was noted that anticipated savings may not be proportionate to a reduction in the number of transaction reports submitted due to fixed costs.

55 Our response: CSSR ensures that the FCA retains visibility of crucial market data, whilst the reporting burden on sending firms is reduced. We acknowledge that receiving firms may incur some additional costs as a result of the proposals, primarily relating to data integration and validation. However, we did not receive any quantitative evidence or data in the consultation responses from stakeholders which would allow us to estimate these costs. We also did not receive any further evidence which would allow us to quantify the expected uptake of CSSR, or the extent to which the number of transaction reports submitted will reduce. We will monitor the use of CSSR carefully following implementation to assess the impact of our changes. Cost and cost saving figures in the CBA were listed as taking effect at the end of the implementation period, in April 2028. However, we intend to enable firms to make certain changes before April 2028 if they are ready to start benefiting from our proposals. We will do this by taking a flexible supervisory approach during the implementation period. This may increase the cost savings (benefits) that firms face. Given the uncertainty around how many firms implement what changes early, we have opted not to quantify the extent of these additional potential cost savings (benefits).

56 Annex 3 Abbreviations used in this paper Abbreviation Description AIFM Alternative investment fund manager AOTC Any other capacity ARM Approved reporting mechanism CBA Cost benefit analysis CCP Central counterparty CET Central European Time CFI Classification of financial instrument CFTC Commodity Futures Trading Commission COBS Conduct of Business Sourcebook CON Content error CONCAT Concatenated code used to identify natural persons CP Consultation Paper CPMI Collective Portfolio Management Investment CSSR Conditional single-sided reporting DEA Direct electronic access DEAL Dealing on own account DEAU Direct Electronic Access User DSB Derivatives Service Bureau EDM Execution decision maker EEA European Economic Area

57 Abbreviation Description EMIR European Market Infrastructure Regulation ESMA European Securities and Markets Authority EU European Union FCA Financial Conduct Authority FIRDS Financial Instrument Reference Data System FSMA Financial Services and Markets Act FX Foreign exchange HSD Handbook style-drafting IDM Investment decision maker INS Instrument level validation error INTC Internal client account – aggregated client account IPO Initial public offering ISIN International Securities Identification Number ISO International Organization for Standardization LEI Legal Entity Identifier MAR Market Conduct Sourcebook MIC Market Identifier Code MiFID Markets in Financial Instruments Directive MiFIR Markets in Financial Instruments Regulation MTCH Matched principal MTF Multilateral trading facility NCA National Competent Authority NOAP Not applicable NORE No one responsible for execution (within the firm)

58 Abbreviation Description NPEX Natural person exemption for qualifying trading venues OTC Over-the-counter OTF Organised trading facility PII Personally identifiable information PRA Prudential Regulation Authority PS Policy Statement RCA Relevant Competent Authority 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 SESR Session restriction SFTR Securities Financing Transactions Regulation SI Systematic internaliser SYSC Senior Management Arrangements, Systems and Controls TOTV Traded on a trading venue TVTIC Trading venue transaction identification code UK United Kingdom UK EMIR The UK version of the European Market Infrastructure 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 UTC Coordinated Universal Time

59 Abbreviation Description UTI Unique Transaction Identifier VFCR Valid for Closing Restriction XML Extensible markup language

60 Appendix 1 Derivation and Changes Table The Treasury will repeal Articles 25, 26 and 27 of the UK version of Regulation (EU) No 600/2014 of the European Parliament and of the Council of 15 May 2014 on markets in financial instruments and amending Regulation (EU) No 648/2012 (UK MiFIR). Commission Delegated Regulations 2017/580 (MiFID RTS 24), 2017/585 (MiFID RTS 23) and 2017/590 (MiFID RTS 22) will be repealed at the same time. These obligations will be replaced with the new Handbook chapters MAR 13, MAR 14 and MAR 15. The table below gives a high-level overview of where the key provisions of these articles and Commission Delegated Regulations appear in the new Handbook chapters. UK MiFIR / RTS Article Draft Handbook Reference Subject matter Handbook style drafting or other comment Article 25 — Obligation to maintain records Art 25(1) MAR 13.2.1G, 13.2.2G Obligation for investment firms to maintain records relating to all orders and transactions Restated with guidance referencing existing record keeping obligations in the Handbook. Art 25(2) MAR 13.3.1R, MAR 13.5.1R, MAR 13.6.1R Obligation for trading venue operators to maintain records for all orders Restated into rules and guidance with amendments and Handbook style changes. Art 25(3) Not restated Delegated power for the FCA to make technical standards Not restated. Article 26 — Obligation to report transactions Art 26(1) MAR 14.1.2(1), MAR 14.5.1R, MAR 14.7.1R Obligation for investment firms to report transactions Restated into rules and guidance with amendments and Handbook style changes.

61 Art 26(2) Glossary: “reportable financial instrument” Scope of reportable instruments Restated into the Glossary of Definitions with amendments and Handbook style changes. Art 26(3) MAR 14.6.1R, MAR 14 Annex 1, MAR 14.13 Content of transaction reports - data fields Restated into rules and guidance with amendments and Handbook style changes. Art 26(4) MAR 14.10 Transmission / Conditional single sided-reporting Restated into rules and guidance with amendments and Handbook style changes to reflect the new conditional single-sided reporting mechanism. Art 26(5) MAR 14.8.1R–5R Obligation for trading venue operators to report transactions executed on its platform by firms not subject to UK MiFIR Restated into rules and guidance with amendments and Handbook style changes. Art 26(6) MAR 14.13.3R, 14.13.8R– 9R, MAR 14 Annex 1 Obligation for investment firms to use LEIs to identify clients who are legal persons Restated into rules and guidance with amendments and Handbook style changes. Art 26(7) MAR 14.7.2G, 14.9.1R, 14.11.1R–2R, 14.12.1R–2R, SUP 17A.2 Responsibility of investment firms, ARMs, and trading venues for transaction reports Restated into rules and guidance with amendments and Handbook style changes. Consequential amendments to ARM-specific obligations in SUP 17A have also been made. Art 26(8) Not applicable Repealed provision Not restated. Art 26(9) Not restated Delegated power for the FCA to make technical standards Not restated. Art 26(10) Not restated Transitional / ESMA obligation Not restated. Art 26(11) Not restated Definition of Gibraltar qualifying trading venue Not restated.

62 Article 27 — Obligation to supply financial instrument reference data Art 27(1) MAR 15.2.1R, 15.2.2R, 15.3.2R, SUP 17A.1.1R(4) Obligation for trading venues to submit reference data Restated into rules and guidance with amendments and Handbook style changes. Art 27(2) Not restated Obligation on the FCA to establish arrangements to receive reference data Not restated. Art 27(3) Not restated Delegated power for the FCA to make technical standards Not restated. RTS 22 — Commission Delegated Regulation (EU) 2017/590 - Transaction Reporting Art –3 Not restated Definitions relating to assimilated law only Not restated. Art -2 Not restated Assimilated law-specific interpretative provision Not restated. Art -1 Not restated Assimilated law-specific application / interpretation provision Not restated. Art 1 MAR 14.6.1R, MAR 14 Annex 1 Table 1 Data standards and formats for transaction reporting Restated into rules and guidance with amendments and Handbook style changes. Art 2 MAR 14.2, MAR 14.3 Meaning of transaction Restated into rules and guidance with amendments and Handbook style changes. Art 3 MAR 14.4 Meaning of execution of a transaction Restated into rules and guidance with amendments and Handbook style changes. Art 4 MAR 14.10 Transmission of an order / Conditional single-sided reporting Restated into rules and guidance with amendments and Handbook style changes to reflect the new conditional single-sided reporting mechanism. Art 5 MAR 14.13.3R–4R Identification of the investment firm executing a transaction Restated into rules and guidance with amendments and Handbook style changes.

63 Art 6 MAR 14.13.5R–7R Designation to identify natural persons Restated into rules and guidance with amendments and Handbook style changes. Art 7 MAR 14.13.8R–9R, 14.13.10G Details of the identity of the client and identifier and details for the decision maker Restated into rules and guidance with amendments and Handbook style changes. Art 8 MAR 14.13.11R–14R Identification of person or computer algorithm responsible for the investment decision Restated into rules and guidance with amendments and Handbook style changes. Art 9 MAR 14.13.15R–19R Identification of person or computer algorithm responsible for execution of a transaction Restated into rules and guidance with amendments and Handbook style changes. Art 10 Not restated Designation to identify an applicable waiver Not restated. Art 11 Not restated Designation to identify a short sale Not restated. Art 12 MAR 14.13.20R–21R Reporting of an execution for a combination of financial instruments Restated into rules and guidance with amendments and Handbook style changes. Art 13 MAR 14.13.24R Conditions upon which legal entity identifiers are to be developed, attributed and maintained Restated into rules and guidance with amendments and Handbook style changes. Art 14 MAR 14.13.25R–31R Reporting transactions executed by branches Restated into rules and guidance with amendments and Handbook style changes. Art 15 MAR 14.14, MAR 14.15 Methods and arrangements for reporting financial transactions Restated into rules and guidance with amendments and Handbook style changes. Art 17 Not restated Assimilated law temporal provisions Not restated. Annex I MAR 14 Annex 1 Details to be reported in transaction reports Restated into rules with amendments and Handbook style changes.

64 Annex II MAR 14 Annex 2 National client identifiers for natural persons to be used in transaction reports Restated into rules with amendments and Handbook style changes. RTS 23 — Commission Delegated Regulation (EU) 2017/585 — Financial Instrument Reference Data Art –3  Not restated  Definitions relating to assimilated law only  Not restated.  Art -2  Glossary “transaction reporting firms” Application provision  Not restated.  Art -1  Not restated  Assimilated law-specific application / interpretation provision  Not restated.  Art 1 MAR 15.3, MAR 15 Annex 1 Content, standards, form and format of reference data Restated into rules and guidance with amendments and Handbook style changes. Art 2 MAR 15.4 Timing for provision of reference data to competent authorities Restated into rules and guidance with amendments and Handbook style changes. Art 3 MAR 15.5 Identification of financial instruments and legal entities Restated into rules and guidance with amendments and Handbook style changes. Art 4 Not restated Arrangements to ensure effective receipt of reference data Not restated. Art 5 Not restated Arrangements to ensure the quality of the reference data Not restated. Art 6 MAR 15.6 Methods and arrangements for supplying reference data Restated into rules and guidance with amendments and Handbook style changes. Art 7 Not restated Arrangements for efficient exchange and publication of reference data Not restated. Art 8 Not restated Assimilated law temporal provisions Not restated. Annex MAR 15 Annex 1 Details to be reported as financial instrument reference data Restated into rules with amendments and Handbook style changes.

65 RTS 24 — Commission Delegated Regulation (EU) 2017/580 Order Record Keeping Art –3  Not restated  Definitions relating to assimilated law only  Not restated.  Art -2  Not restated  Application provision  Not restated.  Art -1  Not restated  Assimilated law-specific application / interpretation provision  Not restated.  Art 1 MAR 13 Annex 1 Table 1 Scope, standards and format of relevant order data Restated into rules with amendments and Handbook style changes. Art 2 MAR 13.4.1R Identification of the relevant parties Restated into rules and guidance with amendments and Handbook style changes. Art 3 MAR 13.4.2R Trading capacity of members or participants of the trading venue and liquidity provision activity Restated into rules and guidance with amendments and Handbook style changes. Art 4 MAR 13.4.3R Date and time recording Restated into rules and guidance with amendments and Handbook style changes. Art 5 MAR 13.4.4R Validity period and order restrictions Restated into rules and guidance with amendments and Handbook style changes. Art 6 MAR 13.4.5R Priority and sequence numbers Restated into rules and guidance with amendments and Handbook style changes. Art 7 MAR 13.4.6R–8R Identification codes for orders in financial instruments Restated into rules and guidance with amendments and Handbook style changes. Art 8 MAR 13.4.9R Events affecting the orders in financial instruments Restated into rules and guidance with amendments and Handbook style changes.

66 Art 9 MAR 13.4.10R Type of order in financial instruments Restated into rules and guidance with amendments and Handbook style changes. Art 10 MAR 13.4.11R Prices relating to orders Restated into rules and guidance with amendments and Handbook style changes. Art 11 MAR 13.4.12R Order instructions Restated into rules and guidance with amendments and Handbook style changes. Art 12 MAR 13.4.13R Trading venue transaction identification code Restated into rules and guidance with amendments and Handbook style changes. Art 13 MAR 13.4.14R, MAR 13.6.1R(3) Trading phases and indicative auction price and volume Restated into rules and guidance with amendments and Handbook style changes. Art 14 Not restated Assimilated law temporal provisions Not restated. Annex MAR 13 Annex 1 Tables 1 and 2 Order record data fields Restated into rules with amendments and Handbook style changes.

Appendix 2 Made rules (legal instrument) Appendix 2 Made rules (legal instrument)

FCA 2026/52 MARKETS IN FINANCIAL INSTRUMENTS (RECORD KEEPING, TRANSACTION REPORTING AND FINANCIAL INSTRUMENT REFERENCE DATA) INSTRUMENT 2026 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 3 April 2028. 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.]

FCA 2026/52 Page 2 of 77 Notes 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 2026. By order of the Board 30 July 2026

FCA 2026/52 Page 3 of 77 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. 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. transaction reporting firm a person who is either: (a) a MiFID investment firm (excluding a collective portfolio management investment firm); or

FCA 2026/52 Page 4 of 77 (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)(30) 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). [Editor’s note: the definition of ‘legal entity identifier’ takes into account the changes introduced by the Glossary (Cryptoassets) Instrument 2026 (FCA 2026/35), which come into force on 25 October 2027.] legal entity identifier (in CRYPTO) a 20-character alphanumeric code that uniquely identifies legally distinct entities which engage in financial transactions. 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

FCA 2026/52 Page 5 of 77 admission to trading to a qualifying trading venue has been made; (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: … (b) which meets the requirements imposed by and under article 26 of MiFIR is required by MAR 14. [Editor’s note: further changes to the definition of ‘working day’ will take place on 18 March 2027 (see FCA 2026/6).] 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 2026/52 Page 6 of 77 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.1.6 G The tables in MAR 13 Annex 1 replace those in the corresponding technical standards that applied previously. The FCA has generally not italicised the terms used in these tables. The technical standards contained their own definitions and were not subject to the Glossary in the same way as Handbook provisions. We have therefore not italicised terms in order not to change the meaning or effect of the requirements. 13.2 Records to be maintained by transaction reporting firms in relation to orders and transactions in financial instruments

FCA 2026/52 Page 7 of 77 13.2.1 G Transaction reporting firms should familiarise themselves 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. 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 . (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 (Relevant data for the purposes of MAR 13.4); (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 (Relevant data for the purposes of MAR 13.4).

FCA 2026/52 Page 8 of 77 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 (Relevant data for the purposes of MAR 13.4); (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 (Relevant data for the purposes of MAR 13.4). 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 (Relevant data for the purposes of MAR 13.4); 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 (Relevant data for the purposes of MAR 13.4). (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 Table 2 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 (Relevant data for the purposes of MAR 13.4). 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 (Relevant data for the purposes of MAR 13.4).

FCA 2026/52 Page 9 of 77 (2) The following orders must be identified as specified in field 8 of Table 2 of MAR 13 Annex 1 (Relevant data for the purposes of MAR 13.4): (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 pre￾determined either by the issuer of the instrument which is the subject of the order or by that qualifying trading venue. Date and time recording 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 (Relevant data for the purposes of MAR 13.4) 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 (Relevant data for the purposes of MAR 13.4). (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 (Relevant data for the purposes of

FCA 2026/52 Page 10 of 77 MAR 13.4). 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 (Relevant data for the purposes of MAR 13.4), 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). (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 (Relevant data for the purposes of MAR 13.4). 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 (Relevant data for the purposes of MAR 13.4). (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).

FCA 2026/52 Page 11 of 77 (2) Field 33 of Table 2 of MAR 13 Annex 1 (Relevant data for the purposes of MAR 13.4) 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 venue must maintain its details as specified in MAR 13 Annex 1 (Trading venue records). (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 (Relevant data for the purposes of MAR 13.4). Routed orders 13.4.8 R Orders submitted to a qualifying trading venue allowing for a routing strategy must: (1) be identified as ‘routed’ as specified in field 33 of Table 2 of MAR 13 Annex 1 (Relevant data for the purposes of MAR 13.4) 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 (Relevant data for the purposes of MAR 13.4) 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(Relevant data for the purposes of MAR 13.4) ; 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(Relevant data for the purposes of MAR 13.4). Prices relating to orders 13.4.11 R Operators of qualifying trading venues must maintain a record of all price￾related details referred to in section I of Table 2 of MAR 13 Annex 1

FCA 2026/52 Page 12 of 77 (Relevant data for the purposes of MAR 13.4) 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 (Relevant data for the purposes of MAR 13.4) . 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 (Relevant data for the purposes of MAR 13.4). 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 (Relevant data for the purposes of MAR 13.4). 13.5 Records of transactions to be maintained by operators of qualifying trading venues 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.

FCA 2026/52 Page 13 of 77 13 Annex 1 Trading venue records 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. Where amendments are to be made, underlining indicates new text and striking through indicates deleted text. 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 … {DATE_TIME_FORMAT} … … "T" — means that the letter "T" shall must be used; … Dates and times shall must be reported in UTC. {DATEFORMAT} … Dates shall must be formatted by the following format: YYYY-MM-DD. … {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

FCA 2026/52 Page 14 of 77 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 1 Identification of the entity which submitted the order The identity of the member or participant of the trading venue. In case of Direct Electronic Access (DEA) the identity shall must be the one of the DEA provider. … 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. “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. … 3 Client identification code Code used to identify the client of the member or participant of the trading venue. In case there is DEA, the code of the DEA user shall must be used. Where the client is a legal entity, the LEI code of the client shall must be used. Where the client is not a legal entity, the {NATIONAL_ID} shall must be used. In case of aggregated orders, the flag “AGGR” as specified in Article 2(3) of this Regulation MAR 13.4.1R(3). In case of pending allocations, the flag “PNAL” as specified in Article 2(2) of this Regulation MAR 13.4.1R(2). This field shall must be left blank only if the member or participant of the trading venue has no client. … 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 … {ALPHANUM-50} — Algorithms

FCA 2026/52 Page 15 of 77 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.14R 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. “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. 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. … {ALPHANUM-50} — Algorithms “NORE” — No one responsible within the firm

FCA 2026/52 Page 16 of 77 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 Non￾executing 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 must be either matched principal trading, dealing on own account, or any other capacity. Where the order submission does not result from the member or, participant or client …

FCA 2026/52 Page 17 of 77 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 C – Date and Time 9 Date and Time The date and time for each event listed in Section [G] and [K]. … The number of digits after the "seconds" shall must be determined in accordance with Article 2 of the Commission Delegated Regulation (EU) 2017/574 (MiFID RTS 25). Section D – Validity period and order restrictions … 11 Order restriction … This field shall must be populated with multiple flags separated by a comma where there are multiple types applicable. “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 … … The number of digits after the "seconds" is determined in accordance with Article 2 of Delegated Regulation (EU)

FCA 2026/52 Page 18 of 77 2017/574 (MiFID RTS 25). Section E – Priority and sequence number 13 Priority time stamp This field shall must be updated every time the priority of an order changes. … The number of digits after the "seconds" is determined in accordance with Article 2 of Delegated Regulation (EU) 2017/574 (MiFID RTS 25). 14 Priority size For trading venues which use size-time priority, this field shall must be populated with a positive number corresponding to the quantity. This field shall must be updated every time the priority of the order changes. … 15 Sequence number Each and every event listed in section G shall must be identified using positive integers in ascending order. The sequence number shall must be unique to each type of event; consistent across all events, timestamped by the operator of the trading venue; be persistent for the date that the event occurs. … … Section F — Identification of the order 16 Segment MIC code … If the trading venue uses segment MICs then the segment MIC shall must be used. If the trading venue does not use segment MICs then the operating MIC shall must be used. … Section G – Events affecting the order 21 … … …

FCA 2026/52 Page 19 of 77 New order, order modification, order cancellation, order rejections, partial or full execution Cancelled by market operations. This includes a protection 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 H — Type of order … Section I – Prices … 24 Limit price … This field shall must be left blank in case of orders that do not have a limit price or in case of unpriced orders. In case of a convertible bond, the real price (clean or dirty) used for the order shall must be reflected in this field. … Where price is reported in monetary terms, it shall must be provided in the major currency unit. 25 Additional limit Price price Any other limit price which may apply to the order. This field shall must be left blank if not relevant. … Where the price is reported in monetary terms, it shall must be provided in the major currency unit. 26 Stop price … For stop orders triggered by events independent of the price of the financial instrument, this field shall must be populated with a stop price equal to zero. … Where the price is reported in monetary terms, it shall must be

FCA 2026/52 Page 20 of 77 This field shall must be left blank if not relevant. provided in the major currency unit. … 27 Pegged limit price … This field shall must be left blank if not relevant. … Where the price is reported in monetary terms, it shall must be provided in the major currency unit. … 28 Transaction price … In the case of option contracts, it shall must be the premium of the derivative contract per underlying or index point. In the case of spread bets it shall must be the reference price of the direct underlying instrument. For credit default swaps (CDS) it shall must be the coupon in basis points. Where price reported in monetary terms, it shall must be provided in the major currency unit. Where price is not applicable the field shall must be populated with the value "NOAP". … … 30 Currency of leg 2 Where there are multi-currency or cross￾currency swaps, the currency of leg 2 shall must be the currency in which leg 2 of the contract is denominated. For swaptions where the underlying swap is multi-currency, the currency of leg 2 shall must be the currency in which leg 2 of the swap is denominated. … … … Section J – Order instructions 32 Buy-sell indicator … …

FCA 2026/52 Page 21 of 77 In case of options and swaptions, the buyer shall must be the counterparty that holds the right to exercise the option and the seller shall must be the counterparty that sells the option and receives a premium. In case of futures and forwards other than futures and forwards relating to currencies, the buyer shall must be the counterparty buying the instrument and the seller the counterparty selling the instrument. In the case of swaps relating to securities, the buyer shall must be the counterparty that gets the risk of price movement of the underlying security and receives the security amount. The seller shall must be the counterparty paying the security amount. In the case of swaps related to interest rates or inflation indices, the buyer shall must be the counterparty paying the fixed rate. The seller shall must be the counterparty receiving the fixed rate. In case of basis swaps (float-to-float interest rate swaps), the buyer shall must be the counterparty that pays the spread and the seller the counterparty that receives the spread. In the case of swaps and forwards related to currencies and of cross currency swaps, the buyer shall must be the counterparty receiving the currency which is first when sorted alphabetically by ISO 4217 standard and the seller shall must be the counterparty delivering this currency. In the case of swaps related to dividends, the buyer shall must be 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 shall must be the counterparty buying the protection. The seller is the counterparty selling the protection. In case of derivative contracts related to commodities or emission allowances, the buyer shall must be the counterparty that

FCA 2026/52 Page 22 of 77 receives the commodity or emission allowance specified in the report and the seller the counterparty delivering this commodity or emission allowance. In case of forward rate agreements, the buyer shall must be the counterparty paying the fixed rate and the seller the counterparty receiving the fixed rate. For an increase in notional the buyer shall must be the same as the acquirer of the financial instrument in the original transaction and the seller shall must be the same as the disposer of the financial instrument in the original transaction. For a decrease in notional the buyer shall must be the same as the disposer of the financial instrument in the original transaction and the seller shall must be the same as the acquirer of the financial instrument in the original transaction. 33 Order Status … … If multiple statuses are applicable, this field shall must be populated with multiple flags separated by comma. … 36 Initial quantity … For spread bets, the quantity shall must be the monetary value wagered per point movement in the underlying financial instrument. For an increase or decrease in notional derivative contracts, the number shall must reflect the absolute value of the change and shall must be expressed as a positive number. For credit default swaps, the quantity shall must be the notional amount for which the protection is acquired or disposed of. … 37 Remaining quantity including hidden … On a partial fill order event, this shall must be the total remaining volume after that …

FCA 2026/52 Page 23 of 77 partial execution. On an order entry this shall must equal the initial quantity. … 39 Traded quantity Where there is a partial or full execution, this field shall must be populated with the executed quantity. … 40 Minimum Acceptable Quantity (MAQ) … This field shall must be left blank if not relevant. … 41 Minimum executable size (MES) … This field shall must be left blank if not relevant. … … 43 Passive only indicator Indicates if the order is submitted to the trading venue with a characteristic/flag, such that the order shall must not immediately execute against any contra visible orders. … 44 Passive or aggressive indicator … This field shall must be left blank if not relevant. … … 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. … 47 Routing Strategy … This field shall must be left blank if not relevant. … 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. The trading venue transaction identification code shall must be unique, consistent and persistent per ISO10383 segment MIC and per trading day. Where the trading venue does not use segment MICs, the trading venue transaction …

FCA 2026/52 Page 24 of 77 identification code shall must be unique, consistent and persistent per operating MIC per trading day. The components of the trading venue transaction identification code shall must not disclose the identity of the counterparties to the transaction for which the code is maintained. … Section K — Trading phases, indicative auction price and volume … 50 Indicative auction price … … Where price reported in monetary terms, it shall must be provided in the major currency unit. … … 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. (4) Transaction reports are also used by the FCA to monitor the functioning of financial markets, supervise firms and shape effective policies. Application

FCA 2026/52 Page 25 of 77 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.1.4 G The tables in MAR 14 Annex 1 replace those in the corresponding technical standards that applied previously. The FCA has generally not italicised the terms used in these tables. The technical standards contained their own definitions and were not subject to the Glossary in the same way as Handbook provisions. We have therefore not italicised terms in order not to change the meaning or effect of the requirements. 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 2026/52 Page 26 of 77 (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) eligible post trade risk reduction services; (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 either: (a) pre-determined contractual terms and irrespective of whether an investment decision on the part of the investor is required; or (b) as a result of mandatory events which are beyond the control of the investor and irrespective of whether an investment decision on the part of the investor is required; (10) a decrease or increase in the notional amount of a derivative contract that is a reportable financial instrument, as a result of pre￾determined 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, or of residual fractional share entitlements following corporate events or

FCA 2026/52 Page 27 of 77 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; (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 10 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) (a) The exclusions provided for in MAR 14.2 apply to all ‘corporate event activity’ except for initial public offerings or secondary public offerings or placings, or debt issuance. (b) ‘Corporate event activity’ in (a) above, refers to corporate restructuring events initiated by the issuer of a financial instrument which results in the creation or termination of a reportable financial instrument or a tender offer (of any type) in relation to a reportable financial instrument. (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.

FCA 2026/52 Page 28 of 77 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. (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.

FCA 2026/52 Page 29 of 77 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 (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) transfers 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

FCA 2026/52 Page 30 of 77 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 7 working 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 has the same instrument classification (field 3) and applicable derivative fields (fields 20-37) as an instrument in the financial instrument 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. (4) Transactions in reportable financial instruments reported by a transaction reporting firm on a voluntary basis where the

FCA 2026/52 Page 31 of 77 reportable financial instruments are not included in the list of financial information reference data published by the FCA. 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 (Details to be reported in transaction reports) 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 (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.

FCA 2026/52 Page 32 of 77 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 (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.

FCA 2026/52 Page 33 of 77 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. 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.

FCA 2026/52 Page 34 of 77 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 (Details to be reported in transaction reports) 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, 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.

FCA 2026/52 Page 35 of 77 (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; (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 person’s first name; and (3) the first 5 characters of the person’s 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 or abbreviations;

FCA 2026/52 Page 36 of 77 (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 (3), 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 client as specified in fields 9, 10, 11, 18, 19 and 20 of Table 2 of MAR 14 Annex 1 (Details to be reported in transaction reports). 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 (Details to be reported in transaction reports). 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 should report the trust as the client, using an LEI when an LEI is available. Where an LEI is not available the transaction reporting firm should report the beneficiary of that trust as the client (using either an LEI ora national identifier, assigned in accordance with MAR 14.13.5R where an LEI is not available). Where there are multiple beneficiaries to the trust, a transaction reporting firm should include each beneficiary as a client in the transaction report. 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 (Details to be reported in transaction reports). The transaction reporting firm must only identify such a person

FCA 2026/52 Page 37 of 77 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 transaction reporting 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: (1) unique for each set of code or trading strategy that constitutes the algorithm, regardless of the reportable financial instruments or markets to which the algorithm applies; (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) the firms to which that firm will transmit orders; 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 (Details to be reported in transaction reports). 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

FCA 2026/52 Page 38 of 77 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.14R. 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 transaction reporting firm who have limited practical involvement in the relevant decisions at a transactional level. Reporting a package transaction 14.13.20 R 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. 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 (Details to be reported in transaction reports). 14.13.22 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.23 R (1) Where the transaction relates to a reportable financial instrument where the underlying is a basket of financial instruments, a

FCA 2026/52 Page 39 of 77 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 Table 2 of MAR 14 Annex 1 must be reported as many times as necessary to list all reportable financial instruments in the basket. 14.13.24 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.25 R (1) A transaction reporting firm must not provide a service that triggers 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 14.13.26 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.27 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.28 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.29 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.30 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.

FCA 2026/52 Page 40 of 77 14.13.31 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.32 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.33 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. Trading venue transaction identification code 14.13.34 R As specified in field 3 of Table 2 of MAR 14 Annex 1 (Details to be reported in transaction reports), 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.35 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

FCA 2026/52 Page 41 of 77 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; (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) 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) the instrument which is the subject of the transaction concerned is not a reportable financial instrument, except where the firm has elected to submit a transaction report where it is not required to (see the guidance in MAR 14.5.5G); (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

FCA 2026/52 Page 42 of 77 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 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

FCA 2026/52 Page 43 of 77 (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 G Unless otherwise directed by the FCA, the obligations in MAR 14.15.3R apply to a transaction for 3 years from the date of its execution. 14.15.5 G A transaction reporting firm or the operator of a qualifying trading venue that has submitted a transaction report under MAR 14.8 should establish and maintain a robust incident management framework to address any errors or omissions in any such transaction report. This incident management framework should be adequate and proportionate to the nature, scale and complexity of the business of the transaction reporting firm or the qualifying trading venue and enable the firm or operator to: (1) triage, assess and manage incidents of errors and omissions; (2) undertake an analysis of the cause of the error or omission; (3) implement and monitor the progress of remedial actions to prevent the error or omission reoccurring; (4) operate an internal escalation protocol; and (5) notify the FCA under MAR 14.15.6R. 14.15.6 G The incident management framework in MAR 14.15.5R should be supported by policies and procedures and offer traceability and auditability of decision making. 14.15.7 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.8 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.9 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 (Details to be reported in transaction reports). Field 1 should be populated with ‘CANC’. If any more fields are populated, the submission will be rejected. 14.15.10 R (1) After cancelling the transaction report containing the errors or omissions, the transaction reporting firm or operator of a qualifying trading venue must submit a new and correct transaction report to the FCA promptly.

FCA 2026/52 Page 44 of 77 (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.11 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.12 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, 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 1 Details to be reported in transaction reports 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 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. Table 1: Legend for Table 2 (Format and standards to be used for reporting) 14 Annex 1.1 R SYMBOL DATA TYPE DEFINITION

FCA 2026/52 Page 45 of 77 … {DATE_TIME_FORMAT} … … "T" — means that the letter "T" shall must be used; … Dates and times shall must be reported in UTC. {DATEFORMAT} … Dates shall must be formatted by the following format: YYYY-MM-DD. … {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 {ALPHANUM-52}

FCA 2026/52 Page 46 of 77 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 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.34R. 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.35R. {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-15 must be populated by the receiving firm in the receiving firm’s report from the information provided by the sending firm.

FCA 2026/52 Page 47 of 77 7 Buyer identification code Code used to identify the acquirer of the reportable financial instrument. Where the acquirer is a legal entity, the LEI 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. 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 qualifying trading venue or on an organised trading platform outside of the United Kingdom that uses a central counterparty (CCP) and where the identity of the acquirer is not disclosed prior to execution, the LEI of the CCP must be used. Where the transaction was executed on a qualifying trading venue or on an organised trading platform outside of the United Kingdom that does not use a CCP and where the identity of the acquirer is not disclosed prior to execution, the MIC 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 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 {LEI} {MIC} {NATIONAL_ID} “INTC”

FCA 2026/52 Page 48 of 77 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. 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 spread bets, 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

FCA 2026/52 Page 49 of 77 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 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. Additional details • Fields 9-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 must be populated “True” where the buyer is a client of the executing entity. This field must 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 {ALPHANUM-140}

FCA 2026/52 Page 50 of 77 surnames must be included in this field separated by a comma. 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.5R to MAR 14.13.7R 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-20 must be repeated for each seller.

FCA 2026/52 Page 51 of 77 • Where the transaction for a seller has met the conditions set out in MAR 14.10R, the information in fields 16-24 must be populated by the receiving firm in the receiving firm’s report from the information received from the sending firm. 16 Seller identification code Code used to identify the disposer of the reportable financial instrument. Where the disposer is a legal entity, the LEI of the disposer must be used. Where the disposer 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 qualifying trading venue or on an organised trading platform outside of the United Kingdom that utilises a CCP and where the identity of the disposer is not disclosed prior to execution, the LEI of the CCP must be used. Where the transaction was executed on a qualifying trading venue or on an organised trading platform outside of the United Kingdom that does not utilise a CCP and where the identity of the disposer is not disclosed prior to execution, the MIC 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 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. {LEI} {MIC} {NATIONAL_ID} “INTC”

FCA 2026/52 Page 52 of 77 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. 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 spread bets, the buyer is the counterparty which goes long on the contract, and the seller is the counterparty that goes short on the contract.

FCA 2026/52 Page 53 of 77 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 must 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 must 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. 17- 24 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 used to identify the sending firm. This must be populated by the receiving firm within the receiving firm’s report {LEI}

FCA 2026/52 Page 54 of 77 code for the seller 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 qualifying 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 qualifying 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 qualifying 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 must 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. “DEAL” - Dealing on own account “MTCH” - Matched principal “AOTC” - Any other capacity

FCA 2026/52 Page 55 of 77 29 Quantity The number of units of the reportable financial instrument, or the number of derivative contracts in the transaction. The nominal or monetary value of the reportable 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 or 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 must 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 2026/52 Page 56 of 77 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 qualifying 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 qualifying 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 must report the MIC of the SI. {MIC}

FCA 2026/52 Page 57 of 77 Use MIC “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 “XXXX” for reportable 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 relating 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 must 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 2026/52 Page 58 of 77 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 2026/52 Page 59 of 77 41 Instrument full name Full name of the reportable financial instrument. {ALPHANUM-350} 42 Instrument classification Taxonomy used to classify the reportable financial instrument. A complete and accurate CFI code must be provided. {CFI_CODE} 43 Notional currency 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 spread bets, the movement in the price of the underlying instrument on which the spread bet 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 of the underlying instrument. For American depository receipts, 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 2026/52 Page 60 of 77 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. Where the underlying is an index and has an ISIN, the ISIN 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 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 {INTEGER-3}+ “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 2026/52 Page 61 of 77 Where strike price is currently not available but pending, the value must 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 must 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.14R. This field only applies for investment decisions within the firm. If there is no one within the firm responsible, 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.8 where the investment decision was made by a natural person. Where this applies, the value “NPEX” must be populated by the qualifying trading venue. {NATIONAL_ID} - Natural persons {ALPHANUM-50} – Algorithms “NPEX” - Natural person exemption for qualifying trading venues 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

FCA 2026/52 Page 62 of 77 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.8R where the execution decision was made by a natural person. Where this applies the value “NPEX” must be populated by the qualifying trading venue. {ALPHANUM-50} – Algorithms “NORE” – No one responsible within the firm “DEAU” – No one responsible within the firm and the executing entity has provided DEA “NPEX” - Natural person exemption for qualifying trading venues Insert the following new annex, MAR 14 Annex 2, after MAR 14 Annex 1 (Details to be reported in transaction reports). 14 Annex 2 Details to be reported in transaction reports 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. Where amendments are to be made to the content of the table, underlining indicates new text and striking through indicates deleted text. National client identifiers for natural persons to be used in transaction reports 14 Annex 2.1 R ISO 3166 — 1 alpha 2 Country Name name 1st priority identifier 2nd priority identifier 3rd priority identifier …

FCA 2026/52 Page 63 of 77 LI Liechtenstein National Passport Number National Identity Card Number CONCAT1 … 1 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. The FCA uses this information 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 2026/52 Page 64 of 77 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. Interpretation 15.1.4 G The tables in MAR 15 Annex 1 replace those in the corresponding technical standards that applied previously. The FCA has generally not italicised the terms used in these tables. The technical standards contained their own definitions and were not subject to the Glossary in the same way as Handbook provisions. We have therefore not italicised terms in order not to change the meaning or effect of the requirements. 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 (Details to be reported as 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:

FCA 2026/52 Page 65 of 77 (1) in accordance with the standards and formats specified in MAR 15 Annex 1 (Details to be reported as 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 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 20: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 occur 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 20: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.

FCA 2026/52 Page 66 of 77 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. 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. 15 Annex 1 Details to be reported as financial instrument reference data 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. Where amendments are to be made, underlining indicates new text and striking through indicates deleted text. 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 …

FCA 2026/52 Page 67 of 77 {DATE_TIME_FORMAT} … … "T" - means that the letter 'T' shall must be used; … Dates and times shall must be reported in UTC. {DATEFORMAT} … Dates shall must be formatted by the following format: YYYY-MM-DD. … {FISN} 35 alphanumeric characters FISN code as defined in ISO 18774 Table 2: Classification of commodity and emission allowances derivatives for Table 3 (Fields 35 27 to 37 29). 15 Annex 1.2 R Base product Sub product Further sub product … "OTHC" - Other C10 derivatives as defined in Table 10.1 of Section 10 of Annex III to Commission Delegated Regulation (EU) 2017/583 (MiFID RTS 2). … … … Table 3: Details to be reported as financial instrument reference data 15 Annex 1.3 R

FCA 2026/52 Page 68 of 77 N. FIELD CONTENT TO BE REPORTED FORMAT AND STANDARDS TO BE USED FOR REPORTING General Fields fields … 3 Instrument classification … A complete and accurate CFI code shall must be provided. … 4 [Editor’s note: the number ‘4’ is struck through.] 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 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 …

FCA 2026/52 Page 69 of 77 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 … In the case of an interest rate or currency derivative contract, this will be the notional currency of leg 1 or the currency 1 of the pair. … … Bonds or other forms of securitised debt related fields 14 12 Total issued nominal amount … … 15 13 Maturity date … … 16 Currency of nominal value Currency of the nominal value for debt instruments. {CURRENCYCODE_3} 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 14 Fixed rate The fixed rate percentage of return on a Debt debt …

FCA 2026/52 Page 70 of 77 instrument when held until maturity date, expressed as a percentage Expressed as a percentage (e.g. 7.0 means 7 % and 0.3 means 0,.3) 19 15 Identifier of the index/benchmark of a floating rate bond … … 20 16 Name of the index/benchmark of a floating rate bond … … 21 17 Term of the index/benchmark of a floating rate bond. Term of the index/benchmark of a floating rate bond. The term shall must be expressed in days, weeks, months or years. … 22 18 Base Point Spread 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 securitised derivatives related fields 24 19 Expiry date … … 25 20 Price multiplier … … 26 21 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 2026/52 Page 71 of 77 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 must be provided. In case the underlying is an Index 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 21 and 27 22 shall must be reported as many times as necessary to list all instruments in the basket. 27 22 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 23 Underlying index name … … 29 24 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 2026/52 Page 72 of 77 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 25 Strike price … Where price is currently not available but pending, the value shall must be "PNDG". Where strike price is not applicable the field shall must not be populated. … 32 26 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 pre￾specified 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 “PHYS” - Physically Settled “CASH” - Cash settled

FCA 2026/52 Page 73 of 77 execution, the value shall be “OPTL”. This field is only applicable for derivatives. “OPTL” - Optional for counterparty or when determined by a third party Commodity and emission allowances derivatives 35 27 Base product … … 36 28 Sub product The Sub Product sub product for the underlying asset class as specified in the classification of commodities and emission allowances derivatives table. Field requires a Base base product. Only values in the "Sub product" column of the classification of commodities derivatives table are allowed are allowed. 37 29 Further sub product The Further further sub product for the underlying asset class as specified in the classification of commodities and emission allowances derivatives table. Field requires a Sub sub product … 38 30 Transaction type … … 39 31 Final price type … … Interest rate derivatives

• The fields in this section shall must 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 32 Reference rate … … 41 33 IR Term of contract If the asset class is Interest Rates, this field states the term of the contract. The term must be expressed in days, weeks, months or years. … 42 34 Notional currency 2 … …

FCA 2026/52 Page 74 of 77 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 35 Floating rate of leg 2 … … 46 36 IR Term of contract of leg 2 An indication of the reference period of the interest rate, which is set at predetermined intervals by reference to a market reference rate. The term shall must be expressed in days, weeks, months or years. … 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 ”FXMJ” - FX Majors

FCA 202X/YY Page 75 of 77 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 2026/52 Page 76 of 77 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 An operator 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 2026/52 Page 77 of 77 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.

68 Appendix 3 Handbook tables This Appendix shows how the tables in MAR 13, MAR 14 and MAR 15 will look like when added to the Handbook. There may be changes to these tables when they are included in the Handbook. Firms should defer to the Handbook versions of the relevant chapters to ensure compliance with the new regime. These tables are indicative versions pending the formal update to the Handbook. 13 Annex 1 Trading venue records 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 {ALPHANUM-n} Up to n alphanumerical characters Free text field. {CURRENCYCODE_3} 3 alphanumerical characters 3 letter currency code, as defined by ISO 4217 currency codes {DATE_TIME_FORMAT} ISO 8601 date and time format Date and time in the following format: YYYY-MM-DDThh:mm:ss.ddddddZ. “YYYY” is the year; “MM” is the month; “DD” is the day; “T” — means that the letter “T” must be used; “hh” is the hour; “mm” is the minute; “ss.dddddd” is the second and its fraction of a second; Z is UTC time. Dates and times must be reported in UTC.

69 {DATEFORMAT} ISO 8601 date format Dates must be formatted in the following format: YYYY-MM-DD. {DECIMAL-n/m} Decimal number of up to n digits in total of which up to m digits can be fraction digits Numerical field for both positive and negative values. decimal separator is “.” (full stop); negative numbers are prefixed with “-” (minus); values are rounded and not truncated. {INTEGER-n} Integer number of up to n digits in total Numerical field for both positive and negative integer values. {ISIN} 12 alphanumerical characters ISIN code as defined in ISO 6166 {LEI} 20 alphanumerical characters Legal entity identifier as defined in ISO 17442 {MIC} 4 alphanumerical characters Market identifier as defined in ISO 10383 {NATIONAL_ID} 35 alphanumerical characters The identifier is that set out in MAR 14 Annex 2 (National client identifiers for natural persons to be used in transaction reports). Table 2: relevant data for the purposes of MAR 13.4 13 Annex R 1.2 N.Field Content of the order details to be maintained Standards and formats of the order details to be used when providing the relevant order data to the FCA Section A – Identification of the relevant parties 1 Identification of the entity which submitted the order The identity of the member or participant of the trading venue. In case of Direct Electronic Access (DEA) the identity must be the one of the DEA provider. {LEI} 2 Direct Electronic Access (DEA) “true” where the order was submitted to the trading venue using DEA. “false” where the order was not submitted to the trading venue using DEA. “true” “false”

70 3 Client identification code Code used to identify the client of the member or participant of the trading venue. In case there is DEA, the code of the DEA user must be used. Where the client is a legal entity, the LEI code of the client must be used. Where the client is not a legal entity, the {NATIONAL_ID} must be used. In case of aggregated orders, the flag “AGGR” as specified in MAR 13.4.1R(3). In case of pending allocations, the flag “PNAL” as specified in MAR 13.4.1R(2). This field must be left blank only if the member or participant of the trading venue has no client. {LEI} {NATIONAL_ID} “AGGR” — aggregated orders “PNAL” — pending allocations 4 Investment decision within firm Code used to identify the person or the algorithm within the member, participant or client of the trading venue who is responsible for the investment decision in accordance with MAR 14.13.11R to MAR 14.13.14R inclusive. Where a natural person within the member, 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 must be populated as set out in MAR 14.13.11R to MAR 14.13.14R 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 must be left blank when the investment decision was not made by a person or algorithm within the member, 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. {NATIONAL_ID} — Natural persons {ALPHANUM-50} — Algorithms “NORE” — No one responsible within the firm

71 5 Execution within firm Code used to identify the person or algorithm within the member, participant or client of the trading venue who is responsible for the execution of the transaction resulting from the order in accordance with MAR 14.13.15R to MAR 14.13.18R inclusive. Where a natural person is responsible for the execution of the transaction, the person 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 must be populated in accordance with 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, participant or client of the trading venue must determine the trader or algorithm primarily responsible as specified in 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. {NATIONAL_ID} — Natural persons {ALPHANUM-50} — Algorithms “NORE” — No one responsible within the firm 6 Non￾executing broker In accordance with MAR 13.4.1R(1)(f). This field must be left blank when not relevant. {LEI} Section B – Trading capacity and liquidity provision 7 Trading capacity Indicates the trading capacity of the member, participant or client of the trading venue that submitted the order. This must be either matched principal trading, dealing on own account, or any other capacity. Where the order submission does not result from the member, participant or client of the trading venue carrying out matched principal trading or dealing on its own account, the field must indicate that the transaction was carried out under any other capacity. “DEAL” — Dealing on own account “MTCH” — Matched principal “AOTC” — Any other capacity 8 Liquidity provision activity Indicates whether an order is submitted to a trading venue as part of a market making strategy, or is submitted as part of another activity in accordance with MAR 13.4.2R. “true” “false” Section C – Date and Time

72 9 Date and Time The date and time for each event listed in Section G and K. {DATE_TIME_FORMAT} The number of digits after the “seconds” must be determined in accordance with Article 2 of the Commission Delegated Regulation (EU) 2017/574 (MiFID RTS 25). Section D – Validity period and order restrictions 10 Validity period Good-For-Day: the order expires at the end of the trading day on which it was entered in the order book. “DAVY” — Good-For-Day Good-Till-Cancelled: the order will remain active in the order book and be executable until it is actually cancelled. “GTCV” — Good-Till-Cancelled Good-Till-Time: the order expires at the latest at a pre-determined time within the current trading session. “GTTV” — Good-Till-Time Good-Till-Date: the order expires at the end of a specified date. “GTDV” — Good-Till-Date Good-Till-Specified Date and Time: the order expires at a specified date and time “GTSV” — Good-Till-Specified Date and Time Good After Time: the order is only active after a pre-determined time within the current trading session. “GATV” — Good After Time Good After Date: the order is only active from the beginning of a pre-determined date “GADV” — Good After Date Good After Specified Date and Time: the order is only active from a pre-determined time on a pre-determined date. “GASV” — Good After Specified Date and Time Immediate-Or-Cancel: an order which is executed upon its entering into the order book (for the quantity that can be executed) and which does not remain in the order book for the remaining quantity (if any) that has not been executed. “IOCV” — Immediate-Or-Cancel Fill-Or-Kill: an order which is executed upon its entering into the order book provided that it can be fully filled: in the event the order can only be partially executed, then it is automatically rejected and cannot therefore be executed. “FOKV” — Fill-Or-Kill or {ALPHANUM-4} characters not already in use for the trading venue’s own classification. Other: any additional indications that are unique for specific business models, trading platforms or systems.

73 11 Order restriction Good For Closing Price Crossing Session: where an order qualifies for the closing price crossing session. “VFCR” – Good for Closing Price Crossing Session Valid For Auction: the order is only active and can only be executed at auction phases (which can be pre-defined by the member or, participant of the trading venue who submitted the order, e.g. opening and/closing auctions and/or intraday auction). “VFAR” — Valid For Auction Valid For Continuous Trading only: the order is only active during continuous trading. “SESR” – Valid for Continuous Trading only Other: any additional indications that are unique for specific business models, trading platforms or systems. {ALPHANUM-4} characters not already in use for the trading venue’s own classification. This field must be populated with multiple flags separated by a comma where there are multiple types applicable 12 Validity period and time This refers to the time stamp reflecting the time on which the order becomes active or it is ultimately removed from the order book. Good for day: the date of entry with the timestamp immediately prior to midnight Good till time: the date of entry and the time to that specified in the order Good till date: will be the specified date of expiry with the timestamp immediately prior to midnight Good till specified date and time: the specified date and time of expiry Good after time: the date of entry and the specified time at which the order becomes active Good after date: the specified date with the timestamp immediately after midnight Good after specified date and time: the specified date and time at which the order becomes active Good till Cancel: the ultimate date and time the order is automatically removed by market operations Other: timestamp for any additional validity type. {DATE_TIME_FORMAT} The number of digits after the “seconds” is determined in accordance with Article 2 of Delegated Regulation (EU) 2017/574 (MiFID RTS 25).

74 Section E – Priority and sequence number 13 Priority time stamp This field must be updated every time the priority of an order changes. {DATE_TIME_FORMAT} The number of digits after the “seconds” is determined in accordance with Article 2 of Delegated Regulation (EU) 2017/574 (MiFID RTS 25). 14 Priority size For trading venues which use size-time priority, this field must be populated with a positive number corresponding to the quantity. This field must be updated every time the priority of the order changes. Up to 20 numeric positive digits. 15 Sequence number Each and every event listed in section G must be identified using positive integers in ascending order. The sequence number must be unique to each type of event; consistent across all events, timestamped by the operator of the trading venue; be persistent for the date that the event occurs. {INTEGER-50} Section F — Identification of the order 16 Segment MIC code Identification of the trading venue where the order was submitted. If the trading venue uses segment MICs then the segment MIC must be used. If the trading venue does not use segment MICs then the operating MIC must be used {MIC} 17 Order book code The alphanumerical code established by the trading venue for each and every order book. {ALPHANUM-20} 18 Financial instrument identification code Unique and unambiguous identifier of the financial instrument {ISIN} 19 Date of receipt Date of receipt of the original order. {DATEFORMAT} 20 Order identification code An alphanumerical code assigned by the operator of the trading venue to the individual order. {ALPHANUM-50}

75 Section G – Events affecting the order 21 New order, order modification, order cancellation, order rejections, partial or full execution New order: receipt of a new order by the operator of the trading venue. “NEWO” — New order Triggered: an order which becomes executable or, as the case may be, non-executable upon the realisation of a pre-determined condition. “TRIG” — Triggered Replaced by the member or participant of the trading venue: where a member, participant or client of the trading venue decides upon its own initiative to change any characteristic of the order it has previously entered into the order book. “REME” — Replaced by the member or participant of the trading venue Replaced by market operations (automatic): where any characteristic of an order is changed by the trading venue operator’s IT systems. This includes where a peg order’s or a trailing stop order’s current characteristics are changed to reflect how the order is located within the order book. “REMA” — Replaced by market operations (automatic) Replaced by market operations (human intervention): where any characteristic of an order is changed by a trading venue operator’s staff. This includes the situation where a member, participant of the trading venue has IT issues and needs its orders to be cancelled urgently. “REMH” — Replaced by market operations (human intervention) Change of status at the initiative of the member, participant of the trading venue. This includes activation and deactivation. “CHME” — Change of status at the initiative of the member/participant of the trading venue Change of status due to market operations. “CHMO” — Change of status due to market operations Cancelled at the initiative of the member, participant of the trading venue; where a member, participant or client decides upon its own initiative to cancel the order it has previously entered “CAME” — Cancelled at the initiative of the member or participant of the trading venue Cancelled by market operations. This includes a protection mechanism provided for investment firms carrying out a market-making strategy. “CAMO” – Cancelled by market operations Rejected order: an order received but rejected by the operator of the trading venue. “REMO” — Rejected order Expired order: where the order is removed from the order book upon the end of its validity period. “EXPI” — Expired order Partially filled: where the order is not fully executed so that there remains a quantity to be executed. “PARF” — Partially filled

76 Filled: where there is no more quantity to be executed. “FILL” — Filled {ALPHANUM-4} characters not already in use for the trading venue’s own classification. Section H — Type of order 22 Order type Identifies the type of order submitted to the trading venue as per the trading venue specifications. {ALPHANUM-50} 23 Order type classification Classification of the order according to two generic order types. LIMIT order: in the cases where the order is tradable and STOP order: in the cases where the order becomes tradable only upon the realisation of a pre￾determined price event. The letters “LMTO” for limit or the letters “STOP” for stop. Section I – Prices 24 Limit price The maximum price at which a buy order can trade or the minimum price at which a sell order can trade. The spread price for a strategy order. It can be negative or positive. This field must be left blank in case of orders that do not have a limit price or in case of unpriced orders. In case of a convertible bond, the real price (clean or dirty) used for the order must be reflected in this field. {DECIMAL-18/13} in case the price is expressed as monetary value. Where price is reported in monetary terms, it must be provided in the major currency unit. {DECIMAL-11/10} in case the price is expressed as a percentage or yield. {DECIMAL-18/17} in case the price is expressed as basis points

77 25 Additional limit price Any other limit price which may apply to the order. This field must be left blank if not relevant. {DECIMAL-18/13} where the price is expressed as a monetary value. Where the price is reported in monetary terms, it must be provided in the major currency unit. {DECIMAL-11/10} where the price is expressed as a percentage or yield. {DECIMAL-18/17} in case the price is expressed as basis points 26 Stop price The price that must be reached for the order to become active. For stop orders triggered by events independent of the price of the financial instrument, this field must be populated with a stop price equal to zero. This field must be left blank if not relevant. {DECIMAL-18/13} where the price is expressed as a monetary value. Where the price is reported in monetary terms, it must be provided in the major currency unit. {DECIMAL-11/10} in case the price is expressed as a percentage or yield. {DECIMAL-18/17} in case the price is expressed as basis points. 27 Pegged limit price The maximum price at which a pegged order to buy can trade or the minimum price at which a pegged order to sell can trade. This field must be left blank if not relevant. {DECIMAL-18/13} where the price is expressed as a monetary value. Where the price is reported in monetary terms, it must be provided in the major currency unit. {DECIMAL-11/10} in case the price is expressed as a percentage or yield. {DECIMAL-18/17} in case the price is expressed as basis points

78 28 Transaction price 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 or index point. In the case of spread bets it must be the reference price of the direct underlying instrument. For credit default swaps it must be the coupon in basis points. Where price reported in monetary terms, it must be provided in the major currency unit. Where price is not applicable the field must be populated with the value “NOAP”. {DECIMAL-18/13} in case the price is expressed as monetary. {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 “NOAP” 29 Price currency Currency in which the trading price for the financial instrument related to the order is expressed (applicable where the price is expressed as monetary value). {CURRENCYCODE_3} 30 Currency of leg 2 Where there are multi-currency or cross-currency swaps, the currency of leg 2 must be the currency in which leg 2 of the contract is denominated. For swaptions where the underlying swap is multi-currency, the currency of leg 2 must be the currency in which leg 2 of the swap is denominated. This field only needs to be filled in where there are interest rates and currency derivatives contracts. {CURRENCYCODE_3} 31 Price notation Indicates whether the price is expressed in monetary value, in percentage, in yield or in basis points. “MONE” — Monetary value “PERC” — Percentage “YIEL” — Yield “BAPO” — Basis points

79 Section J – Order instructions 32 Buy-sell indicator To show if the order is to buy or sell. In case of options and swaptions, the buyer must be the counterparty that holds the right to exercise the option and the seller must be the counterparty that sells the option and receives a premium. In case of futures and forwards other than futures and forwards relating to currencies, the buyer must be the counterparty buying the instrument and the seller the counterparty selling the instrument. In the case of swaps relating to securities, the buyer must be the counterparty that gets the risk of price movement of the underlying security and receives the security amount. The seller must be the counterparty paying the security amount. In the case of swaps related to interest rates or inflation indices, the buyer must be the counterparty paying the fixed rate. The seller must be the counterparty receiving the fixed rate. In case of basis swaps (float-to-float interest rate swaps), the buyer must be the counterparty that pays the spread and the seller the counterparty that receives the spread. In the case of swaps and forwards related to currencies and of cross currency swaps, the buyer must be the counterparty receiving the currency which is first when sorted alphabetically by ISO 4217 standard and the seller must be the counterparty delivering this currency. In the case of swaps related to dividends, the buyer must be the counterparty receiving the equivalent actual dividend payments. The seller is the counterparty paying the dividend and receiving the fixed rate. “BUYI” — buy “SELL” — sell In the case of derivative instruments for the transfer of credit risk except options and swaptions, the buyer must be the counterparty buying the protection. The seller is the counterparty selling the protection. In case of derivative contracts related to commodities or emission allowances, the buyer must be the counterparty that receives the commodity or emission allowance specified in the report and the seller the counterparty delivering this commodity or emission allowance. In case of forward rate agreements, the buyer must be the counterparty paying the fixed rate and the seller the counterparty receiving the fixed rate. For an increase in notional the buyer must be the same as the acquirer of the financial instrument in the original transaction and the seller must be the same as the disposer of the financial instrument in the original transaction. For a decrease in notional the buyer must be the same as the disposer of the financial instrument in the original transaction and the seller must be the same as the acquirer of the financial instrument in the original transaction.

80 33 Order status To identify orders that are active/inactive/suspended, firm/indicative (assigned to quotes only)/ implicit/rerouted. Active — non-quote orders that are tradable. Inactive — non-quote orders that are not tradable. Firm/Indicative — Assigned to quotes only. Indicative quotes mean that they are visible but cannot be executed. This includes warrants in some trading venue. Firm quotes can be executed. Implicit — Used for strategy orders that are derived from implied in or implied out functionality. Routed — Used for orders that are routed by the trading venue to other venues. “ACTI”- active or “INAC”- inactive or “FIRM”- firm quotes or “INDI”- indicative quotes or “IMPL”- implied strategy orders or “ROUT”- routed orders. If multiple statuses are applicable, this field must be populated with multiple flags separated by comma. 34 Quantity notation Indicates whether the quantity reported is expressed in number of units, as a nominal value or as a monetary value. “UNIT” — Number of units “NOML” — Nominal value “MONE” — Monetary value 35 Quantity currency Currency in which the quantity is expressed. Field only needs to be populated where the quantity is expressed as a nominal or monetary value. {CURRENCYCODE_3} 36 Initial quantity The number of units of the financial instrument, or the number of derivative contracts in the order. The nominal or monetary value of the financial instrument. For spread bets, the quantity must be the monetary value wagered per point movement in the underlying financial instrument. For an increase or decrease in notional derivative contracts, the number must reflect the absolute value of the change and must be expressed as a positive number. For credit default swaps, the quantity must be the notional amount for which the protection is acquired or disposed of. {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

81 37 Remaining quantity including hidden The total quantity that remains in the order book after a partial execution or in the case of any other event affecting the order. On a partial fill order event, this must be the total remaining volume after that partial execution. On an order entry this must equal the initial quantity. {DECIMAL-18/17} in case the quantity is expressed as a number of units {DECIMAL-18/5} where the quantity is expressed as monetary or nominal value 38 Displayed quantity The quantity that is visible (as opposed to hidden) in the order book. {DECIMAL-18/17} where the quantity is expressed as a number of units {DECIMAL-18/5} where the quantity is expressed as a monetary or nominal value 39 Traded quantity Where there is a partial or full execution, this field must be populated with the executed quantity. {DECIMAL-18/17} where the quantity is expressed as a number of units {DECIMAL-18/5} where the quantity is expressed as a monetary or nominal value 40 Minimum Acceptable Quantity (MAQ) The minimum acceptable quantity for an order to be filled which can consist of multiple partial executions and is normally only for non-persistent order types. This field must be left blank if not relevant. {DECIMAL-18/17} where the quantity is expressed as a number of units {DECIMAL-18/5} where the quantity is expressed as a monetary or nominal value 41 Minimum executable size (MES) The minimum execution size of any individual potential execution. This field must be left blank if not relevant. {DECIMAL-18/17} where the quantity is expressed as a number of units {DECIMAL-18/5} where the quantity is expressed as a monetary or nominal value 42 MES first execution only Specifies whether the MES is relevant only for the first execution. This field can be left blank where field 41 is left blank. “true” “false” 43 Passive only indicator Indicates if the order is submitted to the trading venue with a characteristic/flag, such that the order must not immediately execute against any contra visible orders. “true” “false”

82 44 Passive or aggressive indicator On partial fill and fill order events, indicates whether the order was already resting on the order book and providing liquidity (passive) or the order initiated the trade and thus took liquidity (aggressive). This field must be left blank if not relevant. “PASV” — passive or “AGRE” — aggressive. 45 Self￾Execution Prevention Indicates if the order has been entered with self-execution prevention criteria, so that it would not execute with an order on the opposite side of the book entered by the same member or participant. “true” “false” 46 Strategy Linked Order identification The alphanumerical code used to link all connected orders that are part of a strategy pursuant to MAR 13.4.7R. {ALPHANUM-50} 47 Routing Strategy The applicable routing strategy as per the trading venue specification. This field must be left blank if not relevant. {ALPHANUM-50} 48 Trading venue transaction identification code Alphanumerical code assigned by the trading venue to the transaction pursuant to MAR 13.4.13R. The trading venue transaction identification code must be unique, consistent and persistent per ISO10383 segment MIC and per trading day. Where the trading venue does not use segment MICs, the trading venue transaction identification code must be unique, consistent and persistent per operating MIC per trading day. The components of the trading venue transaction identification code must not disclose the identity of the counterparties to the transaction for which the code is maintained. {ALPHANUM-52}

83 Section K — Trading phases, indicative auction price and volume 49 Trading phases The name of each of the different trading phases during which an order is present in the order book including trading halts, circuit breakers and suspensions. {ALPHANUM-50} 50 Indicative auction price The price at which each auction is due to uncross in respect to the financial instrument for which one or more orders have been placed. {DECIMAL-18/5} in case the price is expressed as monetary or nominal value. Where price reported in monetary terms, it must be provided in the major currency unit. {DECIMAL-11/10} in case the price is expressed as a percentage or yield. 51 Indicative auction volume The volume (number of units of the financial instrument) that can be executed at the indicative auction price in field 50 if the auction ended at that precise moment of time. {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

84 14 Annex 1 Details to be reported in transaction reports Table 1: Legend for Table 2 (Format and standards to be used for reporting) 14 Annex 1.1 R Symbol Data Type Definition … {NATIONAL_ID} 35 alphanumerical characters The identifier is set out in MAR 14 Annex 2 (National client identifiers for natural persons to be used in transaction reports). 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 replacement report as for the original report that is being replaced. {ALPHANUM-52}

85 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 own 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}

86 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-15 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 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. 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 qualifying trading venue or on an organised trading platform outside of the United Kingdom that uses a central counterparty (CCP) and where the identity of the acquirer is not disclosed prior to execution, the LEI of the CCP must be used. Where the transaction was executed on a qualifying trading venue or on an organised trading platform outside of the United Kingdom that does not use a CCP and where the identity of the acquirer is not disclosed, the MIC 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 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. {LEI} {MIC} {NATIONAL_ID} “INTC”

87 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 spread bets, 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 must 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 must 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 must 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.

88 Additional details Fields 9-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 must be populated “True” where the buyer is a client of the executing entity. This field must 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} 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.5R to MAR 14.13.7R 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}

89 Seller details and decision maker For joint accounts, fields 16-20 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 16-24 must be populated by the receiving firm in the receiving firm’s report from the information received from the sending firm. 16 Seller identification code Code used to identify the disposer of the reportable financial instrument. Where the disposer is a legal entity, the LEI of the disposer must be used. Where the disposer 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 qualifying trading venue or on an organised trading platform outside of the United Kingdom that utilises a CCP and where the identity of the disposer is not disclosed prior to execution, the LEI of the CCP must be used. Where the transaction was executed on a qualifying trading venue or on an organised trading platform outside of the United Kingdom that does not utilise a CCP and where the identity of the disposer is not disclosed prior to execution, the MIC 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 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. {LEI} {MIC} {NATIONAL_ID} “INTC”

90 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 spread bets, 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 must 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 must 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 must 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.

91 17-24 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 with the identification code provided for the sending firm. {LEI} Transaction details 27 Trading date time Date and time when the transaction was executed. For transactions executed on a qualifying 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 qualifying 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 must be the date and time of the transaction rather than the time of the order transmission. {DATE_TIME_ FORMAT} 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. “DEAL” - Dealing on own account “MTCH” - Matched principal “AOTC” - Any other capacity

92 29 Quantity The number of units of the reportable financial instrument, or the number of derivative contracts in the transaction. The nominal or monetary value of the reportable 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 or 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 must be updated with the accurate price. 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). {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 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}

93 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 qualifying 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 must report the MIC of the SI. Use MIC “XOFF” for transactions in reportable financial instruments, where the transaction in that reportable financial instrument is not executed on a qualifying 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 “XXXX” for reportable financial instruments that are not admitted to trading or traded on a qualifying 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. {MIC} 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 relating 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 must 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}

94 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. 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-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 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}

95 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. 41 Instrument full name Full name of the reportable financial instrument. {ALPHANUM-350} 42 Instrument classification Taxonomy used to classify the reportable financial instrument. A complete and accurate CFI code must be provided. {CFI_CODE} 43 Notional currency 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 spread bets, the movement in the price of the underlying instrument on which the spread bet 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}

96 45 Underlying instrument code ISIN of the underlying instrument. For American depository receipts, 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 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. Where the underlying is an index and has an ISIN, the ISIN 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 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. {ISIN} 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 {INTEGER-3}+ “YEAR”
• years

97 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. Where strike price is currently not available but pending, the value must be “PNDG”. Where strike price is not applicable, the value “NOAP” must be populated. {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 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 must be the unadjusted date at which obligations under the derivative transaction stop being effective, as included in the confirmation. {DATEFORMAT}

98 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.14R. This field only applies for investment decisions within the firm. If there is no one within the firm responsible, 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.8 where the investment decision was made by a natural person. Where this applies, the value “NPEX” must be populated by the qualifying trading venue. {NATIONAL_ID} - Natural persons {ALPHANUM-50} – Algorithms “NPEX” - Natural person exemption for qualifying trading venues 52 Execution decision within firm Code used to identify the person or algorithm within the firm who is responsible for the execution. 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. Where this applies the value “NPEX” must be populated by the qualifying trading venue. {NATIONAL_ID} - Natural persons {ALPHANUM-50} – Algorithms “NORE” – No one responsible within the firm “DEAU” – No one responsible within the firm and the executing entity has provided DEA “NPEX” - Natural person exemption for qualifying trading venues Insert the following new annex, MAR 14 Annex 2, after MAR 14 Annex 1 (Details to be reported in transaction reports).

99 14 Annex 2 Details to be reported in transaction reports National client identifiers for natural persons to be used in transaction reports 14 Annex 2.1 R ISO 3166 — 1 alpha 2 Country name 1st priority identifier 2nd priority identifier 3rd priority identifier AT Austria CONCAT BE Belgium Belgian National Number (Numéro de registre national — Rijksregisternummer) CONCAT BG Bulgaria Bulgarian Personal Number CONCAT CY Cyprus National Passport Number CONCAT CZ Czech Republic National identification number (Rodné číslo) Passport Number CONCAT DE Germany CONCAT DK Denmark Personal identity code 10 digits alphanumerical: DDMMYYXXXX CONCAT EE Estonia Estonian Personal Identification Code (Isikukood) ES Spain Tax identification number (Código de identificación fiscal) FI Finland Personal identity code CONCAT FR France CONCAT GB United Kingdom UK National Insurance number CONCAT GR Greece 10 DSS digit investor share CONCAT HR Croatia Personal Identification Number (OIB — Osobni identifikacijski broj) CONCAT

100 HU Hungary CONCAT IE Ireland CONCAT IS Iceland Personal Identity Code (Kennitala) IT Italy Fiscal code (Codice fiscale) LI Liechtenstein National Passport Number National Identity Card Number CONCAT LT Lithuania Personal code (Asmens kodas) National Passport Number CONCAT LU Luxembourg CONCAT LV Latvia Personal code (Personas kods) CONCAT MT Malta National Identification Number National Passport Number NL Netherlands National Passport Number National identity card number CONCAT NO Norway 11 digit personal id (Foedselsnummer) CONCAT PL Poland National Identification Number (PESEL) Tax Number (Numer identyfikacji podatkowej) PT Portugal Tax number (Número de Identificação Fiscal) National Passport Number CONCAT RO Romania National Identification Number (Cod Numeric Personal) National Passport Number CONCAT SE Sweden Personal identity number CONCAT SI Slovenia Personal Identification Number (EMŠO: Enotna Matična Številka Občana) CONCAT

101 SK Slovakia Personal number (Rodné číslo) National Passport Number CONCAT All other countries National Passport Number CONCAT 15 Annex 1 Details to be reported as financial instrument reference data Table 1 Field descriptions for Table 3 (Details to be reported as financial instrument reference data) 15 Annex 1.1 R Symbol Data Type Definition {ALPHANUM-n} Up to n alphanumerical characters Free text field. {CFI_CODE} 6 characters ISO 10962 CFI code {COUNTRYCODE_2} 2 alphanumerical characters 2 letter country code, as defined by ISO 3166-1 alpha-2 country code {CURRENCYCODE_3} 3 alphanumerical characters 3 letter currency code, as defined by ISO 4217 currency codes {DATE_TIME_FORMAT} ISO 8601 date and time format Date and time in the following format: YYYY-MM-DDThh:mm:ss.ddddddZ. “YYYY” is the year; “MM” is the month; “DD” is the day; “T” - means that the letter ‘T’ must be used; “hh” is the hour; “mm” is the minute; “ss.dddddd” is the second and its fraction of a second; Z is UTC time. Dates and times must be reported in UTC. {DATEFORMAT} ISO 8601 date format Dates must be formatted in the following format: YYYY-MM-DD.

102 {DECIMAL-n/m} Decimal number of up to n digits in total of which up to m digits can be fraction digits Numerical field for both positive and negative values. decimal separator is “.” (full stop); negative numbers are prefixed with “-” (minus); values are rounded and not truncated. {INDEX} 4 alphabetic characters “EONA” - EONIA “EONS” - EONIA SWAP “EURI” - EURIBOR “EUUS” - EURODOLLAR “EUCH” - EuroSwiss “GCFR” - GCF REPO “ISDA” - ISDAFIX “LIBI” - LIBID “LIBO” - LIBOR “MAAA” - Muni AAA “PFAN” - Pfandbriefe “TIBO” - TIBOR “STBO” - STIBOR “BBSW” - BBSW “JIBA” - JIBAR “BUBO” - BUBOR “CDOR” - CDOR “CIBO” - CIBOR “MOSP” - MOSPRIM “NIBO” - NIBOR “PRBO” - PRIBOR “TLBO” - TELBOR “WIBO” - WIBOR “TREA” - Treasury “SWAP” - SWAP “FUSW” - Future SWAP

103 {INTEGER-n} Integer number of up to n digits in total Numerical field for both positive and negative integer values. {ISIN} 12 alphanumerical characters ISIN code, as defined in ISO 6166 {LEI} 20 alphanumerical characters Legal entity identifier as defined in ISO 17442 {MIC} 4 alphanumerical characters Market identifier as defined in ISO 10383 15 Annex 1.2 R Table 2: Classification of commodity and emission allowances derivatives for Table 3 (Fields 27 to 29). Base product Sub product Further sub product “AGRI” - Agricultural “GROS” - Grains and Oil Seeds “FWHT” - Feed Wheat “SOYB” - Soybeans “CORN” - Maize “RPSD” - Rapeseed “RICE” - Rice “OTHR” - Other “SOFT” - Softs “CCOA” - Cocoa “ROBU” - Robusta Coffee “WHSG” - White Sugar “BRWN” - Raw Sugar “OTHR” - Other “POTA” - Potato “OOLI” - Olive oil “LAMP” - Lampante “DIRY” - Dairy “FRST” - Forestry “SEAF” - Seafood

104 “LSTK” - Livestock “GRIN” - Grain “MWHT” - Milling Wheat “NRGY” - Energy “ELEC” - Electricity “BSLD” - Base load “FITR” - Financial Transmission Rights “PKLD” - Peak load “OFFP” - Off-peak “OTHR” - Other “NGAS” - Natural Gas “GASP” - GASPOOL “LNGG” - LNG “NBPG” - NBP “NCGG” - NCG “TTFG” - TTF “OILP” - Oil “BAKK” - Bakken “BDSL” - Biodiesel “BRNT” - Brent “BRNX” - Brent NX “CNDA” - Canadian “COND” - Condensate “DSEL” - Diesel “DUBA” - Dubai “ESPO” - ESPO “ETHA” - Ethanol “FUEL” - Fuel “FOIL” - Fuel Oil “GOIL” - Gasoil “GSLN” - Gasoline “HEAT” - Heating Oil “JTFL” - Jet Fuel “KERO” - Kerosene “LLSO” - Light Louisiana Sweet (LLS)

105 «MARS» - Mars «NAPH» - Naptha «NGLO» - NGL “TAPI” - Tapis “URAL” - Urals “WTIO” - WTI “COAL” - Coal “INRG” - Inter Energy “RNNG” - Renewable energy “LGHT” - Light ends “DIST” - Distillates “ENVR” - Environmental “EMIS” - Emissions “CERE” - CER “ERUE” - ERU “EUAE” - EUA “EUAA” - EUAA “OTHR” - Other “WTHR” - Weather “CRBR” - Carbon related “FRGT” - “Freight” “WETF” - Wet “TNKR” - Tankers “DRYF” - Dry “DBCR” - Dry bulk carriers “CSHP” - Container ships “FRTL” - “Fertilizer” “AMMO” - Ammonia “DAPH” - DAP (Diammonium Phosphate) “PTSH” - Potash “SLPH” -Sulphur “UREA” - Urea “UAAN” - UAN (urea and ammonium nitrate)

106 “INDP” - Industrial products “CSTR” - Construction “MFTG” - Manufacturing “METL” - Metals “NPRM” - Non Precious “ALUM” - Aluminium “ALUA” - Aluminium Alloy “CBLT” - Cobalt “COPR” - Copper “IRON” - Iron ore “LEAD” - Lead “MOLY” - Molybdenum “NASC” - NASAAC “NICK” - Nickel “STEL” - Steel “TINN” - Tin “ZINC” - Zinc “OTHR” - Other “PRME” - Precious “GOLD” - Gold “SLVR” - Silver “PTNM” - Platinum “PLDM” - Palladium “OTHR” - Other “MCEX” - Multi Commodity Exotic “PAPR” - Paper “CBRD” - Containerboard “NSPT” - Newsprint “PULP” - Pulp “RCVP” - Recovered paper “POLY” - Polypropylene “PLST” - Plastic “INFL” - Inflation

107 “OEST” - Official economic statistics “OTHC” - Other C10 derivatives as defined in Table 10.1 of Section 10 of Annex III to Commission Delegated Regulation (EU) 2017/583 (MiFID RTS 2). “OTHR” - Other 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 1 Instrument identification code Code used to identify the financial instrument. {ISIN} 2 Instrument full name Full name of the financial instrument. {ALPHANUM-350} 3 Instrument classification Taxonomy used to classify the financial instrument. A complete and accurate CFI code must be provided. {CFI_CODE} Issuer related fields 4 Issuer or operator of the qualifying trading venue identifier LEI of issuer or qualifying trading venue operator. {LEI} Venue related fields 5 Trading venue Segment MIC for the trading venue, where available, otherwise operating MIC. {MIC} 6 Request for admission to trading by issuer Whether the issuer of the financial instrument has requested or approved the trading or admission to trading of its financial instrument on a trading venue. “true” - Yes “false” - No

108 7 Date of approval of the admission to trading Date and time the issuer has approved admission to 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. {DATE_TIME_FORMAT} 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. {DATE_TIME_FORMAT} 9 Date of admission to trading or date of first trade Date and time of the admission to trading on the trading venue or the date and time when the instrument was first traded or an order or quote was first received by the trading venue. {DATE_TIME_FORMAT} 10 Termination date Where available, the date and time when the financial instrument ceases to be traded or to be admitted to trading on the trading venue. {DATE_TIME_FORMAT} Notional related fields 11 Notional currency 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 will be the notional currency of the underlying swap. For swaptions where the underlying is multi-currency, this will be the notional currency of leg 1 of the swap. {CURRENCYCODE_3} Bonds or other forms of securitised debt related fields 12 Total issued nominal amount Total issued nominal amount in monetary value. {DECIMAL-18/5} 13 Maturity date Date of maturity of the financial instrument. Field applicable to Debt instruments with defined maturity. {DATEFORMAT} 14 Fixed rate The fixed rate percentage of return on a Debt instrument when held until maturity date, expressed as a percentage. {DECIMAL-11/10} Expressed as a percentage (e.g. 7.0 means 7 % and 0.3 means 0.3 %)

109 15 Identifier of the index/ benchmark of a floating rate bond Where an identifier exists. {ISIN} 16 Name of the index/ benchmark of a floating rate bond Where no identifier exists, name of the index. {INDEX} Or {ALPHANUM-25} - if the index name is not included in the {INDEX} list 17 Term of the index/benchmark of a floating rate bond. Term of the index/benchmark of a floating rate bond. The term must be expressed in days, weeks, months or years. {INTEGER-3}+”DAYS” - days {INTEGER-3}+”WEEK” - weeks {INTEGER-3}+”MNTH” - months {INTEGER-3}+”YEAR” - years 18 Base point spread of the index/benchmark of a floating rate bond Number of basis points above or below the index used to calculate a price {INTEGER-5} Derivatives and securitised derivatives related fields 19 Expiry date Expiry date of the financial instrument. Field applicable to derivatives with a defined expiry date. {DATEFORMAT} 20 Price multiplier Number of units of the underlying instrument represented by a single derivative contract. For a future or option on an index, the amount per index point. For spread bets, the movement in the price of the underlying instrument on which the spread bet is based. {DECIMAL-18/17}

110 21 Underlying instrument code ISIN of the underlying instrument. For American depositary receipts, global depositary receipts and similar instruments, the ISIN of the financial instrument on which those instruments are based. For convertible bonds, the ISIN of the instrument 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, 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 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 21 and 22 must be reported as many times as necessary to list all instruments in the basket. {ISIN} 22 Underlying issuer In case the instrument is referring to an issuer, rather than to one single instrument, the LEI of the issuer. {LEI} 23 Underlying index name In case 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 24 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 {INTEGER-3}+”YEAR” - years

111 25 Strike price Predetermined 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 applicable to options or warrants, where strike price can be determined at the time of execution. Where price is currently not available but pending, the value must be “PNDG”. Where strike price is not applicable the field must not be populated. {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 26 Strike price currency Currency of the strike price {CURRENCYCODE_3} Commodity and emission allowances derivatives 27 Base product Base product for the underlying asset class as specified in the classification of commodities and emission allowances derivatives table. Only values in the “Base product” column of the classification of commodities derivatives table are allowed. 28 Sub product The sub product for the underlying asset class as specified in the classification of commodities and emission allowances derivatives table. Field requires a base product. Only values in the “Sub product” column of the classification of commodities derivatives table are allowed. 29 Further sub product The further sub product for the underlying asset class as specified in the classification of commodities and emission allowances derivatives table. Field requires a sub product. Only values in the “Further sub product” of the classification of commodities derivatives table are allowed.

112 30 Transaction type Transaction type as specified by the trading venue “FUTR” - Futures “OPTN” - Options “TAPO” - TAPOS “SWAP” - SWAPS “MINI” - Minis “OTCT” - OTC “ORIT” - Outright “CRCK” - Crack “DIFF” - Differential “OTHR” - Other 31 Final price type Final price type as specified by the trading venue “ARGM” - Argus/McCloskey “BLTC” - Baltic “EXOF” - Exchange “GBCL” - GlobalCOAL “IHSM” - IHS McCloskey “PLAT” - Platts “OTHR” - Other Interest rate derivatives The fields in this section must only be populated for instruments that have non-financial instrument of type interest rates as underlying. 32 Reference rate Name of the reference rate {INDEX} Or {ALPHANUM-25}- if the reference rate is not included in the {INDEX} list 33 IR Term of contract If the asset class is Interest Rates, this field states the term of the contract. The term must be expressed in days, weeks, months or years. {INTEGER-3}+”DAYS” - days {INTEGER-3}+”WEEK” - weeks {INTEGER-3}+”MNTH” - months {INTEGER-3}+”YEAR” - years

113 34 Notional currency 2 In the case of multi-currency or cross-currency swaps the currency in which leg 2 of the contract is denominated. For swaptions where the underlying swap is multi-currency, the currency in which leg 2 of the swap is denominated. {CURRENCYCODE_3} 35 Floating rate of leg 2 An indication of the interest rate used if applicable. {INDEX} Or {ALPHANUM-25} - if the reference rate is not included in the {INDEX} list 36 IR Term of contract of leg 2 An indication of the reference period of the interest rate, which is set at predetermined intervals by reference to a market reference rate. The term must be expressed in days, weeks, months or years. {INTEGER-3}+”DAYS” - days {INTEGER-3}+”WEEK” - weeks {INTEGER-3}+”MNTH” - months {INTEGER-3}+”YEAR” - years

© Financial Conduct Authority 2026 12 Endeavour Square London E20 1JN Telephone: +44 (0)20 7066 1000 Website: www.fca.org.uk All rights reserved Pub ref: 1-008576 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