The AI Act and financial services: what banks and fintechs need to know

A new compliance layer, already in motion

The EU Artificial Intelligence Act (Regulation (EU) 2024/1689, CELEX 32024R1689) entered into force on 1 August 2024. It is the world’s first comprehensive horizontal legal framework for AI, and it applies to financial services with direct, specific effect. This is not a general technology regulation that financial firms might peripherally touch. The Act’s Annex III lists credit scoring, insurance risk assessment and pricing, and eligibility evaluation for essential services among its explicitly designated high-risk use cases. If your organisation uses AI to make or inform those decisions for EU-based individuals, the AI Act applies to you.

The implementation is phased. Prohibited AI practices and AI literacy obligations became enforceable from 2 February 2025. Governance provisions and obligations for general-purpose AI models applied from 2 August 2025. The most consequential deadline for most financial institutions is 2 August 2026, when the full compliance requirements for high-risk AI systems listed in Annex III become enforceable.

There is regulatory uncertainty worth noting. The European Commission’s Digital Omnibus proposal, introduced in late 2025, would extend the high-risk deadline for Annex III systems to December 2027. That proposal is still being negotiated between the European Parliament and the Council. Prudent compliance planning treats August 2026 as the binding deadline. AI systems already on the market before the law goes into effect may be grandfathered from certain obligations, which creates an asymmetry between existing deployments and new systems. Do not assume the delay will materialise, and do not assume that grandfathering applies without analysis.

This article explains the AI Act’s risk classification system, what the high-risk obligations require, how financial institutions need to think about their role under the regulation, and how the Act interacts with DORA and MiCA.

For context on how the AI Act fits within the broader EU financial regulatory landscape, see EU financial regulation in 2026: what it covers, who it affects, and why horizon scanning matters.

This article is for informational purposes only and does not constitute legal advice. Consult a qualified legal professional for advice specific to your situation.

How the AI Act classifies risk

The AI Act applies a risk-based structure. The classification determines what obligations apply.

Unacceptable risk covers AI applications that are prohibited outright. These include systems used for social scoring of individuals by public authorities, real-time remote biometric identification in public spaces with limited exceptions, and AI used to exploit psychological vulnerabilities. Financial institutions are unlikely to be deploying prohibited systems, but the prohibition on manipulative techniques affecting individual decision-making is worth reviewing against customer-facing AI.

High risk is the category that matters most for financial services. High-risk systems are regulated but permitted. They are subject to the full compliance obligations under the Act. Two routes lead to high-risk classification:

The first is Annex I: AI systems embedded as safety components in products already subject to EU harmonisation legislation (medical devices, machinery, vehicles). This is less directly relevant for most financial services firms.

The second is Annex III, which is a direct-access list of use cases that are high-risk by definition. The financially relevant ones are:

• AI systems intended to evaluate the creditworthiness of natural persons or establish their credit score, with the exception of AI systems used purely to detect financial fraud
• AI systems intended for risk assessment and pricing in life and health insurance
• AI systems intended to evaluate eligibility for essential public services or benefits, including financial services

The fraud detection exception in the creditworthiness category is narrow. A system that also informs credit decisions is not exempt simply because fraud detection is one of its functions.

Limited risk systems are subject only to transparency obligations. Chatbots must disclose that the user is interacting with an AI. AI-generated content must be labelled. This applies to customer-facing conversational AI in financial services.

Minimal or no risk systems are unregulated, though voluntary codes of conduct are encouraged. Spam filters and basic recommendation engines fall here.

General-purpose AI models are a separate category. Providers of foundation models, such as large language models, have been subject to governance obligations since August 2025. For financial institutions using GPAI models in their products, the relevant question is whether the resulting application constitutes a high-risk system.

What the high-risk obligations require

For any AI system that falls within Annex III, the following obligations apply. The obligations differ depending on whether the organisation is a provider (developing the system) or a deployer (using a system developed by others). Most financial institutions will be deployers when using third-party AI products, and providers when they develop or fine-tune AI systems in-house.

For providers:

Quality management system (Article 9): A documented, continuous process for identifying, analysing, and mitigating risks associated with the AI system throughout its lifecycle. This is not a one-time assessment. It runs from development through decommissioning and must be updated when the system changes materially.

Data governance (Article 10): Training, validation, and testing datasets must be relevant, representative, and free of errors to the extent possible. For credit scoring models, this means documented data lineage, bias testing, and the ability to demonstrate that the training data does not encode discriminatory patterns.

Technical documentation (Article 11): Before placing the system on the EU market, providers must produce documentation sufficient for regulators to assess whether the system complies. The documentation must describe the system’s intended purpose, the logic it uses, the data it was trained on, its performance metrics, and the human oversight mechanisms built into it.

Automatic event logging (Article 12): High-risk AI systems must automatically log events throughout their lifecycle. The logs must be retained for a period appropriate to the system’s risk level, and must support post-incident investigation and regulatory audit.

Transparency for deployers (Article 13): Providers must design systems so that deployers can understand how they work. Instructions for use must explain the system’s intended purpose, known limitations, and the conditions under which human oversight should intervene.

Human oversight (Article 14): High-risk systems must be designed to allow natural persons to effectively oversee and intervene in their operation. For credit decisions, this means a meaningful human review process for cases where the AI output is the basis for an adverse decision, not a nominal checkbox.

Conformity assessment: Before placing a high-risk AI system on the EU market, providers must complete a conformity assessment and register the system in the EU AI database. For most Annex III systems, self-assessment is permitted; third-party assessment is required for systems in the biometric identification category.

For deployers:

Deployer obligations are narrower but still significant. Deployers of high-risk AI systems must use the system in accordance with the provider’s instructions, assign human oversight to appropriately skilled individuals, monitor the system’s performance in their operational context, and inform the provider if they identify risks not anticipated in the technical documentation.

The deployer is not exempt from the consequences of a system’s decisions simply because someone else built it. The deployer is responsible for how the system is applied.

The accidental provider problem:

A financial institution that licenses a third-party general-purpose AI model and fine-tunes it on proprietary data to create a credit-scoring tool may be reclassified as a provider under the AI Act. Fine-tuning a model for a high-risk use case transfers provider obligations, including the full compliance stack above, to the institution. This is a significant risk for firms that are iterating rapidly on AI applications using foundation model APIs and have not mapped their development activities to the AI Act’s provider definition.

Provider versus deployer in practice

The distinction between provider and deployer determines the compliance burden. The rule is:

If your organisation develops an AI system, or has one developed under its direction and places it on the market under its own name, it is a provider.

If your organisation uses a system developed by a third party in a professional context, it is a deployer.

If your organisation fine-tunes, modifies, or substantially adapts a system for a new purpose, it is a provider for that adapted system.

Most banks and financial institutions will be both, depending on the system. A bank that uses a third-party fraud detection tool is a deployer. A bank that builds its own credit-scoring model is a provider. A bank that takes a third-party GPAI model and builds a new loan assessment application on top of it is a provider of that application.

How the AI Act interacts with DORA

Financial institutions already subject to DORA face requirements that overlap significantly with the AI Act, particularly around ICT risk management, technical documentation, and operational resilience. This overlap creates both compliance synergy and potential duplication.

The shared requirements include: risk management frameworks that cover the full lifecycle of technology systems, incident reporting obligations, third-party provider oversight, and business continuity arrangements. An institution that has built a rigorous DORA compliance programme has most of the foundational infrastructure the AI Act requires. The gap is in the AI-specific elements: bias testing, training data governance, transparency obligations for affected individuals, and the human oversight design requirements.

DORA does not satisfy the AI Act, and the AI Act does not satisfy DORA. But firms that have invested in genuine DORA compliance have a significant head start on AI Act implementation.

The Digital Omnibus proposal mentioned above would, if adopted, align the breach notification thresholds and timelines between DORA and the AI Act, reducing the reporting complexity for financial institutions subject to both. That alignment is not yet in effect.

For more detail on what DORA requires, see the DORA compliance checklist.

How the AI Act interacts with MiCA

Crypto-asset service providers authorised under MiCA that use AI in their operations are subject to both regimes. The most likely points of intersection are:

Customer onboarding and identity verification. AI systems used in biometric identification are high-risk under Annex III regardless of sector.

Credit assessment within crypto lending products. Any AI system evaluating creditworthiness for lending products, including crypto-backed loans, falls within the Annex III credit scoring definition.

Trading systems. Algorithmic trading systems that use AI to generate recommendations or execute decisions fall within the AI Act’s scope. Whether they constitute high-risk systems depends on whether they are classified as safety components or whether their output affects access to financial services in a manner that brings them within Annex III.

MiCA’s authorisation process already requires CASPs to address ICT architecture and DORA compliance. Firms going through CASP authorisation in 2026 should be mapping their AI systems to the AI Act simultaneously, as the overlap between the two compliance exercises is substantial.

For more detail on MiCA CASP authorisation requirements, see MiCA for crypto asset service providers: what authorisation actually requires.

Penalties and enforcement

Non-compliance with the AI Act carries significant penalties:

• Up to EUR 35 million or 7% of worldwide annual turnover for prohibited AI practices, whichever is higher
• Up to EUR 15 million or 3% of worldwide annual turnover for other violations of high-risk system requirements
• Up to EUR 7.5 million or 1% of worldwide annual turnover for supplying incorrect or misleading information to regulators

These penalty levels exceed GDPR maximums and reflect the EU’s intent to treat AI governance as a primary regulatory concern, not a secondary compliance consideration.

Enforcement is distributed across national competent authorities. In the financial sector, the existing sectoral supervisors, the national banking authorities, securities regulators, and insurance supervisors, are expected to act as market surveillance authorities for AI systems in their domains. Luxembourg has formally designated the CSSF as the competent authority for AI systems connected to financial services. Other member states are at different stages of establishing their supervisory frameworks.

The EBA’s position, as of late 2025, is that no new EBA guidelines are needed immediately and that the existing frameworks, combined with the AI Act’s own requirements, are sufficient. In 2026 and 2027, the EBA plans to promote a common supervisory approach and cooperate with the European AI Office. For banks and payment institutions, this means the practical supervision of AI Act compliance will come from existing supervisory relationships, not a new separate regulator.

What to do now

For most financial institutions, the practical starting point is an AI inventory. You cannot assess compliance without knowing what systems you have, what they do, and whether their intended use maps to any Annex III category. Many institutions discovered during GDPR implementation that they had significantly underestimated the number and scope of data processing activities. The AI inventory problem is similar.

Once systems are inventoried and classified, the compliance path differs for providers and deployers. For deployers, the primary obligation is ensuring that third-party providers have produced compliant documentation and that human oversight is genuinely implemented in operational processes. For providers and accidental providers, the full obligation stack applies.

The conformity assessment and EU database registration requirements mean that high-risk systems cannot legally be placed on the EU market after 2 August 2026 without completed documentation. Given the lead time required to build quality management systems, document training data lineage, and complete conformity assessments, institutions that have not begun should treat August 2026 as an immediate operational deadline, not a future planning horizon.

Forseti monitors AI Act implementation guidance, EBA supervisory publications, and Digital Omnibus developments continuously, so financial institutions are working from current requirements as the August 2026 deadline approaches. Start for free.