Algorithmic Fairness in Underwriting and Scoring — What Prudential Validation Does Not Test
For actuarial functions, credit risk modelling and model validation: which fairness metrics apply to a real scoring or pricing model, why they contradict one another, and why the exercise need not fail on the fact that you are not permitted to hold the relevant attributes.
Prudential validation under Article 185 CRR, or Articles 121, 122 and 124 of the Solvency II Directive, tests discriminatory power, calibration and appropriateness. It does not test fairness across protected groups. Not through negligence — it was never designed to.
For institutions supervised under the SSM, the ECB Guide to internal models (Release 4.0, July 2025) makes the same boundary visible from the supervisory side. It sets out expectations for model development, validation and change management in considerable detail, and it acknowledges the AI Act without absorbing its requirements. The two frameworks are adjacent, not nested.
This article takes the next step a technical conversation usually calls for: what exactly would you measure, and what does the exercise actually depend on?
The reasonable first objection
It comes from the actuarial function, and it is well founded: risk-based differentiation is our business, and it is expressly permitted.
That is correct, and the Union framework says so — but the permission is narrower than it is usually quoted.
Gender was removed from the permission, not weakened. Article 5(2) of Directive 2004/113/EC once allowed proportionate differences in premiums and benefits where sex was a determining factor supported by actuarial and statistical data. In Test-Achats (C-236/09) the Court of Justice declared that provision invalid with effect from 21 December 2012. The mortality differential between men and women is statistically uncontested. It was held insufficient as a justification nonetheless.
Some differentiation remains unlawful under perfect statistics. Article 5(3) of the same directive provides that costs related to pregnancy and maternity shall not result in differences in premiums and benefits. No proportionality test, no actuarial exception. For a health or life pricing model this is not an abstract proposition but a concrete test requirement — including the question of which features allow those costs to re-enter the score indirectly.
And for ethnic origin the position is different again. Directive 2000/43/EC prohibits discrimination based on racial or ethnic origin in access to goods and services, including financial services, and it contains no insurance-style justification provision at all. My reading is that this silence is deliberate: where the framework provides an actuarial justification route for one set of grounds and none for another, the omission is the point. That is my interpretation rather than legal advice, and anyone relying on it internally should have their own legal function confirm it. For test design, however, nothing turns on the question — see the section on proxies below.
The overall finding: the legislator does distinguish between differentiation and discrimination. But statistical correctness is nowhere a sufficient justification. At best it is a necessary one.
The AI Act follows the same logic. For high-risk systems — and Annex III point 5 covers both creditworthiness assessment and risk assessment and pricing in life and health insurance — Regulation (EU) 2024/1689 does not require the absence of group differences. Article 10(2)(f) and (g) require that possible biases be examined and that appropriate measures be taken to detect, prevent and mitigate them. What is required is a documented, reasoned examination — not a particular result.
That is good news for an actuarial function that works carefully. It shifts the task from we have to change our model to we have to be able to show what we accept and why.
Three metric families — and your validation already runs one of them
The fairness literature offers dozens of metrics. On a real scoring or pricing model they fall into three families, and the families must be kept apart because they ask different questions.
Independence (statistical parity). Do the protected and reference groups receive positive decisions at the same rate? Operationalised as statistical parity difference or disparate impact ratio. Both libraries expose this directly: Fairlearn as demographic_parity_difference and demographic_parity_ratio, AIF360 as statistical_parity_difference. For documentation purposes the disaggregated view is usually more useful than the single figure — in Fairlearn, a MetricFrame with selection_rate by group, which returns the table rather than the number. This family is almost always violated in underwriting, and enforcing it would usually be wrong, because it ignores real risk differences. It remains relevant for one reason: it is the figure a supervisor, a court or a consumer organisation will compute first. Not knowing it means being surprised by it.
Error rate equality (separation). Are the errors distributed evenly? Equal opportunity compares false negative rates; equalized odds adds false positive rates. Translated into your own vocabulary: is a genuinely good applicant from group A rejected more often than an equally good applicant from group B? This is the family that carries the most weight for credit and acceptance decisions, because it has already netted out the risk difference — it asks only whether the model performs equally well at equal risk. In Fairlearn: equalized_odds_difference, plus false_negative_rate and false_positive_rate by group through the MetricFrame; equal_opportunity_difference is available there as well. The AIF360 equivalents are average_odds_difference and equal_opportunity_difference.
Within-group calibration (sufficiency). Does a score of 0.08 mean the same realised default or claims probability in every group? This is where it becomes interesting for a validation function: it is a fairness metric you already command. Your existing calibration testing — binomial test, Hosmer-Lemeshow, observed versus expected — is precisely this procedure. You simply run it in aggregate across the portfolio rather than separately by group.
The practical consequence is undramatic. The first step of a fairness test is not a new methodology but a stratification of your existing validation pipeline. That lowers the barrier to entry considerably and is straightforward to explain in a supervisory dialogue.
One practical warning that saves trouble later: both libraries have restructured their interfaces more than once, and AIF360 now maintains a scikit-learn-compatible module alongside its older dataset API in which some metrics are named differently. The library version therefore belongs in the test documentation. Without it the repeat measurement two years from now is not properly reproducible — and that is exactly what a validation function will look for.
Why you have to choose between the families
Here is the point that AI Act overviews routinely skip: the three families cannot be satisfied together.
Kleinberg, Mullainathan and Raghavan, and — independently — Alexandra Chouldechova, showed in 2016 that where base rates differ between groups, a model cannot simultaneously be calibrated and equalise error rates, except in the practically irrelevant case of perfect prediction. This is not a modeling defect that better data will fix. It is a mathematical result.
For underwriting and scoring the implication is direct: differing base rates are the rule here, not the exception. Your model will therefore necessarily violate at least one common fairness definition. The question cannot be whether your model is fair. It is: which fairness definition is the right one for this use case, who decided that, and is the decision documented?
Algorithmic fairness thereby moves from a technical question to a governance question — and in that form it becomes auditable. A fairness report that states the impossibility result, justifies the chosen lead metric and quantifies the deviation deliberately accepted is considerably more robust before a supervisor than a report presenting a single green figure.
Group fairness is not enough: the proxy problem
Two additions, without which an examination in financial services remains incomplete.
Individual fairness. Dwork and colleagues formulated the principle in 2012 that sufficiently similar individuals should be treated sufficiently similarly. Applied to a scoring model this means counterfactual testing: does the decision change when a single attribute is varied that is not causal for the risk? This finds effects that every group metric misses, because they cancel out within groups.
Proxy attributes. In practice this is the most important test, and it is the reason we do not use protected attributes at all is not a defence. Models find stand-ins. Postcode correlates strongly with migration background in many European cities — the local variant of what became known in the United States as redlining. Employment gaps and part-time rates correlate with sex. Contract tenure and product holdings correlate with age. A gradient boosting model with several hundred features will often reconstruct an unobserved protected attribute with remarkable accuracy, without anyone having intended it.
For consumer lending there is a further and quite specific reason to look at postcode. Article 6 of the Second Consumer Credit Directive, Directive (EU) 2023/2225, requires that the conditions for granting credit do not discriminate against consumers legally resident in the Union on grounds of nationality or place of residence. Place of residence is not an abstract protected characteristic here — it is a variable that sits in your feature set by name.
The robust test itself is unspectacular. You check how well the protected attribute can be predicted from the remaining model features, and you use SHAP attributions to see which features carry the predicted differences between groups. The output is a candidate list for a technical discussion, not an automatic verdict.
A timing point specific to consumer lending
The high-risk obligations under Annex III of the AI Act apply from 2 December 2027 following the Digital Omnibus. For consumer credit, however, a nearer date matters more.
CCD II applies from 20 November 2026. Article 18 requires creditors to document their creditworthiness assessment procedures and the information used, and — where the assessment involves automated processing — to inform the consumer of the right to obtain human intervention, to be told that automated processing was used, and to be able to contest the decision. Recital text in the directive links this expressly to the classification of credit scoring as high-risk under the AI Act.
The practical consequence is worth stating plainly: from late 2026 a rejected applicant can require a human review and an explanation. If your model carries a group differential you have not measured, you will first learn of it through individual contested cases rather than through a supervisory dialogue. That is a considerably less comfortable way to find out.
The real obstacle: you need data you are not permitted to hold
This is where fairness projects in regulated institutions typically stall. Every metric above requires the protected attribute, at minimum in the test dataset. That is precisely the attribute you have good reasons not to collect and which Article 9 GDPR treats as a special category.
The AI Act anticipated the dilemma. Article 10(5) permits, by way of exception, the processing of special categories of personal data where strictly necessary for the purpose of bias detection and correction. The permission is subject to six cumulative conditions; Recital 70 characterises it as a substantial public interest within the meaning of Article 9(2)(g) GDPR.
One of those conditions deserves particular attention in a vendor decision. Article 10(5)(d) requires that the special categories of personal data are not transmitted to, or otherwise accessed by, other parties. Points (b) and (c) add technical limitations on use, pseudonymisation, strict access controls and documentation; point (e) requires deletion once the purpose has been achieved.
Anyone taking those conditions seriously has already made a vendor decision. A fairness testing service that receives your application data, protected attributes included, in order to compute the metrics is difficult to reconcile with point (d) — however well drafted its data processing agreement may be.
The architecture follows from the norm, not from the sales pitch
The AI Act supplies the answer within the same instrument. Recital 69 expressly refers to the use of technology permitting algorithms to be brought to the data, rather than raw data being transmitted or copied between parties.
That is how our testing pipeline is built. Computation runs client-side in a container inside your environment, on your data, behind your access controls. What leaves the building is aggregated metrics, the reasoning behind the metric choices and the audit documentation — no application records and no special categories of personal data.
Translated into governance language, which is the version for the board paper: the outsourcing footprint under the EBA Guidelines on outsourcing arrangements — or the corresponding EIOPA guidance for insurers — is materially smaller, because the service provider processes no personal customer data. No additional ICT third-party risk arises under DORA, because no ongoing service is embedded in the value chain. Data sovereignty remains entirely in-house.
This is not a selling point retrofitted to a methodology. It is the only architecture that keeps Article 10(5)(d) intact.
Who will ask you these questions
One caveat for institutions operating across several Member States: national AI Act supervisory arrangements in the financial sector are not settled everywhere. France has moved closest to a single-authority model with the ACPR. Italy has adopted a sectoral split across several authorities. In the Netherlands the allocation between DNB and AFM remains under discussion. Others are still in progress.
The practical inference is not to wait for clarity. It is that documentation designed around one national supervisor’s expectations may not travel. The ECB Guide is the more durable structuring reference here, because it organises expectations by institution type rather than by jurisdiction.
What an auditable fairness test protocol contains
From practice, compressed into six points:
- Protected attributes and comparison groups, with the reasoning behind their selection and the legal basis for processing them under Article 10(5).
- Lead metric plus supporting metrics, with documented reasoning for the choice and an explicit reference to the impossibility result.
- Thresholds and tolerance bands, fixed before measurement — not after.
- Proxy and counterfactual analysis, including the candidates examined and discarded.
- Technical justification of remaining differences, derived actuarially or in credit terms, kept separate from the statistical finding.
- Repeat cycle and escalation path, connected to existing model validation and to post-market monitoring under Article 72.
Point 6 is the one most often missing. A one-off fairness test has a short shelf life: portfolios shift, feature distributions drift, and a model within tolerance today may not be in eighteen months.
What this actually costs
Not the computation. The metrics are implemented in AIF360 and Fairlearn and can be applied to an existing model in a matter of days.
The cost sits in the reasoning: selecting the right metric for the specific use case, deriving what constitutes legitimate risk differentiation and what does not, and producing documentation that still holds up two years later.
That work cannot be outsourced. What can be outsourced is the method that structures it.
The protocol as a one-page document: Download the six-point audit protocol — one page, no registration
If you have a specific model in mind whose fairness profile you would like measured properly, write to me at vmayr@waveimpact.de. Half an hour of technical discussion, with no proposal logic behind it.
Dr Valentin José Mayr is founder and managing director of waveImpact GmbH, Bremen.
Sources
Primary
- Regulation (EU) 2024/1689 (AI Act): Art. 10(2)(f), (g); Art. 10(5)(b)–(f); Art. 72; Annex III point 5; Recitals 69, 70
- Regulation (EU) 2016/679 (GDPR): Art. 9(2)(g); Art. 22
- Directive 2004/113/EC: Art. 5(2) (invalidated), Art. 5(3)
- Directive 2000/43/EC (racial equality)
- Directive (EU) 2023/2225 (CCD II): Art. 6, Art. 18 — applicable from 20 November 2026
- CJEU, judgment of 1 March 2011, C-236/09 (Test-Achats)
- Regulation (EU) 2022/2554 (DORA); EBA Guidelines on outsourcing arrangements (EBA/GL/2019/02)
- ECB Guide to internal models, Release 4.0 (July 2025)
Literature
- Kleinberg, Mullainathan, Raghavan (2016), Inherent Trade-Offs in the Fair Determination of Risk Scores
- Chouldechova (2016), Fair Prediction with Disparate Impact
- Dwork, Hardt, Pitassi, Reingold, Zemel (2012), Fairness Through Awareness
Tooling
- Fairlearn — API reference
- AIF360 — scikit-learn API reference
This article is provided for technical information and does not constitute legal advice. The reading of Directive 2000/43/EC offered in the section on the first objection is identified in the text as the author’s interpretation.
Last updated: July 2026.