Why the AI Act left bank credit models with the supervisor they already had

The week

On Wednesday, March 13, 2024, the European Parliament voted to adopt the Artificial Intelligence Act, following the political agreement with member states in December 2023.

The vote was 523 in favor, 46 against and 49 abstentions. It closed a process that began when the European Commission proposed the law in April 2021. Negotiations among the Commission, Parliament and member states ran through 2023 and ended in a marathon session that produced a political deal on December 8. By then the arrival of ChatGPT and similar tools had forced negotiators to add a separate chapter for general-purpose AI models, which the original proposal had not anticipated.

It was a decisive step toward regulating the software that increasingly shapes how banks across Europe decide who gets a loan, a credit card or a mortgage, and on what terms: software that has learned patterns from past data about who repaid, who defaulted, and what distinguished them.

The law’s central idea is that what matters is not how clever a piece of software is, but what it is used for. Using artificial intelligence to recommend a song carries little risk. Using it to decide whether someone can borrow money to buy a home carries a great deal. So the regulation classed a defined list of uses as high-risk, and attached the heaviest obligations to them.

For financial services, the list included AI systems used to evaluate the creditworthiness of natural persons or establish their credit score. “Natural persons” is legal language for individual human beings, as opposed to companies. A credit score is a number summarizing how likely someone is to repay. The list carried an explicit exclusion for systems used to detect financial fraud. Risk assessment and pricing for individuals in life and health insurance were also listed.

The law sorted uses into tiers. A short list of practices was banned outright, including social scoring and AI that manipulates behavior or exploits people’s vulnerabilities. High-risk uses, such as credit scoring, carried detailed duties on risk management, data, logging, transparency, accuracy and human oversight. Some systems that interact with people, such as chatbots, carried lighter transparency duties. Everything else was left largely alone. The Parliament’s announcement also stressed two new rights for individuals: to complain about AI systems, and to receive explanations of decisions based on high-risk systems that affect their rights.

What made the text especially important for banks was a set of provisions aimed specifically at institutions already regulated under EU financial services law. Banks are among the most heavily supervised businesses in the world. The question was whether AI rules would pile a second, separate layer of oversight on top. These provisions answered it. They covered who would supervise these systems, and which AI Act duties a bank could meet through its existing internal governance.

The vote landed on ground that was already moving. In December 2023, the EU’s Court of Justice had ruled in a case involving the German credit bureau SCHUFA. Producing a credit score, it found, can itself count as automated decision-making under the GDPR when lenders rely heavily on it. Since 2021, European Banking Authority guidelines on loan origination had expected banks using automated models for creditworthiness to understand them, manage their data and guard against bias. A revised Consumer Credit Directive, adopted in October 2023, added rights to human intervention and explanation in automated credit assessments. The AI Act was the fourth layer on the same decisions.

The Parliament vote was not quite the end of the process. The Council, which represents the governments of member states, adopted the regulation in May 2024, and it was published in the Official Journal, the EU’s official record of law, that July.

The text the Parliament voted on still needed a final legal and linguistic check, which it completed through a correction procedure in April. Once published, the law would enter into force twenty days later and apply in stages. Bans would apply after six months, general-purpose AI rules after twelve, most of the law after twenty-four, and duties for AI built into products covered by other EU safety laws after thirty-six. For credit scoring, a use listed in Annex III, the original date fell twenty-four months out, in August 2026.

For banks, the March 2024 text did not create a new supervisor for credit models. It folded them into the supervision a bank already had. That design answers most of the practical questions a bank with EU-regulated entities had to settle. It breaks into three parts: who would examine the systems, which obligations existing governance already met, and which obligations no banking rule covered.

The analysis applies to any credit model used in the EU, whoever owns the bank. The law reaches providers that place systems on the EU market and, in some cases, providers and deployers outside the EU whose systems’ output is used in the Union. A US or UK banking group with EU subsidiaries therefore faces the same three questions for the models those subsidiaries use. Its home regulators will ask different ones.

How credit models learn, and why that worries regulators

