EBA Draft Operational Risk Framework: Actions for AI and Automation

The EBA’s new consultation on operational risk is more than an issue for banks’ risk functions. It directly affects how customer-facing automation, AI assistants and digital workflows are designed, approved, monitored and improved. Buyers and operators should therefore look beyond model performance and integration. They need clear accountability, usable event data and controls whose effectiveness can be demonstrated.

The regulatory status matters. On 26 August 2026, the European Banking Authority (EBA) opened a consultation on draft Regulatory Technical Standards (RTS) under Article 323 of CRR3. The draft is not final law. Responses are due by 31 December 2026; after considering feedback, the EBA intends to finalise the draft RTS and submit them to the European Commission for adoption. EBA consultation announcement EBA consultation page

Three components, not an isolated control checklist

The draft organises the framework around three components: governance arrangements, the ongoing operational risk management process and the operational risk assessment system. It also addresses risk data and taxonomy, reporting, internal validation, audit and data governance. Proportionality is explicit, with aspects of scope and frequency varying according to an institution’s size and complexity. EBA consultation announcement

For customer-facing automation, these components form a connected control loop. Governance sets risk appetite, responsibilities and escalation routes. The management process continuously identifies, monitors, controls, mitigates and reports risk. The assessment system connects process mapping, risk and control assessments and, where relevant, scenario analysis and stress testing. Outputs are intended to feed decisions, remediation and change. EBA consultation paper, Articles 4–8

This matters in procurement because evidence cannot stop at a product demonstration. A bank needs a defensible mapping between the customer process, an automated decision or recommendation, possible failure effects, controls, event data and accountable roles. That mapping turns a technical component into a manageable banking process.

Workflow ownership must include exceptions

For a service assistant, an automated next-best action or a digital onboarding workflow, the business owner should therefore cover more than the happy path. The remit should include abandonment, hand-off to staff, misclassification, prohibited input, missing data, provider outage and retrospective correction. This is a practical implementation recommendation, not a verbatim list in the draft.

Procurement and change management should ask for at least five artefacts: an end-to-end process map, a responsibility matrix, documented approval criteria, defined escalation paths and a history of material changes. The draft identifies process mapping as a possible assessment procedure and says outputs from the operational risk assessment system should be used systematically in change management and action plans. It also gives the second line a role in challenging material changes to products, activities, processes and systems. EBA consultation paper, Articles 7, 8 and 10

Controls for automation: prevent, detect and correct

The draft distinguishes preventive, detective and corrective control measures. Documentation should cover control design, implementation and tested effectiveness, and the framework should be reviewed and revised as appropriate on the basis of continuous assessment of the control environment. EBA consultation paper, Articles 5 and 6

In customer-facing systems, preventive controls can constrain approved data sources, actions and customer segments, with approval gates for sensitive steps. Detective controls can identify unusual abandonment, inconsistent outputs, policy breaches or suspicious manual overrides. Corrective controls can stop a flow, reroute cases, correct customer data and record remediation. The appropriate design depends on the risk and the process. The key requirement for a buyer is that control claims can be tested rather than merely described in product material.

Incidents and losses need a common language

Rich technical telemetry is not yet an operational risk data set. The draft calls for processes to collect, record, store, aggregate, analyse and monitor operational risk data that are accurate, complete, consistent and timely. It also covers incidents and near misses without loss impact, plus minimum fields for drivers, root causes, consequences and links to the relevant business process. The required depth of data is proportionate. EBA consultation paper, Article 9

For buyers, this means provider logs, CRM events, service tickets, complaint records and accounting consequences need stable identifiers that allow them to be connected. A shared taxonomy should distinguish a technical failure from a process failure, data issue, misconduct event, third-party problem and customer impact. The draft requires governance, ownership and change control for the risk taxonomy, as well as traceable data flows, data quality controls and audit trails. EBA consultation paper, Articles 9 and 15

Validation and audit provide different evidence

Internal validation and audit have distinct but complementary roles in the draft. Where models are used for decision-making, internal validation should assess, among other things, the soundness of models used for AI applications and client profiling. Results should be documented and suitable for internal decisions and supervisory review. Audit, by contrast, should assess the reliability and effectiveness of the process and assessment system, and verify policies, relevant procedures, controls and data quality. EBA consultation paper, Articles 12–14

An approval pack for customer automation should therefore answer two questions separately. First, does the solution perform reliably within its defined conditions, limits and scenarios? Second, is the wider control system—including roles, data, exceptions, controls and remediation tracking—independently reviewable? Suppliers should be able to provide reproducible tests, version evidence, data lineage, known limitations and exportable audit trails. None of this transfers the bank’s accountability to the supplier.

Use DORA coverage without reducing the wider framework to it

DORA sets detailed requirements for ICT risk management, ICT-related incident handling and reporting, resilience testing and ICT third-party risk management. The draft RTS would allow banks to rely on DORA strategies, processes, protocols, tools and controls where these also satisfy the requirements of the broader operational risk framework. ICT incidents within operational risk should also be treated as operational risk events. EBA consultation paper, Article 2 and recitals

DORA is therefore an important foundation, but not a substitute for the full view. An AI assistant may be technically available and well controlled from a cyber perspective while still creating operational risk through unsuitable guidance, unclear ownership, broken process hand-offs or incomplete loss data. Banks should reuse DORA evidence, then document the remaining business-process and organisational gaps explicitly.

What buyers can do before the consultation closes

Banks should not build a supposedly final RTS checklist before 31 December 2026. A reversible readiness sprint is more useful: map priority customer workflows, appoint an owner for each, assign control types and escalation routes, test whether event and loss data can be linked, and involve validation and audit early. Open issues can then become evidence-based consultation responses. The EBA asks respondents to identify the specific point, provide a clear rationale and evidence, and describe alternative regulatory choices. EBA consultation paper, consultation instructions

The immediate value is not premature compliance. It is better buying and operating discipline: teams can specify supplier requirements precisely, follow risk across system boundaries and release changes under control. If the draft changes, those foundations will still be useful for customer-facing automation.

Illustration: AI-generated. AI-assisted content: We use AI technologies and automated agents in the creation of our articles, including from Microsoft, Google, OpenAI, Anthropic and other providers. Topics, editorial direction and final approval remain with our team.