EBA Draft RTS on Operational Risk Management Framework: What Article 323 CRR Now Requires of Institutions

The EBA draft RTS on operational risk management framework, published on 26 August 2026 as EBA/CP/2026/18, closes a gap that CRR3 left open: the standardised approach told institutions how to calculate own funds requirements for operational risk, but said little at Level 2 about what sound management of that risk actually has to look like. The draft standard answers that question under the mandate in Article 323(2) CRR.

The draft results in a conversion. Practices that have circulated for years as supervisory expectation — largely drawn from the Basel Committee's Principles for the Sound Management of Operational Risk and the EBA Guidelines on internal governance — become binding minimum requirements under the draft.

For German institutions much of the substance will read as familiar from MaRisk, and like MaRisk the draft is explicitly principle-based. What changes is the legal form. An RTS is adopted as a Commission Delegated Regulation and applies directly in every Member State, without national transposition.

How much work that conversion creates depends heavily on a single figure, namely whether the institution's business indicator reaches EUR 750 million. Above that line, the draft demands an extended data set, quarterly reporting to the supervisory function, annual effectiveness reviews and taxonomy consistency with the technical standards on operational risk losses developed under Article 317(9) CRR. Below it, several of those obligations are relaxed.This article works through the draft in that order:

• Governance — the split of responsibilities between the management body in its supervisory and management functions, senior management, and the independent second-line function, plus the documentation standard that has to make all of it reviewable.
• The management process — the requirement that operational risk management leave visible traces in product approval, change management, third-party decisions and remediation planning, rather than sitting beside them.
• The assessment system — forward-looking identification and assessment, the divergence between the extended and reduced data sets at the EUR 750 million business indicator threshold, and the assurance layer of internal validation, audit and data governance.

Governance under the EBA draft RTS on operational risk management framework: who approves, who implements, who monitors

The draft allocates responsibility more precisely than most institutions currently document, and the sharpest edge is the split between the two functions of the management body.

Under Article 4(3), the management body approves the framework, defines and approves the operational risk appetite at least annually, and monitors on a continuous basis that the operational risk profile stays within that appetite. Article 4(5) then assigns implementation of the approved framework to the management body in its management function, with senior management empowered to put the underlying policies, processes, procedures and systems in place. Article 4(6) goes a step further: senior management has to translate the appetite into quantitative limits, monitor exposures against them, and operate escalation procedures for breaches.

Two points deserve attention here.

1. First, the annual appetite refresh carries no proportionality relief. The effectiveness review of the framework is annual above the EUR 750 million business indicator threshold and every two years below it (Article 4(4)), but the appetite itself has to be approved annually by every institution.
2. Second, the requirement to translate appetite into quantitative limits is a real change of practice for smaller institutions. Article 4(7) does offer relief: institutions below the threshold may use the business indicator, or its relevant components, as the only proxy for the appetite and for allocating it across the organisation. But the same paragraph gives the competent authority an explicit override where the business model or risk profile would be misrepresented by that proxy. A business-indicator-only appetite is therefore a defensible starting position, not a settled one, and institutions should expect to justify it in dialogue with the supervisor.

The independent operational risk management function sits in the second line under Article 10, with five minimum tasks: designing and overseeing the management process and the assessment system, contributing to the risk profile monitoring and reporting, challenging the operational risk in new or materially changed products, markets, processes and systems, overseeing activities that could breach the risk appetite, and promoting risk culture including through training and setting targets.

Independence is defined negatively and usefully: the function must not be responsible for day-to-day management, operation or the performance of controls of what it oversees, must be free of conflicts of interest, and under Article 10(3) must not be responsible for the audit function. The head of the operational risk management function shall maintain regular and direct communication with the management body.

Where certain types of operational risk are overseen by other functions, for example ICT risk by an ICT risk function, compliance and conduct risk by compliance, third-party risk by a vendor management unit, the operational risk management function has to ensure and be able to evidence that it retains an independent, comprehensive, institution-wide view. In many institutions the OpRisk function today receives filtered summaries from those units. Evidencing an independent view means access rights, an aggregation path and a documented challenge process.

Article 5 sets the documentation standard that makes the governance layer auditable. The documentation has to identify governance structures including committee mandates and membership, describe roles across the three lines, set out the appetite and approved mitigation strategies, and describe the operational risk treatment strategy including the tested effectiveness of controls. Article 5(4) requires that the documentation must be detailed enough for independent review by internal or external parties, including competent authorities.