A credit model is a set of rules, usually built from statistics, that takes information about an applicant and produces a judgment about how likely they are to repay. Traditional models use a modest number of factors, such as income, existing debts and repayment history, combined in ways a trained analyst can follow on paper.

Increasingly, banks use machine learning: software that finds patterns in large amounts of historical data by itself, rather than following rules a person wrote. Feed it thousands of past loans and their outcomes, and it learns which combinations of characteristics tend to go with repayment or default. The result resembles an experienced loan officer who has seen so many applications that they develop a feel for risk, except that the feel is encoded in mathematics and applied to every application in the same way.

That power brings two concerns. The first is opacity. A complex model may be accurate without anyone being able to say clearly why it declined a particular person. The second is bias. A model trained on historical data can absorb historical patterns, including unfair ones. If certain groups were treated worse in the past, a model can learn to treat them worse in the future, even if nobody intended it.

Banks have managed models for years under a discipline called model risk management. It is the set of policies that govern how models are built, independently checked (a step called validation), approved, monitored and retired. Supervisors expect it, and large banks have dedicated teams for it. Model risk management asks, broadly, whether a model works and whether the bank would know if it stopped working.

The AI Act asks some of the same questions, and some different ones. Working out which is which is the heart of the matter.

What banking rules already said about automated credit

Three existing rules already reached into these models before the AI Act. The European Banking Authority’s guidelines on loan origination and monitoring have applied since mid-2021. They expect banks using automated models to assess creditworthiness to understand their design and data, to manage model risk, and to detect and prevent bias. The GDPR restricts decisions based solely on automated processing that significantly affect people, and the SCHUFA ruling of December 2023 showed that the restriction can reach the score itself. The revised Consumer Credit Directive, due to apply from November 2026, gives consumers a right to human intervention and an explanation when creditworthiness is assessed by automated means.

Each rule has its own supervisor and its own vocabulary. The loan origination guidelines are enforced by banking supervisors. The GDPR is enforced by data protection authorities. Consumer credit rules are enforced by consumer protection or conduct authorities, which vary by country. The AI Act added a fourth layer, and its design choice was to route that layer through the banking supervisor for banks.

Why credit scoring landed in the high-risk list

Credit scoring appears in Annex III because access to credit shapes access to housing, transport and other essential services. The Act also contains a filter: an Annex III system can escape high-risk status if it performs only a narrow procedural task or otherwise poses no significant risk. That filter never applies to a system that profiles individuals, and scoring a borrower is profiling. Credit scoring models for individuals therefore stay high-risk.

Two exclusions narrow the scope. Systems used to detect financial fraud are carved out in the text. The recitals add that AI systems provided for by EU law for prudential purposes, such as calculating banks’ capital requirements, should not be considered high-risk. A probability-of-default model built for capital purposes may thus fall outside, while a closely related model used to accept or decline applicants falls inside. Banks that share models across both uses need to document which use drives which classification.

Who examines: the financial supervisor

Under the final text, the market surveillance authority for high-risk AI used by regulated financial institutions is, as a rule, the national authority that supervises those institutions. A market surveillance authority is the body that checks whether products on the market comply with the law. That applies where the system is directly connected to providing the financial service.

The recitals, the explanatory passages at the start of an EU regulation, add that authorities taking part in the Single Supervisory Mechanism should pass relevant findings to the European Central Bank. The Single Supervisory Mechanism is the system through which the European Central Bank and national authorities jointly supervise banks in the euro area.

The consequence is easy to understate. A bank’s credit-scoring models would be questioned by the same supervisor that already reviews its internal models, its credit risk processes and its outsourcing. That supervisor knows the bank’s model inventory and validation history. It also has established ways of following up findings.

AI Act questions would arrive inside an existing supervisory relationship, mixed with prudential and conduct concerns, and not as a standalone audit by an unfamiliar agency. Prudential supervision is about safety and soundness: whether the bank is likely to stay solvent. Conduct supervision is about how the bank treats customers. AI questions would now sit alongside both.

