How Banks Should Complete a Fundamental Rights Impact Assessment for Credit Scoring AI

What the obligation requires and who carries it

AI systems used to evaluate the credit score or creditworthiness of natural persons are classified as high-risk, because they determine access to financial resources and essential services such as housing, electricity and telecommunication services. Article 27 of Regulation (EU) 2024/1689 requires certain deployers to assess the impact on fundamental rights before deploying a high-risk system referred to in Article 6(2). It applies to public-law bodies, private entities providing public services, and deployers of high-risk systems referred to in points 5(b) and (c) of Annex III. Systems in the area listed in point 2 of Annex III are excepted. Recital 96 names banking and insurance entities as examples of deployers that should carry out the assessment, and the Commission FAQ confirms that operators of creditworthiness-assessment systems must assess the impact and notify the national authority of the results.

The duty sits with the deployer, which is the bank. The provider designs the system and assesses risks generically. The deployer's assessment addresses risks that can only be identified in the context of use. Provider documentation is an input, not a substitute.

The purpose, per recital 96, is to let the deployer identify the specific risks to the rights of individuals or groups likely to be affected, and the measures to take if those risks materialise. The assessment is done before deployment and updated when the deployer considers that any relevant factor has changed. As of November 2026, these are the obligations to plan against.

Working through the FRIA in sequence

Recital 96 describes what the assessment should cover. The sequence below follows it and keeps each step reviewable by model risk and compliance teams.

• 1. Scope the processes and use: Identify the bank's processes in which the credit scoring system will be used in line with its intended purpose, for example consumer loan origination or limit reviews. Record the period and frequency of intended use. Declared parameters become the baseline for later comparison.
• 2. Identify affected categories of people: Describe the specific categories of natural persons and groups likely to be affected in this context of use, including applicants, existing customers and any groups who may be disadvantaged by the system's outputs.
• 3. Analyse the rights at risk: For each group, assess non-discrimination, access to essential services, privacy and effective remedy. State the likelihood and nature of harm, and the evidence you hold about it.
• 4. Define human oversight: Specify oversight arrangements according to the instructions of use. Record which oversight step applies to which process, who performs it, and what triggers it.
• 5. Define mitigation, complaints and redress: Set the measures to take if a risk materialises, including complaint handling and redress procedures that a declined applicant can actually reach.
• 6. Notify and set update triggers: Submit the results to the market surveillance authority using the Article 27(5) template. Define who judges that a relevant factor has changed, and what evidence prompts that judgement.

Aligning the FRIA with the DPIA and model risk management

Many deployers must also complete a GDPR data protection impact assessment. The Commission FAQ says that, to avoid substantive overlap, the FRIA is conducted in conjunction with the DPIA. In practice, run one joint workstream with a shared description of the processing, data and affected persons. Add the rights analysis the DPIA does not cover, such as access to essential services and effective remedy. Where the situation is similar, a deployer may rely on previously conducted FRIAs or on impact assessments already carried out by the provider. Treat that as reuse of a starting point and document why the cases are similar.

Model risk management supplies much of the surrounding evidence: the model inventory entry, validation reports, performance and fairness testing results, and ongoing monitoring. Link these artefacts to the FRIA by reference rather than copying them. The FRIA then states the context-specific risks and commitments, and the model risk file shows how the system itself was validated. This alignment is an organisational design choice, not a prescribed format, so assign a single owner who reconciles the three documents whenever one changes.

Keep a record of the notification and the template as submitted. Examiners will want to see the version that was in force at first use.

Which commitments can be enforced and evidenced at runtime

A FRIA mixes commitments of different kinds. Operational commitments, which govern what happens in individual interactions, can be enforced and evidenced in production. Commitments about model design, data quality and statistical fairness are established before deployment and cannot be proven by runtime controls. Separating the two prevents the assessment from overstating what is demonstrable in operation.

• Escalation to human review for defined cases: Runtime: a policy can escalate an interaction for human approval and record the decision. Outside runtime: deciding which cases require review.
• Restrictions on personal data exposed to the AI system: Runtime: policy can redact or block specified data in an interaction. Outside runtime: the privacy analysis that defines what is permitted.
• Limits on actions the system can take through tools: Runtime: tool calls can be allowed or blocked by policy, with a record of each decision. Outside runtime: the design of the tools and permissions.
• Complaint routing and redress: Runtime: only where the route is triggered by an interaction. Outside runtime: the complaint procedure, staffing and remedy decisions.
• Declared period and frequency of use: Runtime: records of actual usage can be compared with declared parameters. Outside runtime: setting the parameters and judging whether a change is relevant.
• Absence of discriminatory outcomes: Outside runtime: model validation, bias testing and data analysis. Runtime enforcement does not establish this.

Where runtime policy enforcement supports FRIA evidence

A FRIA written at design time describes intended controls. An examiner will also ask whether those controls operated on real interactions. The distinction is between design-time evidence, such as the assessment and validation reports, and operating evidence, such as a record showing that a control acted on a specific interaction. The second kind is what lets the bank show that oversight and mitigation commitments were applied in production and not only documented.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, at the level of individual interactions and tool calls. Policy can allow, redact, block, rate limit or escalate for human approval, enforced at runtime, not reviewed after the fact. Each enforcement produces audit-ready evidence, mapped to the EU AI Act and NIST. A FRIA oversight commitment, for example, can be expressed as a policy that escalates defined interactions for human approval, and the resulting records show when it triggered and what the reviewer decided.

The boundaries matter. Trussed does not perform the assessment, bias testing or model validation. It does not provide model or dataset provenance, transaction-level governance or end-to-end tracing of agentic workflows. Insurance, a regulated financial sector, is where Trussed is deepest, and the evidence approach described here is framed for examiner scrutiny and model risk management in regulated enterprises.