CRR3 operational risk requirements push the management process into day-to-day decisions

Operational risk management may no longer be run as a parallel compliance exercise. Recital 12 says so, and Articles 6 and 8 turn it into obligations.

Article 6 requires an ongoing process with named ownership: institutions have to clearly identify the staff responsible for each component. Article 6(3) then requires that the information produced by that process is communicated to those responsible for managing operational risk including the first line, and to those responsible for the activities that give rise to the risk. This is one of the points the EBA has flagged for comment, because scope, recipients and frequency are left open. Institutions that currently route OpRisk reporting upward to committees but not laterally back into the business units that generated the events will need to build that return path.

Article 6(5) requires control activities across the full causal chain, that is, preventive measures addressing sources of risk, detective measures addressing the occurrence of events, and corrective measures addressing adverse effects on objectives. The three-part structure matters because it forces a control inventory to be mapped against sources, events and effects separately. Control catalogues built around event types alone will not map cleanly.

Article 8 consists of eight sub-points; three of them are the ones institutions most often fail:

• Article 8(2)(d) requires a predetermined set of protocols for identification, analysis, end-to-end management and reporting of operational risk events. End-to-end means from detection through root cause analysis to remediation closure, with the handoffs defined in advance.
• Article 8(2)(f) requires that the nature, quality and balance of inputs into the assessment system reflect the business model, strategy, organisation and risk profile at all times. A scenario set or self-assessment taxonomy that has not moved while the business has entered new products or markets fails this test.
• Article 8(2)(h) requires systematic use of assessment outputs in decision-making, and names action plans, business and insurance plans, and change management. The insurance reference is easy to skip and hard to demonstrate. If scenario analysis and loss data do not visibly inform the insurance programme, that is a documented gap.

The operational risk assessment system and the EUR 750 million business indicator threshold

Article 7 requires an assessment system that works both bottom-up and top-down, that categorises events in a structured way — sources of risk, the event itself, the resulting impact on objectives, then drivers and root causes — and that feeds the internal capital adequacy assessment. It also requires the calculation of the business indicator component for all institutions, and of the annual operational risk loss for those at or above EUR 750 million.

Article 7(3) names the assessment procedures to be applied "where relevant": business process mapping to locate key steps and areas of control weakness, risk and control assessments, and scenario analysis and stress testing.

Article 7(4) then fixes three purposes for scenario analysis and stress testing, which means the exercise has to produce output usable for all three: the internal capital adequacy assessment for operational risk, decisions on appetite level and limit allocation, and the assessment of exposures, threats and vulnerabilities under severe but plausible conditions, with results fed into the operational resilience approach. A scenario programme designed only for ICAAP purposes will not satisfy the second and third.

Where the two data sets diverge — and where they do not

The proportionality logic runs as follows:

The most challenging part of the draft from an operational standpoint concerns operational risk data, information and taxonomy (Article 9).

The extended set under Article 9(2) runs to nine categories: relevant sub-EUR 20,000 losses, incidents and near misses with no loss impact plus boundary cases, minimum information fields supporting root cause analysis and linkage to business processes, external loss data where appropriate, scenario and stress testing results, self-assessment (RCSA) outputs, key risk indicators and key control indicators, financial and non-financial information, and the input and output data behind the business indicator and its component, including how losses, expenses, provisions and financial impacts are allocated to P&L items.

For smaller institutions scenario and stress testing results, RCSA outputs, and key risk and control indicators are not part of the mandated data set below the threshold.

That exclusion is narrower than it looks. Article 7(3) still requires risk and control assessments and scenario analysis "where relevant", proportionate to the operational risk profile. What Article 9(3) relieves is the obligation to carry the outputs of those tools in the structured data set, not the obligation to run the tools where the profile warrants them. A smaller institution can therefore reasonably operate a lighter RCSA and scenario process with less formal data capture, but it cannot conclude from Article 9(3) that RCSA and KRIs are optional.

Both large and smaller institutions have to define, in internal documents and procedures, the key criteria determining when sub-EUR 20,000 losses count — "relevant" for large institutions, "relevant and material" for smaller ones.

Article 9(1)(b) requires monitoring of internal and external factors including the threat landscape and third-party arrangements, which pulls threat intelligence and vendor concentration into the OpRisk data perimeter rather than leaving them with security and procurement.

