EU AI Act for Fintech: High-Risk Classification, Obligations, and the Deadline That Matters

Credit-scoring algorithms. Life insurance pricing engines. Robo-advisers. Anti-money-laundering models. Every fintech firm deploying algorithmic decision-making faces the same first question under Regulation (EU) 2024/1689: does this system land in Annex III — and if it does, what exactly does that trigger?

The answer is not uniform across financial services. Two fintech use cases sit squarely in the high-risk list. Several others that practitioners assume are covered are not — and treating them as equivalent wastes compliance resources and obscures where the real obligations bite. This article maps the regulatory terrain precisely.

---

The High-Risk Hotspot: Creditworthiness Assessment

The clearest high-risk classification for fintech is Annex III, point 5(b): AI systems used to evaluate the creditworthiness of natural persons or establish their credit score. This covers automated decisioning in consumer lending, credit card approval, peer-to-peer lending platforms, and any model that determines whether a person gets access to credit and on what terms.

Point 5(b) does not require that the AI system makes the final decision alone. A model that produces a score that a loan officer then uses is still within scope if the AI output materially shapes the outcome. The key is whether the system influences access to an essential service for a natural person.

The fraud-detection carve-out is real and significant. Annex III, point 5(b) explicitly excludes AI systems used for fraud detection. A model that flags suspicious transactions, screens for payment anomalies, or identifies account-takeover patterns is not high-risk on this basis — regardless of how sophisticated it is. The EU legislature made a deliberate choice here: fraud models protect consumers and the financial system; they do not determine access to credit or services in a way that creates the same fundamental-rights exposure.

This matters practically. A lender that builds its own credit model and licenses a fraud-detection engine from a specialist vendor has two very different compliance tasks. The credit model triggers the full high-risk obligation stack. The fraud engine does not — at least not under Annex III point 5(b).

---

Life and Health Insurance Pricing: Annex III Point 5(c)

Annex III, point 5(c) covers AI systems used to assess risks and set pricing for health insurance and life insurance. This captures underwriting models that determine premium levels, risk categorisation, or eligibility for cover. The same high-risk obligation stack applies as for credit scoring.

Insurance firms operating in multiple EU jurisdictions need to be aware that this Annex III classification operates alongside existing sectoral regulation (Solvency II, IDD). The EU AI Act does not replace those frameworks — it layers on top of them.

---

What Is Not in Annex III (and Why It Matters)

Several common fintech AI applications are not in Annex III as high-risk systems:

Robo-advice and algorithmic trading. An AI that recommends investment portfolios or executes trades at algorithmic speed is not in Annex III. It faces obligations under MiFID II (product governance, suitability, best execution) and GDPR (where it processes personal data), but the EU AI Act's high-risk tier does not apply. If the system operates as a chatbot or interacts with users, Article 50's limited-risk transparency rules apply — but that is a disclosure obligation, not a conformity assessment.

AML and transaction monitoring. As noted above, fraud and AML models are explicitly carved out of Annex III, point 5(b). They may be subject to EBA guidelines on model risk and GDPR Article 22 (automated decision-making), but they are not EU AI Act high-risk systems by virtue of Annex III alone.

KYC and identity verification. Automated identity document verification — reading a passport, matching a selfie — is not in Annex III unless it constitutes remote biometric identification used in a public space for law enforcement purposes (Annex III, point 1). Standard KYC onboarding flows sit outside the high-risk list.

Knowing what is out of scope is as useful as knowing what is in scope. Mis-classifying a fraud model as high-risk is not just wasteful — it signals to auditors that your classification methodology is unreliable.

---

Article 6(3): The Exemption Filter

A system that falls within an Annex III category is still not automatically high-risk. Article 6(3) allows a provider to conclude that a system poses no significant risk of harm to health, safety, or fundamental rights — provided it meets one of four conditions: it performs a narrow procedural task; it improves the outcome of a previously completed human activity; it detects decision patterns without replacing or influencing a human assessment; or it performs preparatory tasks only.

