Annex III Section 5 of the EU AI Act classifies AI used for consumer credit scoring and life/health insurance pricing as high-risk. Banks, lenders, fintech companies, and insurers using or building these systems have binding obligations before August 2, 2026 — whether they built the AI themselves or buy it from a vendor.
The EU AI Act does not classify all financial services AI as high-risk — it targets two specific, high-stakes decisions about individuals: whether to extend credit to them, and what to charge them for life or health insurance. These are decisions with material consequences for people's lives and financial wellbeing, which is why the Act singles them out.
AI systems intended to evaluate the creditworthiness of natural persons or establish their credit score. Does NOT include AI used for fraud detection — fraud AI is explicitly carved out.
In scope — examples
Explicitly excluded or outside scope
AI systems intended for risk assessment and pricing decisions in relation to natural persons in the case of life insurance and health insurance.
In scope — examples
Explicitly excluded or outside scope
The scope of Annex III 5 is narrower than many financial services firms assume. Several major categories of financial AI fall entirely outside the high-risk classification:
| AI system | Why NOT in Annex III |
|---|---|
| AI fraud detection / AML screening | Explicitly excluded from Annex III 5(a). Still subject to other regulatory frameworks (PSD2, AMLD). |
| Algorithmic trading / quantitative models | Trading algorithms and investment management AI are not listed in Annex III. Covered separately under MiFID II. |
| Business credit scoring (SME or corporate) | Annex III 5(a) covers natural persons only. B2B credit risk AI is outside scope. |
| Property, motor, or contents insurance AI | Annex III 5(b) covers life and health insurance only. General insurance pricing AI is not in scope. |
| Customer service chatbot for banking | No creditworthiness or insurance pricing decision. Still requires Article 50 chatbot disclosure. |
| Internal capital adequacy modelling (Basel III/IV) | Regulatory capital models used internally by the bank, not to make decisions about individual consumers. |
| AI-powered personal finance aggregator / budgeting tool | Displaying account data and budgeting advice does not evaluate creditworthiness or set insurance premiums. |
Even where the EU AI Act high-risk classification does not apply, other obligations may: Article 50 transparency requirements for customer-facing AI chatbots, Article 4 AI literacy for all companies using AI, and sector-specific regulation such as MiFID II, DORA, and EBA guidelines on internal model governance.
Financial services firms often sit in both roles simultaneously — and many underestimate their provider obligations by assuming they are simply a customer of their AI vendor.
Provider obligations are significantly heavier: Annex IV documentation, risk management system, conformity assessment, CE marking, EU database registration, and post-market monitoring.
Deployer obligations are lighter but still enforceable: human oversight, customer notification, explanations on request, log retention. The six obligations are below.
The Article 28 trap for fintechs
Under Article 28(1)(b), a deployer becomes a provider if they place the AI system on the market under their own name or brand, modify its intended purpose substantially, or make a substantial modification to the system. A fintech that takes a credit scoring API and trains it further on their own loan book data, or uses it in a way the original provider did not document as an intended use case, may find they have crossed into provider territory — with all the additional obligations that entails. If in doubt, review your API licence agreement and the provider's instructions for use carefully.
Fintech lenders and insurtech firms that have built their own credit scoring or insurance pricing models are providers under the EU AI Act. These seven obligations apply before placing the system on the market and on an ongoing basis. They are significantly more demanding than deployer obligations.
Providers of high-risk AI systems must maintain an ongoing risk management system — not a one-time assessment. For credit scoring AI, this means iterative testing for bias, discriminatory proxies (e.g., postcode as a proxy for ethnicity), and performance degradation over time. For insurance pricing AI, it includes monitoring whether protected characteristics are being inferred through correlated variables.
Training, validation, and test datasets must be relevant, representative, and free of errors. For financial services AI, this has specific bite: historical lending data often reflects past discriminatory practices. You must examine datasets for biases related to protected characteristics under EU anti-discrimination law and document how you addressed them.
Providers must maintain an Annex IV technical document covering: system description and intended purpose, design choices and logic, training data and methodology, validation and testing results, known limitations and risks, and post-deployment monitoring arrangements. For a credit scoring model, this must be sufficient to allow a regulator to assess conformity.
High-risk AI systems must generate logs of their operation automatically. For a credit scoring engine, this means logging each decision event — what inputs were provided, what score or output was generated, and when. These logs support both regulatory review and the consumer explanation rights under Article 26(6).
The system must be designed so that deployers can understand its outputs and intervene. For credit scoring, this means providing interpretable output (a score plus the key factors driving it), not a black-box decision. Deployers need to be able to override the AI decision — the system design must make that practically possible.
Before placing a high-risk credit scoring or insurance AI system on the market, providers must complete a conformity assessment (self-assessment via Annex VI for most financial AI), draw up a declaration of conformity, affix CE marking, and register the system in the EU AI Act database before or at market launch. The database registration is publicly accessible.
Once deployed, providers must monitor system performance against declared metrics. If a serious incident occurs — for example, a credit scoring model is found to discriminate systematically against a protected group — it must be reported to the relevant national market surveillance authority within 15 working days for serious incidents.
Even if you did not build the credit scoring or insurance AI system, you have six binding obligations as a deployer under Article 26. These cannot be delegated to your vendor. "Our provider is compliant" does not satisfy your own obligations.
Do not use a credit scoring AI for purposes its provider has not documented — for instance, using a consumer mortgage scoring engine to evaluate SME loan applications. If your use case is not covered by the provider's instructions for use, you need to determine whether using it that way makes you a provider under Article 28.
You must designate specific individuals — with sufficient competence and authority — to perform human oversight of the credit or insurance AI. These individuals must be able to meaningfully review AI outputs, understand the factors driving a decision, and override the AI when appropriate. "A human sees it before it's actioned" is not enough; they must be capable of exercising real judgement.
If you supply data to a third-party AI system (e.g., providing a credit bureau with your customers' transaction history to generate a score), you are responsible for the quality and relevance of that input. You cannot outsource responsibility for discriminatory or irrelevant data to your vendor.
This is the most commercially significant obligation for consumer-facing financial services. Deployers must: (a) inform natural persons that they are subject to an AI-based credit or insurance decision; (b) on request, provide a meaningful explanation of the factors that led to the decision — including how the AI reached its output and what the main factors were. This supplements (and may go further than) GDPR Article 22 rights for automated decisions.
Where the AI system automatically generates logs, you must retain them for at least 6 months from each use of the system. For credit and insurance decisions, this log record should align with your existing record-keeping obligations under financial regulation — but check that your vendor's log format captures what you need for an AI Act regulatory review.
If you have reason to believe that the AI system does not conform to the EU AI Act — for example, because the provider cannot produce the Annex IV documentation, or because an audit reveals systematic bias — you must suspend its use, inform the provider, and notify the relevant market surveillance authority. Continuing to use a known non-compliant credit scoring system is itself a regulatory violation.
Article 26(6) gives consumers the right to an explanation of any AI-assisted decision that significantly affects them. For credit and insurance, this is directly actionable: a consumer who is declined credit, offered a higher rate, or quoted a higher premium based on AI output can ask you to explain why.
The explanation must be meaningful at the individual level — not a generic description of how your model works. It should cover the main factors that influenced the AI output for their specific application: for credit, this might be payment history, existing debt-to-income ratio, and length of credit history; for insurance, the health or lifestyle variables that drove the premium.
Practical implications:
This table summarises how common financial services AI systems typically map to the EU AI Act. The actual classification depends on how the system is used — always verify with your own legal team for your specific context.
You have provider AND deployer obligations. Most onerous path: requires Annex IV documentation, risk management system, conformity assessment, EU database registration, and all deployer obligations.
Experian/Equifax is the provider. You are a deployer: implement human oversight, inform customers, provide explanations on request, retain logs.
Request Annex IV documentation and CE declaration from the vendor. Implement your own deployer obligations. If the vendor cannot provide documentation, you may need to suspend use.
Your BNPL eligibility model is evaluating consumer creditworthiness. You are a provider: Annex IV documentation, risk management, conformity assessment, and registration required.
If the tool evaluates whether a natural person qualifies for a mortgage — not just calculates affordability from declared income — it likely falls under Annex III 5(a). Confirm scope with your legal team.
You are a deployer of a high-risk AI system under Annex III 5(b). Request provider documentation, inform policyholders, implement oversight.
Explicitly excluded from Annex III 5(a). No EU AI Act high-risk obligations. Covered by PSD2, AMLD, and other financial regulation separately.
Trading algorithms are not listed in Annex III. MiFID II, EMIR, and MAR apply. No EU AI Act high-risk classification for typical trading AI.
Financial services firms are already subject to substantial regulation. The EU AI Act adds to, rather than replaces, that landscape — and several existing frameworks have significant overlap.
Both GDPR Article 22 and the EU AI Act protect individuals from automated decision-making. GDPR gives data subjects the right not to be subject to automated decisions with significant effects and requires an explanation and human review right. The EU AI Act adds system-level obligations (documentation, conformity assessment, registration) that GDPR does not. They run in parallel: full GDPR Article 22 compliance does not satisfy EU AI Act obligations, and vice versa.
The European Banking Authority has published guidance on model risk management and the use of machine learning in credit risk models. EBA guidelines already require model validation, documentation, and governance that overlaps significantly with EU AI Act Article 9–13 obligations. Firms with mature EBA-compliant model governance frameworks have a head-start — but check that your EBA documentation covers the specific Annex IV requirements for the EU AI Act.
DORA requires financial entities to manage ICT risk, including third-party technology risk. An AI vendor who provides your credit scoring API is a third-party ICT provider under DORA. Ensure your contractual arrangements with credit AI vendors address both DORA requirements (resilience, audit rights, incident reporting) and EU AI Act requirements (Annex IV documentation, CE declaration, instructions for use).
Both directives already require lenders to explain credit decisions to consumers and to use responsible underwriting. The EU AI Act's explanation rights for AI-assisted decisions align with and reinforce these requirements. If you already have a process for adverse action notices under consumer credit law, extend it to cover the AI-specific explanation elements the Act requires.
Map your credit and insurance AI systems
Inventory every AI system involved in consumer credit decisions (approval, pricing, limits) or life/health insurance pricing. For each: who built it (provider), who uses it (deployer), and whether you are one or both.
Determine your role for each system
For third-party AI: contact vendors and request their EU AI Act status — specifically whether the system is CE-marked, registered in the EU database, and whether they can provide Annex IV documentation. For in-house AI: begin the provider compliance process now — risk management system, Annex IV documentation, and conformity assessment are multi-month workstreams.
Build or enhance your explainability capability
For every credit or insurance AI system, confirm you can generate a per-decision explanation of the factors that influenced the output. If you cannot, either build that capability into your model (SHAP values, LIME, or similar) or work with your vendor to ensure their system provides it. A black-box model that cannot explain individual decisions is non-compliant.
Update customer-facing communications
Add disclosure of AI use to credit application journeys, insurance quote flows, and adverse action notices. Add a process for customers to request an explanation of AI-assisted decisions. Update your privacy notice to reference AI-based decision-making alongside GDPR Article 22 rights.
Designate human oversight roles and document them
For each high-risk AI system, assign a named individual (or role) responsible for reviewing AI outputs before or after decisions. Document the oversight process: what the reviewer looks at, how they can override the AI, and when to escalate. Keep records of human oversight for at least 6 months.
No. Annex III Section 5(a) explicitly covers AI systems that evaluate the creditworthiness of natural persons or establish their credit score. Business credit assessment — scoring an SME, a limited company, or a partnership — falls outside this provision. If you are a lender that does both consumer and SME credit, only your consumer-facing credit AI is in scope for Annex III 5(a).
No — fraud detection AI is explicitly carved out of Annex III 5(a). The provision reads "with the exception of AI systems used for the purpose of detecting financial fraud." This is a deliberate exclusion: requiring heavy conformity obligations for fraud systems could impair their effectiveness. Fraud and AML AI remain subject to PSD2, the Anti-Money Laundering Directives, and other financial regulation, but not to the EU AI Act high-risk classification.
Existing high-risk AI systems already on the market when the Act applies get a transitional period — but that period ends. Under the EU AI Act, existing high-risk systems that continue to be used must comply with the relevant obligations. The precise transitional provisions for AI systems already on the market distinguish between "placed on the market" and "put into service" dates, and there are transitional provisions that may give providers additional time for systems that were already CE-marked under other EU product legislation. If you have an older model, assess it against the Act's requirements now and plan remediation — don't assume age is a defence.
You are a deployer. The company that developed and placed the credit scoring API on the market is the provider — they have the Annex IV documentation, risk management, and conformity assessment obligations. Your obligations are the Article 26 deployer duties: use as intended, human oversight, inform customers, provide explanations on request, retain logs, and suspend if non-compliant. However, if you materially customise the API's model using your own training data, or if you repurpose it for a use case not covered by the provider's instructions for use, you may become a provider under Article 28.
Under Article 26(6), when a deployer uses a high-risk AI system to make or assist in decisions concerning a natural person, the deployer must inform that person they are subject to the AI system. On request, the deployer must provide a "meaningful explanation of the individual-level rationale" behind the decision — not just a generic statement about the model. For credit: if a consumer asks why their application was declined, you need to be able to tell them what factors the AI weighted heavily (e.g., payment history, credit utilisation, length of credit history) and how those led to the output. This reinforces and extends the GDPR Article 22 explanation right for automated decisions. Make sure your provider's system can generate per-decision explanations — if it is a true black box that cannot explain its outputs, this is a fundamental compliance problem.
GDPR Article 22 gives individuals the right not to be subject to a decision based solely on automated processing that significantly affects them — which fully automated credit decisions typically are. Under GDPR, data subjects can request human review, contest the decision, and receive an explanation. The EU AI Act's Article 26(6) explanation and notification requirements operate alongside GDPR Article 22, not instead of it. Both frameworks apply simultaneously. The practical effect: automated credit decisions need both a GDPR-compliant basis for automated processing and separate EU AI Act compliance. If you already have robust GDPR Article 22 processes for credit decisions, you have a head-start — but the AI Act adds obligations your GDPR programme does not cover (human oversight designation, log retention, provider documentation review).
Yes, if you are a deployer or provider of AI systems that are used in decisions affecting consumers in the EU, or if you place AI systems on the EU market. The EU AI Act has the same extraterritorial reach as GDPR: where the output of an AI system is used within the EU, the Act can apply regardless of where the provider or deployer is based. UK banks with EU branches, subsidiaries, or customers offering credit products in the EU should assess their position carefully. The UK has not yet enacted equivalent national legislation, but the EU Act's extraterritorial scope means it may apply directly.
Use the free EU AI Act risk classifier. Answer 5 questions about your AI system and get a clear classification — Prohibited, High-Risk, Limited Risk, or Minimal Risk — with your specific obligations listed.
Classify your financial AI system — free