FRIA for AI Credit Scoring: A Complete Worked Example

Why credit scoring triggers a FRIA, regardless of public or private status¶

Article 27(1) opens: "Prior to deploying a high-risk AI system referred to in Article 6(2), with the exception of high-risk AI systems intended to be used in the area listed in point 2 of Annex III, deployers that are bodies governed by public law, or are private entities providing public services, and deployers of high-risk AI systems referred to in points 5 (b) and (c) of Annex III, shall perform an assessment of the impact on fundamental rights that the use of such system may produce." The sentence defines two groups of deployers who owe the assessment.

The first group is public bodies and private entities providing public services deploying Annex III high-risk systems. The second group is deployers of the systems referred to in Annex III points 5(b) and (c) — credit scoring, and life or health insurance pricing. That second clause carries no public-or-private qualifier. It binds every deployer of a 5(b) creditworthiness system and every deployer of a 5(c) life or health insurance-pricing system, commercial banks and consumer lenders included.

One reading trap is worth naming directly. The phrase "with the exception of … point 2 of Annex III" removes critical-infrastructure systems from the first group only. Point 2 of Annex III covers critical infrastructure; credit scoring sits in point 5(b). A 5(b) credit-scoring deployer is pulled in through the second clause, and the point-2 exception does not touch that clause.

Annex III point 5(b) covers "AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score, with the exception of AI systems used for the purpose of detecting financial fraud." A probability-of-default model that drives consumer-credit decisions sits squarely inside that definition. The FRIA template guide summarises this trigger; the rest of this article works it through in full. For the wider classification picture, including how Article 6 and Annex III decide what counts as high-risk, see the high-risk AI classification guide.

One further classification step makes the trigger airtight. Under Article 6(3), an Annex III system can fall outside high-risk where it does not pose a significant risk of harm to the health, safety, or fundamental rights of natural persons — for instance where it performs a narrow procedural task. That derogation does not reach credit scoring: Article 6(3) states that an Annex III system shall always be considered high-risk where it performs profiling of natural persons, and a creditworthiness model that evaluates a person's economic situation is profiling within the meaning of GDPR Article 4(4). A credit-scoring system that materially drives credit decisions therefore stays high-risk, and its deployer keeps the Article 27 FRIA duty.

The fraud-detection carve-out: what is in and what is out¶

The 5(b) definition expressly excepts AI "used for the purpose of detecting financial fraud." A pure fraud-detection model is therefore outside the 5(b) creditworthiness category, and it does not inherit the credit-scoring FRIA trigger through 5(b). A fraud model can still be high-risk on other grounds and carry its own governance duties; it simply does not inherit the 5(b) credit-scoring FRIA hook. Where the same institution runs fraud and AML models alongside its credit engine, the governance approach for those is covered in governing AML and payments agents.

Two adjacent cases round out the boundary. Solely pricing non-life insurance (motor, home, travel) is outside point 5(c); a non-life line would need a separate Annex III or Annex I route to be high-risk. Only life and health insurance risk assessment and pricing falls in under point 5(c), which carries its own FRIA duty.

Three legal layers on one AI credit decision¶

A single automated decline does not sit under the AI Act alone. Three bodies of EU law layer onto the same decision, and a credible FRIA has to account for all of them. This consumer-credit depth is what separates a worked credit-scoring assessment from the generic template.

The Article 86 explanation right and the GDPR hooks¶