The carve-out has limits. Any system that profiles natural persons is always high-risk — the Art 6(3) filter cannot apply. And providers that invoke the exemption must document their assessment and still register the system in the EU database under Article 49. The exemption is not a way to avoid scrutiny; it is a documented risk judgment.

For a credit-scoring model that profiles borrowers, Art 6(3) is unlikely to provide relief. For a narrow pre-screening tool that only checks whether an application form is complete before a human reviews it, the argument is more viable — but it still needs to be made in writing.

---

Roles: Provider, Deployer, or Both?

Most banks and lenders are deployers under Article 26. They license a credit-scoring model from a specialist vendor, embed it in their loan-origination workflow, and use the outputs to support credit decisions. They did not build the model, train it, or place it on the market — so they are not the provider.

A bank that builds its own credit-scoring model in-house and uses it is both provider (Article 16) and deployer. A fintech that develops a credit-scoring engine and licenses it to other lenders is a provider. The role determines the obligation stack.

Article 25 means the role can shift. If a deployer puts its own name on a third-party model, substantially modifies it, or repurposes it beyond its intended use, it becomes a provider and picks up the full provider obligation set. A lender that takes a vendor model and retrains it on its own proprietary data has likely crossed that threshold.

What Providers Must Do

Providers of high-risk AI systems in Annex III carry the heaviest obligations under Articles 9–17 and 43:

• Article 9 — a continuous risk management system, identifying foreseeable risks, estimating probability and severity, testing mitigation measures, and updating through the system's lifecycle.
• Article 10 — data governance: training, validation, and test datasets must be relevant, representative, and free of known errors that could cause discriminatory outcomes.
• Article 11 / Annex IV — technical documentation, compiled before market placement, covering system architecture, training data, performance benchmarks, and instructions for deployers.
• Article 12 — logging capability, so that the system automatically generates logs of its operation.
• Article 13 — transparency: instructions provided to deployers, including the system's intended purpose, performance limits, and any known biases.
• Article 14 — human oversight: the system must be designed so that deployers can monitor it and natural persons can intervene, override, and understand outputs.
• Article 15 — accuracy, robustness, and cybersecurity across the system's lifecycle.
• Article 17 — a quality management system covering all of the above.
• Article 43 — conformity assessment before placing the system on the market (most Annex III systems use the internal-control route under Annex VI; notified-body involvement is required for certain biometric systems under Annex VII).
• Article 47 / Annex V — an EU declaration of conformity.
• Article 49 — registration in the EU database before deployment.
• Article 72 — post-market monitoring, once the system is in use.
• Article 73 — reporting serious incidents to the market-surveillance authority within the timelines specified (15 days in most cases; 2 days for critical infrastructure disruption or widespread infringement; 10 days where a person has died).

What Deployers Must Do

Deployers under Article 26 have a shorter but non-trivial list:

• Use the system only for its intended purpose, per the provider's instructions.
• Assign human oversight to people with the competence and authority to intervene.
• Monitor the system during use and report issues to the provider.
• Keep logs of operation under Article 26 for at least six months.
• Inform and consult workers' representatives before deploying in the workplace (Article 26).

Article 27 — the Fundamental Rights Impact Assessment (FRIA) — applies to a specific subset of deployers. If you are a public body, or if you deploy a system covered by Annex III point 5(b) (creditworthiness) or point 5(c) (life/health insurance pricing) in a private capacity, you must run a FRIA before deployment. The FRIA is not a light-touch exercise: it maps the rights of affected persons, the risks the deployment creates, and the measures in place to mitigate them. Confir generates it as a structured output from the classification assessment.

---

The Obligation Stack in Practice: A Credit-Scoring Example

A regional lender — 200 employees, operating in Germany and Austria — built its own consumer credit-scoring model. It produces a probability-of-default score that loan officers see alongside a score-band recommendation; they retain override authority.

Classification: Annex III, point 5(b). The system evaluates the creditworthiness of natural persons and profiles borrowers, so Art 6(3) cannot apply. High-risk.

