An Austrian mobile operator refused to sign a customer up for a phone contract. The contract would have cost her €10 a month. The operator’s reason was her credit standing, which an automated assessment run by Dun & Bradstreet Austria had found insufficient.
The customer asked how that assessment had been made. The answer she got didn’t satisfy her, and an Austrian court later found, in a final decision, that Dun & Bradstreet had breached the GDPR by failing to give her “meaningful information about the logic involved”. Enforcing that decision raised more questions, and those went to the Court of Justice of the EU. The case was registered in 2022. The judgment came on 27 February 2025.
A ten-euro phone contract, three years in Luxembourg.
That case was decided under data protection law. When I read the European Commission’s draft guidelines on high-risk classification, published in May, I could see that one of their examples of a high-risk credit system is a credit agency whose scores are shared with a third party deciding whether to grant “a loan/mortgage or access to housing, healthcare or telecommunication services”.
If you build, buy or run credit scoring systems with AI, the EU AI Act has a use case for it. Point 5(b) of Annex III. The obligations attached to it apply from 2 December 2027. What’s still open is which of your credit systems it actually reaches, and the draft guidelines answer some of those questions.
What Point 5(b) Says
The text is one line:
“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;”
The Digital Omnibus didn’t touch it.
It covers two use cases, and a system only needs to be intended for one of them.
Evaluating creditworthiness means assessing a person’s ability and willingness to pay for a service or repay credit.
Establishing a credit score means building a representation of that creditworthiness, and the draft guidelines are clear that the form doesn’t matter: “a number, a ranking, or a label”. Renaming your score a “customer tier” doesn’t take it out.
Then, the guidelines add that a system intended to produce such a score for deciding access to financial resources or essential services is high-risk “regardless of other purpose the AI system may have”. The compliance assessment “should be limited to the intended high-risk purpose,” which is a small mercy for the multipurpose platforms.
Pricing gets its own line. A system that only prices credit isn’t covered, even if it uses creditworthiness data. A system that assesses creditworthiness and sets the price in one integrated process is.
There Are Three Gates to Look At
Before any of the 5(b) obligations reach a credit scoring system, three things have to be true. Whether it profiles people only matters after that.
First, it has to be an AI system. The Commission’s 2025 guidelines on the AI system definition list “linear or logistic regression methods” as an example of systems that improve mathematical optimization and can fall outside the definition. A large share of traditional credit scorecards are logistic regressions. Whether yours falls outside is a real question.
Second, its intended purpose has to be 5(b). The draft guidelines list what falls outside:
customer classification for information duties, suitability or personalized marketing, “so long as the classification does not play a part in the assessment of the creditworthiness”
segmentation and pricing simulations that are distinct from the creditworthiness system
chatbots that help applicants fill in the form, and complaint-handling tools after the decision
tools that monitor credit exposures after the loan is granted, for internal prudential purposes
collateral valuation, where the system looks only at the asset
Every item comes with a condition. Once the marketing segmentation starts feeding the credit decision, it’s no longer marketing segmentation.
Third, the AI Act has to apply to it at all. A legacy model is still a 5(b) system, but Article 111(2) keeps its operators outside most of the AI Act. More on that below.
Essential Credit, and Credit That Isn’t Essential
Annex III point 5 of the EU AI Act is about access to “essential private services”. Point 5(b) doesn’t repeat the word, but the draft guidelines read it in anyway.
Their list of financial services that count as essential:
a bank account,
payment services (including an overdraft that supports a transaction),
loans and credit, extending a credit line or card limit, and
mortgages, plus
publicly backed schemes like subsidized first-home loans or social microcredit.
Their list of services that don’t count:
buying stocks and securities,
margin trading,
complex financial instruments,
premium credit cards, and
“special loans, such as leisure/travel loans”.
So a system that only scores applicants for travel loans may be outside 5(b). A system that scores applicants for travel loans and personal loans is inside. The draft is explicit that a system intended for both is high-risk, and it expects the provider to show that a system is “solely intended to be used for non-essential private services”.
But I would treat this exemption with caution: 5(b) itself has no “essential” qualifier. The practical consequence is a documentation question. If you want to rely on this, the intended purpose has to say so, the product has to match, and the model can’t drift into scoring the product line or anything like that.
Lastly, point 5(b) also covers natural persons. The draft guidelines say sole traders and the self-employed count as natural persons in their commercial activity. A system that scores companies from company data doesn’t. The guidelines go one step further. Where the owner of a legal entity is assessed to back a company loan, the owner falls outside 5(b) “as the primary beneficiary of the credit is the company, not the individual”.
Lend to a plumber trading in his own name, and you’re in. Lend to his limited company and take his personal guarantee, and on the draft guidelines’s reading you’re out. That sits awkwardly with the draft’s own condition in the same paragraph (company scoring is out “so long as the system is not intended to be used to evaluate the personal finances of natural persons”). The final text of the guidelines may differ though.
The Exit That Profiling Closes
Article 6(3) lets a provider argue that an Annex III system isn’t high-risk after all, if
it only performs a narrow procedural task,
improves a completed human activity,
detects deviations from past decision patterns, or
does preparatory work.
It’s the route providers in other Annex III areas will look at first. Providers of credit-scoring systems won’t get to use it, because of the sentence that follows:
“Notwithstanding the first subparagraph, an AI system referred to in Annex III shall always be considered to be high-risk where the AI system performs profiling of natural persons.”
Profiling has its GDPR meaning. The draft guidelines break it into three cumulative elements: automated processing, of personal data, with the objective of evaluating personal aspects. The GDPR’s own list of personal aspects includes a person’s “economic situation” and “reliability”. A credit score is about as close to the textbook example as it gets.
For a lender, then, the classification memo isn’t about derogations. It’s about scope:
is this an AI system,
is its purpose 5(b), and
was it already running before December 2027?
Yes, yes and no, and the conversation is over.
A narrow space remains for tools that process personal data without evaluating anyone. The draft guidelines note that a simple classification by characteristics like age doesn’t necessarily amount to profiling. A tool that reads income figures off a payslip for an underwriter might sit there. That line is untested, so document why the tool doesn’t assess anyone before relying on it.
Then, there’s the fraud exception. Fraud detection has to be “the main intended use of the AI system, preceding all other purposes”. If it is, the system stays outside 5(b) even when its output later feeds the credit decision. Anti-money laundering tools aren’t covered by the exception at all. They’re outside 5(b) only as long as they don’t assess creditworthiness, and the draft guidelines classify them as high-risk where they’re “functionally linked and simultaneously intended” for it.
One System or Two: Where the Capital Models Land
Recital 58 says AI systems “provided for by Union law… for prudential purposes to calculate credit institutions’ and insurance undertakings’ capital requirements should not be considered to be high-risk”. That reads like good news for banks’ internal ratings-based (IRB) models, the models that calculate how much capital they hold against their loan books.
The complication is the “use test”. Article 144(1)(b) of the Capital Requirements Regulation requires IRB ratings and estimates to “play an essential role in the risk management and decision-making process, and in the credit approval” functions of the bank. The prudential rules require the capital model to be used in lending decisions. Lending decisions about individuals are 5(b).
The draft guidelines take this on directly in a section on the CRR (section 3.5.5).
A system used solely to calculate risk-weighted exposure under the IRB approach, and not intended for credit scoring or creditworthiness, is outside 5(b). The use test alone doesn’t make it high-risk.
A system that does both is high-risk, and its main purpose doesn’t matter: “Provided one of the purposes of the system is the use case listed in point 5(b)… the AI system should be classified as high-risk”.
Where the bank runs two systems (a credit-scoring system that takes the IRB output as an input, or the other way round), only the credit-scoring system is high-risk.
Whether you have one system or two is “a case-by-case assessment,” based on the AI system definition, and the draft suggests describing hardware and software components, inputs, outputs and interfaces to show where one system ends.
For a bank, then, one of the most consequential classification documents is the architecture diagram. Two boxes and an arrow can put the capital model outside the high-risk regime, and one box can put it inside. Expect a market surveillance authority to check the diagram against the code.
The Exemption Clause
Article 111(2) says the AI Act applies to high-risk systems placed on the market or put into service before the Chapter III application date “only if, as from that date, those systems are subject to significant changes in their designs”. For credit systems under 5(b), that date is 2 December 2027.
A scoring system already placed on the market or put into service by that date is outside the AI Act (the prohibitions aside) until it changes significantly. The draft guidelines confirm this for financial institutions in plain terms: such systems “are grandfathered”.
Credit systems don’t stand still, though. They get monitored, recalibrated and redeveloped as a matter of routine. The question is when routine becomes significant.
The AI Act gives two anchors. Recital 177 says “significant change” should be understood as equivalent in substance to “substantial modification”. Article 3(23) defines that as a change “not foreseen or planned in the initial conformity assessment”. Legacy systems never had a conformity assessment, so nothing was foreseen or planned in one. Part of the definition points at a document that doesn’t exist. The rest still works: a change that alters the intended purpose counts, so moving a legacy system onto a new product line is a clean trigger.
For banks on the IRB approach, the draft guidelines offer a way out of that loop: “the definition of material change to the credit-scoring within the IRB Approach as set out in the relevant Union legislation will be relevant”. Banks already classify IRB model changes as material or not for their supervisors, under Delegated Regulation (EU) No 529/2014. The AI Act assessment would borrow that work.
Just a side note: in March 2026 the EBA sent the Commission revised standards that it says “significantly reduce the number of changes classified as material”. If the AI Act test follows the prudential one, fewer changes would count as significant, and more legacy systems would stay outside for longer. That’s my reading of where the two could meet, not something either text says.
For everyone else, the question stays open. A consumer lender that isn’t on the IRB approach, a buy-now-pay-later provider, a credit bureau: none of them has a prudential materiality framework to borrow. The final guidelines, expected by the end of 2026, may change the picture.
Who Owes What
If you build a scoring system and use it yourself, you’re the provider and the deployer. Both sets of obligations are yours.
Bought-in scores are less tidy. The draft guidelines’ bureau example says it is “not necessary that the deployer of the system is identical to the party using the credit score for its decision-making”. A deployer is whoever uses the system “under its authority”. A lender that integrates and configures a vendor’s model is using the system. A lender that receives a number from a bureau is arguably using an output, and the bureau may be both provider and deployer.
The AI Act doesn’t settle this. Article 86 gives a right to an explanation of a decision “taken by the deployer”. If the bureau is the deployer and the lender makes the decision, Article 86 may not reach that decision at all. Article 26(11) requires deployers that make decisions or assist in making decisions to inform the people affected, and a bureau assists but has no channel to the borrower. The open question is whether anyone owes the explanation at all.
The fundamental rights impact assessment has its own paragraph. Article 27(1) requires it from public bodies, from private entities providing public services, and from “deployers of high-risk AI systems referred to in points 5 (b) and (c) of Annex III.” Deployers of credit-scoring systems and of life and health insurance pricing systems are the only private businesses the article names by use case, which would include a bureau if it’s the deployer. After the Digital Omnibus on AI, a deployer “may” pull in the relevant parts of its GDPR impact assessment. That helps with the overlap.
Financial institutions do get relief, mostly about where things are filed:
the quality management system is deemed covered by financial services,
governance rules, except risk management, post-market monitoring,
risk management isn’t deemed covered, but it can be made “part of, or combined with” the risk-management procedures banks already run under other Union law,
technical documentation and logs sit inside the documentation banks already keep,
deployer monitoring is deemed fulfilled through internal governance rules,
for Annex III point 5 systems placed on the market or put into service by financial institutions, post-market monitoring can be integrated into existing systems and plans, “provided that it achieves an equivalent level of protection”.
However, there’s no comparable relief for data governance, human oversight, accuracy and robustness, the impact assessment, or informing the people affected. The EBA’s own mapping found “no significant contradictions” between the AI Act and banking law. It doesn’t mean the work is done, though some of it is. The CRR already requires banks to document when human judgment may override a rating and to analyze how overridden exposures perform. That’s a real head start on human oversight. On the other side, the CRR’s references to “biases” are about statistical estimation error. They aren’t about discrimination, so they won’t support AI Act.
What Stacks on Top
The GDPR already applies. In SCHUFA (C-634/21, 7 December 2023), the Court of Justice held that a credit score can itself be an automated decision under Article 22 of the GDPR where the bank or other party receiving it gives it a determining role in the decision. In Dun & Bradstreet, it set the standard for the explanation: the controller must describe “the procedure and principles actually applied” so the person can understand which of their data were used and how. “The mere communication of an algorithm” isn’t enough. It may be appropriate to tell the person how far a change in their data would have changed the result. Trade secrets go to the authority or court to be balanced. They don’t justify a refusal as such.
The second Consumer Credit Directive applies from 20 November 2026, a year before the AI Act’s high-risk rules. Its Article 18 does two things. The information behind a creditworthiness assessment can’t include special categories of personal data, and “social networks shall not be considered as an external source”. And where the assessment “involves the use of automated processing of personal data,” the consumer gets a right to human intervention, which includes a “clear and comprehensible explanation” of the assessment, the chance to give their own view, and a review of the assessment and the credit decision. “Involves” is a lower bar than the GDPR’s decisions “based solely on automated processing”. A human decision resting on an automated score still triggers it.
Against that background, the AI Act’s right to an explanation may do less in consumer credit. It applies “only to the extent that the right… is not otherwise provided for under Union law,” and the consumer credit right arguably is that right. It’s also limited to decisions that affect a person “in a way that they consider to have an adverse impact on their health, safety or fundamental rights”. A borrower approved on standard terms is unlikely to have a claim.
Lastly, mortgages are different. They sit outside the new consumer credit rules and under the Mortgage Credit Directive, which requires a lender who rejects an application to say, “where applicable, that the decision is based on automated processing of data”. That’s a notice, not an explanation. Where a person makes the mortgage decision with help from a score, the GDPR’s Article 22 may not apply either. That’s where, I think, the AI Act will do its real work.
What to Do Before December 2027
List every system that touches a credit decision, including the ones your teams don’t call AI. Then test each against the AI system definition and write down the answer.
Draw the system boundaries. If a capital system and a scoring system share components, decide now whether they’re one system or two, and make sure the documented boundary matches how the system is actually built.
Write the intended purpose down, including which products each system scores. If you’re relying on the non-essential carve-out, check that the system scores only those products.
Mark every system that will already have been placed on the market or put into service by 2 December 2027, and agree internally what a “significant change” means for it. If you’re on the IRB approach, start from your material-change classification. If you aren’t, you’ll have to build the definition yourself.
For bought-in scores, set out in the contract who operates the system and who does what, and make sure that matches how the system is actually run. A contract can’t make anyone a deployer, but it can show who is.
Map your GDPR impact assessment against Article 27(1) and note what’s missing.
Test your explanations against the Dun & Bradstreet standard now. That standard already applies wherever the decision is automated in the GDPR sense, and after SCHUFA that can include bureau scores. The AI Act adds to it rather than replacing it.
A woman asked why she couldn’t have a €10 phone contract, and it took the Court of Justice to spell out what kind of answer she was owed. From December 2027, an AI system that produces that kind of verdict will have to be built so that the people using it can interpret what it produced.
Unless it was already running by then and never changes much. In that case, what she’s owed will still come from data protection law, however long the system keeps deciding.
Like this article? The AI Governance Roadmap is something you can use in practice. It’s a company’s roadmap with steps and working documents: the classification, inventory spreadsheet, role assignment, vendor questions and AI policy template. Everything a company needs to govern AI, in one place.
Point 5(b) settles who is in scope; Article 86 settles who has to explain. Any affected person subject to a decision the deployer takes on the basis of output from an Annex III high-risk system can require clear and meaningful explanations of the role of the system in the decision procedure and the main elements of the decision, and that duty sits on the deployer rather than the vendor. My view is that Article 86(3) is the weak joint: the right applies only to the extent it is not otherwise provided under Union law, so in a Dun & Bradstreet fact pattern the data protection route keeps doing the work.