EU AI Act Compliance for Banking and Financial Services

Most of a bank's AI portfolio is not high-risk under the EU AI Act. That is the finding practitioners rarely hear — and it matters, because the sector has been told repeatedly that its AI exposure is vast. It isn't: the high-risk surface in banking is narrow, well-defined, and limited to two Annex III sub-points. Getting compliant means identifying those systems precisely, not running the full high-risk regime across every model in the inventory.

Regulation (EU) 2024/1689 — the EU AI Act — sits alongside the Digital Operational Resilience Act (DORA), MiFID II, Solvency II, GDPR Article 22, and the EBA's model risk management guidelines. None of those frameworks disappears. But the AI Act adds its own classification logic, and financial institutions that understand that logic can scope their compliance programme accurately rather than over-engineering it.

---

The narrow high-risk surface: two Annex III sub-points

Annex III of the EU AI Act lists the eight areas where AI systems are presumed high-risk. Financial services appears in area 5 — "access to essential private and public services" — with two sub-points directly relevant to banks.

Annex III point 5(b): creditworthiness and credit scoring of natural persons. AI systems used to evaluate whether a natural person receives credit, at what price, and under what conditions are high-risk. This covers retail credit-scoring models, loan underwriting AI, overdraft eligibility algorithms, and income-verification systems whose output materially influences the credit decision. The qualifier "natural persons" matters: B2B credit risk AI assessing corporate counterparties falls outside 5(b).

The explicit fraud-detection carve-out applies here. The Annex III text excludes AI systems used for fraud detection from the creditworthiness definition. A model that detects anomalous payment patterns to flag potential fraud is not high-risk on this basis, even if it operates on natural-person transaction data. The boundary is the purpose: creditworthiness evaluation versus fraud detection. Institutions should document this distinction carefully for every model in the grey zone.

Annex III point 5(c): life and health insurance risk assessment and pricing. AI used to assess individual risk and set premiums in life insurance, health insurance, and critical illness products is high-risk. Banks with bancassurance operations offering these products are in scope. The category does not extend to motor insurance or property insurance — those lines are excluded. A regional bank whose insurance arm writes motor and home policies but not life or health is not exposed under 5(c).

Everything else in the standard bank AI inventory — AML and transaction monitoring, algorithmic trading, robo-advice, customer chatbots, internal risk models for market or liquidity risk, KYC screening — is not high-risk on the basis of Annex III. Chatbots fall under Article 50 limited-risk transparency obligations: users must be told they are interacting with an AI system. AML models are a compliance function, not a law enforcement application in the Article 6(2) sense. Algorithmic trading is not an Annex III use case.

The Article 6(3) filter provides an additional escape valve. A system that falls within an Annex III area is nonetheless not high-risk if it poses no significant risk of harm — for example, it performs a narrow procedural task or improves a previously completed human activity. Any provider claiming this exemption must document the assessment and register it (Article 49).

---

Provider and deployer obligations in banking

Large financial institutions occupy both positions within the same institution — sometimes within the same team.

A bank that builds its own credit-scoring model in-house, or fine-tunes a third-party model on its own data, or substantially modifies a vendor scorecard, bears provider obligations under Articles 9–17: a risk management system (Article 9), data governance (Article 10), Annex IV technical documentation (Article 11), logging (Article 12), transparency toward deployers (Article 13), human oversight design (Article 14), and accuracy and robustness requirements (Article 15). Before the system goes into service it requires a conformity assessment under Article 43 — for Annex III categories other than biometrics, this is the internal self-assessment route (Annex VI). It must also be registered in the EU database under Article 49.

A bank that licenses a credit-scoring system from a third-party vendor is a deployer under Article 26. Deployer obligations are lighter: use the system within its intended purpose, implement the oversight protocols described in the provider's documentation, keep logs for at least six months (Article 26), and monitor performance. Where the deployer is using a creditworthiness model (Annex III 5(b)) or a life/health insurance pricing model (5(c)), Article 27 requires a Fundamental Rights Impact Assessment (FRIA) before deployment.

Article 25(1) sets the threshold for role conversion. A deployer that substantially modifies a high-risk AI system — by retraining it on proprietary data, shifting its decision thresholds materially, or deploying it for a purpose outside the provider's original intended use — becomes the provider for that system. Annual recalibration that updates model weights is very likely sufficient to trigger this. Institutions that routinely recalibrate third-party scorecards should assess each recalibration cycle against this threshold.

In practice, a major bank may be the provider for fifteen AI systems and the deployer for thirty-five. The compliance programme must address both regimes, with documentation structured differently for each.

---

The FRIA obligation for credit and insurance deployers

Article 27 does not apply to all deployers. It applies specifically to deployers that are public bodies, and to private deployers using creditworthiness (Annex III 5(b)) or life/health insurance (Annex III 5(c)) AI systems. For most financial institutions, the credit and insurance systems are precisely where the FRIA obligation lands.