The assurance layer: internal validation, audit and operational risk data governance

Articles 12 to 15 build the assurance layer, and two provisions extend beyond what an OpRisk function would normally scope.

Internal validation has to cover the assessment system and the processes for calculating the business indicator component and the annual operational risk loss process above the size threshold.

Article 12(2)(b) brings models used for decision-making purposes into periodic internal validation, naming product pricing, artificial intelligence applications, the evaluation of financial instruments and client profiling, and covering the soundness of models used to identify and mitigate model risk other than regulatory models. This is a concrete validation obligation arriving through the operational risk standard that should be reconciled with whatever model inventory and validation policy already exists.

Article 12(2)(c) and Article 15(3) require reconciliation between accounting data on operational risk losses and the operational risk loss data set. Article 13(2) then puts the quality, accuracy and completeness of the data used for operational risk management and assessment, including the business indicator component, into the audit function's scope. Taken together these create a direct line from data quality to own funds: an error in the allocation of losses, provisions or expenses to P&L items flows through the business indicator into the Pillar 1 requirement.

Article 15 rounds this out by requiring the end-to-end flow from capture through classification, aggregation, analysis, reporting and retention, assigned data ownership, minimum data quality controls such as audit trails, documented data definitions, and the ability of users to understand the origin, meaning and limitations of the underlying data. Institutions within scope of BCBS 239 are pointed to those principles for their operational risk data and reporting arrangements.

Specific questions the draft raises

Do banks have to record operational risk losses below EUR 20,000?

Yes, in both large and smaller institutions, but the trigger differs. Institutions at or above EUR 750 million must identify and assess the relevance of sub-EUR 20,000 losses and record, store and manage them where relevant (Article 9(2)(a)). Institutions below the threshold must assess relevance and materiality and record accordingly, and in any case record losses above EUR 20,000 consistently with Articles 317 and 318 CRR (Article 9(3)(a)). Individually immaterial losses may in aggregate reveal recurring deficiencies or emerging risks, and losses forming part of a pattern or highlighting known weaknesses are to be treated as relevant.

What is the difference between relevant and material operational risk losses?

The draft does not define either term, which is the most consequential open point in the consultation. The structure implies that relevance concerns informational value for risk management while materiality concerns size relative to the institution. The additional materiality filter for smaller institutions is described in Recital 14 as keeping the effort proportionate. Questions 8 and 9 of the consultation ask directly whether both concepts should be developed further.

Must the internal taxonomy be consistent with Article 317(9) CRR?

Above the size threshold, yes. Article 9(7) requires that the taxonomy used to identify and classify operational risk events for risk management and supervisory purposes be consistent with the applicable technical standards on operational risk loss data classification developed under Article 317(9) CRR; smaller institutions below the size threshold are recommended to do the same. Practically this means a documented mapping between the internal taxonomy and the regulatory categories, which preserves internal granularity while making supervisory aggregation possible.

Can banks rely on existing DORA policies to meet the operational risk RTS?

Partly, and the mechanism is Article 2. ICT risk management under DORA and Directive (EU) 2022/2556 is required to form an integral part of the overall risk management framework. Reliance on strategies, policies, procedures, ICT protocols, tools and controls established under DORA is permitted to fulfil the requirements of this Regulation where those arrangements are already specified in detail there. Recital 5 adds that ICT-related incidents falling within the scope of operational risk are to be identified and treated as operational risk events, drawing on information already produced under DORA incident management and reporting.

The reliance is conditional, not automatic: the DORA arrangement has to satisfy the requirement in this draft. The practical exercise is a mapping of DORA artefacts against the articles here, showing which requirement each artefact discharges and where a gap remains. Question 1 of the consultation asks specifically whether further clarification is needed to avoid duplication, which suggests the EBA expects the boundary to be contested.

How are boundary cases with other risk types treated?

Question 11 sets out the EBA's interpretation. Boundary cases under Article 9(2)(b) are those where the institution already calculates Pillar 1 capital for the other risk type: credit risk, counterparty risk and CVA risk, market risk losses being already inside the operational risk perimeter via Article 317(6) CRR. Boundary cases involving Pillar 2 risks — strategic, business, liquidity risk — are to be treated always as operational risk, so the losses feed the operational risk regulatory capital through the business indicator and, above EUR 750 million, into the annual operational risk loss.

At which level of consolidation is the threshold measured?