For a bank, that changes how evidence should be organized. A separate AI compliance binder, maintained by a new team, would sit awkwardly beside the model documentation the supervisor already receives. The better design adds AI Act fields to the existing model inventory, the master list of every model the bank uses. They cover the Annex III classification (Annex III is the part of the law that lists high-risk uses), the bank’s role as provider or deployer, the legal entities and markets served, and the date of the last review against the Act. Examiners can then follow one record from approval to monitoring.

How the supervisory route differs by type of lender

• Significant banks in the euro area. The European Central Bank supervises them directly, but market surveillance under the AI Act falls to the national authority. That authority is expected to pass relevant findings to the ECB, so AI issues can surface in the joint supervisory team’s wider assessment.
• Smaller banks. Less significant institutions are supervised day to day by their national authority, which would also handle AI Act questions. The route is shorter, and the same examiners are more likely to see both sets of issues.
• Non-bank lenders and fintechs. Consumer credit firms that are not banks may be supervised by a conduct authority, a different financial regulator or none in the prudential sense. Which body acts as their AI Act authority depends on how each member state allocated the role.
• Credit bureaus and scoring vendors. These are usually providers, not banks, and outside banking supervision. Their AI Act supervisor will often differ from their bank customers’ supervisor, which can complicate a joint response to findings.
• Insurers. Life and health insurers using AI to assess risk or price cover for individuals fall under the same high-risk heading, with their insurance supervisor in the role.

Member states had until August 2025 to designate their national authorities. Groups operating in several countries should expect differences in emphasis, even where the same type of authority holds the role.

Provider or deployer?

Those two roles recur throughout the law, so they are worth defining. A provider is the organization that develops an AI system and puts it on the market or into service under its own name; in banking terms, the builder. A deployer is the organization that uses the system in its own operations; the user. A bank that builds its own credit model in-house may be both. A bank that buys a score from a credit bureau or a technology firm is usually a deployer, with the vendor as provider. The obligations differ, so getting the label right for each system comes first.

What existing governance already meets

The text then gave regulated financial institutions specific credit for what they already do.

• A provider that is a financial institution subject to internal governance requirements is treated as meeting most of the quality management system obligation by complying with those rules. A quality management system is the documented set of processes an organization uses to make sure its products are built and maintained consistently.
• A deployer that is a financial institution can meet the duty to monitor a high-risk system through its internal governance arrangements.
• Documentation and automatically generated logs can be kept as part of the records financial services law already requires. Logs are the automatic records a system keeps of what it did and when.

These are real savings, but they are narrower than they look. The quality management credit does not extend to the risk management system for the AI itself, to post-market monitoring (keeping watch on how the system performs once in use), or to serious incident reporting. Those still apply in full. A bank that read the derogations, the legal term for these carve-outs, as a general exemption would leave gaps exactly where supervisors would look first.

The practical step is a mapping exercise, done once and kept current. On one side sit the AI Act duties for each high-risk system. On the other sit the policies and controls already in place: the model risk policy, validation standards, the credit risk framework, outsourcing and ICT third-party rules (ICT means information and communications technology), and record retention.

Building the map

A useful map has one row per duty per high-risk system, not one row per article of the law. Each row names the duty, the article it comes from, the existing control that addresses it, the evidence that proves the control operated, the owner, and the status. The evidence column matters most. A supervisor testing compliance will ask for the artifact: the validation report, the change log, the override register. A control that exists on paper without that trail counts for little.

The map should follow the bank’s existing model tiering. Banks already classify models by materiality and apply more rigorous validation to the most important. High-risk AI systems will usually fall in the top tier. Where they do not, the bank should explain why, because the classification under the Act does not depend on the bank’s own view of materiality.

Each duty gets one of three labels: met by an existing control, met with an addition, or not met. Second-line model risk and compliance should own the map jointly, because neither alone sees the whole picture. (In banking, the “second line” refers to the risk and compliance functions that oversee the business, as distinct from the business itself, the first line, and internal audit, the third.)

Three systems at one lender

Suppose a mid-sized European lender has three relevant systems: an in-house model that scores personal loan applications, a purchased score from an external vendor used for credit cards, and a fraud detection system.

The fraud system falls outside the high-risk credit category because of the explicit exclusion. The in-house model makes the bank a provider and a deployer. The purchased score makes it a deployer only.

