AI Credit Scoring Under the EU AI Act: High-Risk, Hard Obligations, and the Fraud-Detection Line

A lender's AI model predicts whether an applicant will repay a loan. That system is high-risk under the EU AI Act. A different model at the same lender flags suspicious transaction patterns for fraud investigation. That system is not. One word separates them in Annex III — and getting that distinction wrong will define whether you face the full high-risk obligation stack or none of it.

Why creditworthiness AI is high-risk

Annex III, point 5(b) of Regulation (EU) 2024/1689 lists as high-risk any AI system "intended to be used to evaluate the creditworthiness of natural persons or establish their credit score." The rationale is structural: credit decisions are access decisions. Approval opens the door to housing, business formation, and financial resilience. Denial closes those doors. When an algorithm makes or heavily shapes that call, the potential for discriminatory exclusion — at scale, opaquely — is exactly what the Act was designed to address.

Two features make creditworthiness AI particularly dangerous from a fundamental-rights perspective. First, machine-learning models trained on historical lending data absorb the discriminatory patterns of past decisions. A model built on thirty years of lending data from a bank that historically approved fewer mortgages in certain postcodes will learn to replicate that pattern, even if the postcode variable is removed. Proxy variables — income volatility, utility-payment history, employer type — carry the same signal. Second, many high-performing credit models are black boxes in the technical sense: gradient-boosted ensembles or neural networks that cannot tell an applicant why they were declined in terms a human can act on. Article 13's transparency requirement and GDPR Article 22's right to explanation both press directly on this gap.

The Article 6(3) filter exists: a provider can self-assess that their Annex III system does not pose a significant risk of harm and escape the high-risk tier, provided they document the assessment and register the system under Article 49. For creditworthiness models, that exit is almost never available. Any system that profiles natural persons is always high-risk under the Act, and scoring an individual's probability of default is precisely profiling.

The fraud-detection carve-out: a hard line, not a grey area

Annex III, point 5(b) contains an explicit exception: AI used to detect financial fraud is not high-risk on this basis. The logic is clean. A fraud-detection model asks whether a transaction or application is anomalous relative to known fraud patterns. Its output triggers additional human review, not a credit decision. It does not determine whether a person gets access to credit.

A creditworthiness model asks a different question: will this person repay? Its output directly influences whether a loan is granted, at what rate, and on what terms. That is a decision about access to an essential financial service.

In practice, some lenders deploy both in the same pipeline — fraud screening before creditworthiness scoring. The fraud-screening component sits outside Annex III point 5(b). The creditworthiness-scoring component does not. If your vendor sells you a single model that claims to do both simultaneously, be cautious: the intended purpose of the system governs its classification, and a model whose primary design purpose is to evaluate repayment likelihood does not become non-high-risk because it also catches fraud signals.

Provider obligations: what the scoring-model vendor must do

Under the Act, a provider (Article 16) is the organisation that develops and places a high-risk AI system on the market or into service under its own name. For credit scoring, the provider is typically the fintech or analytics company supplying the scoring model — whether sold as a standalone product, embedded in lending software, or delivered via API.

Provider obligations run deep:

Article 9 — Risk management system. The provider must establish, implement, document, and maintain a risk management system throughout the model's lifetime. For a credit-scoring model, this means identifying discrimination risks (disparate impact across gender, age, ethnicity, disability), data-quality risks (biased or unrepresentative training data), and model-drift risks (the model degrading as population characteristics shift). Every identified risk needs a probability/severity assessment and documented mitigation. The risk management system is not a one-time exercise; it runs continuously.

Article 10 — Data and data governance. Training, validation, and testing datasets must be relevant, representative, free of errors, and complete. Providers must document data sources, collection methodology, and quality-assurance procedures. For credit models, this specifically requires demographic stratification: testing whether the data over- or under-represents groups protected under the EU Charter, and correcting imbalances before training.

Article 11 — Technical documentation (Annex IV). Before the system goes to market, providers must compile a technical documentation package that covers system design, architecture, training methodology, performance metrics across demographic groups, risk-assessment results, and human-oversight procedures. This documentation must be sufficient for a competent authority to assess compliance. It is the evidentiary foundation for the conformity assessment.

Article 13 — Transparency to deployers. The provider must supply instructions for use that tell deployers what the system does, its known limitations, the conditions under which it performs reliably, and what human oversight it requires. Deployers cannot meet their own obligations without accurate information from the provider.

Article 15 — Accuracy, robustness, cybersecurity. The system must achieve appropriate levels of accuracy and consistency. For credit scoring, this requires documented performance across cohorts — not just aggregate accuracy, but performance disaggregated by demographic group. A model that is 92% accurate overall but 78% accurate for applicants from a particular region has a robustness problem.

Article 43 — Conformity assessment. Before the system is placed on the market, the provider must complete a conformity assessment. For most high-risk systems outside regulated product sectors, this is an internal control procedure under Annex VI — but "internal" does not mean light. The provider must methodically verify that every requirement in Articles 9–15 has been met and document the results. The output feeds the Article 49 registration and the Article 47 EU Declaration of Conformity.

