EU AI Act for Financial Services AI: Compliance Requirements

Finance got to AI early. Credit scoring, insurance risk models, fraud detection, algorithmic trading engines: there is barely a function in modern banking that does not have a model running somewhere underneath it. Now the EU AI Act is in force, and it lands on top of a sector that was already one of the most heavily regulated on earth. So you are not learning one rulebook. You are reconciling two: the sector-specific rules you already live by, and a new horizontal AI framework that cuts across all of them.

This guide breaks down exactly what the EU AI Act asks of financial services organisations, where it overlaps with regimes like MiFID II and DORA, and how your compliance team can build a roadmap that actually gets you to the enforcement deadlines in one piece.

Why Financial Services AI Attracts High-Risk Classification

The EU AI Act sorts AI systems by the risk they pose to fundamental rights and safety. Under Annex III, point 5(b), AI systems used to evaluate the creditworthiness of natural persons or to establish their credit score are explicitly designated high-risk. There is no grey area here, and nothing to argue about. If your organisation uses AI to decide whether a consumer qualifies for a loan, a mortgage, or a credit card, that system sits squarely inside the high-risk category.

Beyond credit scoring, Annex III captures several additional financial use cases:

• Insurance risk assessment: AI systems that set insurance premiums or determine eligibility based on risk profiling of individuals.
• Customer creditworthiness assessment: Any AI-driven evaluation of a natural person's ability to repay debt or meet financial obligations.
• Access to essential services: AI that determines whether an individual can access a bank account or other essential financial services.

Fraud detection AI and algorithmic trading systems do not appear by name in Annex III. That does not put them in the clear. Either one can still tip into high-risk classification depending on how it is deployed and whether it shapes an individual's access to financial services. The safe move is to run a proper risk assessment on every AI system in your portfolio, rather than assuming anything is exempt by default.

High-Risk Obligations for Financial AI Systems

Once an AI system is classified as high-risk, the EU AI Act stacks a full set of requirements on top of it under Articles 8 through 15. For a financial institution, those are not abstract principles. They turn into concrete things your operations team has to build and keep running.

Risk Management System (Article 9)

You must establish and maintain a risk management system for each high-risk AI system. This is not a box you tick once and forget. The risk management system has to run as a continuous, iterative process across the entire lifecycle of the AI system. For a credit scoring model, that means:

• Identifying and analysing known and reasonably foreseeable risks to health, safety, and fundamental rights.
• Estimating and evaluating risks that may emerge when the system is used in accordance with its intended purpose and under conditions of reasonably foreseeable misuse.
• Adopting appropriate risk management measures, including design choices and technical safeguards.
• Testing the system to identify the most appropriate risk management measures.

For financial AI, the risk to watch hardest is discriminatory outcomes. A credit scoring model that systematically disadvantages applicants on protected characteristics such as ethnicity, gender, or age is not just an AI Act violation. It is also a breach of anti-discrimination law you were already bound by. One model, two regimes, double the exposure.

Data Governance (Article 10)

Article 10 lays down strict requirements for training, validation, and testing data. The datasets you use to build credit scoring, insurance pricing, or creditworthiness models have to clear specific quality criteria:

• Training data must be relevant, sufficiently representative, and as free of errors as possible.
• Data must reflect the specific geographical, contextual, behavioural, or functional setting in which the AI system is intended to operate.
• Where personal data is processed, appropriate data governance measures must be in place, including data collection protocols, data preparation operations, and assessments of data availability, quantity, and suitability.

For financial services, this runs straight into your GDPR obligations around data minimisation and purpose limitation. You cannot satisfy one framework and ignore the other. The processes you build have to answer to both at once. Our EU AI Act vs GDPR comparison digs into where the two meet.

Technical Documentation (Article 11)

Every high-risk AI system needs complete technical documentation in place before it is placed on the market or put into service. Not after launch. Before. For financial AI systems, that documentation must include:

• A general description of the AI system, its intended purpose, and the provider's identity.
• A detailed description of the elements of the AI system and the development process, including training methodologies, design specifications, and system architecture.
• Information about the monitoring, functioning, and control of the system.
• A detailed description of the risk management system.
• Information about the performance of the system, including accuracy metrics, robustness measures, and cybersecurity provisions.

If your teams already document models under the ECB's Guide to Internal Models or the PRA's model risk management expectations, some of this will feel familiar. Do not assume it is a copy-paste job. The AI Act's documentation requirements reach wider, and they are pointed explicitly at protecting fundamental rights, which your existing model paperwork was never written to do.

Record-Keeping and Logging (Article 12)