When the mapping is done, most rows for the in-house model read “met by existing control” or “met with an addition”: validation, documentation, change control and record keeping are all familiar. But a handful read “not met”: the AI-specific risk management system, post-market monitoring, serious incident reporting, the bias examination of training data and the fundamental rights impact assessment. For the purchased score, the biggest gap lies outside the controls altogether: the vendor contract does not require the vendor to supply what the bank needs. That short list of gaps becomes the project plan.

A fair objection

A sceptic might say the mapping exercise is overcautious. Large banks already validate models independently, test them for fair lending and keep extensive records. A supervisor will often accept that evidence, for those parts. The Act, however, is product safety law adapted for software, and it uses that law’s machinery: conformity assessment, declarations, registration, post-market monitoring and incident reporting. Banking rules have no equivalent of that machinery, so the gaps are structural, not cosmetic.

What no banking rule covers

The third part is where new work concentrated. Several AI Act obligations have no close equivalent in prudential or conduct rules, and the derogations did not touch them.

Data governance for training, validation and test data. Model risk frameworks ask whether data is accurate and fit for the model’s purpose. The Act asks, in addition, whether the data is relevant and sufficiently representative, and requires examination for possible biases that could harm people or lead to prohibited discrimination. That calls for documented bias testing across groups, which many credit teams had done for fair lending purposes but not in this form. Fair lending is the body of rules against discrimination in credit decisions.

Human oversight by design. Providers must build systems so that people can understand outputs, avoid over-relying on them and intervene. Deployers must assign oversight to staff with competence and authority. For an automated decline, that means defining who can override, on what evidence, and how often overrides are reviewed. A common failure in any automated process is the reviewer who rubber-stamps whatever the machine says; the law aims squarely at that.

Oversight that works on a busy day

Human oversight is easy to describe and hard to run. Most automated credit processes use three bands: applications the model approves, applications it declines, and a middle band referred to a person. Oversight has to cover all three. Reviewers in the middle band need the model’s main reasons, the underlying data and enough time per case to disagree. Automatic approvals and declines need sampling, so that someone checks a share of them after the fact.

The metrics are straightforward. Override rates show whether reviewers ever disagree; a rate near zero suggests rubber-stamping, while a very high rate suggests the model is not trusted. Override outcomes show whether reviewers’ judgments were better, by tracking later repayment. Time per case shows whether staffing allows real review. All three belong in the monitoring pack the model risk team already produces.

The fundamental rights impact assessment. Deployers using AI to evaluate creditworthiness, or to price life and health insurance, must assess the effects on the people concerned before first use. Fundamental rights, in EU law, include rights to non-discrimination, privacy and data protection. No banking rule required this. It needs input from compliance, fair lending, customer complaints and the business line as well as model developers.

The Act sets out what the assessment must contain. It describes the process in which the system will be used and how often. It identifies the categories of people likely to be affected and the specific risks of harm to them. It records the human oversight measures and what the deployer will do if those risks materialize, including internal governance and complaint arrangements. The deployer must notify the market surveillance authority of the results. A credit card issuer using the same scoring model across several countries may need to reflect differences in those markets, such as customer populations and local complaint channels.

Explanations for individuals. A person subject to a decision based on a high-risk system’s output, with significant effects, gained a right to a clear explanation of the system’s role. Adverse action and GDPR processes already provided some of this, so the work is extending existing templates. (Adverse action notices tell an applicant why they were declined; GDPR is the EU’s general data protection law.)

Product-law paperwork for in-house models

A bank that builds its own credit model and uses it is a provider under the Act, even if it never sells the model. Putting a system into service for your own use counts. The provider must complete a conformity assessment before use, which for this Annex III category is based on internal control rather than an outside notified body. It must then draw up an EU declaration of conformity, apply the CE marking, and register the system in the EU database for high-risk AI. Serious incidents must generally be reported to the market surveillance authority within fifteen days of the provider becoming aware of them.

None of those steps exists in model risk management. Each is modest on its own. Together they create a set of legal records that a bank’s model governance process must now produce, file and keep current through every material change.

Bias testing and the data it needs

