The EU AI Act for Banks: What 13 Years of BCBS 239 Are Really Worth in the Age of AI

By 2 December 2027, banks must be able to demonstrate that their high-risk AI systems meet the requirements of the EU AI Act: representative and validated data, comprehensive record-keeping, effective human oversight, and demonstrated robustness. While implementing these requirements is a multi-year programme for companies without established data management frameworks, many financial institutions are not starting from scratch. This article sets out requirements of the EU AI Act for banks. It will be shown where they genuinely have a head start, and where further action is required.

Banks owe this head start in particular to a regulatory framework they have known since 2013: BCBS 239 – Principles for effective risk data aggregation and risk reporting (mandatory for globally and domestically systemically important institutions). In 2024, the ECB operationalised the BCBS 239 principles in its RDARR Guide (Risk Data Aggregation and Risk Reporting) for significant institutions under its direct supervision and made them a supervisory priority (Supervisory Priorities 2025–2027 and 2026–2028).

On the one hand, institutions that have implemented BCBS 239 or RDARR properly already possess organisational and technical foundations on which compliant AI governance in banking can be built more effectively.

On the other hand, the EU AI Act introduces requirements that have no equivalent in either BCBS 239 or traditional model risk management: systematic controls for bias and fairness, explainability of model decisions, and the fundamental rights impact assessment (FRIA) required under Article 27.

This article examines the EU AI Act requirements for banks from five perspectives:

• Data quality and data governance as the foundation for permissible model inputs (Article 10)
• Data lineage as a prerequisite for traceability and documentation (Articles 12 and 13)
• Model risk management and human oversight as governance practices already embedded in banking (Articles 9 and 14)
• Robustness as more than a secondary consideration (Article 15)
• Risk reporting as actionable information for human oversight (Articles 13 and 14)

The guiding principle throughout is to use BCBS 239 as a foundation for AI governance and to leverage synergies rather than duplicate structures.

1. Data Quality and Data Governance: EU AI Act Article 10 and the Validated Model Input

Article 10 of the EU AI Act requires training, validation, and testing datasets for high-risk AI systems to be relevant, sufficiently representative and, to the extent possible, free of errors and complete. For a company starting from scratch in data management, this is a multi-year project. A bank that has implemented BCBS 239 has an advantage here.

The BCBS 239 advantage: Institutions with high-quality risk data already have a robust foundation for AI data in the risk domain. Through BCBS 239 (Principles 1–3), banks have established risk data infrastructures with automated quality controls, clearly defined responsibilities, and a documented “single source of truth”. Rather than building new data quality processes from the ground up, institutions can build their AI applications in the risk domain on these existing structures.

The limits of this advantage should be recognised rather than glossed over. Traditional data quality, that is, accuracy, completeness, and timeliness, is well covered by BCBS 239 (Principles 3–5). What the EU AI Act additionally requires is systematic examination for distortions in the data: representativeness, bias, and fairness. These requirements are not yet, or not sufficiently, covered by the existing control frameworks of most banks and therefore need to be added. The Digital Omnibus permits the processing of special categories of personal data for this purpose—but only where strictly necessary and subject to appropriate safeguards.

In practice, this means: Existing data governance under BCBS 239 provides the framework for meeting the EU AI Act Article 10 data governance requirements. The specific action required is to extend existing quality controls to include bias and fairness testing and embed these tests within the same control logic already used to monitor data quality.

2. Data Lineage as a Prerequisite for Traceability under the EU AI Act

The record-keeping obligations under Article 12 and the transparency requirements under Article 13 cannot be met without a complete history of data flows. An AI decision for which the origin of the underlying data cannot be reconstructed is not traceable within the meaning of the EU AI Act and therefore cannot be deployed in compliance with the Act.

The BCBS 239 advantage: Data lineage derived from the BCBS 239 requirements on data architecture and accuracy (Principles 2 and 3) documents where a data point originated, which transformations it underwent, and which output it ultimately contributed to.

Here too, there is an important limitation that puts the head start into perspective: Data lineage answers the question of which data went into a model. It does not answer why the model arrived at a particular result on that basis. Explaining model behaviour is a separate task that goes beyond the mere provenance of the data.

In practice, this means: For financial institutions, existing lineage artefacts are necessary for demonstrating compliance with Articles 12 and 13, but they are not sufficient. Additional effort is required, with the focus shifting to the more complex issue of explainability for AI models rather than merely establishing the origin of input data.

3. Model Risk Management and Human Oversight: AI Governance in Practice

The EU AI Act requires risk management throughout the entire lifecycle of a system (Article 9) and effective human oversight (Article 14). Both concepts are deeply embedded in banking. Not through BCBS 239; they stem instead from model risk management and supervisory expectations concerning internal models, including the ECB’s guide to internal models (EGIM).

