Skip to content
SimpleAct Logo

Industry · Fintech & financial services

Status: 6 October 2026

EU AI Act for Fintech and Banks: Credit Scoring, Insurance, Obligations

Hardly any industry is named as directly in Annex III as financial services: creditworthiness assessment and the pricing of life and health insurance are high-risk uses, while fraud detection is expressly excluded. This page shows which systems are affected, what deployers and providers must do and where the special rules for financial institutions apply.

Start the duty checkSee typical systems
  • Credit scoring under Annex III 5(b)
  • Carve-out for fraud detection
  • Fundamental rights impact assessment (Art. 27)
  • Special rule for financial institutions (Art. 26)
app.simpleact.de

AI register

Demo Organisation GmbH · retail banking

A
SystemClassification
  • Credit scoring for instalment loansPurchased, proposal for the credit decisionHigh-risk
  • Fraud detection for card paymentsAnnex III 5(b) excludes fraud detectionExcluded
  • Service chat in the banking appOwn front end on a language modelTransparency
  • Video ident during onboardingBiometric verification, service providerDepends on use

Sample data · simplified classification, check the actual use

In short

AI used to assess the creditworthiness of natural persons and for risk assessment and pricing in life and health insurance is high-risk under Annex III points 5(b) and (c); systems for detecting financial fraud are excluded. Deployers of such systems need a fundamental rights impact assessment before first use (Art. 27). The high-risk obligations apply from 2 December 2027.

Context

Why the EU AI Act hits financial services in particular

The AI Act (Regulation (EU) 2024/1689) classifies AI systems by their intended purpose. For financial services the result is clearer than in almost any other sector: under the heading "access to and enjoyment of essential private services and essential public services and benefits", Annex III point 5 expressly names creditworthiness assessment and credit scoring of natural persons (point (b)) and risk assessment and pricing in relation to natural persons for life and health insurance (point (c)).

The reason is obvious: whether someone gets a loan, can pay for something in instalments or obtains affordable health insurance shapes their life chances. Errors or bias in a scoring model can systematically disadvantage whole groups. The regulation therefore requires the full high-risk programme for these systems – from the provider’s risk management to human oversight and the deployer’s fundamental rights impact assessment.

The carve-out is just as clear: Annex III point 5(b) expressly excludes AI systems used for the purpose of detecting financial fraud. Fraud and anomaly detection in payments is therefore not high-risk merely because of this use case. The exact boundary matters, though: a model that also assesses a person’s ability to pay alongside fraud patterns and feeds into the credit decision is no longer a pure fraud system.

Most banks, savings banks, insurers and fintechs are deployers of these systems: they use a scoring or pricing system from a provider. Anyone who develops the model themselves or offers it under their own brand – a scoring service or a fintech with its own model, for instance – is the provider and carries the more extensive obligations under Art. 16. Often an institution is both: deployer of purchased solutions and provider of models built in-house.

For financial institutions, the regulation links directly to supervisory law. Under Art. 26(5), the deployer’s duty to monitor the operation of a high-risk system is deemed fulfilled for financial institutions that comply with the rules on internal governance arrangements, processes and mechanisms under the relevant financial services law. Under Art. 26(6), they keep logs as part of the documentation kept under that law. All other deployer obligations remain.

In terms of timing, the Digital Omnibus (Regulation (EU) 2026/1744, in force since 27 July 2026) moved the high-risk obligations for Annex III to 2 December 2027. The prohibitions under Art. 5 and the duty to take AI literacy measures under Art. 4 already apply, and since 2 August 2026 so do the transparency duties under Art. 50 – for chatbots in the banking app, for example. Breaches of deployer obligations under Art. 26 can be fined up to €15 million or 3% of worldwide annual turnover (Art. 99(4)).

This page classifies the typical AI systems in the sector, explains the high-risk cases under points 5(b) and (c), the fundamental rights impact assessment and the special rules, and leads, via a short check, to the obligations likely to apply to you. We describe how the AI Act relates to DORA and banking supervision only in general terms – for supervisory questions, involve your specialists.