Testing a model for bias against a protected group usually requires knowing who is in that group. Banks often do not collect that information, and the GDPR treats data on ethnicity, health and similar characteristics as special categories with strict limits. The Act addressed the tension directly. Providers may process special categories of personal data where strictly necessary to detect and correct bias in high-risk systems, subject to safeguards such as pseudonymization, access restrictions and deletion once the testing is complete.

That permission does not settle the method. Banks must choose fairness measures, such as comparing approval rates or error rates across groups, and decide what differences are acceptable. These measures can conflict with one another and with predictive accuracy. A model tuned to equalize approval rates may misprice risk for some applicants. The Act does not choose for the bank. It requires the examination to be done, documented and acted on.

Becoming a provider by accident

A deployer can become a provider. Under the Act, a bank that puts its own name on a vendor’s system, or substantially modifies it, takes on provider duties for that system. Retraining a purchased model on the bank’s own data, or changing its intended purpose, could cross that line. Model development teams should flag such changes to compliance before they go live, not after.

For a bank that buys scoring from a bureau or fintech, most of the provider duties sit with the vendor. The bank still needs the vendor’s documentation and instructions to meet its own duties, and contracts signed before 2024 rarely required them. Organizations should confirm the scope of each obligation, and the classification of borderline systems, with counsel.

One credit model, from design to retirement

Following a single credit model from idea to retirement shows where the AI Act touches it, alongside the controls a bank already runs.

Design. A team proposes a new model to score personal loan applications. Under existing model risk management, they write down its purpose, the data it will use and how it will be tested. The AI Act adds two things at this stage. The team must examine the training data for accuracy and also for whether it is relevant, representative and free of biases that could lead to unfair outcomes. And the model must be designed so that people reviewing its outputs can understand them well enough to question them.

Validation and approval. An independent team checks the model, as it always has. The AI Act fields in the inventory are filled in: high-risk classification, provider and deployer role, entities and markets served. Before the model is used on real applicants, the business completes a fundamental rights impact assessment, drawing on compliance, fair lending and complaints data.

Use. The model goes live. Named staff, with the training and authority to do so, oversee its decisions and can override them. Applicants who are declined receive an explanation of the system’s role, building on existing adverse action and GDPR templates. Logs of the model’s activity are kept within the bank’s normal records.

Monitoring. Model risk teams already watch whether a model’s accuracy drifts over time. Under the Act, the bank also runs post-market monitoring and has a route for reporting serious incidents, such as a fault that causes widespread wrongful declines.

The definition of a serious incident deserves attention. Alongside physical harm and serious disruption, it includes an infringement of EU obligations intended to protect fundamental rights. A model fault that systematically disadvantaged a protected group could therefore qualify. Banks should agree in advance who decides whether an event meets the definition, because the reporting clock starts when the provider becomes aware of it.

Deployers have smaller duties of their own. They must keep the logs the system generates, for at least six months unless other law requires otherwise. They must also inform people that they are subject to the use of a high-risk system in decisions about them. Banks already keep records for far longer under financial services law, so the log duty is usually met. The notice duty means updating application journeys and decline letters.

Who signs at each stage

Each checkpoint needs a named owner. The model owner in the business line answers for the purpose, the data and the impact assessment. Model validation, in the second line, answers for independent testing and for confirming that AI Act fields are complete. Compliance answers for classification, the conformity paperwork and the link to fair lending. The data protection officer has a role too. The Act allows the impact assessment to build on a GDPR data protection impact assessment where one exists, and the two should be prepared together. Internal audit, in the third line, tests whether the whole chain worked.

The roles look familiar because they are. What changes is the content each must sign and the number of handoffs. A bank that adds three new approval steps without adjusting cycle times will slow its model releases. Some will accept that. Others will invest in tooling that captures evidence as the work happens, so approval becomes a review of records instead of a scramble to create them.

Change and retirement. When the model is updated or replaced, the same record carries the history, so a supervisor can see what changed and why.

Walked through this way, the AI Act adds checkpoints to the life cycle banks already have rather than creating a second one. Most of those checkpoints are modest extensions. A few, notably the data examination, real human oversight and the impact assessment, are genuinely new disciplines that need people, time and budget.

