EU AI Act compliance for credit scoring & lending AI

AI used to evaluate creditworthiness or set credit scores for individuals is high-risk under the EU AI Act — outside of fraud detection. The obligations are extensive and documentation-heavy.

AI that evaluates the creditworthiness of a natural person, or establishes their credit score, is high-risk under Annex III point 5(b). The category is narrower than it looks in one direction and wider in another: it is about scoring people rather than companies, and the Act carves out one use by name — systems whose purpose is to detect financial fraud are not caught by this point.

Why it is in scope

Annex III(5)(b) lists creditworthiness assessment and credit scoring of natural persons as high-risk, given the impact on access to essential financial services.

What this does not trigger

Point 5(b) is narrower than everything a lender runs. Fraud detection is carved out by name. Anti-money-laundering screening, transaction monitoring, and pricing models that never assess an individual's creditworthiness fall outside it, as does scoring a company on its own financial statements. What decides the question is whether the output is an assessment of a natural person's creditworthiness, or a credit score for that person.

Provider or deployer?

Banks, lenders and fintechs are usually deployers of a scoring engine and providers of the models they build in house. That distinction decides who owes the Annex IV technical file. It decides nothing about Article 27: the fundamental rights impact assessment attaches to the deployer of a point 5(b) system whether or not it is a public body — Recital 96 names banking and insurance entities directly.

Key obligations

• Risk management system (Article 9)
• Data governance and bias mitigation on training data (Article 10)
• Annex IV technical documentation (Article 11)
• Accuracy, robustness, and cybersecurity (Article 15)
• Human oversight (Article 14)
• Conformity assessment and EU database registration (Articles 43, 49)
• Fundamental rights impact assessment before first use (Article 27)

What this looks like in practice

• A model that outputs a probability of default used to accept, reject or price a consumer loan is the core case — it is caught because it evaluates creditworthiness, whatever decision it then feeds. Point 5(b) does not name pricing as such, while point 5(c) does for life and health insurance, so a pricing engine that only applies a rate grid to a score produced elsewhere is not itself inside point 5(b).
• Scoring a sole trader is scoring a natural person, so it sits squarely in point 5(b). An incorporated micro-enterprise does not, even where the model reads the director's personal data — the test is whose creditworthiness the system is intended to evaluate, not whose data it consumes. Score the director personally, for instance behind a personal guarantee, and you are back inside.
• Fraud detection is carved out of point 5(b): a system whose purpose is to flag fraudulent transactions is not high-risk on that ground. Purpose is what counts — a fraud model repurposed to inform credit limits stops being a fraud model.
• Buy-now-pay-later underwriting is creditworthiness assessment however short the term. The category is defined by what the model assesses, not by the size or the duration of the credit.
• A challenger model run in shadow mode beside a production scorer is still a high-risk system if it is put into service for that purpose. Testing in real-world conditions has its own regime under Article 60; running a second model quietly is not a way around classification.

Where SMEs get this wrong

• Treating the Article 27 fundamental rights impact assessment as optional. For point 5(b) deployers it is mandatory, it must be done before first use, and its result must be notified to the market surveillance authority.
• Assuming an existing GDPR data protection impact assessment is enough. Article 27(4) lets you build on a DPIA where one exists, but the fundamental-rights analysis complements it — it does not replace it.
• Documenting the model but not the data. Article 10 is about the training, validation and testing sets: their provenance, their relevance, their gaps, and the examination for bias. This is where credit files are usually thinnest.

What actually proves compliance

Expect to show the Article 9 risk-management records across the lifecycle, the Article 10 data-governance evidence including the bias examination, the Annex IV technical file, the Article 14 human-oversight design and — as a deployer — the Article 26(2) record of the named people to whom oversight is assigned, with their competence, training and authority, the Article 15 accuracy, robustness and cybersecurity evidence, and the Article 27 assessment together with the notification to the authority.

What getting it wrong costs

Credit-scoring systems are Annex III high-risk, so breaches of the provider duties in Article 16 or the deployer duties in Article 26 sit in the Article 99(4) band: up to EUR 15 million or 3% of total worldwide annual turnover, whichever is higher. Article 27 is not in that list — failing to carry out or notify the fundamental rights impact assessment is penalised under the national rules Member States lay down under Article 99(1), not under the harmonised 3% band. Article 99(6) caps fines for SMEs and start-ups at whichever of the two is lower across the (3), (4) and (5) bands, and the Digital Omnibus added Article 99(6a) giving small mid-caps that lower-of ceiling for the (4) and (5) bands. Supplying incorrect, incomplete or misleading information to a notified body or a national competent authority in reply to a request is its own band under Article 99(5): up to EUR 7.5 million or 1%, whichever is higher.

When it applies

Annex III obligations apply from December 2, 2027 after the Digital Omnibus reschedule. Credit files are among the slowest to assemble, because the data-governance evidence has to be reconstructed from how the model was actually trained rather than written from scratch.

Questions we get asked

Does this cover business lending?

Point 5(b) is about natural persons, so lending to a company sits outside it. But if you score the director or the sole trader personally, the assessment is of a natural person and you are back inside. The test is whose creditworthiness is being evaluated, not what the loan is for.

Our score is only one input; a credit officer makes the decision.

That does not take the system out of Annex III. Article 6(3) can drop a listed system out of high-risk where it only performs a narrow procedural or preparatory task and does not materially influence the outcome — but it never applies to a system that profiles natural persons, and a credit scorer always does. Human involvement is what Article 14 requires of you; it is not an exit from the regime.

We buy the score from a credit bureau. Who does what?

The bureau is the provider and owes the technical documentation, the conformity assessment and the registration. You are the deployer: the Article 26 duties, plus the Article 27 fundamental rights impact assessment. Responsibility for it stays yours and cannot be transferred by contract — though Article 27(2) lets you rely, in similar cases, on an existing impact assessment already carried out by the bureau.

When exactly does the Article 27 assessment have to be done?

Before the first use of the system. It is a prior obligation, not an annual review, though it must be updated when any of its inputs change. The deployer notifies the market surveillance authority of the result using the template the AI Office provides. Where a GDPR data protection impact assessment already exists, Article 27(4) lets the fundamental-rights assessment complement it rather than repeat it.

Check the law yourself

• Regulation (EU) 2024/1689 — consolidated text
• Regulation (EU) 2026/1744 — Digital Omnibus on AI