The FRIA covers the system's purpose and intended use, who is affected, which fundamental rights are at risk (non-discrimination, access to financial services, data protection), what mitigation measures are in place, how human oversight is designed, and what redress mechanisms exist for individuals affected by the AI's output.

For credit systems, the non-discrimination section requires the most care. The proxies embedded in credit models — postcode, occupation category, purchase behaviour — can encode demographic disparities without directly processing protected characteristics. The FRIA must address how the institution tests for and mitigates these effects. Article 27(4) allows a FRIA to build on an existing GDPR Article 35 Data Protection Impact Assessment (DPIA) where the two assessments overlap — this is worth doing to reduce duplication.

State-owned banks, development banks (KfW, BPI France), savings banks with universal-service mandates, and financial institutions operating under public-interest schemes are clearly in scope for the FRIA. Fully commercial banks operating credit models under purely market terms should still assess their FRIA position — the Article 27 text does not limit scope to public-sector banks.

---

GDPR Article 22 and AI Act Article 14: two human-oversight requirements

GDPR Article 22 prohibits automated individual decisions with legal or similarly significant effects unless a specific lawful basis applies. For credit decisions, the lawful basis is typically Article 22(2)(a) — necessity for a contract. That basis does not remove the Article 22(3) obligation to implement "suitable measures," including the right to obtain human intervention, express a point of view, and contest the decision.

The AI Act's Article 14 human oversight requirement covers the same functional ground from a different legal angle. Article 14 requires that high-risk AI systems be designed and deployed so that natural persons can oversee them effectively, understand their outputs, and intervene or override.

The practical requirement is the same for both: a credit officer with genuine override authority, access to the information needed to form an independent view, and a documented process for recording and acting on that override. Supervisors in multiple member states have indicated that a nominal human-in-the-loop — a person who reviews the AI's output but has no practical ability to question it — does not satisfy either obligation. The documentation should address both Article 14 and Article 22(3) in a single unified human-review procedure.

---

Where DORA intersects

DORA (Regulation 2022/2554, applicable from January 2025) creates parallel ICT-risk obligations that apply directly to AI systems. DORA's ICT risk management framework (Articles 5–10) requires financial entities to identify, classify, and manage ICT risks; AI systems are ICT systems.

The most significant overlap is in third-party risk. DORA Articles 28–44 require due diligence on ICT third-party providers, with contractual provisions for audit rights, exit strategies, and incident notification. When the third party is an AI system vendor, due diligence must satisfy both DORA's third-party risk requirements and the AI Act's Article 26 deployer obligations — including verifying that the vendor has produced Article 11 technical documentation. Institutions that build unified vendor-assessment processes covering both regimes avoid the cost and inconsistency risk of parallel documentation tracks.

DORA's TLPT (threat-led penetration testing) requirements for significant ICT systems and the AI Act's Article 15 robustness and cybersecurity requirements overlap in scope for high-risk AI. The testing evidence produced for DORA can often be structured to serve both frameworks.

---

EBA model risk management and ECB supervisory expectations

The EBA's revised internal governance guidelines (EBA/GL/2021/05) require a model inventory, independent validation for material models, performance monitoring with defined thresholds, and escalation procedures for model degradation. These requirements map directly onto the AI Act's Article 9 risk management system and Article 15 accuracy requirements — but the EBA's validation depth is often more operationally prescriptive than the AI Act text alone.

Institutions that already maintain an EBA-compliant model risk management framework have most of the technical infrastructure the AI Act requires. The gap is typically in AI Act-specific areas: the Article 11 Annex IV documentation format, FRIA completion, EU database registration (Article 49), and post-market monitoring records under Article 72.

The ECB expects board-level understanding of AI systems material to an institution's risk profile. For institutions under ECB direct supervision, this means AI governance must be a board risk-committee topic, not purely a technical function. Article 14's human oversight requirements and the ECB's substantive-oversight expectation are aligned: both reject nominal compliance.

---

How Confir helps

Confir classifies each AI system in your inventory under Articles 5 and 6 using Annex III logic, via plain-English intake. For a credit-scoring model, the classification checklist works through whether the system evaluates natural persons' creditworthiness, whether the fraud-detection carve-out applies, whether the Article 6(3) narrow-task exemption is arguable, and which role the institution occupies. The output is a documented risk tier and role derivation, not an advisory opinion.

For confirmed high-risk systems, Confir runs a structured assessment across four compliance areas — risk management (Article 9), data governance and technical robustness (Articles 10, 11, 15), transparency and human oversight (Articles 13, 14, 27), and governance and post-market monitoring (Articles 9, 72, 73) — and generates the Annex IV technical documentation pack and Article 27 FRIA. The engine is rule-based and deterministic: same intake, same finding, with the rule that fired visible and audit-defensible.