Creditworthiness and life and health insurance are high-risk use cases under Annex III
5(b)/(c)
Creditworthiness and life and health insurance are high-risk use cases under Annex III
Obligations for high-risk AI under Annex III apply (Digital Omnibus)
2 Dec 2027
Obligations for high-risk AI under Annex III apply (Digital Omnibus)
or 3% of turnover: fine ceiling for breaches of Art. 26, among others (Art. 99(4))
€15m
or 3% of turnover: fine ceiling for breaches of Art. 26, among others (Art. 99(4))

More on high-risk AI

All Annex III areas and the full list of obligations are on dedicated pages.

Typical AI systems

Which AI systems are typical in fintech and banking – and how are they classified?

The table shows common AI applications at banks, payment providers, lending platforms and insurers, with the role institutions usually take and the classification that often applies. The specific intended purpose of the system is always decisive.

  • Creditworthiness assessment and credit scoring of retail customers

    High-risk

    Deployer; provider for own model · Annex III 5(b)

    Named explicitly. Because scoring is regularly profiling, the Art. 6(3) exemption usually does not apply. Deployers need a fundamental rights impact assessment.

  • Scoring of self-employed people and sole traders

    High-risk

    Deployer / provider · Annex III 5(b)

    Self-employed people and sole traders are natural persons too. Draw the line to corporate banking carefully.

  • Rating of companies (legal persons)

    Depends on use

    Deployer / provider · Annex III 5(b)

    Point 5(b) covers natural persons. If data on shareholders or guarantors as individuals is used, the picture may differ.

  • Fraud detection for payments, cards and account opening

    Excluded

    Deployer · Annex III 5(b)

    Systems for detecting financial fraud are excluded from 5(b). If the same model also assesses ability to pay, the carve-out does not cover that part.

  • Anti-money-laundering monitoring and sanctions screening

    Depends on use

    Deployer · Art. 6, Annex III

    Not named as a separate case in Annex III. Check and document the classification based on the design; anti-money-laundering obligations remain unaffected.

  • Risk assessment and pricing in life and health insurance

    High-risk

    Deployer; provider for own model · Annex III 5(c)

    Named explicitly, in relation to natural persons. Deployers need a fundamental rights impact assessment.

  • Pricing in property, motor or liability insurance

    Depends on use

    Deployer / provider · Annex III 5(c)

    Point 5(c) only names life and health insurance. Other lines are not covered by Annex III for that reason alone – data protection and non-discrimination rules still apply.

  • Video ident and biometric verification at onboarding

    Depends on use

    Deployer · Annex III 1(a)

    Biometric verification whose sole purpose is to confirm a person’s identity is excluded from remote identification under 1(a). Art. 9 GDPR applies to biometric data.

  • Service chatbot, voice assistant, AI adviser in the app

    Transparency

    Provider or deployer · Art. 50(1)

    Customers must be told they are interacting with an AI unless that is obvious. The duty lies with the provider of the system.

  • Generated customer letters, reports and marketing texts

    Transparency

    Deployer · Art. 50(2) and (4)

    Marking duty for the provider of the generating system; disclosure duties for deepfakes and certain published texts for the deployer.

  • Candidate pre-selection and performance evaluation in-house

    High-risk

    Deployer · Annex III 4

    Banks are employers too. HR systems that rank candidates or evaluate staff are high-risk; inform workers’ representatives beforehand.

  • Internal assistants for research, document analysis and code

    Minimal

    Deployer · Art. 4

    Usually no specific duties. AI literacy, usage rules, data protection and outsourcing and third-party risk matter most.

Simplified, non-exhaustive overview. "Common classification" means: this is often the case, but not always. The intended purpose and design in the individual case are decisive; document your classification per system.

Focus areas for financial services

The four points where the obligations are decided

Creditworthiness with the fraud carve-out, insurance, the fundamental rights impact assessment and the special rules for financial institutions.

01Annex III 5(b)

Creditworthiness and credit scoring – and the carve-out for fraud detection

AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score are high-risk. That covers classic scorecards built with machine learning as well as models that analyse account transactions, payment behaviour or alternative data to help decide on credit, limits, instalments or buy-now-pay-later.