High-risk AI systems must be built to record events automatically (logs) while they run. For credit scoring and insurance AI, that means keeping logs that cover:

• Traceability of the system's operation.
• Monitoring of the system's performance over time.
• Post-market surveillance and investigation of incidents.

Logs must be retained for a period appropriate to the intended purpose of the system, and in any case for no less than six months unless otherwise provided by applicable Union or national law. Here is the practical wrinkle: financial regulations frequently demand far longer retention than that. So set your AI logging to your existing record-keeping obligations, not to the floor, and you will not get caught short.

Human Oversight (Article 14)

High-risk AI systems must be designed to allow effective human oversight. In financial services, that means credit decisions, insurance pricing calls, and fraud detection alerts coming out of an AI must face meaningful human review. The Act requires that human overseers:

• Fully understand the capabilities and limitations of the AI system.
• Be able to correctly interpret the system's output.
• Be able to decide not to use the system, override the output, or reverse an automated decision.
• Be able to intervene in the system's operation or interrupt it through a stop button or similar procedure.

This one bites hard on straight-through processing (STP) in lending. A fully automated credit decision with no human in the loop may not satisfy Article 14 at all, not unless you can show the system was built with effective override mechanisms and that your staff are trained and genuinely empowered to use them. A stop button nobody is allowed to press does not count.

Overlap with Existing Financial Regulation

The EU AI Act does not land on an empty desk. Its requirements have to coexist with the dense web of sector-specific regulation you already answer to, and the seams between them are where most of the work hides.

MiFID II and Algorithmic Trading

The Markets in Financial Instruments Directive II (MiFID II) already puts requirements on algorithmic trading systems: risk controls, testing obligations, record-keeping. The AI Act adds a second layer. Where an algorithmic trading system bakes in AI capabilities that meet the Act's definition, it may have to answer to both MiFID II's algorithmic trading rules and the AI Act's requirements for high-risk systems.

If you run AI for order execution, market-making, or portfolio optimisation, the question to settle first is whether those systems fall within the AI Act's scope. Once you know that, you can work out how to fold AI Act compliance into the MiFID II frameworks you already operate.

DORA (Digital Operational Resilience Act)

The Digital Operational Resilience Act (DORA), which became applicable in January 2025, sets requirements for ICT risk management, incident reporting, and digital operational resilience testing across the financial sector. An AI system is a form of ICT. That means your AI risk management practices have to line up with DORA's wider ICT risk framework, not sit in a separate silo run by a separate team.

Key areas of overlap include:

• Third-party risk management: Where AI systems are procured from external providers, DORA's requirements for managing ICT third-party risk apply alongside the AI Act's obligations for deployers of high-risk AI.
• Incident reporting: AI system failures that result in operational incidents may trigger reporting obligations under both DORA and the AI Act.
• Testing: DORA's digital operational resilience testing requirements may need to incorporate AI-specific testing mandated by the AI Act.

Anti-Money Laundering (AML) AI

AI systems used for anti-money laundering and counter-terrorism financing (AML/CTF) sit in an awkward spot. They do essential regulatory compliance work, yes. They also chew through sensitive personal data and can land real consequences on the individuals whose transactions get flagged. So your AML AI systems have to:

• Comply with the AI Act's transparency and documentation requirements.
• Maintain appropriate human oversight so that suspicious activity reports (SARs) are reviewed by qualified personnel.
• Be regularly tested for bias and accuracy to avoid disproportionate impacts on specific demographic groups.
• Satisfy GDPR requirements for lawful processing, including the legal basis for profiling.

Bias Testing and Fairness Requirements

Bias in financial AI is not just a compliance risk. It is a reputational and legal liability, and the two tend to arrive together. The EU AI Act backs up the non-discrimination obligations you already carry by requiring that high-risk AI systems be designed and developed to minimise the risk of biased outputs.

In practice, that means standing up serious bias testing for your credit scoring, insurance pricing, and customer segmentation models. Best practices include:

• Pre-deployment bias audits: Testing the model against protected characteristics before it goes live.
• Ongoing monitoring: Continuously tracking model outputs for disparate impact across demographic groups.
• Corrective mechanisms: Establishing processes to retrain or adjust models when bias is detected.
• Documentation: Recording all bias testing activities, results, and remediation steps as part of the technical documentation required under Article 11.

The European Banking Authority (EBA) and the European Insurance and Occupational Pensions Authority (EIOPA) are expected to put out further guidance on AI fairness in financial services. Watch that space closely, because the bar is going to keep moving.

Deployer Obligations for Financial Institutions