Financial institutions that already operate an independent validation function, a model change policy with defined approval processes, and a model inventory, as required by supervisory expectations for internal models, can integrate AI models into these existing control cycles. This avoids establishing a parallel organisation and enables a consistent approach to risk management.

Human oversight under the EU AI Act deserves particular attention because it is becoming increasingly relevant in 2026: autonomous AI agents are increasingly preparing operational decisions, bringing the question of accountability to the forefront. The EU AI Act leaves no doubt that responsibility cannot be delegated to a system (Articles 14 and 26). Decision-making processes and escalation paths must be demonstrably documented end to end. This is familiar territory for banks: the segregation of duties, for example, between model development and independent validation, establishes responsibilities and escalation procedures in a verifiable manner. Segregation of duties therefore provides a suitable blueprint for human oversight of AI agents.

What BCBS 239 does not cover here is the fundamental rights perspective. For banks using AI to assess the creditworthiness of natural persons, Article 27 requires a fundamental rights impact assessment. This is an obligation for which there is no direct equivalent even in traditional model risk management.

In practice, this means: Existing governance structures can go a long way towards supporting AI governance, but they need to be supplemented, in particular, by an additional layer for assessing fundamental rights.

4. Robustness and Resilience of High-Risk AI Systems in Financial Services

Under Article 15, high-risk AI systems must operate accurately and robustly, including when systems are disrupted, placed under stress, or confronted with erroneous inputs. Backup plans must also be in place for failure scenarios. There is a clear parallel here: resilience was not a secondary consideration but the starting point of BCBS 239. In fact, BCBS 239 originally emerged from the experience that many banks during the financial crisis were unable to access their own risk data quickly and reliably enough.

The BCBS 239 advantage: Principle 2 requires a data architecture and IT infrastructure that explicitly support risk data aggregation even during periods of stress and crisis. In addition, the Digital Operational Resilience Act (DORA) has required operational resilience since 2025. What matters is not only having the relevant safeguards in place, but also being able to demonstrate their effectiveness. Similarly, in connection with Article 15 of the EU AI Act, an AI system must be robust, and this robustness must be demonstrable. Institutions that have implemented BCBS 239 and DORA already have an institutionalised practice for this purpose: defined stress scenarios, documented test runs, thresholds, escalation paths, and independently reviewed results. This approach can be transferred to AI.

In practice, this means: AI failure scenarios can be incorporated into existing operational resilience and contingency planning frameworks rather than being reinvented as a separate discipline. The additional effort lies in AI-specific issues such as monitoring output quality during operation and defining the accuracy metrics required under Article 15.

5. Risk Reporting: Actionable Information for Human Oversight

Effective human oversight (Article 14) and transparency (Article 13) depend on one fundamental prerequisite: the person responsible for supervising an AI system and, where necessary, overriding it can only do so in practice if they receive timely, accurate, complete, and comprehensible information about what the system is doing and how reliably it is operating. Ongoing monitoring of output quality (Article 15) likewise creates value only when its results reach the appropriate decision-makers in an actionable form. Reporting is therefore not a downstream step; it is a prerequisite for oversight and control to function at all.

The BCBS 239 advantage: BCBS 239 contains a dedicated set of principles for precisely this task, which the data-related principles alone do not cover: the principles governing risk reporting (Principles 7–11: accuracy, comprehensiveness, clarity and usefulness, frequency, and distribution). Banks have therefore institutionalised how complex risk information is translated into accurate, comprehensible, and audience-appropriate reporting. This capability can be transferred to the AI environment: monitoring results on model drift and output quality must follow the same path as a risk report—from data collection through to the decision-maker—and be sufficiently clear to enable action.

Here too, it is worth taking an honest look at a limitation that already emerged in the discussion of data lineage. The reporting principles govern how information is presented and to whom it is distributed, but not why a model arrives at a particular result.

In practice, this means: Existing reporting channels and the governance surrounding them are also relevant to AI oversight: who receives which report, at what frequency, and through which distribution channel. The specific action required is to define what information oversight functions and system operators actually need and feed the monitoring results into this established reporting logic rather than creating a second reporting stream. What still needs to be built is model-level explainability, not the reporting infrastructure.

EU AI Act for Banks: Where the Head Start Ends and What to Do Now

The strategic advantage for AI governance in banking lies in harmonising the regulatory frameworks, not in conflating them. A clear picture emerges from a simple division of responsibilities:

• BCBS 239 addresses whether data arrive complete and error-free—the logistics.
• The EU AI Act addresses whether those data are used correctly and without impermissible bias—the logic.

The two frameworks interact, but they are not the same.

The point at which the head start ends can be summarised as follows: BCBS 239 provides no controls for bias and fairness, no means of explaining model behaviour to affected individuals, and no fundamental rights impact assessment. These three areas are what genuinely has to be built from scratch, whereas implementation of the other requirements largely involves extending existing capabilities.

For senior management, this translates into three concrete steps:

1. Map the control points. Review which existing BCBS 239 artefacts—data lineage documentation, data quality controls, and governance evidence—can directly serve as evidence of compliance with the EU AI Act requirements for data governance (Article 10), record-keeping (Article 12), lifecycle risk management (Article 9), and oversight structures (Article 14). Where duplicate controls have been introduced, consolidate them.
2. Expand roles rather than create new ones. Leverage the expertise of existing data stewards and risk managers and extend established control cycles to AI development teams. Add the missing expertise specifically where needed, particularly for bias testing and fundamental rights assessments.
3. Address obligations that are already in force. Two requirements apply irrespective of the postponement of other obligations: AI literacy for the workforce (Article 4), which has been in force since February 2025, and transparency obligations (Article 50), applicable from August 2026. Both can be addressed in the short term with comparatively limited effort and are therefore natural starting points.

Conclusion: EU AI Act Compliance Builds on BCBS 239

For banks, the EU AI Act requires a consistent next step in an already established regulatory journey. Its demanding requirements for data quality, traceability, governance, and robustness apply to institutions that have been operating precisely these disciplines for more than a decade. The head start is real, but limited: it reduces the foundational work required for EU AI Act compliance, but it does not eliminate the three genuinely new tasks of bias control, explainability, and fundamental rights assessment.

EU AI Act and BCBS 239: Frequently Asked Questions (FAQ)

When do the EU AI Act requirements for banks take effect?

Under the Digital Omnibus, the obligations for high-risk AI systems under Annex III apply from 2 December 2027, while AI embedded in products will be subject to the requirements from 2 August 2028. Independently of this, the transparency obligations under Article 50 have applied since August 2026 (with the provider disclosure obligation under Article 50(2) applying only from 2 December 2026), while the AI literacy requirement under Article 4 has already applied since February 2025.

Which high-risk AI systems in financial services fall under the EU AI Act?

Annex III explicitly identifies systems used to assess the creditworthiness of natural persons and to establish credit scores. AI used exclusively for the detection of financial fraud is exempt. Internal systems that have no external effect on natural persons are generally not affected, but the classification must be assessed on a system-by-system basis.

What is RDARR and how does it relate to BCBS 239?

BCBS 239 refers to the Basel principles established in 2013 for risk data aggregation and risk reporting. RDARR (Risk Data Aggregation and Risk Reporting) represents their operational implementation: with its RDARR Guide (finalised in May 2024), the ECB specified supervisory expectations for significant institutions under its direct supervision and made RDARR a priority for 2026–2028. In terms of substance, RDARR builds on BCBS 239 but goes significantly further in its practical implications, particularly with regard to auditability, evidentiary requirements, and management responsibility.

Is an existing BCBS 239 implementation sufficient for EU AI Act compliance?

No. BCBS 239 provides the foundation for data quality, data governance, and data lineage, but it does not cover bias and fairness controls, explainability of model decisions, or the fundamental rights impact assessment required under Article 27. Put simply, BCBS 239 governs whether the right risk data arrive completely and on time, whereas the EU AI Act governs whether those data are used correctly, transparently, and without impermissible bias.

How are data lineage and EU AI Act compliance connected?

Data lineage documents the origin and processing of data and is therefore a practical prerequisite for meeting the record-keeping and transparency requirements under Articles 12 and 13. Without traceable data flows, an AI decision cannot be adequately evidenced for the purposes of the Act.

What does human oversight under the EU AI Act mean in banking practice?

Article 14 requires humans to effectively oversee AI systems and to be able to intervene. For banks, this means defined responsibilities, escalation paths, and the ability to override automated decisions. These are principles that closely resemble established model risk management practices.

What does EU AI Act Article 10 require for data governance?

Article 10 requires that the training, validation, and testing datasets used by high-risk AI systems are relevant, sufficiently representative and, to the extent possible, free of errors and complete, and that they are examined for possible biases. Banks can build on the data quality controls established under BCBS 239 for accuracy, completeness, and timeliness, but they need to extend them to include systematic bias and fairness testing.

How can BCBS 239 serve as a foundation for AI governance?

BCBS 239 has already established data ownership, automated data quality controls, a documented single source of truth, data lineage, and institutionalised risk reporting. These artefacts can be used directly as evidence for the EU AI Act requirements on data governance (Article 10), record-keeping (Article 12), lifecycle risk management (Article 9), and oversight structures (Article 14). What has to be built in addition is bias and fairness testing, explainability, and the fundamental rights impact assessment.

What is a fundamental rights impact assessment (FRIA)?

Article 27 of the EU AI Act requires deployers of certain high-risk AI systems to assess the impact on the fundamental rights of affected persons before the system is put into use. For banks, this applies in particular to AI used to assess the creditworthiness of natural persons. Neither BCBS 239 nor traditional model risk management provides a direct equivalent, which makes the FRIA one of the genuinely new obligations.