Role: The lender built and deploys the model under its own name. It is both provider (Art 16) and deployer (Art 26).

What must happen by 2 December 2027: Compile the Article 11 / Annex IV technical documentation pack (training data provenance, bias testing, performance benchmarks, instructions for use); formalise the Article 9 risk management system; complete the Article 10 data quality review; document Article 14 human-oversight arrangements for loan officers; complete the Article 43 conformity assessment (Annex VI internal control), sign the Article 47 declaration of conformity, and register under Article 49; run the Article 27 FRIA documenting borrower rights impacts; and establish Article 72 post-market monitoring and Article 12 logging.

The lender's existing model risk committee is the natural home for this work. The Act does not require starting from scratch — it requires mapping existing governance to the statutory requirements and filling the gaps.

---

Regulatory Overlap: DORA, MiFID II, GDPR, and Consumer Credit

The EU AI Act does not operate in isolation. Four other frameworks interact with fintech AI governance:

DORA (Digital Operational Resilience Act, from 17 January 2025) — ICT risk management (Articles 5–16) and third-party provider oversight (Articles 28–44) cover AI systems as ICT tools. A vendor credit-scoring model triggers both DORA third-party oversight and EU AI Act deployer obligations. The documentation is distinct but the due-diligence process can run in parallel.

GDPR Article 22 — individuals have the right not to be subject to decisions based solely on automated processing that produce legal or similarly significant effects. Credit decisions based purely on automated scoring engage Article 22. The EU AI Act's Article 14 human-oversight requirement is complementary but does not substitute for the GDPR right.

MiFID II — suitability and appropriateness assessments for investment products must meet MiFID standards as well as any applicable EU AI Act obligations (Article 50 transparency if a chatbot; the full Annex III stack if the system is high-risk under Article 6).

Consumer Credit Directive II (2023/2225, from November 2025) — requires creditors to explain the basis for an adverse credit decision. An AI credit-scoring system must be able to produce that explanation, aligning with Article 14's interpretability requirement but applying independently and to a broader creditor set.

---

The Deadline: 2 December 2027

The original high-risk deadline under the EU AI Act was 2 August 2026. That date is no longer operative for stand-alone Annex III systems. Under the Digital Omnibus — a Commission proposal of November 2025, with political agreement between Parliament and Council reached on 7 May 2026 — the application date for stand-alone high-risk AI systems (the Annex III list, including Annex III point 5(b) and 5(c)) is 2 December 2027. For high-risk AI embedded in products covered by Annex I product safety law, the date is 2 August 2028.

Formal adoption of the Digital Omnibus is expected before 2 August 2026. The 2 December 2027 date should be treated as current and authoritative.

The extension is not a reason to delay. Technical documentation under Article 11 / Annex IV takes months to assemble properly, particularly for a system trained on proprietary data. Article 9 risk management requires evidence generated over time. The Article 27 FRIA requires stakeholder input. A realistic preparation timeline for a lender starting from a functioning model-risk programme is 12–18 months of structured work. Starting in late 2026 is possible; starting in 2027 is not.

---

Penalties

Non-compliance with the high-risk obligations — including Articles 9, 10, 11, 13, 14, 15, 43, and 49 — is subject to fines under Article 99(4) of up to €15,000,000 or 3% of total worldwide annual turnover, whichever is higher.

A violation of Article 5's prohibited practices carries the highest tier: up to €35,000,000 or 7% of worldwide turnover (Article 99(3)).

Providing incorrect or incomplete information to a notified body or competent authority is the lowest tier: up to €7,500,000 or 1% (Article 99(5)).

For companies that qualify as SMEs or start-ups under the Act's definition, Article 99(6) caps the fine at the lower of the percentage or the fixed amount. That proportionality provision is genuine — it should be documented in compliance planning as a risk-calibration factor, not assumed to eliminate exposure.

---

How Confir Helps