Most financial institutions will act as deployers rather than providers of AI systems under the EU AI Act. That distinction matters, because it decides which obligations land on you. Deployer obligations under Article 26 require you to:

• Use high-risk AI systems in accordance with the provider's instructions for use.
• Ensure that input data is relevant and sufficiently representative for the system's intended purpose.
• Monitor the operation of the AI system and inform the provider or distributor of any serious incidents or malfunctions.
• Conduct a fundamental rights impact assessment before deploying high-risk AI systems (for entities governed by Union law in the banking and insurance sectors, this assessment may be integrated into existing impact assessment procedures).
• Maintain logs generated by the high-risk AI system for a period appropriate to the system's intended purpose.
• Inform individuals that they are subject to a decision made by or with the assistance of a high-risk AI system.

The fundamental rights impact assessment (FRIA) is a genuinely new obligation with no direct equivalent in current financial regulation. Do not wait for a template to appear. Start building your FRIA processes now, and lean on what your teams already know from Data Protection Impact Assessments (DPIAs) under the GDPR. For a full walkthrough of every compliance requirement, see our EU AI Act Compliance Checklist.

Practical Compliance Roadmap for Financial Services

Getting compliant is not a single sprint. It runs in phases, and the order matters. Here is an approach that works for financial institutions:

Phase 1: AI Inventory and Classification (Q2 2026)

Inventory every AI system running across the organisation. You cannot regulate what you have not found. For each one, work out whether it falls within the AI Act's scope, classify its risk level, and pin down whether you are acting as a provider or a deployer.

Phase 2: Gap Analysis and Documentation (Q3 2026)

For each high-risk AI system, run a gap analysis against the Act's requirements. Put technical documentation, risk management systems, and data governance measures at the front of the queue. Start drafting fundamental rights impact assessments while you are at it.

Phase 3: Remediation and Implementation (Q4 2026 - Q1 2027)

Close the gaps you found through technical remediation, process work, and organisational change. Stand up bias testing protocols, logging mechanisms, and human oversight procedures. And train your staff on what the AI Act actually asks of them, because oversight on paper is worth nothing if nobody knows their role.

Phase 4: Ongoing Compliance and Monitoring (Continuous)

Compliance is not a finish line you cross once. Build monitoring that keeps you there, and wire AI Act obligations into the compliance management systems, internal audit programmes, and risk reporting frameworks you already run.

Penalties for Non-Compliance

Getting the EU AI Act wrong is expensive. Violate the Act's requirements for high-risk AI systems and you face administrative fines of up to 15 million EUR or 3% of total worldwide annual turnover, whichever is higher. For prohibited practices, the ceiling climbs to 35 million EUR or 7% of turnover. And these sit on top of whatever sanctions your existing financial regulators can already impose, not instead of them. For the full breakdown, see our guide on EU AI Act fines and enforcement.

Getting Started

If your institution has not started its EU AI Act work yet, start it now. The deadlines are not waiting, and lining AI Act obligations up against the financial regulation you already follow takes real planning and people from more than one team in the room.

The best place to begin is a structured compliance assessment: map your AI systems against the Act's requirements and surface the gaps that matter most.

Start Your Free Compliance Assessment

Where AI regulation meets financial services law, the rules are still being written, and they will keep shifting as supervisory authorities issue guidance and enforcement gets going. Institutions that put dependable AI governance in place now will adapt to whatever comes next far more easily, and they will keep the trust of their customers and regulators while they do it. For a side-by-side review of tools that take weight off your compliance team, see our analysis of the best EU AI Act compliance tools.

Update: Where the Digital Omnibus Stands (June 12, 2026)

A quick note before you act on any date in this article. The Digital Omnibus is a simplification package the European Commission proposed on November 19, 2025. It would amend several EU digital laws at once, and for the AI Act it proposes two big changes: the high-risk obligations would apply later (December 2, 2027 for the stand-alone high-risk systems listed in Annex III, and August 2, 2028 for high-risk AI embedded in regulated products), and a number of requirements would be simplified along the way.

Here is the part that matters: none of this is law yet. The European Parliament and the Council reached a provisional agreement on May 7, 2026, and formal adoption is expected, but until the final text is adopted and published, nothing changes. The dates and obligations described in this article are the ones in force today. And the rules that already apply, like the prohibited practices and the AI literacy duty, stay exactly where they are no matter what happens to the Omnibus.

We are watching this closely. The moment the Omnibus is adopted, amended, or rejected, we will update this article to reflect the new EU AI compliance dates. Check back, or run the free 90-second risk check to see your obligations under the rules as they stand right now.