Pricing from €600/year at confir.eu.

---

Compliance deadlines

The high-risk obligations under Annex III apply from 2 December 2027 for stand-alone AI systems — including credit and insurance AI — under the Digital Omnibus (political agreement reached 7 May 2026). The original August 2026 date applied to the general rollout; high-risk Annex III obligations were always slated for later, and the Omnibus extended that further. Article 50 limited-risk transparency obligations (chatbots, synthetic-content disclosure) apply from 2 August 2026.

The non-compliance fine ceiling for most obligations is €15,000,000 or 3% of total worldwide annual turnover, whichever is higher (Article 99(4)). That ceiling applies to failures in provider and deployer obligations alike. The 2 December 2027 date is breathing room, not a reprieve: Annex IV documentation alone takes months to assemble, and FRIA completion requires data that may not be readily accessible.

---

Frequently Asked Questions

Does the EU AI Act apply to all AI systems a bank uses?

No. Classification drives obligations. Most bank AI — AML transaction monitoring, algorithmic trading, robo-advice, customer chatbots, internal risk models — is minimal-risk or limited-risk under the Act. The high-risk categories in banking are narrow: AI that evaluates the creditworthiness of natural persons (Annex III point 5(b), with the fraud-detection carve-out) and AI used for life or health insurance risk assessment and pricing (5(c)). Everything else is outside the high-risk regime on that basis, though it may have limited-risk transparency obligations under Article 50.

Is AML transaction monitoring high-risk under the EU AI Act?

Generally no. AML transaction monitoring is a compliance function: it generates alerts that analysts review, not law enforcement decisions. Annex III point 6 (law enforcement AI) applies where a system is used to make risk assessments for law enforcement purposes — not to internal SAR-generation processes. The fraud-detection carve-out in Annex III point 5(b) also makes explicit that fraud models are not high-risk creditworthiness systems. Institutions should document their AML system's purpose to support this position.

Does the fraud-detection carve-out apply to all fraud models?

The carve-out in Annex III point 5(b) excludes from the creditworthiness definition AI systems used for fraud detection. It applies where fraud detection is the genuine purpose — anomaly detection, transaction-pattern analysis, account-takeover prevention. It does not apply to a model that evaluates creditworthiness and also produces a fraud score as a secondary output. The determining factor is the system's primary intended purpose, which must be documented.

If a bank recalibrates a third-party credit scorecard annually, is it the AI Act provider?

Likely yes. Article 25(1) converts a deployer into a provider when it substantially modifies a high-risk AI system. Annual recalibration that updates model weights or materially shifts decision thresholds is likely sufficient to trigger this. The practical consequence is that the bank inherits the provider obligation stack — Articles 9–15, Annex IV documentation, conformity assessment, Article 49 registration — rather than the lighter deployer obligations under Article 26. Each recalibration cycle should be assessed against the Article 3(23) substantial modification definition.

When does the FRIA apply to a bank deploying a vendor credit model?

Article 27 requires a Fundamental Rights Impact Assessment before deploying a high-risk AI system for creditworthiness (Annex III 5(b)) or life/health insurance (5(c)) purposes. The obligation applies to the deployer — meaning the bank using the vendor's model. The FRIA must address non-discrimination risk, access to financial services impacts, oversight design, and individual redress. It can build on an existing GDPR Article 35 DPIA where the two overlap (Article 27(4)). The FRIA is completed before deployment, not as a post-market activity.

What is the penalty for non-compliance in banking AI?

The standard ceiling under Article 99(4) is €15,000,000 or 3% of total worldwide annual turnover, whichever is higher. This applies to failures in provider obligations (Articles 9–17), deployer obligations (Article 26), and the FRIA requirement (Article 27). For smaller institutions, Article 99(6) caps fines at the lower of the percentage or the fixed amount — a proportionality protection. These figures apply from 2 August 2025 (when the penalty provisions entered force), though high-risk obligations themselves apply from 2 December 2027.

How does the AI Act relate to GDPR Article 22 for credit decisions?

The two instruments operate in parallel and must both be satisfied. GDPR Article 22 restricts automated individual decisions with legal or significant effects, requiring a lawful basis and — where Article 22(2)(a) applies — suitable measures including human intervention rights. The AI Act's Article 14 human oversight requirement covers the same functional ground: a natural person must be able to understand, oversee, and override the AI's output. In practice, the bank should document a unified human-review procedure that satisfies both Article 14 and Article 22(3) simultaneously, specifying override authority, information access, logging of overrides, and the individual's right to contest.

---

Related guides

• DORA compliance for fintech AI systems
• Annex III high-risk insurance AI
• healthcare AI operational resilience requirements
• Annex III public sector AI obligations
• machinery regulation and high-risk AI
• legal tech DORA and AI Act alignment