AI systems used for the purpose of detecting financial fraud are excluded. The carve-out depends on purpose: a system that detects fraudulent transactions, identity theft or account takeovers does not fall under point 5(b). Recommendation: for every fraud system, document what it is intended for and that its outputs do not feed into credit scoring – otherwise the carve-out is hard to evidence.

The Art. 6(3) exemption for systems without significant risk rarely helps with credit scoring. Among other things, it does not apply where the system performs profiling of natural persons – and credit scoring is regularly exactly that. Anyone relying on the exemption anyway must document the assessment and still register the system.

02Annex III 5(c)

Life and health insurance: risk assessment and pricing

AI systems intended to be used for risk assessment and pricing in relation to natural persons in the case of life and health insurance are high-risk as well. This covers, for example, models that analyse health information, lifestyle or telematics data to decide on acceptance, risk loadings or premiums.

Point 5(c) does not name other lines such as motor, household or liability insurance. A pricing model there is not high-risk merely because of this use case. That does not mean there are no requirements: data protection, the rules on automated individual decisions in Art. 22 GDPR and non-discrimination law apply regardless of the AI Act.

Insurers working with comparison portals, brokers or managing general agents should also clarify roles: who deploys the model, who provides it and who merely passes on results determines who carries the obligations under Art. 16 and Art. 26.

03Art. 27

Fundamental rights impact assessment before first use

Deployers of high-risk systems under Annex III points 5(b) and (c) must carry out an assessment of the impact on fundamental rights before putting the system into use (Art. 27(1)). Besides public bodies and private entities providing public services, this expressly applies to these two financial use cases – so also to private banks, fintechs and insurers.

The assessment describes, among other things, the processes in which the system is used, the period and frequency of use, the categories of natural persons and groups affected, the specific risks of harm, the human oversight measures and the measures to be taken if risks materialise. The result is notified to the market surveillance authority.

A data protection impact assessment you carry out anyway under Art. 35 GDPR can complement the fundamental rights impact assessment; Art. 27(4) allows you to build on it. Recommendation: keep both in one document or at least with a shared structure, so changes to the system trigger both assessments.

04Art. 26(5) and (6)

Special rules for financial institutions – and what remains

Deployers must monitor the operation of a high-risk system on the basis of the instructions for use and inform providers and authorities of risks or serious incidents (Art. 26(5)). For financial institutions subject to requirements on their internal governance under financial services law, the monitoring obligation is deemed fulfilled by complying with those governance rules.

Similarly for logs: instead of the general rule of at least six months, financial institutions keep automatically generated logs as part of the documentation they maintain under the relevant financial services law (Art. 26(6)).

All other deployer obligations remain: use in line with the instructions, human oversight by competent people, appropriate input data, informing staff and affected persons, the data protection impact assessment and the fundamental rights impact assessment. Anyone covering monitoring through existing governance should still document the mapping – in an audit it must be clear which process covers which obligation.

Interactive check

Duty check for banks, fintechs and insurers

Answer five questions. The list then shows the obligations and recommendations that are likely to apply – with the legal reference. Tick off what is done and copy the open points as a task list. Your answers stay in your browser.

Your use
  • Do you use AI to assess the creditworthiness of natural persons?Retail customers, self-employed, buy-now-pay-later, limits
  • Do you assess or price risks in life or health insurance?Acceptance, risk loadings, premiums
  • Do you develop such a system yourself or offer it under your brand?Own scoring model, scoring as a service
  • Are you a financial institution subject to governance rules under financial supervision law?e.g. credit institution, insurance undertaking
  • Do you use chatbots or generated customer communication?Service chat, voice assistant, AI texts
For every institution using AI
app.simpleact.de

Your status

0 of 4 done

A
0 of 4 done0%

Nothing ticked yet. Answer the questions and start with the first item.

Simplified overview, not legal advice. Items marked "Recommendation" are not legal obligations. Supervisory requirements are not covered.

Deadlines

The dates that matter for financial services

The AI Act applies in stages. For banks, fintechs and insurers, the basic duties already in force, Art. 50 and the high-risk date after the Digital Omnibus matter most.

Scroll the table sideways →