Confir's classification module steps through Annex III, point by point, using plain-English scenarios drawn from the regulation's text. For a credit-scoring system, it confirms the Annex III 5(b) classification, identifies the provider and deployer roles from your intake answers, and maps the full obligation stack. The logic is deterministic and rule-based — the same inputs always produce the same classification, with the rule that fired recorded in the output.

From there, Confir drives the structured assessment across four compliance areas (AIRC, AITR, AITO, AIGM) and generates the Article 11 / Annex IV technical documentation pack, the Article 47 / Annex V Declaration of Conformity, and the Article 27 FRIA — three documents that a lender's compliance team would otherwise need to produce from scratch. Pricing starts at €600 per year.

---

Frequently Asked Questions

Is fraud detection high-risk under the EU AI Act?

No — not on the basis of Annex III, point 5(b). The creditworthiness provision explicitly excludes AI systems used for fraud detection. A transaction-monitoring or payment-anomaly model does not sit in the Annex III high-risk list. It may face GDPR Article 22 obligations if it produces legally significant automated decisions, and EBA model-risk guidance may apply, but the EU AI Act high-risk conformity-assessment stack does not.

My bank licenses a credit-scoring model from a fintech vendor. What do we owe?

You are a deployer under Article 26. Your obligations include using the system within its intended purpose, maintaining human oversight, keeping logs for at least six months under Article 26, and running the Article 27 FRIA — because creditworthiness deployers are explicitly required to complete one. You are not responsible for the provider's conformity assessment, but you should verify the provider has one (request the Article 13 instructions and the Article 47 declaration of conformity as part of vendor due diligence).

When does the high-risk deadline apply to credit-scoring systems?

Under the Digital Omnibus (political agreement of 7 May 2026), the application date for stand-alone Annex III high-risk systems — including credit scoring under point 5(b) and insurance pricing under point 5(c) — is 2 December 2027. The original 2 August 2026 date has been formally deferred. Formal adoption of the Digital Omnibus is expected before August 2026.

Does robo-advice trigger the high-risk regime?

Generally no. Robo-advisory systems that recommend investment portfolios are not in Annex III. They face MiFID II suitability requirements and GDPR Article 22 where they produce automated recommendations with significant effects. If a robo-adviser operates as an interactive chatbot, Article 50's transparency obligations apply — the user must know they are interacting with an AI system. But the full high-risk conformity-assessment stack is not triggered.

What is the Article 27 FRIA and who in fintech must do it?

The Fundamental Rights Impact Assessment (Article 27) is a pre-deployment analysis that deployers must complete before operating certain high-risk AI systems. In fintech, the FRIA obligation applies to deployers of creditworthiness-assessment systems (Annex III, point 5(b)) and life/health insurance pricing systems (point 5(c)). It requires identifying the affected population, mapping the rights at stake, cataloguing the risks, and documenting the safeguards. Public bodies deploying any high-risk system must also complete one.

How does the EU AI Act interact with GDPR Article 22?

GDPR Article 22 gives individuals the right not to be subject to decisions based solely on automated processing that produces legal or significant effects. EU AI Act Article 14 requires that high-risk AI systems be designed for human oversight, so that a person can intervene and override outputs. The two obligations are complementary but independent: a lender must satisfy both. In practice, the Article 14 oversight arrangements — a loan officer who reviews the score and has override authority — also support the GDPR Article 22 defence that the decision is not solely automated.

What are the penalties for a fintech that misses its high-risk obligations?

Under Article 99(4), the maximum fine for failing to meet high-risk obligations (including Articles 9, 10, 11, 13, 14, 15, 43, and 49) is €15,000,000 or 3% of total worldwide annual turnover, whichever is higher. That is not the Article 5 prohibition tier (€35M/7%) — it is the second tier, which covers the full set of high-risk requirements. Smaller companies benefit from the Article 99(6) proportionality cap: for them, the fine is the lower of the percentage or the fixed amount.

---

Related guides

• CISO governance framework
• Article 6 high-risk classification
• enterprise compliance obligations
• Article 9 risk management system
• EU AI Act deadlines and timeline
• deployer obligations checklist