EU AI Act in the Financial Sector: Banks, Insurers, and Credit Institutions

Banks, insurers, asset managers, and payment institutions face EU AI Act obligations layered on top of existing financial regulation (DORA, MiFID II, GDPR, CRR). This page explains which AI use cases are high-risk, how sector regulators interact with the AI Act, and what financial institutions must do to comply.

The AI Act Comes to Finance

Financial institutions — banks, insurers, asset managers, payment providers, credit bureaux — are among the most intensive users of AI in Europe. Credit scoring, fraud detection, algorithmic trading, customer risk profiling, insurance underwriting, regulatory reporting automation, and AML/KYC screening all rely on AI systems that may be subject to the EU AI Act.

For financial institutions, the EU AI Act does not arrive in isolation. It layers on top of an already dense regulatory stack: DORA (digital resilience), MiFID II (investment services), GDPR (data protection), CRR/CRD (capital requirements), Solvency II (insurance), PSD2/PSD3 (payment services), and sectoral EBA, EIOPA, and ESMA guidelines. Understanding how the AI Act integrates with — and sometimes conflicts with — existing financial regulation is essential for efficient compliance.

Which AI Use Cases Are High-Risk in Finance?

The EU AI Act's Annex III identifies use cases that are automatically high-risk. In the financial sector, the most directly relevant are:

Category 5(b): Creditworthiness Assessment

High-risk. AI systems used to evaluate the creditworthiness of natural persons or to classify natural persons in terms of credit risk are explicitly listed. This covers:

• Automated credit scoring for consumer loans, personal overdrafts, credit cards, and mortgages
• Models that assess repayment probability, default risk, or debt capacity of individual consumers
• AI systems that recommend credit limits or loan amounts based on individual risk assessment

Not automatically covered: Corporate credit models assessing legal entities rather than natural persons, though these may still trigger Art. 50 transparency obligations depending on deployment.

Category 5(b): Insurance Premium and Coverage Decisions

High-risk if affecting natural persons significantly. AI systems that make or strongly influence decisions about:

• Insurance coverage (acceptance or rejection of applicants)
• Premium levels (actuarial models that set individual premiums)
• Claim assessment and settlement (automated claim handling)

Motor insurance pricing models, health insurance underwriting, and property insurance models for households are directly in scope. The determining factor is whether the AI system makes or significantly influences a decision that materially affects a natural person's access to an essential private service.

Category 1: Biometric Identification

High-risk. AI systems used for:

• Remote biometric identification of customers (KYC video verification, continuous authentication)
• Biometric categorisation where it influences risk classification or service access

Real-time biometric identification in publicly accessible spaces for law enforcement is prohibited under Art. 5. Commercial identity verification systems using facial recognition for KYC are subject to high-risk requirements but not prohibited.

Category 6: AML/KYC and Law Enforcement Adjacent

AI systems used by financial institutions to support AML/KYC screening, sanctions filtering, or transaction monitoring where the outcome is reported to or used by law enforcement may fall within Annex III category 6 (law enforcement). This includes:

• AI-generated Suspicious Activity Reports (SARs) transmitted to FIUs
• Automated PEP (Politically Exposed Person) screening systems

Systems used purely for internal risk management without law enforcement output are less likely to be classified as high-risk under category 6, though other categories may apply.

What High-Risk AI Obligations Mean for Financial Institutions

If an AI system used by a financial institution is high-risk under Annex III, the obligations differ depending on whether the institution is a provider (built the system) or deployer (purchased or licensed it).

If You Are the Provider (Built the System)

• Risk management system (Art. 9): Establish and maintain a documented risk management process iterating throughout the system lifecycle
• Data governance (Art. 10): Training, validation, and testing data must be subject to governance practices covering relevance, representativeness, and bias assessment
• Technical documentation (Annex IV): Full technical file including system description, architecture, training approach, performance metrics, and post-market monitoring plan
• Transparency (Art. 13): Instructions for use enabling deployers to understand capabilities, limitations, and oversight requirements
• Human oversight (Art. 14): Design measures enabling human oversight and intervention
• Accuracy, robustness, cybersecurity (Art. 15): Demonstrated performance levels and resilience
• Conformity assessment: Self-assessment (Annex VI) for most Annex III systems, or notified body assessment for biometric systems
• CE marking and EU declaration of conformity
• Registration in EU AI database
• Post-market monitoring (Art. 72): Active system for collecting real-world performance data and incident reporting