The dates that matter for financial services
TopicApplies fromReference
AI Act enters into force1 August 2024Reg. (EU) 2024/1689
Prohibited practices and AI literacy2 February 2025Art. 4, 5
Obligations for GPAI model providers2 August 2025 (existing models by 2 August 2027)Art. 53, 111(3)
Transparency duties for chatbots and generated content; general application2 August 2026Art. 50, 113
New prohibitions: non-consensual intimate deepfakes, child sexual abuse material2 December 2026Art. 5 as amended
High-risk AI under Annex III 5(b) and (c) (credit, life and health insurance)2 December 2027 (previously 2 August 2026)Reg. (EU) 2026/1744
Fundamental rights impact assessmentbefore first use, once the high-risk obligations applyArt. 27(1)
Logs kept by deployersat least 6 months; financial institutions under financial services lawArt. 26(6)
All AI Act deadlines with calendar export

Interfaces

EU AI Act, DORA, banking supervision and GDPR

Financial institutions already document models, ICT risks and outsourcing today. The AI Act does not build a parallel world, but it requires AI-specific obligations to plug verifiably into existing processes. The following is deliberately general.

DORA (Reg. (EU) 2022/2554)
DORA governs digital operational resilience in the financial sector, including ICT risk management and dealing with ICT third-party service providers. For purchased AI services – scoring via API, fraud detection as a service – third-party risk under DORA and deployer obligations under the AI Act meet at the same provider. A shared register for systems and service providers avoids duplicate work.
Supervisory governance
Requirements for risk management, models and outsourcing come from supervisory law and supervisors’ expectations. Art. 26(5) and (6) of the AI Act link expressly to that governance. Decide with your compliance and risk functions which processes cover which AI obligation.
GDPR: scoring and automated decisions
Credit scoring processes personal data and can be an automated individual decision within the meaning of Art. 22 GDPR where the result plays a decisive role in the credit decision. Information duties, access rights and the right to human intervention apply alongside the AI Act.
Data protection impact assessment
For scoring and pricing, a DPIA under Art. 35 GDPR is required in many cases. It can complement the fundamental rights impact assessment under Art. 27 – plan both together.
Consumer protection and equal treatment
Non-discrimination rules and requirements for consumer lending apply regardless of the AI Act classification. Data governance and bias testing under Art. 10 help evidence both.

Not legal advice: for supervisory questions on DORA, model risk and outsourcing, involve your specialists. This page does not replace coordination with the competent supervisor.

Approach

Six steps to an AI Act roadmap for your institution

A sequence that works well in regulated firms. It is a recommendation and fits well with existing governance cycles.

  1. 1

    Inventory systems

    Record all AI systems – built in-house, purchased and used as a service. Existing model and outsourcing registers are a good starting point.

  2. 2

    Classify and delimit

    Identify credit and insurance cases under 5(b) and (c), delimit fraud systems with reasons, flag transparency cases.

  3. 3

    Clarify the role

    Decide per system whether you are deployer or provider – and whether adapting the model makes you a provider under Art. 25.

  4. 4

    Map governance

    Map existing processes for model validation, monitoring and documentation to the obligations in Art. 26 and record gaps.

  5. 5

    Prepare FRIA and DPIA

    For high-risk systems, prepare both assessments together and request the provider’s documentation.

  6. 6

    Enable people

    Train oversight staff, prepare information for applicants and staff, set up a process for explaining decisions.

Common mistakes

Where implementation stalls in financial firms

Treating a fraud model as a free pass

The carve-out covers detecting financial fraud. If the same scores feed into the credit decision, the model is credit scoring to that extent.

Forgetting the self-employed

Sole traders and freelancers are natural persons. Scoring in small-business banking can therefore fall under 5(b).

Confusing the FRIA with the DPIA

The DPIA covers data protection risks, the FRIA further fundamental rights such as non-discrimination. A DPIA can complement the FRIA but does not fully replace it.

Overstretching the special rule

Art. 26(5) and (6) ease monitoring and log retention. Oversight, informing affected persons and the FRIA remain mandatory.

Not requesting provider documents

Without instructions for use, performance information and log access, oversight, DPIA and FRIA are hard to complete. This belongs in contracts and outsourcing management.

Waiting for 2027

Model validation, data quality and documentation need lead time. Anyone offering their own scoring models should start on technical documentation now.