Cost, customers, supervisors and vendors

Beyond compliance, the AI Act touches several things a bank’s leadership cares about directly.

Cost. The supervisory design means banks do not have to build a parallel compliance organization. Extending what exists is far cheaper than starting again. But underestimating the gaps creates its own cost, in rushed remediation once a supervisor finds them.

The burden falls unevenly. A large bank with a central model risk function can absorb new checkpoints into existing teams. A small savings or cooperative bank often does not build its own models at all. In networks of such banks, scoring systems are frequently developed centrally and used by many local institutions. The central body then carries most provider duties, and each local bank becomes a deployer that needs the central body’s documentation to meet its own obligations. For those networks, the efficient answer is a shared impact assessment template and shared oversight training, adapted locally where customer populations differ.

Customers. Credit decisions shape people’s lives. A model that treats some groups unfairly, or a decline nobody can explain, is a customer problem before it is a legal one. The Act’s requirements on bias testing, oversight and explanation broadly line up with what customers would want anyway.

Supervisory relationship. Because AI questions arrive through the existing supervisor, weaknesses in AI governance will color the supervisor’s wider view of the bank. Good AI documentation, integrated with model risk records, signals a well-run institution.

Vendors. Banks that rely on purchased scores depend on their vendors to meet their own obligations. Contract renewals are the natural moment to fix that.

Useful contract terms are specific. They oblige the vendor to supply the technical documentation and instructions for use the Act requires, and to notify the bank of serious incidents and material changes. They require support for the bank’s impact assessment, with information about training data and known limitations, and cooperation with supervisory requests. A vendor that resists these terms is signaling how it will behave when a supervisor asks.

Penalties. Breaches of the high-risk obligations can draw fines of up to €15 million or 3 percent of worldwide annual turnover, whichever is higher, under the Act’s general penalty scale. Fines for prohibited practices go higher. For a bank, the supervisory consequences, such as findings, remediation orders and a weaker view of governance, are likely to bite before any fine.

How US and UK groups should read it

Banks headquartered outside the EU face a choice. They can build AI Act processes only for EU entities, or extend them across the group. In the United States, model risk management already follows the 2011 supervisory guidance known as SR 11-7. The Consumer Financial Protection Bureau had also said, in 2022 and 2023, that lenders using complex algorithms must still give specific, accurate reasons for adverse action. In the UK, the Prudential Regulation Authority’s model risk principles, published in 2023, took effect in May 2024. Much of the AI Act work, such as bias testing, override governance and vendor documentation, maps to these regimes. A single group standard, with EU-specific additions for conformity paperwork and the impact assessment, avoids running two programs.

One inventory, one map, a short list of gaps

A bank in good shape has one model inventory with AI Act fields added; a living map of duties against controls with clear owners; a short, funded list of genuine gaps; vendor contracts that require the documentation the bank needs; and oversight staff who are trained and empowered to override.

A sequence that works

The order of work matters because lead times differ. Classification comes first: every model in the inventory gets a high-risk decision, a role and a named decision-maker. Vendor outreach comes second, because contract changes wait for renewal dates and vendors need time to produce documentation. The data protection officer should be involved early, since bias testing may require processing special categories of data under safeguards that take time to design.

Next, the bank should pilot the impact assessment and the conformity paperwork on one in-house model, ideally one due for redevelopment anyway. The pilot shows how long each step takes and where templates need work. It also gives the bank a realistic budget for the rest of the portfolio, based on hours actually spent rather than estimates. Only then should the bank roll the approach across the portfolio, starting with the models that touch the most customers. Oversight training and override metrics can run in parallel, because they depend on people more than documents.

Throughout, progress should be reported through the existing model risk committee, not a new AI committee. That keeps one view of model risk and makes it easier to explain to the supervisor how AI Act work fits the bank’s governance.

The usual ways it goes wrong:

• Building a separate AI compliance silo that duplicates model risk records and confuses examiners.
• Reading the derogations as an exemption and leaving risk management, post-market monitoring and incident reporting unaddressed.
• Treating bias testing as already done because fair lending analysis exists, without checking it meets the Act’s framing.
• Nominal human oversight, where reviewers lack the time, information or authority to disagree with the model.
• Forgetting purchased models, on the assumption that the vendor carries all the obligations.
• Leaving the impact assessment to data scientists alone, without compliance, complaints and business input.

The case for waiting, and its limits

Some banks concluded in 2024 that the high-risk deadline was far enough away, and the rules uncertain enough, to defer the work. Guidance and standards were still being written, and the deadline might move. The second part of that view turned out to be right. The first part had a cost. Much of the work, especially the data examination, override governance and vendor contracts, depends on long cycles: model redevelopment, contract renewals, staff training. Banks that started late would compress years of change into months, and the other rules on automated credit decisions were not waiting.

Where AI Act gaps hide in a credit portfolio

1. Which of our systems fall into the AI Act’s high-risk categories, and which are excluded, such as fraud detection? Who made that call?
2. Which AI Act duties do our existing model risk controls meet, which need extending, and which are genuine gaps? Who owns that map?
3. How have we tested training and test data for bias, and is that documented in a way that meets the Act as well as fair lending rules?
4. Who can override an automated credit decline, on what evidence, and how often are overrides reviewed?
5. Do our contracts with scoring vendors require them to give us the documentation and instructions we need?

With hindsight

The AI Act entered into force on August 1, 2024. Its obligations were designed to switch on in stages. Prohibitions on certain uses applied from February 2025, and obligations for general-purpose AI models, the large, flexible systems that underpin many chatbots and other tools, from August 2025.

A less noticed duty also applied from February 2025: providers and deployers had to take measures to ensure a sufficient level of AI literacy among staff dealing with AI systems. For banks, that meant extending model risk training beyond specialist teams to the credit officers and reviewers who rely on model outputs. Member states then had until August 2025 to designate the authorities that would enforce the Act.

The Commission also began issuing guidance. In February 2025 it published guidelines on the definition of an AI system and on the prohibited practices. The Act set February 2026 as the deadline for guidance on classifying high-risk systems, the guidance that matters most for borderline credit and pricing tools. Until it arrived, banks building their maps had to work from the legal text.

The high-risk obligations, including credit scoring, were originally due in August 2026. The Commission proposed a change in November 2025. EU lawmakers agreed on an amendment in May 2026, in force since July 2026, that moved the rules for high-risk uses listed in Annex III, including credit scoring, to December 2, 2027. Banks should confirm the dates that apply to them with counsel.

Other rules on the same decisions kept moving. In February 2025, the Court of Justice ruled in a case involving Dun & Bradstreet Austria that a person subject to an automated credit assessment is entitled to a meaningful explanation of the procedure and principles actually applied, without hiding behind trade secrets as a blanket answer. The revised Consumer Credit Directive was due to apply from November 2026, with its own rights to human intervention and explanation. A bank that paused AI Act work during the delay still faced these duties on the original timetable.

Outside the EU, the direction varied. In the United States, the federal government shifted toward a lighter touch on AI in 2025, but states moved on their own. Colorado enacted an AI law in May 2024 covering high-risk systems used in consequential decisions, including lending, with an effective date first set for February 2026 and later pushed to June 2026. US lenders with EU operations found the work overlapping, and organizations should check the current status of each regime with counsel.

The delay buys time; it is no reason to stop. The work described here takes longer than it looks: mapping duties to controls, testing data for bias, designing real human oversight and fixing vendor contracts. Much of it is good practice regardless of the deadline.

The supervisory design held. In November 2025 the European Banking Authority, the EU agency that coordinates banking regulation, reported on its mapping of the AI Act against banking and payments law, focused on credit scoring. It found no significant contradictions and planned no new guidelines for now. That is reassuring: banks are not facing a clash between two rulebooks.

The authority also noted that the targeted derogations did not extend to areas such as human oversight and data governance. That is the split described here: integration where banking rules already reached, and new work where they did not.

The broader takeaway for any regulated organization is that new technology rules rarely arrive on a blank page. They tend to be grafted onto existing supervision. The efficient response is to extend what already works, be honest about what it never covered, and put the new effort there.