Article 49 — Registration in the EU database. High-risk AI systems must be registered in the EU AI Act public database before deployment. For providers claiming the Article 6(3) exemption, a separate register entry is required even for systems not classified as high-risk.

Deployer obligations: what the lender or bank must do

A deployer (Article 26) is the organisation using the scoring model in its operations — the bank, credit union, consumer-finance company, or BNPL provider. Deployer obligations are lighter than provider obligations, but they are not light.

Article 26 — Deployer duties. Deployers must use the system in accordance with the provider's instructions for use; assign human oversight to qualified staff; monitor the system's operation; and — where the provider has not already done so — inform the competent authority of serious incidents under Article 73. Deployers must also inform affected workers where the system is used in employment contexts (less relevant here, but applicable if the lender uses AI for staff-related decisions alongside credit decisions).

Article 14 — Human oversight. This is the obligation that bites in practice. The deployer must ensure that natural persons with appropriate competence, authority, and resources can intervene and override the system's output. For a credit decision, this means loan officers must have genuine authority — documented, not just nominal — to approve applicants the model rejects. They must receive training on the system's capabilities, its known limitations, and how to recognise signs of bias or malfunction. Override rates by demographic group are a key monitoring signal: systematic over-representation of one group in override approvals suggests the model is producing biased outputs that human reviewers are correcting post hoc.

Article 27 — Fundamental Rights Impact Assessment (FRIA). This obligation applies specifically to deployers of high-risk AI systems in areas listed in Annex III that involve access to essential private or public services. Creditworthiness assessment falls squarely in that category. The deployer — the lender, not the model vendor — must carry out a written FRIA before putting the system into use, assessing risks to fundamental rights, documenting mitigation measures, and notifying the relevant market surveillance authority. This is not the conformity assessment (that is Article 43, the provider's obligation). The FRIA is a separate deployer-specific exercise. Many lenders overlook it because they assume the vendor's conformity work covers it. It does not.

Article 12 / Article 73 — Record-keeping and incident reporting. Deployers must keep logs of the system's operation where it is within their control, and report serious incidents — including systematic discriminatory outcomes — to the relevant national authority.

The GDPR dimension: Article 22 and the right to explanation

The EU AI Act sits alongside, not above, GDPR. GDPR Article 22 gives data subjects the right not to be subject to a decision based solely on automated processing that produces legal or similarly significant effects. A fully automated credit decision — one where no human reviews the output before the approval or rejection letter goes out — is potentially unlawful under Article 22 independently of the AI Act.

Article 22 also creates an obligation to provide the data subject with meaningful information about the logic involved. This is distinct from the AI Act's transparency requirements but points in the same direction: the applicant is entitled to understand, in accessible terms, what drove the decision. Telling a rejected applicant their "score was below threshold" satisfies neither GDPR Article 22 nor the EU AI Act's transparency requirements. A compliant explanation identifies the main factors that negatively influenced the score and, where feasible, what changes would lead to a different outcome.

Lenders operating in EU jurisdictions with active data-protection supervisory authorities — Germany, France, the Netherlands — should expect that credit-scoring complaints will be routed through both GDPR and AI Act channels simultaneously.

Worked example: a regional lender deploys a third-party scoring model

A regional bank with 12 branches sources a creditworthiness AI from a specialist fintech vendor. The vendor trained the model on pan-European lending data and delivers it as a cloud API. Here is how the obligation split lands:

The vendor (provider under Article 16) must:

• Maintain the Article 9 risk management system covering discrimination and drift risks
• Document training data demographics and quality-assurance procedures (Article 10)
• Hold the Annex IV technical documentation (Article 11) and make it available to the bank and competent authorities on request
• Complete an Article 43 conformity assessment before sale
• Register the system in the EU database (Article 49)
• Supply accurate instructions for use telling the bank how to deploy the system safely (Article 13)

The bank (deployer under Article 26) must:

• Follow the vendor's instructions for use (Article 26)
• Designate loan officers with genuine override authority and train them (Article 14)
• Carry out a written FRIA before deploying the system (Article 27) — this is the bank's obligation and cannot be outsourced to the vendor
• Monitor the system's operation and track approval rates by demographic group (Article 26, Article 72 via the vendor's post-market monitoring obligations)
• Report serious incidents — if the system produces systematically discriminatory outcomes at the bank's customer population level, that is a serious incident under Article 73

If the bank modifies the model's intended purpose — say, it adjusts the scoring threshold, retrains on its own data, or adds features without the vendor's involvement — it may become a provider under Article 25. That role shift triggers the full provider obligation stack. Banks should document every customisation carefully.

Deadline: 2 December 2027