The draft does not say. Article 1 applies the Regulation on an individual and, where applicable, on a consolidated and sub-consolidated basis under Part One, Title II CRR, while the business indicator is defined by reference to Article 314 CRR. For a group above EUR 750 million on a consolidated basis with individual entities below it, the answer determines whether those subsidiaries owe the extended data set.

What to do before the consultation closes on 31 December 2026

This is a draft standard under consultation, not an adopted delegated regulation.

Run a gap assessment against the three components, scoped by threshold. The first question is where the institution sits relative to EUR 750 million and at which levels of application. From there, the gaps that recur most often are: sub-EUR 20,000 relevance and materiality criteria; evidence of an independent institution-wide view where ICT, compliance and third-party risk are overseen elsewhere; the loss-data-to-accounting reconciliation trail; ownership of the business indicator input data; the lateral communication path back to the first line under Article 6(3); and validation coverage for pricing, AI and client profiling models under Article 12(2)(b).

Respond where the text is genuinely open. The consultation questions signal where the EBA expects to move. Relevance and materiality (Questions 8 and 9) affect data architecture directly and the EBA is asking for evidence of internal thresholds. DORA duplication (Question 1) affects how much existing work counts. The positioning of the operational risk management function against risk management and compliance in the second line (Question 12) affects target operating models. Question 16 asks whether the EUR 750 million business indicator threshold is the right cut at all, having been chosen over the SNCI classification because the business indicator is already used as a riskiness measure in the operational risk framework while the SNCI concept is not.

Frequently asked questions

What is the legal basis for the EBA draft RTS on operational risk management framework?

Article 323(2) CRR mandates the EBA to develop regulatory technical standards specifying the obligations in Article 323(1), points (a) to (h), taking into consideration the size and complexity of the institution. Article 323(1) was introduced by Regulation (EU) 2024/1623. The draft was published as EBA/CP/2026/18 on 26 August 2026 and will be submitted to the European Commission for adoption after the consultation.

Which institutions fall within scope?

All institutions subject to the CRR, on an individual and, where applicable, consolidated and sub-consolidated basis under Part One, Title II CRR. There is no exemption for small or non-complex institutions: every institution must have an operational risk management framework.

Does the removal of the AMA under CRR3 reduce operational risk management requirements?

No, and the draft is explicit about the opposite. Recital 2 states that the revision of the prudential framework does not lessen the need for sound internal arrangements. Recital 4 goes further and cites supervisory experience with advanced operational risk management practices as a benchmark for the new requirements. In effect, disciplines developed under the AMA, that is, governance, loss data collection, scenario-based assessment, independent challenge, validation and audit, are being generalised to all institutions, rather than retired with the internal models.

What does the EBA draft RTS on operational risk management require?

It specifies the arrangements demanded by Article 323 CRR: governance, documentation, the management process, the assessment system, data and taxonomy, an independent operational risk management function, reporting, compliance routines and internal validation, audit reviews, and operational risk data flows and data governance.

What is the difference between the operational risk profile and the operational risk appetite?

Article 3 defines the profile as the representation, at a given point in time, of the institution's aggregated operational risk exposure, both current and forward-looking. The appetite is the aggregate level and types of exposure the institution is willing to assume within its risk capacity, in line with its business model, to achieve its strategic objectives. The profile is a measurement; the appetite is a decision. The management body approves the appetite at least annually and monitors continuously that the profile stays inside it.

Are key risk indicators and RCSA mandatory below the EUR 750 million threshold?

Their outputs are not part of the mandated data set for smaller institutions: Article 9(3)(b) omits the points of the list that cover scenario and stress testing results, RCSA outputs, and key risk and control indicators. Article 7(3), however, still requires risk and control assessments and scenario analysis where relevant to the operational risk profile. The relief concerns structured data capture, not the underlying assessment activity.

Can compliance and the operational risk management function be combined?

The draft allows for both arrangements. Recital 15 addresses the case where the two do not coincide within the same organisational unit and requires them to cooperate and exchange information, particularly on legal risk, with responsibilities, reporting lines and escalation procedures clearly documented. Where they do coincide, the independence requirements of Article 10 still apply in full, and Article 10(3) prohibits the operational risk management function from being responsible for the audit function in either arrangement. Question 12 invites views on how the function should be positioned within the second line.

When is the deadline to respond to the consultation?

Comments must be submitted through the EBA consultation page by 31 December 2026.