Theme 1 - Who reports and who does not under PS26/15
Reporting responsibility under PS26/15 depends on a firm's regulatory status. A smaller population of energy and commodity firms are MiFID investment firms that meet the definition of a transaction reporting firm. These firms carry a direct MAR 14 obligation to report and are responsible for the completeness, accuracy and timely submission of their reports (PS26/15, Appendix 2, MAR 14.7.1R, 14.11.1R).
The definition also captures a third-country investment firm carrying on MiFID or equivalent third-country business from an establishment in the UK, so a UK branch of an overseas trading group can fall within the perimeter even where the group's head office does not (PS26/15, page 23, section "Transaction reporting firms").
Non-investment firm requirements. Most energy and commodity firms sit outside this perimeter as they are not investment firms. For these firms, MAR 14.8 places the reporting obligation on the operator of the qualifying trading venue through which the transaction is executed. The venue must report relevant transactions in reportable financial instruments carried out by a member, participant or client that is not itself a transaction reporting firm, including negotiated transactions brought onto the venue rather than executed against the order book (PS26/15, Appendix 2, MAR 14.8.1R). MAR 14.8 also requires the venue to obtain the firm's LEI before providing a service that triggers this reporting obligation, which places the formal data-collection duty on the venue even though the firm remains the practical source of that data.
A non-investment firm can also appear in a transaction report without acquiring a reporting obligation of its own. Where it trades bilaterally with a MiFID investment firm, that firm reports the transaction under MAR 14.7 and identifies the non-investment firm as counterparty, generally through its LEI (PS26/15, page 16). This differs from the MAR 14.8 route, where the venue itself submits the report rather than the counterparty. Where two transaction reporting firms trade with each other, MAR 14.10.1R allows Conditional Single-Sided Reporting (CSSR), under which the receiving firm submits a single report incorporating details transmitted by the sending firm rather than both parties reporting separately. Both counterparties must be transaction reporting firms for CSSR to apply.
Investment firm requirements. An investment firm may submit its transaction reports directly to the FCA or through an approved reporting mechanism (ARM), or through a person verified under the Data Reporting Services (DRS) Regulations (click here). Using an ARM changes the submission channel only. It does not change the investment firm's regulatory status or its underlying responsibility for the report. MAR 14.11.2R relieves the investment firm of responsibility only for failures attributable to the ARM itself, not for failures originating in the firm's own trade or reference data (PS26/15, Appendix 2, MAR 14.11.2R).
For firms with MiFID investment-firm status, the first control point is an impact assessment of the existing transaction-reporting operating model against the final MAR 14 framework. This includes confirming which entities, including any UK-established third-country branches, fall within the transaction-reporting-firm definition, and testing whether current systems meet the completeness, accuracy and timeliness standard set by MAR 14.11.
Determination of reportable financial instruments (OTC and exchange traded). Once a firm has confirmed it is a transaction reporting firm, it must determine whether a given exchange-traded or OTC derivative is itself a reportable financial instrument, including the use of FCA Financial Instrument Reference Data System (FIRDS - click here) for eligibility assessment. We review this determination in Theme 3. Responsibility for completeness, accuracy and timely submission under MAR 14.11 applies once reportability is established, subject to the specific allocation of responsibility for failures attributable to an ARM or other permitted reporting provider (PS26/15, Appendix 2, MAR 14.5, MAR 14.11).
Where an ARM is used, the firm should be able to reconcile its internal trade record against what the ARM actually submitted, so that a failure can be attributed correctly between firm data and ARM processing rather than assumed to fall under the narrow MAR 14.11.2R relief by default.
Non-investment firms should confirm which qualifying trading venues report on their behalf under MAR 14.8, and should review what information those venues require to complete an accurate report, including LEI and other counterparty static data. While non-investment firms do not need to build a MAR 14 reporting capability they should define a process for supplying accurate data to the venue and for correcting errors identified through venue queries.
Firms relying on CSSR should confirm counterparty status directly rather than inferring it from the counterparty's size or market profile. A large, well-known trading counterparty is not necessarily a transaction reporting firm in the MAR 14 sense, and CSSR is only available where both parties meet the definition.
For firms operating both a regulated trading entity and an unregulated physical business within the same group, governance should confirm that each entity's reporting route is mapped and documented separately based on the specific legal entity status of the respective contracting entity.
Theme 2 - FX derivatives removed from UK MiFIR transaction reporting as regulatory reliance shifts to UK EMIR
CP25/32 identified foreign exchange derivative reporting as a recurring source of operational difficulty for firms, citing problems with base and quote currency conventions, FX swaps, short-dated forwards, and differences between MiFIR and UK EMIR reporting conventions (CP25/32, pages 35-36, section "Foreign exchange (FX) derivatives"). PS26/15 adopts the proposed exclusion in full. The FCA concludes that UK EMIR is a more appropriate and effective source of information for monitoring FX derivative markets than UK MiFIR transaction reporting (PS26/15, pages 11-12, paragraphs 3.8-3.13).
The final policy also provides confirmation of the FX products that are removed. The exclusion covers:
- Options;
- Futures;
- Swaps;
- Forward rate agreements; and
- Other derivative contracts relating to currencies that may be settled physically or in cash.
Derivative contracts relating to cryptoassets remain outside the FX exclusion (PS26/15, page 12, section “Foreign exchange (FX) derivatives”).
The FCA's transitional approach links early relief from MiFIR FX transaction reporting directly to whether the same transactions are already being reported under UK EMIR. From 3 August 2026 until 3 April 2028, the FCA will refrain from supervisory action against firms that stop submitting MiFIR transaction reports for FX derivatives where those firms continue to submit UK EMIR data for the same transactions. This allows firms already providing the FCA with equivalent FX data through UK EMIR to benefit from the simplification before the new MAR 14 rules formally take effect. Firms outside the UK EMIR reporting perimeter must continue to meet their applicable MiFIR transaction-reporting requirements during the implementation period.
PS26/15 specifically identifies UK branches of third-country firms as part of this latter population, reflecting the current gap in UK EMIR coverage that the FCA plans to consider separately through its wider UK EMIR reform work (PS26/15, page 12, section “Foreign exchange (FX) derivatives”).
For regulated energy and commodity firms with a centralised treasury function, the FX reporting exclusion is not a uniform relief that applies the moment the transitional period starts. A treasury desk executing equivalent currency hedges for several group entities through common systems may find that one entity qualifies for early relief while another does not, depending on each entity's UK EMIR reporting status rather than on the treasury function's own view of its FX activity.
A transaction reporting firm within the group that also submits UK EMIR data for the same FX transactions can rely on the early MiFIR relief. A UK branch of a third-country firm that does not submit UK EMIR data for those transactions cannot, and must continue MiFIR reporting until the new regime formally applies from 3 April 2028.
Firms should not apply the FX relief on a group-wide basis. Instead, they should map each legal entity's UK MiFIR and UK EMIR reporting status individually. This mapping should be done entity by entity and, within each entity, product by product, since the FX exclusion applies to a defined set of instrument types (options, futures, swaps, forward rate agreements, and other physically or cash-settled currency derivatives) and does not extend to cryptoasset derivatives. A group that stops MiFIR FX reporting across all entities on the assumption that the exclusion applies uniformly risks a reporting gap for any entity or branch that does not have equivalent UK EMIR coverage.
UK branches of third-country groups are also important to analyse. Where a group's UK branch structure means that branch-level UK EMIR coverage differs from the coverage maintained by other group entities, compliance functions should confirm the branch's specific reporting position rather than relying on the wider group's UK EMIR status. The FCA has flagged this branch population directly, which indicates it expects firms to identify this gap themselves during the transition rather than waiting for the wider UK EMIR reform work referenced in PS26/15 to resolve it.
Theme 3 - The reporting perimeter moves to a UK trading-venue nexus, while EU-only instruments are removed
CP25/32 identified the removal of instruments tradeable only on EU trading venues as one of the most significant scope changes proposed for firms operating across UK and continental European commodity markets, alongside the operational consequences of divergence between UK and EU reporting frameworks (CP25/32, pages 15-16, 29-33). PS26/15 adopts the narrower UK geographic scope and removes financial instruments whose only reporting nexus arises from EU-venue trading. The FCA estimates that around seven million EU-only instruments will leave the reporting population as a result (PS26/15, pages 8-14, 38-39).
The narrower scope does not mean MAR 14 applies only to UK-executed transactions. The final definition of a reportable financial instrument retains several routes through which an instrument can acquire a UK reporting nexus. An instrument is reportable where it is itself admitted to trading or traded on a qualifying UK trading venue. It can also become reportable where its underlying is a financial instrument traded on such a venue, or where its underlying is an index or basket containing at least one financial instrument traded on a qualifying UK venue. A regulated commodity firm can therefore execute an OTC derivative bilaterally, away from any venue, and still have a MAR 14 reporting obligation because of the UK venue status of the underlying rather than the place of execution (PS26/15, Appendix 2, definition of "reportable financial instrument"; MAR 14.5.2G).
FCA reference data determines reportability in practice. MAR 14.5.3G directs transaction reporting firms to use FCA-published financial instrument reference data, held in the Financial Instrument Reference Data System (FIRDS), when assessing whether an instrument is a reportable financial instrument. Where neither the instrument itself nor any relevant underlying instrument appears in FIRDS within seven working days of execution, the firm may conclude the instrument falls outside the reportable population. The FCA's policy response confirms that this T+7 treatment applies irrespective of where the transaction was executed, and that where the instrument or its underlying is absent from FIRDS by T+7, "there would be no obligation to report" (PS26/15, page 39, paragraphs 5.7-5.14; Appendix 2, MAR 14.5.3G).
OTC derivatives require a separate assessment. MAR 14.5.4G requires a transaction reporting firm to compare an OTC derivative's reference-data characteristics against FCA-published financial instrument reference data. An OTC derivative sharing the same instrument classification and applicable derivative fields as an instrument already in FCA reference data should be treated as reportable, even though the OTC transaction itself was not executed on a trading venue (PS26/15, page 13, paragraphs 3.14-3.17; Appendix 2, MAR 14.5.4G).
Supervisory flexibility applies during the implementation period. The FCA will refrain from action against firms that stop reporting transactions in financial instruments that are only tradeable on EU venues, identifiable through a non-GB "Upcoming Relevant Competent Authority" value ('RCA') in FIRDS (PS26/15, pages 11 and 49, sections "Geographic scope" and "Supervisory flexibility").
International alignment remains part of the FCA's longer-term approach. PS26/15 retains three long-term principles: data should only be collected where needed, firms should only report data once, and data should be shared between authorities where appropriate (PS26/15, pages 8-9, paragraphs 2.3-2.10). The FCA and Bank of England have established a Transaction and Post-trade Reporting Industry Harmonisation Taskforce (click here), which held its inaugural meeting in July 2026. The FCA states it will seek alignment with global data standards where appropriate, while continuing with UK-specific changes where it assesses the benefits to market integrity, growth and data quality as outweighing the costs of divergence (PS26/15, page 9, Chapter 2). The FCA has separately decided against adopting the Unique Product Identifier (UPI) for OTC derivatives at this stage, retaining the OTC ISIN instead. Its stated rationale is that the longer-term division of reporting between MAR 14 and UK EMIR remains under review, and introducing a new identifier now could require firms to make a further significant systems change that later becomes redundant (PS26/15, pages 18-19, section "OTC derivative identifiers").
Index and basket derivatives retain a simplified eligibility route. An index or basket derivative comes within scope where at least one constituent of the underlying index or basket is a financial instrument traded on a qualifying UK trading venue (PS26/15, Appendix 2, definition of "reportable financial instrument"; page 14, paragraphs 3.18-3.20). The FCA recognises that establishing this position can be disproportionately burdensome for index derivatives with large or changing constituent populations. PS26/15 therefore permits firms to voluntarily over-report index derivatives rather than complete the full constituent-level eligibility exercise before every reporting decision, provided that any transaction reported voluntarily is populated in accordance with the requirements applicable to comparable reportable index derivatives.
The FCA has decided against publishing a prescribed list of reportable indices (PS26/15, pages 13-14, paragraphs 3.18-3.20). For basket derivatives, firms must include the ISIN of each basket constituent admitted to trading or traded on a qualifying trading venue. MAR 14.13.24G permits firms to include ISINs for additional constituents not held in FCA reference data without causing the report to be rejected under Field 45 (PS26/15, Appendix 3, MAR 14 Annex 1, Field 45).
Energy and commodity firms should plan around continued UK and EU transaction reporting divergence rather than build implementation solutions based on an assumption that the regimes will remain aligned or converge. The UK-only instrument scope and removal of FX derivatives from UK MiFIR are already concrete examples of different UK reporting logic.
Investment firms with OTC commodity derivatives referencing UK-traded underlyings, or with any index or basket product containing a UK-venue constituent, should reassess reportability against the retained tests rather than assuming the EU-only removal reduces their reporting population proportionately.
The seven-working-day FIRDS check is an important control to review. MAR 14.5.3G allows transaction reporting firms to use FCA FIRDS to determine reportability for up to seven working days after execution. T+7 marks the end of the reportability assessment period rather than a reporting deadline. Where an instrument or relevant underlying appears in FCA FIRDS earlier in that period, for example on T+2, the firm has established that the instrument is reportable and should submit the transaction report as soon as possible rather than wait until T+7. Where the instrument and any relevant underlying remain absent from FCA FIRDS at T+7, the FCA states that there is no obligation to report the transaction. Firms should retain evidence of the FIRDS assessment supporting that conclusion. (PS26/15, p.39, paras 5.7–5.14; Appendix 2, MAR 14.5.1R and MAR 14.5.3G).
Firms should therefore monitor unresolved instruments throughout the seven working-day period and trigger reporting when FCA FIRDS establishes reportability. The final rules do not expressly specify a new submission deadline where an instrument first enters FIRDS after the ordinary T+1 reporting deadline. Firms should therefore report promptly once the instrument appears and review the FCA's forthcoming Transaction Reporting User Pack for further guidance on delayed-reference-data scenarios.
OTC derivative desks will require a comparison process against FIRDS reference-data characteristics. Because MAR 14.5.4G tests an OTC derivative's classification and applicable derivative fields against instruments already in FCA reference data, rather than testing where the OTC transaction itself was executed, product control (or equivalent) and reporting teams should ensure their instrument classification logic is capable of running this comparison systematically, rather than relying on manual review of individual trades.
For firms operating common reporting infrastructure across the UK and the EU, the retained divergence in scope, identifiers and now FX treatment (Theme 2) means implementation should be planned on the basis that UK and EU reporting logic will continue to differ, rather than on an expectation that the FCA's stated alignment principles will produce near-term convergence. The Harmonisation Taskforce's July 2026 inaugural meeting indicates the alignment work is still at an early, structural stage. Firms should therefore continue designing their April 2028 solution around the OTC ISIN as confirmed, rather than anticipating a UPI transition, while reviewing how OTC commodity derivatives are identified and how changes to a derivative's terms over its lifecycle are reflected in the identifier carried through trading, confirmation, booking and regulatory reporting.
The voluntary over-reporting option for index derivatives is a policy choice for the firm to adopt and document, and is not a default. Firms with material exposure to broad commodity or multi-asset indices should decide, and record, whether they will perform full constituent-level eligibility testing or adopt voluntary over-reporting for defined index populations, and should apply the chosen approach consistently rather than case by case. For basket derivatives, firms should review any existing system rule that strips out non-FIRDS constituents from the underlying-instrument field, since MAR 14.13.24G no longer requires this filtering and retaining it may now represent unnecessary processing rather than a compliance requirement.
Firms whose OTC commodity or emissions derivatives reference indices or baskets with a changing constituent population should continue to monitor this population. While PS26/15 does not itself state that firms must monitor index or basket composition on an ongoing basis, the reportability test depends on current constituent status, so a firm relying on a point-in-time assessment risks missing a change in composition that later brings the derivative into or out of scope.
Theme 4 - Algorithm reporting remains relevant to both regulated and non-investment firms
CP25/32 identified algorithm reporting as one of the most relevant elements of the consultation for energy and commodity trading firms, covering the proposed primary-responsibility rules, the treatment of investment and execution decisions, the new Direct Electronic Access User (DEAU) reporting value (field 52), and the continued relevance of algorithm identifiers for firms outside the transaction-reporting perimeter. PS26/15 largely adopts this framework and provides final clarity on the relationship between MAR 13 venue order records and MAR 14 transaction reports.
Field 51 – Investment decision within firm. For a transaction reporting firm, Field 51 identifies the person or algorithm responsible for the investment decision within the firm. This covers decisions taken for the firm's own account and decisions taken for a client under a discretionary mandate. Where more than one person or algorithm participates in the investment decision, the firm must identify the one with primary responsibility and establish criteria for making that determination (PS26/15, Appendix 2, pages 103-104, MAR 14.13.11R-14.13.13G).
MAR 14.13.13G states that the person allocated primary responsibility should have practical involvement in the relevant transaction-level decision, and that senior management with limited practical involvement would not normally represent an appropriate designation (PS26/15, Appendix 2, MAR 14.13.13G). An algorithm allocated primary responsibility must receive a designation that is unique for each set of code or trading strategy constituting the algorithm, used consistently for that algorithm or version, and unique over time (PS26/15, Appendix 2, MAR 14.13.14R).
Field 52 – Execution decision within firm. Field 52 captures a separate stage of the trading process from the investment decision reported in Field 51. Once the decision to trade has been made, the firm must identify the person or algorithm responsible for the subsequent execution decision. MAR 14.13.15R treats this as covering matters such as which trading venue, systematic internaliser or overseas organised trading platform to access, which firm an order should be transmitted to, or other conditions governing how the transaction is executed. Where more than one person or algorithm contributes to the execution decision, the primary-responsibility rules apply in the same way as for Field 51 (PS26/15, Appendix 2, MAR 14.13.15R-14.13.19G).
Non-investment firms remain relevant to MAR 13 order records. For orders submitted by a firm that is not a transaction reporting firm, the qualifying venue's MAR 13 order records must still capture algorithm information where an algorithm made the relevant investment decision. Where the investment decision was not made by an algorithm, the corresponding field is left blank.
The same treatment applies to execution decisions. An execution algorithm must be identified where one was responsible, while the field is left blank where execution was not algorithmic (PS26/15, Appendix 2, MAR 13.4.1R; Appendix 3, MAR 13 Annex 1, Fields 4-5). A non-investment firm does not become a transaction reporting firm because it uses an algorithm. Its trading activity nonetheless generates information that the qualifying venue must retain in its order records and, for relevant transactions, use in the transaction report it submits under MAR 14.8. MAR 14.8 expressly requires the venue to obtain the firm's LEI before providing a service that triggers the venue's reporting obligation (PS26/15, Appendix 2, MAR 14.8.1R-14.8.3R).
NPEX reduces natural-person reporting for non-investment firms, but not algorithm reporting. PS26/15 introduces NPEX, meaning Natural Person Exemption for qualifying trading venues. The code applies specifically where a qualifying trading venue submits a transaction report under MAR 14.8 for a member, participant or client that is not a transaction reporting firm.
The FCA introduced NPEX to reduce the burden and data-quality problems associated with venues collecting natural-person identifiers from firms outside the transaction-reporting perimeter (PS26/15, page 37, paragraphs 5.1-5.4). NPEX does not apply to a transaction reporting firm submitting its own MAR 14 report. Field 51 and Field 52 requirements continue to apply in full, including identification of the relevant natural person or algorithm where required (PS26/15, Appendix 3, MAR 14 Annex 1, Fields 51-52).
For non-investment firms, from 3 April 2028 a qualifying venue uses NPEX in Fields 51 or 52 where the relevant investment or execution decision was made by a natural person. Where the decision was algorithmic, the relevant algorithm identifier continues to be required. Non-investment firms therefore need to distinguish accurately between human and algorithmic decision-making and maintain the algorithm identifiers supplied to venues, but no longer need to manage natural-person identifiers solely for these venue transaction-reporting fields.
DEAU clarifies Direct Electronic Access (DEA) reporting. DEA allows a venue member or participant to permit another person to use its trading code to transmit orders directly to the venue. Where the reporting firm provides DEA and the execution decision sits with the DEA user, the provider reports the new DEAU value in Field 52, instead of the generic NORE value used for other circumstances where the execution decision was made outside the reporting firm (PS26/15, pages 33-34, paragraphs 4.52-4.53).
For a MiFID investment firm providing DEA, the reporting logic must distinguish DEA transactions from other externally determined execution decisions and populate Field 52 accordingly.
For a firm using DEA rather than providing it, the FCA expressly states that DEA users do not need to make changes solely because of the new DEAU value, and a non-investment firm using DEA does not acquire a MAR 14 reporting obligation as a result. DEAU is populated in the relevant DEA provider's transaction report, not by the DEA user (PS26/15, page 33, paragraph 4.52).
Firms with transaction reporting firm status should review how primary responsibility for investment and execution decisions is currently determined and documented, particularly for desks where more than one trader or system contributes to a single decision. Given that MAR 14.13.13G excludes senior management with limited practical involvement from being an appropriate Field 51 designation, firms should confirm that their existing sign-off or governance structures are not being used as a proxy for the primary-responsibility determination. The person or algorithm actually exercising practical control over the decision is the relevant reference point, not a supervisory or approval layer sitting above it.
Algorithm identification and governance require particular attention where a single algorithm, or a family of related algorithms, is used across multiple strategies or versions. Because MAR 14.13.14R requires a designation that is unique per set of code or trading strategy, used consistently and unique over time, firms running algorithmic commodity trading strategies should maintain a version-controlled mapping between each algorithm identifier and the underlying code or strategy it represents, updated whenever a material change is made to the algorithm.
Firms should treat Field 51 and Field 52 as genuinely separate. The investment decision and the execution decision can involve different people or algorithms, particularly where a portfolio manager or algorithm decides to trade but a separate execution desk or execution algorithm determines venue and timing. Reporting logic that defaults to using the same identifier for both fields risks misreporting execution arrangements that genuinely differ from the investment decision.
For non-investment firms, the practical requirement is to maintain, and supply to venues, an accurate record of whether each investment and execution decision was made by a natural person or an algorithm, together with the correct algorithm identifier where relevant. NPEX removes the need to manage natural-person identifiers for these specific venue-reporting fields, but it does not reduce the underlying need to track which decisions are algorithmic. Firms should not treat NPEX as a general simplification of algorithm governance and acknowledge that it only addresses the natural-person identification only.
Non-investment firms using algorithms should maintain a clear mapping between each venue-facing algorithm identifier, the underlying strategy or code, the relevant version, and whether the algorithm is responsible for the investment decision, the execution decision, or both. MAR 14.13.14R requires algorithm designations to be unique for each set of code or trading strategy constituting the algorithm, to be used consistently for the algorithm or version once assigned, and to remain unique over time. PS26/15 does not state that every modification to an algorithm automatically requires a new identifier. Where a change results in a new algorithm or version requiring a different designation under these rules, the identifier supplied to the relevant venue should be updated accordingly. Changes to execution arrangements may instead require an update to the firm's mapping of which algorithm is responsible for the investment or execution decision, without necessarily requiring a new algorithm identifier. Firms should also have clear internal ownership for investigating and correcting inaccurate LEIs, algorithm identifiers or other data flagged through venue queries. (PS26/15, Appendix 2, MAR 14.13.14R; Appendix 3, MAR 13 Annex 1, Fields 4–5)
Firms providing DEA should confirm that their reporting logic correctly distinguishes DEA-related execution decisions, requiring the DEAU value, from other circumstances where execution sits outside the firm, which continue to use the generic "No one responsible for execution" NORE value. This distinction did not exist in the same form under the previous regime, so firms should treat it as a new change to their reporting framework logic rather than an extension of existing NORE logic. Firms that only use DEA as customers, rather than providing it, do not need to change their own reporting arrangements, since DEAU is populated by the provider and does not create a reporting obligation for the DEA user.
Theme 5 - Back reporting and incident management create different obligations for investment and non-investment firms
Back reporting refers to the retrospective correction of transaction-reporting errors, omissions and failures to report. Final MAR 14.15.3R requires a transaction reporting firm or relevant qualifying trading venue to take corrective action where it becomes aware that a submitted transaction report contains an error or omission, a reportable transaction was not submitted, including where a rejected report was not successfully resubmitted, or a transaction was reported when there was no obligation to report it.
Back reporting was a principal theme in the CP25/32 review. The consultation proposed reducing the retrospective period over which those corrective obligations apply from five years to three years, and PS26/15 adopts that approach. Unless the FCA directs otherwise, MAR 14.15.4G provides that the corrective obligations in MAR 14.15.3R apply for three years from the date of execution. The FCA retains the ability to require five years of back reporting on an exceptional basis. Existing five-year transaction and order recordkeeping requirements remain unchanged. (PS26/15, pages 46-47; Appendix 2, MAR 14.15.3R-14.15.4G)
The three-year supervisory approach applies from 3 August 2026. Where a reporting issue requires historical remediation, firms will therefore generally be expected to correct the affected transactions executed within the preceding three years unless the FCA instructs otherwise. (PS26/15, page 49, Table 1)
A new governance expectation not present in the CP25/32 draft rules. Final MAR 14.15.5G expects a transaction reporting firm, or the operator of a qualifying trading venue that has submitted a transaction report under MAR 14.8, to establish and maintain a robust incident management framework addressing errors and omissions in transaction reports. The framework should be proportionate to the nature, scale and complexity of the business (PS26/15, page 36, section "Systems and controls for transaction reporting"). The framework should enable the firm or venue to undertake the following activities:
- Triage, assess and manage reporting incidents;
- Analyse the cause of errors or omissions;
- Implement remedial action and monitor progress;
- Operate an internal escalation protocol; and
- Notify the FCA under the applicable notification requirement.
The FCA did not introduce a materiality threshold for breach notifications at this stage (PS26/15, page 36).
The wider implementation guidance directs firms to assess data governance, ownership and control frameworks, including the completeness, accuracy and lineage of reporting data across internal systems, trading venues, ARMs and vendors (PS26/15, page 48, paragraphs 6.11-6.12).
Supervisory flexibility applies to remediation during the implementation period, but only to specifically identified requirements. For areas where the FCA is applying its flexible approach, firms are not expected to correct errors or omissions, or to notify the FCA about related issues, between 3 August 2026 and implementation of the new regime. This applies only to the specific requirements the FCA has identified in Chapter 6, and firms should incorporate the flexibility into their incident and remediation procedures on a requirement-by-requirement basis rather than as a general relaxation (PS26/15, page 48, paragraphs 6.13-6.14).
Chapter 6 sets this flexibility alongside two implementation topics. It directs firms to assess data governance, ownership and control frameworks, including the completeness, accuracy and lineage of reporting data across internal systems, trading venues, ARMs and vendors (PS26/15, page 48, paragraphs 6.11-6.12), and it confirms the backwards-compatible treatment of the new transaction-reporting schema for historical remediation, together with the FCA's decision not to introduce a separate amend function (PS26/15, pages 47-48, Chapter 6).
Historical remediation uses the new schema. The FCA confirms the new transaction-reporting schema will be backwards compatible, allowing transactions executed under the current regime to be resubmitted using the new schema after April 2028. The transaction's trade date determines whether the historical or new validation rules apply (PS26/15, pages 47-48, Chapter 6). The FCA rejected industry requests for a separate "amend" function, concluding that the system changes required across firms, ARMs and the FCA would be disproportionate to the expected benefit, though it may reconsider this through its longer-term harmonisation work (PS26/15, page 47, Chapter 6).
MAR 14.15.5G does not extend directly to non-investment firms. The incident-management framework applies to the transaction reporting firm and to a qualifying trading venue that has submitted reports under MAR 14.8. A non-investment commodity company does not acquire the same direct FCA incident-management expectation (PS26/15, Appendix 2, MAR 14.8 and MAR 14.15.5G). This differs from the position of an investment firm using an ARM, where responsibility moves to the ARM only for failures attributable to the ARM itself, and the investment firm otherwise remains within the MAR 14 reporting framework (PS26/15, Appendix 2, MAR 14.11.1R-14.11.2R).
Transaction reporting firms should treat the reduction in the default back-reporting period as a change in scope. The three-year default applies from 3 August 2026, but the FCA retains the ability to require five years on an ad hoc basis for serious reporting failings. Firms should ensure that historical data and audit trails remain available for at least five years despite the shorter default, since a firm unable to produce five years of data if the FCA exercises its extended power would be in a materially worse position than one that has simply reduced its retention practices to match the new default.
The introduction of MAR 14.15.5G is the more significant change for governance purposes. Transaction reporting firms should map their existing error-handling processes against the five specific capabilities the FCA has identified: triage, cause analysis, remedial action with progress monitoring, internal escalation, and FCA notification. Where any of these exists only informally, for example where root-cause analysis is performed inconsistently or escalation depends on individual judgment rather than a defined protocol, the framework should be documented formally, since MAR 14.15.5G expects an established framework rather than ad hoc practice. The absence of a materiality threshold for notification means firms cannot rely on an assumption that only large or high-value errors require escalation through the framework. The threshold for what triggers internal triage and potential FCA notification should be set by the firm's own documented criteria, applied consistently.
Firms should approach the supervisory flexibility implementation period with caution. Because the relief applies only to the specific requirements identified in Chapter 6, incident-management procedures should record, requirement by requirement, which obligations currently benefit from the flexible treatment and which remain fully operative. A general instruction to relax remediation activity across the whole transaction-reporting process during the transition would go beyond the FCA's stated position and risks leaving genuine errors uncorrected in areas the flexibility does not cover.
PS26/15 also resolves an important implementation issue for historical remediation. From 3 April 2028, the new transaction-reporting schema will be backwards compatible, allowing firms to correct transactions executed under the current regime by resubmitting them using the new schema. Firms will therefore not need to retain the existing submission schema solely for the purpose of correcting pre-April 2028 transactions. The FCA will use the transaction's trade date to determine whether the historical or new validation rules apply to the resubmitted report.
The FCA has also rejected requests for a separate 'amend' function. Historical errors will therefore continue to be corrected through resubmission of the relevant transaction report rather than by changing individual reporting fields. The detailed operation of the backwards-compatible schema and validation rules will become clearer when the FCA publishes its draft schema, validation rules and Transaction Reporting User Pack in October 2026.
Transaction reporting firms should ensure that they retain the historical transaction and reference data needed to reconstruct an accurate report when remediation is required. The FCA's approach removes the need to keep two live submission schemas, while the regulator will apply the appropriate historical or new validation rules according to the original trade date.
For non-investment firms, MAR 14.15.5G does not create a direct obligation, but it does not remove the practical need for an internal process. Where an incorrect LEI, algorithm identifier or account attribute supplied by the firm affects a venue's MAR 14.8 report, the firm should be able to investigate a venue query, identify the affected activity, and provide corrected information promptly. This is a narrower obligation than the formal incident-management framework required of transaction reporting firms and venues, but firms should not treat the absence of a direct MAR 14.15.5G obligation as removing the need for any documented process at all. A firm with no defined route for resolving venue queries about its own data risks delaying the venue's ability to meet its own MAR 14.15.5G obligations, even though the non-investment firm bears no direct regulatory consequence itself.
Firms should distinguish this position clearly from that of an investment firm using an ARM. Where an ARM is used, responsibility for the underlying transaction reporting obligation remains with the investment firm throughout, and only failures specifically attributable to the ARM are excluded from that responsibility. A non-investment firm relying on a venue under MAR 14.8 transfers reporting obligation to the venue, while the firm's role is limited to supplying accurate underlying data.