Summary
The FCA’s PS26/2 is not just a reporting reform but a direction of travel we’ve been seeing consistently with regulation: moving to addressing data architecture.
At its core, the policy introduces a single, cross-regulator regime for:
- operational incident reporting
- material third-party reporting
with a clear objective: structured, timely, decision-useful data to enable real-time supervisory response and systemic risk identification. For AIFMs, this shifts the burden from “can you report?” to “can you operationalise and evidence your data at speed?”
The FCA is driving towards visibility that is more timely, structured, and comparable across firms and across third-party dependencies. Visibility that allows patterns to be identified early, rather than reconstructed after the fact.
This shift is being driven by a change in operational risk itself.
In 2025, over 40% of reported incidents were linked to third-party providers and reflects a system where failure no longer sits neatly within firm boundaries, but propagates through shared infrastructure, outsourced services, and increasingly complex digital supply chains.
If incidents are increasingly driven by third parties, by infrastructure, platforms, and providers outside the firm’s direct control, then reporting can only ever be part of the solution. Firms are still fully accountable for outcomes. But increasingly, they are not fully in control of the components that drive those outcomes.
From internal resilience to distributed exposure
Operational resilience has traditionally been framed around what sits inside the firm. Systems, controls, governance, escalation frameworks were all designed around a relatively defined perimeter. But what happens when that perimeter is dissolved?
Critical services now sit across cloud environments, administrators, data providers, RegTech platforms, and intra-group structures that themselves rely on external dependencies. The result is a more distributed model of risk, where disruption can originate anywhere along the chain and cascade quickly.
This creates a structural tension where firms are expected to demonstrate resilience, but much of the infrastructure underpinning that resilience sits outside their direct control.
What the FCA is actually building
The language of the policy focuses on clarity and consistency with a streamlined approach across the FCA, PRA, and Bank of England. But the underlying objective is more ambitious.
The regulators are aiming to build a dataset that allows them to understand how the financial system behaves under stress. To do that, they need data that is structured, consistent, and comparable. It needs to be able to link incidents across firms, identify common third-party dependencies, and detect concentration risk as it emerges.
The move to a single portal and standardised templates is not simply about reducing burden but about creating the conditions for system-wide analysis. This is less about reporting individual events, and more about mapping the architecture of the system itself.
What has actually changed
1. Single regime = single data standard
- One definition of incidents
- One reporting portal (FCA Connect)
- One structured template
- One lifecycle-based reporting process
This will be standardisation to enable cross-firm comparability, systemic pattern detection and faster regulatory intervention. Data consistency will really matter.
2. Reporting is now lifecycle-based, not event-based
For enhanced firms (relevant to many AIFMs depending on scale):
- initial → intermediate → final updates via a single dynamic form
- initial notification expected within ~24 hours of threshold breach
This creates an operational shift where reporting is no longer retrospective but live, iterative, and data driven.
3. Third-party reporting moves from outsourcing to ecosystem mapping
The regime expands from outsourcing to:
- all material third-party arrangements (including non-outsourcing)
- annual structured register
- notification of new or materially changed arrangements
This will enable regulators to map of dependencies across the financial system and have visibility of concentration risk and systemic nodes for supply chain intelligence.
Where firms are likely to underestimate the challenge
A logical approach by AIFMs to PS26/2 is reviewing the templates, build or update their third-party registers, and ensure that incident reporting processes align with the new timelines and thresholds. All of that is necessary, but it is not where the real challenge lies.
The harder questions sit beneath the surface but need to be addressed. Do firms genuinely understand their dependency chains beyond their immediate vendors? Can they identify where concentration risk sits within their operating model? If a key provider fails, do they retain meaningful control over data, access, and continuity of service, or are they dependent on contractual assurances and retrospective explanations?
The FCA is not explicitly asking these questions in the rules, but the data it collects will increasingly allow it to answer them.
Judgement, not checklists
As always under the principles based regulatory system, one of the more subtle but important features of the framework is the reliance on judgement. There are no hard quantitative thresholds that determine whether an incident must be reported. Instead, firms are expected to form a “reasonable belief” that a threshold has been met, based on the information available at the time.
Operational risk does not lend itself to rigid standardisation across firms of different sizes, structures, and business models. What the FCA is doing instead is placing responsibility back on firms to exercise judgement, and then to evidence that judgement through structured, timely reporting.
Governance and record keeping will be a critical factor for firms to consider. It is not just about whether a rule was followed, but whether a decision was defensible in the moment it was made.
Practical next steps for AIFMs (12-month window)
With implementation by March 2027, the timeline is deceptively long.
Phase 1: Gap assessment (0–3 months)
- map current incident reporting process vs FCA lifecycle
- assess data availability at “initial notification” stage
- review third-party register against new definition of materiality
Phase 2: Data design (3–6 months)
- define internal taxonomies aligned to FCA templates
- design incident and third-party data models
- identify system owners (IT vs Compliance vs Ops)
Phase 3: Implementation (6–12 months)
- centralise incident logging
- digitise third-party register
- integrate reporting outputs with FCA Connect requirements
Phase 4: Testing and governance (12–18 months)
- simulate incidents and reporting timelines
- test escalation and threshold decision-making
- embed into SMCR accountability and board MI
Final thought
Over the next 12 months, the question is simple: if an incident happens tomorrow, could you identify it, classify it, and submit a defensible report within 24 hours using data you already trust?
If the answer is no, then there is a real operational gap to fill to end up with clearer ownership of their risks, faster internal decision-making, and a much stronger grip on the third parties they rely on.