With SimpleAct

An AI register that fits your institution’s governance

In SimpleAct you record your AI systems in the AI inventory, set role and purpose, classify them by risk class and work through a matching compliance checklist per system. A library of 19 controls along the EU AI Act holds status and evidence links per system. You keep DPIAs and the record of processing activities in the GDPR module. SimpleAct supports the AI Act part; it does not replace supervisory reviews.

In a pilot project, six AI systems – one of them high-risk – were recorded and assessed in around four hours.

  • AI inventory with role, purpose and vendor
  • Risk classification per system
  • Compliance checklist per risk class
  • 19 controls with status and evidence links
  • DPIA and record of processing in the GDPR module (from Professional)
View the AI inventory software

FAQ

Frequently asked questions about the EU AI Act for fintech and banks

Yes, where natural persons are concerned. AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score are high-risk under Annex III point 5(b). Systems used to detect financial fraud are excluded. The obligations apply from 2 December 2027.
Not because of point 5(b): Annex III expressly excludes AI systems used for detecting financial fraud from creditworthiness assessment. Check the specific purpose, though. If the same system also assesses ability to pay or feeds into credit decisions, the carve-out does not cover that.
Annex III point 5(c) names risk assessment and pricing in relation to natural persons for life and health insurance. Other lines such as motor, household or liability insurance are not named there; for them, the AI Act does not treat pricing as high-risk merely because of this use case.
Yes, as deployers of high-risk systems under Annex III point 5(b) or (c). Art. 27 requires the assessment before putting the system into use and expressly covers private deployers of these systems. The result is notified to the market surveillance authority. An existing DPIA can be built on (Art. 27(4)).
Financial institutions subject to governance requirements under financial services law fulfil the duty to monitor the operation of a high-risk system by complying with those requirements (Art. 26(5)). They keep logs as part of their supervisory documentation (Art. 26(6)). The other deployer obligations continue to apply.
If you use a purchased system under your own authority, you are the deployer. If you develop the model yourself or offer it under your brand, you are the provider with the obligations under Art. 16. If you substantially modify a purchased high-risk system, you may become the provider under Art. 25.
No, as a rule. For high-risk systems under Annex III points 2 to 8 – which include point 5 – Art. 43 provides for conformity assessment by internal control under Annex VI. The conformity assessment is the provider’s task.
Deployers must inform people when a high-risk system under Annex III makes or assists decisions about them (Art. 26(11)). Anyone affected by a decision based on such a system with legal or similarly significant effects can request a clear and meaningful explanation under Art. 86. GDPR rights apply alongside.
In general terms: DORA governs ICT risk management and ICT third-party providers in the financial sector, the AI Act the AI-specific obligations. For purchased AI services, both meet at the same provider. A shared register for AI systems and service providers helps. For the exact delimitation, involve your supervisory law specialists.
For breaches of deployer obligations under Art. 26, provider obligations under Art. 16 and transparency duties under Art. 50, up to €15m or 3% of worldwide annual turnover; for prohibited practices, up to €35m or 7% (Art. 99). For SMEs, including start-ups, the lower amount applies (Art. 99(6)). Since the Digital Omnibus, this also applies to small mid-caps (Art. 3(14b)), but only for fines under paragraphs 4 and 5 (Art. 99(6a)).

More questions? We're happy to help. Send email · Get started

Sources and status

Last reviewed on · SimpleAct editorial team

This page and the duty check are a simplified overview and not legal or supervisory advice. The wording of Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744 is authoritative. The remarks on DORA and banking supervision are deliberately general. Examples, classifications in the table and items marked as recommendations are not a binding assessment.

Changes to this page

  • 6 October 2026 – Rebuilt: table of typical AI systems with classification, point 5(b) with the fraud carve-out, point 5(c), fundamental rights impact assessment, special rules under Art. 26(5) and (6), interactive duty check, deadlines after the Digital Omnibus, sources.
  • 8 July 2026 – Short version with use cases, DORA notes and FAQ.

Related topics

Scoring, fraud detection and chatbots in one register

AI inventory, classification, checklist and evidence in one place – aligned with your existing governance.

Book a demoTry 7 days free