FCA PS26/2: What the New Operational Incident and Third-Party Reporting Rules Actually Mean for PSPs
Published on 18 March 2026, Policy Statement PS26/2 marks the FCA’s most substantive intervention in operational resilience reporting since the Payment Services Regulations 2017 introduced the first structured incident notification requirements for payment service providers. Together with the PRA’s PS7/26 and the Bank of England’s parallel statement for financial market infrastructures, it establishes a unified regime for operational incident and third-party reporting that will come into force on 18 March 2027, giving firms exactly twelve months to prepare.
The timing is not coincidental. In 2025, more than 40% of cyber incidents reported to the FCA involved a third party. High-profile outages affecting Cloudflare and AWS disrupted financial services across the sector, exposing the systemic vulnerability embedded in every payment and e-money firm’s dependency on a concentrated pool of technology providers. The regulator’s response is PS26/2: a framework designed not merely to record disruption after the fact, but to give the FCA structured, machine-readable data fast enough to intervene meaningfully while an incident is still unfolding.
For authorised payment institutions (APIs) and authorised electronic money institutions (AEMIs), this matters in a very specific way. Both are in scope for operational incident reporting, and AEMIs and APIs also fall squarely within the third-party reporting regime. The combination imposes obligations in two directions simultaneously: outward, when your own services fail customers; and inward, when the providers underpinning your operations create that failure for you.
The Operational Incident Reporting Framework
PS26/2 establishes a new rulebook definition of what constitutes a reportable operational incident, replacing the existing patchwork of obligations under PSRs 2017 regulation 99 and EBA major incident guidelines, which were quite outdated for quite a while. The new rules define an operational incident as “either a single event or a series of linked events which disrupts the firm’s operations such that it:
(a) disrupts the delivery of a service to an end user external to the firm; or
(b) impacts the availability, authenticity, integrity or confidentiality of information or data relating or belonging to such an end user.”
At the same time, the event has to cross certain thresholds. Those thresholds are designed around three categories of impact:
- consumer harm that is intolerable and difficult to recover from;
- threats to the safety and soundness of the firm or other market participants; and
- risks to market stability, integrity or confidence in the UK financial system.
The language is deliberately outcomes-based rather than prescriptive. Intolerable harm is not assigned a numerical definition; firms must assess it against the characteristics of their own customer base and service profile. For an API or an AEMI processing high-volume low-value transactions to retail customers, that assessment will look very different from a firm serving sophisticated institutional clients.
The reporting process itself operates in two tiers. Most FCA solo-regulated firms will submit a short ‘standard’ report through a single portal on the FCA’s Connect platform, regardless of which regulator the report is addressed to. A smaller subset of ‘enhanced’ reporting firms must provide more granular updates as an incident evolves and a formal, finalised report once it is resolved. The standard/enhanced distinction reflects the FCA’s proportionality argument: smaller firms posing a lower level of risks need not absorb the administrative burden of multi-stage reporting for incidents that do not pose systemic consequences. Sadly for APIs/AEMIs this distinction doesn’t matter that much, as all payment service providers are considered to be enhanced firms as per SUP 15.18.3 R (7).
Importantly, the rules incorporate a reasonable belief standard. A firm is not required to report instantaneously upon first detection; it must report as soon as practicable after it reasonably believes a threshold has been met. And if an incident escalates (initially assessed as sub-threshold before worsening) the firm will not be penalised for the delay in notification, provided it acts promptly once the threshold is crossed. This codifies the reality that operational incidents rarely arrive with clear labels.
The Third-Party Reporting Regime
The third-party reporting framework operates separately from, but in parallel to, incident reporting. Where incident reporting captures what went wrong, third-party reporting captures the structural dependencies that create exposure before anything goes wrong. It applies to a defined subset of regulated firms, a subset that includes AEMIs and APIs as explicit named categories.
Under the new rules, a third-party arrangement is material where its disruption or failure could:
- cause intolerable harm to the firm’s clients;
- pose a risk to the soundness, stability, resilience, confidence or integrity of the UK financial system; or
- cast serious doubt on the firm’s ability to satisfy the threshold conditions, or meet its obligations under the Principles, or under SYSC 15A (Operational resilience).
This is not a low bar. It targets the arrangements without which the firm’s important business services cannot function: core banking/payments platforms, cloud hosting, payment processing gateway, and fraud screening tools.
The obligations are threefold. Firms must notify the FCA of any new material third-party arrangement, and of any significant change to an existing one. Firms must also maintain a register of all material third-party arrangements and submit it annually to the FCA. The notification and register use a single standardised template across the FCA, PRA, and Bank of England, submitted through the FCA’s RegData platform for the register and Connect for notifications.
Regulatory Intent: Read Between the Lines
The FCA’s stated rationale is straightforward: consistent, structured data enables better and faster supervisory responses. But the architecture of PS26/2 reveals something more strategic. The FCA is not simply trying to receive better incident reports- it is building a surveillance infrastructure for the financial sector’s supply chain.
The third-party register is the centrepiece of this ambition. By requiring firms to annually disclose every material third-party arrangement in standardised form, the FCA will, over time, be able to map the network of dependencies across the sector. When Cloudflare fails, or when a core banking platform serving dozens of EMIs experiences an outage, the FCA will be able to see (from its own dataset) exactly which firms are exposed, how critical the affected service is to their operations, and how many consumers are downstream of the disruption. That is qualitatively different from what any individual firm’s incident report could tell them.
This connects directly to the Critical Third Parties regime introduced under the Financial Services and Markets Act 2023. That legislation empowers regulators to designate third parties whose failure could threaten UK financial stability and to impose direct obligations on them. But designation requires identification first. The annual third-party register is the mechanism through which the FCA will assemble the evidence base needed to exercise those powers. PS26/2 and the CTP regime are sequential steps in the same strategy, not merely parallel initiatives.
The FCA has been explicit about this intention. The data will be used to ‘see through firms’ supply chains to identify which services are the most exposed and help identify potential critical third parties to the UK financial system. That framing should concentrate minds. Every material third-party arrangement a firm discloses becomes part of the regulator’s map of systemic risk- and the firms that populate that map most prominently are those whose third-party dependencies are deepest.
Practical Impact on Firms
For AEMIs and APIs, PS26/2 lands on top of an already-demanding operational resilience framework. The existing obligation under PSRs 2017 to report major operational or security incidents to the FCA does not disappear- it is subsumed into the new regime for most purposes, with the new rules replacing duplicative requirements from 18 March 2027. The FCA has specifically removed duplicative incident reporting for payment service providers, which is a genuine simplification. But simplification of the reporting form does not translate to simplification of the compliance challenge.
The harder problem for most PIs and EMIs is classification. The reasonable belief standard gives firms flexibility, but it also places the entire burden of threshold assessment on the firm in real time, under operational pressure, without the benefit of hindsight. A firm experiencing a payment processing outage at 2 am must simultaneously manage the incident, communicate with affected customers, and make a defensible legal assessment of whether the disruption crosses the consumer harm threshold, not in abstract terms, but against its own customer base characteristics. Firms that have not pre-built this classification logic into their incident management procedures will find themselves improvising. That improvisation is where regulatory risk concentrates.
Firms Heavily Reliant on Outsourcing and Cloud
The third-party reporting obligations hit hardest at firms whose business models are built on aggregated third-party services: EMI with card issuing through a BIN sponsor/processor, the e-commerce payments firm routing through a single acquirer, the institution whose entire tech stack sits on one hyperscaler. For these firms, identifying which arrangements are material is not a desk exercise; it requires a genuine dependency mapping exercise that most will not have conducted with the rigour PS26/2 now demands.
The definition of materiality links to the disruption-or-failure test: would the arrangement’s failure cause intolerable harm to clients, threaten the firm’s ability to satisfy regulatory thresholds, or pose systemic risk? A firm that has mapped its important business services under SYSC 15A already has a foundation for this exercise, but the third-party register requires going further, identifying the specific external providers that underpin each service and assessing their materiality individually. The exclusion of purely intra-group arrangements (where there is no external dependency in the chain) offers some relief for vertically integrated groups, but most payment firms rely on a combination of intra-group and external providers that will require careful disaggregation.
Annual submission of the register through RegData, with 90 calendar days from the opening of the submission window at the end of the implementation period, creates a recurring compliance deadline with a fixed data architecture requirement. Firms that do not maintain their registers as living documents (updated on notification of each new or significantly changed arrangement) will face a scramble to reconstruct their supply chain picture annually. That is a governance failure waiting to happen.
Third-Party Risk: The Real Target
It would be a mistake to treat the incident reporting and third-party reporting components of PS26/2 as equal in regulatory priority. They are not. Incident reporting is the FCA’s diagnostic tool; third-party reporting is its systemic risk management infrastructure. The clue is in the scope: incident reporting applies to virtually all FCA-regulated firms and PSPs, while third-party reporting is reserved for a specific and more significant subset- the firms whose supply chain dependencies are large enough to matter at a sector level.
The concentration of technology provision in financial services is not a hypothetical concern. A small number of cloud providers, core banking platforms, compliance solutions, and payment processing vendors serve the overwhelming majority of UK-regulated payment institutions. When one of these providers experiences an outage, the incident is not isolated; it propagates simultaneously across dozens or hundreds of firms, each of which currently reports to the FCA independently and in different formats. PS26/2 is designed to collapse that fragmentation. With standardised reports flowing through a single portal, the FCA will be able to identify, in near real time, that a wave of incident reports all trace to the same upstream provider. That is the early warning signal that the regulator currently cannot generate reliably.
The notification obligation for new or significantly changed material arrangements adds a forward-looking dimension. Rather than waiting for a provider failure to reveal a dependency, the FCA will know in advance when a firm has taken on a new material relationship, and can assess whether that relationship creates concentration risk at a sector level. Combined with the CTP designation power, this gives regulators tools to intervene in the structure of firms’ supply chains and not just respond to their failures.
The Twelve-Month Window and What Firms Should Start Doing
Twelve months sounds generous. It is not. The preparation required for full compliance with PS26/2 is structural, not procedural. It involves updating incident management frameworks, building classification logic into operational runbooks, mapping third-party dependencies against the materiality definition, constructing register entries for each material arrangement, establishing governance processes for ongoing register maintenance, and integrating reporting requirements with the FCA’s Connect and RegData platforms. None of these tasks is quick, and several require external input: legal advice on definitional questions, technology investment for register management, engagement with third-party providers to extract the data the register templates require.
Firms should begin immediately with two parallel workstreams. The first is a dependency audit: a systematic review of all third-party arrangements against the materiality test. This is the foundational exercise from which all other obligations flow. Without knowing which arrangements are material, a firm cannot build its notification process, cannot construct its register, and cannot assess its exposure to third-party incident risk. The second workstream is incident management framework review: stress-testing current procedures against the new threshold definitions, identifying classification gaps, and building escalation logic that integrates reporting timelines into incident response protocols.
Where Firms Will Struggle
Three areas will generate the most difficulty in practice. The first is a threshold interpretation for the consumer harm test. The outcomes-based framing (intolerable levels of harm from which consumers cannot easily recover) is deliberately flexible, but that flexibility is a double-edged instrument.
Firms with diverse customer bases, including both retail and business clients with very different recovery capabilities, will need segmented assessment frameworks. FG26/3 provides examples and guidance, but the guidance stops short of quantitative metrics; it explicitly preserves firm judgment, which means firms carry the interpretive risk.
The second challenge is data standardisation for third-party registers. The FCA’s register template requires specific information about each material arrangement: provider identity, services covered, contractual terms, concentration metrics. Much of this information is held in disparate systems: legal databases, procurement records, operational runbooks, IT asset registers. Assembling it into a single standardised format, and keeping it current, requires data architecture investment that most payment institutions have not made. Firms whose vendor management processes are informal will need to build something more robust before the annual submission window opens.
The third challenge is obtaining information from third parties themselves. Both FG26/3 and the Bank of England’s parallel statement acknowledge this explicitly: firms are expected to engage with their providers before the regime comes into force to establish the data-sharing arrangements needed to populate incident reports and register entries accurately. Providers (particularly large technology platforms) are not always forthcoming with the operational details that regulators expect their clients to maintain. Firms should not wait for March 2027 to discover that a key provider will not share the data the register template demands.
Where Guidance Helps and Where It Does Not
FG26/3 and FG26/4 provide clearer practical support than many industry stakeholders expected. The inclusion of worked examples for incident classification, practical guidance on applying thresholds to specific scenarios, and explicit direction on completing notification templates represents a genuine improvement over the existing major incident reporting framework under PSRs 2017, which relied heavily on EBA guidelines that were neither straightforward to apply nor aligned to FCA supervisory expectations and as well even by EU standards quite outdated, as the EBA has updated their own version back in 2021 whilst the FCA still relied to that of 2017.
Where the guidance falls short is on the boundary cases: the incident that is clearly significant but arguably sub-threshold; the third-party arrangement that serves multiple business services with different levels of criticality; the intra-group structure with an embedded external dependency that may or may not require notification.
The FCA’s answer to these cases is consistent (firms must use judgment, apply the reasonable belief standard, and can engage supervisors where uncertain), but judgment-based compliance in a rules-based supervisory environment is inherently uncertain territory. Firms that are close to thresholds should document their reasoning carefully, because that documentation will be the first thing a supervisor requests when an incident occurs that was not reported.
What Firms Should Prioritise Now
PS26/2 is not a routine compliance update. It is a structural change to the regulatory relationship between payment institutions and their supervisors, one that extends FCA visibility into firms’ operational dependencies in a way that no previous regime has attempted at this scale. The twelve-month implementation period is sufficient for firms that start now; it is almost certainly insufficient for firms that treat the 18 March 2027 deadline as the point at which preparation begins.
The immediate priorities are clear. Firms should complete their dependency audit before mid-2026, while there is still time to resolve definitional questions through FCA engagement and to negotiate data-sharing arrangements with providers before the submission window opens. Incident management frameworks should be tested against the new threshold definitions and classification logic embedded in operational runbooks before year’s end. And governance structures for ongoing register maintenance should be established as formal processes- not assigned informally to an already-stretched compliance function.
The strategic takeaway is this: the FCA is building the infrastructure for sector-wide operational surveillance. Firms that understand that ambition (and position themselves as providers of high-quality, accurate data rather than reluctant compilers of minimum required disclosures) will find that PS26/2 creates something more valuable than compliance: it creates credibility with a regulator that is increasingly data-driven in how it assesses firm risk. In a sector where the next supervisory review may be triggered by what the regulator sees in the data before it ever contacts the firm, that credibility is worth investing in.
How PSP Lab Can Help
PS26/2 compliance is not a project that benefits from a standing start in late 2026. The dependency audit, the incident framework rebuild, the third-party register architecture, the provider engagement — each of these workstreams takes longer than it looks on paper, and the interactions between them create sequencing dependencies that compress the available time further. Firms that engage specialist support now will have completed the foundational work before the FCA begins its implementation engagement programme; firms that delay will find themselves conducting a gap analysis under the same regulatory scrutiny they were trying to prepare for.
If you are unsure where your firm stands under the new regime, or want an independent view on whether your current preparations are sufficient, reach out to us today. We are here to help you get this right, not just get it done.