If You Are the Deployer (Purchased/Licensed the System)

• Instructions compliance: Use the system strictly in accordance with the provider's instructions
• Human oversight: Assign qualified personnel to perform oversight with appropriate authority and resources
• Input data quality: Ensure input data is relevant and representative for the specific deployment context
• Log retention: Activate and retain automated logs for the required period
• Incident reporting: Report serious incidents to the provider and, in some cases, directly to authorities
• Fundamental rights impact assessment (Art. 27): Required for public bodies; recommended for private sector deployers in sensitive contexts

Interaction with DORA

The Digital Operational Resilience Act (DORA) entered into application in January 2025 and imposes comprehensive ICT risk management requirements on financial institutions — including AI systems as ICT components.

Key interaction points:

ICT Risk Management Framework

DORA requires financial institutions to maintain an ICT risk management framework covering identification, protection, detection, response, and recovery. AI systems are ICT tools subject to this framework. The EU AI Act adds AI-specific requirements on top: bias testing, transparency documentation, human oversight design, and lifecycle management.

In practice: A bank's AI credit scoring model must comply with both DORA ICT risk management (incident detection, continuity planning, change management) and EU AI Act high-risk requirements (risk management system, technical documentation, post-market monitoring).

Third-Party Risk (ICT Third-Party Providers)

DORA imposes detailed requirements for managing ICT third-party providers — including contractual requirements, audit rights, and oversight of critical providers. When a financial institution uses a third-party AI system (e.g., a vendor-supplied credit scoring model), DORA's third-party risk management requirements apply to that vendor.

The EU AI Act's deployer obligations also apply — requiring the provider to supply instructions, conformity documentation, and logging capability. Financial institutions should ensure their third-party AI vendor contracts satisfy both DORA ICT provider requirements and EU AI Act deployer information rights.

Incident Reporting

DORA has its own incident reporting framework for significant ICT-related incidents, reported to sectoral supervisors (EBA, EIOPA, ESMA). The EU AI Act requires serious incidents involving high-risk AI systems to be reported to national market surveillance authorities.

These are separate reporting obligations to different authorities. A serious incident involving an AI credit scoring system could trigger both a DORA incident report (to EBA/national financial supervisor) and an EU AI Act incident report (to the market surveillance authority).

Sectoral Supervisors and AI Act Enforcement

For financial institutions, the sectoral financial supervisors — EBA (banking), EIOPA (insurance), ESMA (securities and markets) — have a specific role in EU AI Act implementation, though they are not the primary AI Act enforcement authority.

Under the AI Act, financial institutions that are providers of high-risk AI systems must register in the EU AI database. In the financial sector, the relevant financial supervisory authority may be designated as or collaborate with the national market surveillance authority responsible for AI Act oversight of that sector.

The European Supervisory Authorities (ESAs) have been active in:

• Publishing guidance on AI governance in financial services (EBA guidelines on internal governance, ML/AI in credit risk)
• Contributing to EU AI Act implementation guidance for the financial sector
• Coordinating with the EU AI Office on GPAI model oversight as it affects financial services

Practical Compliance Priorities for Financial Institutions

1. Inventory all AI systems in use — classify each against Annex III criteria. Prioritise creditworthiness, insurance pricing, and biometric/KYC systems.

2. Determine provider vs. deployer status for each system — are you using vendor-supplied models or building in-house?

3. Align AI governance with DORA ICT risk framework — integrate AI Act obligations into the existing DORA governance structure to avoid duplicate processes.

4. Review third-party AI vendor contracts — ensure contracts provide: conformity documentation, instructions for use, logging access, incident notification commitments, update obligations, and audit rights.

5. Establish human oversight mechanisms — for high-risk AI use cases, ensure qualified staff have the authority, tools, and time to meaningfully review AI outputs before consequential decisions are made.

6. Connect to post-market monitoring — extend existing model risk management processes (Basel model validation, DORA change management) to cover the Art. 72 post-market monitoring requirements.

7. Prepare for the EU AI database — if you are a provider of high-risk AI systems, registration is mandatory. If you are a public body deployer, registration may also be required.