The obligation to comply with the high-risk requirements does not fall on 2 August 2026. Under the Digital Omnibus agreed by the Parliament and Council in May 2026, that date has been deferred. Stand-alone high-risk AI systems — which is precisely what a credit-scoring model is — must comply from 2 December 2027. High-risk AI embedded in products covered by EU product-safety law (Annex I of the Act) must comply from 2 August 2028.

The original 2 August 2026 date may appear in vendor contracts, internal planning documents, and legacy compliance programmes. It is no longer the operative deadline for Annex III systems.

The deferral is meaningful breathing room for lenders that have not yet started their compliance work. It is not an invitation to wait. Technical documentation for a production credit-scoring model takes months to assemble properly. An Article 9 risk management system requires multiple rounds of bias testing, documentation, and remediation. An Article 27 FRIA requires structured stakeholder engagement. Starting in 2027 is starting too late.

Penalties for non-compliance with high-risk obligations fall under Article 99(4): up to €15 million or 3% of total worldwide annual turnover, whichever is higher. For SMEs and start-ups, Article 99(6) caps the fine at the lower of the two — the percentage or the fixed sum. That cap is genuine protection for smaller lenders; the full €15 million ceiling applies to larger institutions.

How Confir helps

Confir's rule-based classification engine walks through the Annex III point 5(b) criteria and the Article 6(3) filter to determine whether your credit-scoring system is high-risk — and it flags the fraud-detection boundary automatically, so you are not misclassifying exempt systems or exempting non-exempt ones.

For deployers, Confir runs the Article 27 FRIA structured workflow: the assessment covers discrimination risks, financial-exclusion risks, mitigation measures, and the notification requirements, producing a documented output you can present to a supervisory authority.

For providers, Confir generates the Article 11 / Annex IV technical documentation pack and the Article 47 Declaration of Conformity from your intake data, using deterministic rules — the same inputs produce the same documented output, with the rule that fired visible and auditable. No hallucination, no inconsistency between reviews.

---

Frequently asked questions

Is fraud-detection AI high-risk under Annex III point 5(b)?

No. Annex III point 5(b) explicitly excludes AI intended to detect financial fraud. A model that identifies suspicious transactions or flags applications for fraud investigation does not determine creditworthiness and is not high-risk on this basis. It may still be subject to other EU AI Act requirements depending on its design and risk profile, but it does not inherit the full high-risk obligation stack that applies to creditworthiness systems.

What is the compliance deadline for credit-scoring AI?

Under the Digital Omnibus agreed in May 2026, stand-alone high-risk AI systems — including creditworthiness and credit-scoring systems listed in Annex III point 5(b) — must comply from 2 December 2027. The original date of 2 August 2026 has been deferred. Formal adoption of the Omnibus is expected before 2 August 2026. Plan against the December 2027 date.

Who is the provider and who is the deployer for a third-party credit-scoring model?

The company that built and markets the scoring model is the provider (Article 16). The lender or bank that uses the model to make credit decisions is the deployer (Article 26). If the lender modifies the model — adjusts its intended purpose, retrains it, or puts its own name on it — it becomes a provider under Article 25 and takes on the full provider obligation stack.

Does the deployer (lender) need to run a FRIA, or does the vendor's conformity assessment cover it?

The deployer must run a separate Article 27 Fundamental Rights Impact Assessment. The vendor's Article 43 conformity assessment covers the provider's obligations; it does not discharge the deployer's FRIA requirement. Both are mandatory and distinct. For creditworthiness systems, which access essential financial services, the FRIA obligation is unambiguous.

What does human oversight under Article 14 actually require for credit decisions?

Designated staff must have the competence, authority, and resources to understand the system's outputs, recognise when the system is malfunctioning or producing biased results, and override or suspend the system. Oversight must be genuine, not nominal — a loan officer who is expected to approve the algorithm's output 99% of the time without additional information does not satisfy Article 14. Override rates, training records, and decision logs are the evidence a supervisory authority will examine.

What fine applies if a lender fails to comply with high-risk obligations?

Article 99(4) sets the ceiling at €15 million or 3% of total worldwide annual turnover, whichever is higher. For SMEs and start-ups, Article 99(6) caps the fine at the lower of the two. The €7.5 million / 1% tier (Article 99(5)) applies only to supplying incorrect or misleading information to authorities — not to substantive non-compliance with the high-risk requirements.

What is the relationship between the EU AI Act and GDPR Article 22 for credit decisions?

They are complementary obligations. GDPR Article 22 restricts fully automated decisions that produce legal or similarly significant effects on individuals — a credit decision is the paradigm case. The AI Act adds transparency, documentation, and human-oversight requirements on top of GDPR's framework. Both apply; satisfying one does not satisfy the other. A lender that meets the AI Act's Article 14 human-oversight requirement will typically also satisfy GDPR Article 22, since genuine human review breaks the "solely automated" trigger — but the GDPR right to an explanation of the logic involved remains independent.

Related guides

• Article 6 high-risk classification
• Articles 6–29 compliance obligations
• EU AI Act key requirements
• risk classification levels guide
• risk assessment methodology
• EU AI Act explained