AI Act Article 86 is the explain-the-decline hook inside the Act itself. It gives "any affected person subject to a decision which is taken by the deployer on the basis of the output from a high-risk AI system listed in Annex III … and which produces legal effects or similarly significantly affects that person in a way that they consider to have an adverse impact on their health, safety or fundamental rights … the right to obtain from the deployer clear and meaningful explanations of the role of the AI system in the decision-making procedure and the main elements of the decision taken." The right is conditional on that threshold: the decision has to produce legal effects or similarly significantly affect the person. A credit decline meets that threshold, because it governs access to a loan, card, or overdraft, so a declined applicant is an affected person who can invoke Article 86. Article 86(3) keeps the right a gap-filler: it applies only to the extent that an equivalent right is not otherwise provided for under Union law, so where the GDPR transparency and Article 22 rights already cover the explanation, those provisions govern and Article 86 fills what they leave open. On the GDPR side, the binding hooks are Articles 13 to 15 (meaningful information about the logic involved) and Article 22(3) (human intervention, the right to express a view, and to contest). Recital 71 also describes an explanation of the decision reached, though it is a non-binding recital, so the explanation duty is best anchored in those binding articles plus Article 86. The United States term "adverse-action notice" is useful shorthand for these duties, though it is not an EU statutory term.

The scenario: the bank and the system¶

The worked example uses one deployer throughout. The bank is a mid-sized EU retail bank and consumer lender, acting as the deployer of a high-risk AI system. The system is a machine-learning creditworthiness model (provider "ScoreCo", model v2.3) that outputs a probability-of-default score used to decide consumer-credit applications: personal loans, credit cards, and arranged overdrafts.

The decisioning design is a three-band cut-off. Scores above the upper threshold are auto-approved; scores below the lower threshold are auto-declined; the middle band is referred to human underwriters. A separate, independent fraud-screening model runs first and is out of scope of this FRIA under the Annex III 5(b) carve-out. Use is continuous and indefinite from the deployment date, with real-time scoring at the point of application, around 3,000 decisions a week (roughly 150,000 a year) across the bank's EU retail markets, online and in-branch. The system is Annex III point 5(b), so the FRIA is required under Article 27(1) whatever the bank's public or private status.

The worked FRIA, section by section (Article 27(1)(a)-(f))¶

Article 27(1) lists six mandatory components. The two paragraphs below set out what each one is doing for the credit-scoring case, and the table that follows completes all six for the worked example.

Sections 1 to 3 fix the facts the rest of the assessment reasons over. Section 1 records the system and its intended purpose (the ScoreCo probability-of-default model, the origination workflow it sits in, and the three-band cut-off design) and states plainly that fraud screening is a separate model outside this FRIA. Section 2 records duration and frequency: continuous production use, real-time scoring at the point of application, and the weekly decision volume. Section 3 identifies the affected persons, with particular attention to thin-file and vulnerable applicants and to third parties such as joint applicants and guarantors.

Sections 4 to 6 carry the analysis. Section 4 is the risk register set out in full below: each fundamental right, the harm scenario, a likelihood and severity rating, the mitigation, and the residual risk. Section 5 documents the human-oversight measures: the named officers who can override an auto-decline, the mandatory review of declines in flagged groups, and the second-line model-risk function. Section 6 records what happens when a risk materialises: the complaint route, the GDPR Article 22(3) and Article 86 rights an applicant can invoke, model rollback and threshold adjustment, and the Article 27(3) notification to the market surveillance authority.

Section 4 in full: the credit-scoring risk register¶

Section 4 is where a FRIA becomes concrete. Article 27(1)(d) requires the assessment to set out the specific risks of harm likely to affect the categories of natural persons identified in section 3; a right-by-right register — each fundamental right at stake, a specific harm scenario, a likelihood and severity rating, the mitigation, and the residual risk — is a defensible way to document those risks. The register below does that for the credit-scoring case. The likelihood, severity, and residual values are a sample assessment, internally consistent with the scoring matrix that follows. They illustrate a defensible method; the specific figures are not prescribed by any regulator.

Scoring the register: likelihood x severity¶

The risk levels in the register come from a likelihood-by-severity matrix applied consistently across the whole assessment. Recording the matrix, and the reasoning behind each rating, matters as much to a regulator as the final risk level.

Mitigations in depth¶

Disparate-impact testing. Run quarterly adverse-impact-ratio testing across protected groups, comparing approval rates, decline rates, and pricing outcomes. The four-fifths (80%) screen is a starting signal; document the test, the populations, and the action taken when a disparity appears.

