Credit Scoring and Automated Decisions: CCD2, AI Act and GDPR

For years, the regulatory analysis of a scoring model began and ended with data protection. Today three regimes overlap on the same decision (granting or refusing credit to a person), and each one looks at something different:

• Directive (EU) 2023/2225, CCD2, looks at the outcome for the consumer: what rights they have when the decision affects them, what data cannot be used and what must be assessed.
• Regulation (EU) 2024/1689, the AI Act, looks at the system: how it was built, what data it was trained on, how it is documented and who oversees it.
• The GDPR looks at the processing: the legal basis, the information given to the data subject and the limits on decisions based solely on automated processing.

The practical consequence is that a project that has worked on only one of the three fronts almost certainly has gaps in the other two. And the most common gap is the same in every case: the model works, but it cannot be explained. A model can predict well and still be unable to tell a customer why they were rejected in terms they understand, or to show a supervisor how it was built.

One idea frames everything else. None of the three laws prohibits automation. What they do is require automation to be reversible, explainable and supervised. A model that decides alone, with no possibility of human review and no ability to explain its output, is not an efficient model: it is a non-compliant one.

The three rights are quick to read and slow to implement, because each one touches a different layer of the system. The right to human intervention is organizational: it requires people, training and a clear definition of how far their power to override the model goes. The right to an explanation is technical: the model must produce reasons, not just a number, which in practice determines which architectures are viable. And the right to a review is procedural: you have to record what the customer argues, show that it was considered and give reasons for the new decision.

The second right is the one that forces most projects back to the drawing board. A highly accurate but opaque model (a deep ensemble, for example) can become unusable not because of its performance, but because its output cannot be translated into a meaningful explanation. That is an architecture decision best made at the design stage, not when the first complaint arrives.

There is also a connection worth keeping in mind: the distance financial services directive separately establishes the right to obtain human intervention at the pre-contractual stage when automated tools are used. These are two different laws pointing at the same place (before contracting and when deciding whether to grant credit), so the escalation process must cover both moments.

CCD2 sets out what information can support the creditworthiness assessment and expressly excludes two sources that until now appeared in alternative scoring models:

• The GDPR special categories of data, with express mention of health data.
• Data from social networks.

The first prohibition is consistent with the general data protection regime and comes as little surprise. The second is the one that changes projects: for years, digital behavior signals and social footprint have been presented as the way to give credit to people with no credit history. That route is now closed for creditworthiness assessments in consumer credit.

But the consequence that really calls for technical work is a different one, and it is not written down: proxy variables. A model may not use health data and yet include variables that predict it with high correlation, such as spending patterns at pharmacies, type of merchant or the frequency of certain categories. Formally, the prohibited data is not used; in substance, it does enter the decision. Cleaning a model of these proxies is not a document review: it is a statistical exercise that must be carried out on the actual variables and documented.

This analysis also does double duty. It is what CCD2 requires on data and, to a large extent, it is also what the AI Act requires under the heading of data governance for high-risk systems. It makes sense to do it once and use it for both files.

The classification is beyond dispute: assessing the creditworthiness of natural persons is expressly listed in Annex III, within the category of access to essential services. A lender that uses an artificial intelligence system to decide on credit applications is operating a high-risk system, with everything that entails.

Two of the obligations deserve a closer look, because they are the most often misunderstood. Human oversight is not satisfied by an override button that nobody uses: the law requires a design that allows effective oversight. This means the person overseeing the system understands the output, has enough time to assess it and has real power to depart from it. And record-keeping is not the application log: it is the audit trail that makes it possible to reconstruct why the system decided what it did, in a specific transaction, months later.

The good news is that there is overlap with what CCD2 already requires. The human intervention process required by the credit directive is largely the human oversight required by the AI Act; and the traceability that makes it possible to explain a rejection is the same traceability that makes record-keeping possible. Designing them separately duplicates work. If you are already working on the AI Act from another angle, cross-check it with our AI Act analysis.

Article 22 of the GDPR gives data subjects the right not to be subject to a decision based solely on automated processing which produces legal effects concerning them or similarly significantly affects them. Rejecting a credit application falls squarely within that scenario, which is why most institutions already have a position on this issue.

What changes now is that this position has to be re-examined in light of the other two laws, because the bar has been raised. Many models relied on the idea that the decision was not “solely” automated because there was a nominal human review. CCD2 and the AI Act tighten that reading from two angles: the first grants an express right to human intervention, explanation and review; the second requires human oversight to be effective by design. A merely formal review no longer supports the argument.

The result is that the three laws converge on the same practical deliverable, and it makes sense to build it only once: a decision file for each transaction, recording what data went in, what output the system produced, who reviewed it, what the customer argued (if anything) and how the final decision was reasoned. That file is at the same time the evidence of GDPR compliance, the evidence of human intervention under CCD2 and the record required by the AI Act.

Two phrases in that table deserve attention because they generate the most work. The first is “appropriate consideration of current obligations”: knowing the customer’s income is not enough; you must factor in the financial burden the customer already carries. That means deciding where that data comes from (credit file checks, information provided by the customer, account aggregation) and documenting the choice.

The second is “in a manner appropriate to the volume of operations”. It is a proportionality clause, and it should be read in both directions. For a small lender, it means it will not be expected to have the machinery of a large institution. For a large lender, it means exactly the opposite: the expected standard grows with volume, so a handcrafted procedure stops being defensible beyond a certain size. Proportionality is not always a relief.

Picture the scene, because it is the one you need to solve: a customer whose credit application was rejected calls and asks why. The answer “you did not pass our assessment system” no longer works. The directive grants the right to a meaningful and comprehensible explanation, and those two adjectives carry real weight.

Meaningful means the explanation has to refer to the factors that actually weighed in that specific decision, not to a generic description of the model. Comprehensible means it has to be in the customer’s language, not the risk team’s: talking about the “percentile of the job tenure variable” explains nothing.

That requires three things that must be built before the first request arrives:

• Technical attribution capability. The system must be able to say which factors drove the decision in that transaction, not on average. This shapes the model’s architecture.
• A catalog of reasons in plain language. Pre-written, reviewed translations of each factor into a sentence a consumer can understand, so that the explanation does not depend on who takes the call.
• A submission and review process. Where the customer’s input comes in, who assesses it and how the new decision is reasoned.

There is also a limit to watch: explaining is not revealing the model. There is a balance between the consumer’s right to understand the decision and the institution’s legitimate interest in not exposing its assessment system to reverse engineering or fraud. That balance is struck in the design of the catalog of reasons (specific enough to be useful, aggregated enough not to become a manual on how to game the model), and the reasoning should be put in writing.