Proxy-feature handling. Audit input features for correlation with protected characteristics. Postcode, occupation, device type, and nationality-linked variables are common proxies for ethnicity, gender, or age. Remove or transform the features that carry proxy signal, and re-test after each change.

Human review of declines. Route every decline in a flagged group to a named underwriter before it is communicated, and give that underwriter genuine authority to override the model. Low-confidence scores go to human review.

Adverse-action reasons and the Article 86 explanation. Give the applicant the principal reasons for the decline in plain language, plus the Article 86 explanation of the AI system's role in the decision and the main elements of the decision taken. Principal-reason codes mapped to the model's drivers make this repeatable and auditable.

Alternative manual pathway. Offer a route to a full manual assessment for applicants who contest an automated decline or who can supply additional evidence, such as rental or utility payment history.

Thin-file and alternative data. For applicants with sparse credit history, use consented alternative data (rental, utility, or open-banking cash-flow) under manual review, and monitor model performance by file-thickness and age cohort to detect segment-level failure.

Each of these controls needs an owner, evidence, and a place in the bank's control framework; mapping them to the relevant AI Act articles is what the control mapping view is for.

GDPR Article 22, SCHUFA, and the DPIA¶

An auto-decline at a score cut-off is a decision based solely on automated processing with a significant effect, which puts it under GDPR Article 22. The CJEU set that threshold lower than many lenders assumed. In SCHUFA Holding (Scoring), Case C-634/21 (judgment 7 December 2023), the Court held that a credit reference agency producing an automated credit-score probability value is itself carrying out automated individual decision-making under Article 22(1) where a third party such as a lender draws strongly on that value to grant or refuse credit; the Court noted that an insufficient probability value leads, in almost all cases, to a refusal. A score can itself fall under Article 22 where a third party draws strongly on it to grant or refuse credit, so a bank that auto-declines at its own cut-off is more directly making such a decision.

That means the bank needs both a separate Article 6 lawful basis for the processing and an Article 22(2) exception to the prohibition on solely-automated decisions. The usual exception is Article 22(2)(a) contract-necessity — the decision is necessary for entering into a credit contract — which, like the explicit-consent route in Article 22(2)(c), carries the Article 22(3) safeguards: the right to obtain human intervention, to express a point of view, and to contest the decision. The Article 22(2)(b) route, a decision authorised by Union or Member State law, instead requires those safeguards to be laid down in the authorising law. Article 22(4) also restricts the use of special-category data, which is why the risk register bans special-category inputs and monitors for their proxies. The remaining option is to keep a human in the loop on every decline so the decision is not solely automated.

The data-protection analysis overlaps heavily with a GDPR DPIA. Article 27(4) of the AI Act provides that where an obligation is already met through a DPIA, the FRIA complements that DPIA. Reuse the DPIA's data-flow, lawful-basis, and data-quality work as input, and extend it to the Charter rights a DPIA does not cover. For the DPIA side, see DPIA for AI systems, and to draft both together use the DPIA and FRIA generator.

After the FRIA: notification and ongoing monitoring¶

Article 27 also requires notification and updates after the assessment. Under Article 27(3), once the FRIA is performed the deployer notifies the relevant market surveillance authority of its results, using the Article 27(5) template. The AI Office has not yet published that template as of June 2026, so document against the Article 27(1) criteria in the meantime; the template's absence does not excuse the obligation. The only exemption from notification is the narrow Article 46(1) case.

The FRIA is also a living document. Article 27(2) requires an update whenever its elements change or are no longer up to date. For a credit-scoring model the practical update triggers are a model retrain or version change, a threshold or cut-off adjustment, performance or distribution drift, a new applicant cohort or market, and any change to the data sources feeding the score. A deployer may rely on a previously conducted FRIA for a sufficiently similar system, and it has to keep the assessment current. The French-supervision angle for banks deploying this kind of model is covered in ACPR AI governance for French banks.