Does the EU AI Act apply to our credit scoring models?
A lender's credit scoring model may now be the subject of a regulator's question, a customer contract clause or an internal audit request that refers to the AI Act. The starting point is Annex III point 5(b), which classifies AI used to evaluate creditworthiness or set credit scores as high-risk, with the exception of financial fraud detection. The high-risk rules for Annex III systems apply from 2 December 2027, as amended in 2026, so the question for most lenders is less whether a deadline exists and more which of their models fall inside the category and what they must prepare before that date.
The answer depends on three things. The first is the use case: a model that scores applicants for loans or sets a credit score is in scope, while a model that only flags suspicious transactions for fraud review falls under the exception, and borderline tools such as affordability calculators or collections prioritization need a documented analysis. The second is the role. A bank that buys a scoring engine from a vendor and configures it for its own lending decisions is usually a deployer, while a company that develops the system and places it on the market is a provider, and some institutions hold both roles for in-house models. The third is whether the institution already operates under Union financial services governance rules, which affects how several provider and deployer duties can be met.
Before the 2027 date, ask your compliance team to produce a written scope note for each scoring model, covering the purpose, the decision it informs, the role you hold and the financial supervisor you expect to deal with. Confirm the classification approach against the draft Commission guidelines on high-risk classification and with your national financial supervisor, since the Act assigns supervision of high-risk systems used by regulated financial institutions to the authority responsible for their financial supervision. Outside help can prepare this inventory and scope analysis, but the institution owns the classification decision.
Which duties apply to a bank acting as provider or deployer
A bank using a credit scoring system is usually a deployer, and a bank that builds or substantially changes its own system may also become a provider. The duties below run in parallel, and several of them can be met through records the bank already keeps under financial services law, provided the AI Act elements are included.
Quality management system under the financial sector route
Article 17 requires a quality management system for providers of high-risk systems. Under Article 17(4), a financial institution is treated as compliant through its internal governance rules under Union financial services law, except for risk management, post-market monitoring and incident reporting, which still need their own AI Act treatment. Ask for the governance document that maps each Article 17 aspect to an existing control and shows where the three exceptions are handled separately.
**Fundamental rights impact assessment** before first use
Article 27(1) requires deployers of credit scoring systems to assess the impact on fundamental rights before first use. The assessment must be completed before the system goes live, not after the first decisions are made. An assessor will ask for the dated assessment, the affected groups considered, the safeguards chosen and who approved them.
Technical documentation kept in financial records
Under Article 18(3), a financial institution may keep the technical documentation for its high-risk system as part of the documentation it already keeps under Union financial services law. The bank must still be able to show that the AI-specific technical content exists and is current. Check that model versions, data sources and intended purpose are recorded in the same register the supervisor reviews.
Logs kept within financial services documentation
Article 19(2) allows financial institutions to keep the automatically generated logs as part of the documentation they hold under financial services rules. The logs should let the bank reconstruct how a credit decision was produced, including the input data, model version and the time of the decision. Ask whether retention periods in the financial records cover the period in which a borrower can contest a decision.
Deployer monitoring met through governance rules
Article 26(5) treats the duty of a deployer that is a financial institution to monitor the high-risk system as fulfilled when it complies with its internal governance rules under financial services law. Article 26(6) then requires that the bank keep the logs as part of its financial services documentation. Evidence an assessor will request includes monitoring procedures, review minutes, exception reports and records showing that governance reviews covered the credit scoring system.
Who is paid for what in AI Act readiness for lenders
This table lists each cost component of AI Act readiness for a lender using creditworthiness or credit scoring AI, who is paid for it, whether it is one-time or recurring, and what drives it up. Use it to shape a request for quote, since no figures are given here and each line should be priced from your written scope. The main takeaway is that the largest recurring costs sit with your own staff, while outside help is usually concentrated in setup.
| Cost component | Who is paid | One-time or recurring | What drives the cost |
|---|---|---|---|
| Internal model risk and compliance staff | Your own employees (risk, compliance, model owners) | Recurring | Number of credit models in scope, how many are already governed under existing model risk rules, and how often models are re-validated |
| Legal counsel for classification | External law firm or in-house counsel | One-time, then periodic review | Whether each use falls under Annex III point 5(b) or the fraud detection exclusion, and how many systems need a written position |
| Implementation partner for inventory and mapping | Implementation partner under a written scope | One-time, with updates | Number of AI systems, vendor-supplied models, and how much system documentation already exists |
| Technical documentation and log setup | Implementation partner and your engineering team | One-time build, recurring upkeep | Logging architecture, retention periods set by your financial services rules, and integration with existing model governance tools |
| Fundamental rights impact assessment preparation | Your compliance team, with optional outside support | One-time per system, with reviews | Number of credit scoring deployments and the depth of your existing fairness and customer impact analysis |
| Tooling and infrastructure | Software vendors and your cloud or data center budget, plus self-hosted open-source platform costs paid to your staff or partner | One-time setup, recurring licences and hosting | Whether you reuse existing monitoring and governance platforms, and the hosting model you choose |
| Notified body or assessor, if applicable | Notified body or independent assessor, not DeployOpen | Usually one-time per conformity cycle, with surveillance | Whether the system falls under a route requiring a notified body under Article 43; most Annex III systems use internal control (Annex VI) |
| Ongoing monitoring and incident handling | Your operations and risk teams, optional retainer support | Recurring | Post-market monitoring under Article 72 and how it is folded into existing supervisory monitoring under Article 72(4) |
Who owns the controls, who prepares evidence, and who reviews it
The lender remains accountable for its credit scoring or creditworthiness system. It decides whether a use falls under Annex III point 5(b), owns the risk management and governance decisions, and signs off the fundamental rights impact assessment required by Article 27(1) before first use. Where the lender is also the provider of an in-house system, it owns the quality management system and technical documentation. Financial institutions can rely on their internal governance rules under Union financial services law, so the credit risk, compliance and model risk functions usually carry this work.
- Classification decisions: Record why each model is or is not used for creditworthiness or credit scoring, and why fraud detection is treated separately.
- Fundamental rights impact assessment: Own the assessment, its scope, the affected groups and the mitigation decisions before first use.
- Governance sign-off: Approve policies, risk acceptance and any changes to the system through the existing model risk process.
- Monitoring duties: Decide how Article 26(5) monitoring is met through governance rules and who reviews the results.
- Supervisor contact: Keep the named owner who answers the financial supervisor's questions.
Check whether your internal governance rules already name these owners, and whether the classification record is current for every model in the inventory.
An implementation partner such as DeployOpen prepares the technical side of the evidence. Work is carried out on the lender's own infrastructure, whether cloud accounts, data centers or air-gapped networks, using self-hosted open-source platforms. The partner can configure log retention, build documentation pipelines, set up model and data versioning, and assemble the evidence packs that the lender's owners review. It does not decide whether a system is high-risk, does not sign the fundamental rights impact assessment, and does not issue audit reports or certifications.
- Logging and records: Configure automatically generated logs under Article 19 and align retention with the financial services documentation the lender already keeps.
- Technical documentation: Prepare system descriptions, data lineage and version records that feed the documentation kept under Article 18(3).
- Access and change controls: Implement role-based access and change tracking for the scoring pipeline, with records the lender can show a supervisor.
- Evidence packs: Assemble test results, monitoring outputs and incident records in a structure the lender's governance committee can review.
- Scope boundaries: Agree in writing which artifacts the partner delivers, which the lender produces, and who maintains them after handover.
Confirm with the lender's compliance function which artifacts it will accept as evidence before the fixed scope is signed.
Under Article 74(6), the market surveillance authority for high-risk systems used by regulated financial institutions in direct connection with financial services is the national authority responsible for their financial supervision. Supervisors review the lender's governance, classification records and evidence during their normal supervisory work. Independent bodies play a different role: only an independent auditor, assessor or certification body can issue an audit report or certificate. Most Annex III systems rely on internal control under Annex VI, so the lender's own declaration and documentation are the core of the conformity route, with external review used where the lender chooses it or where a standard or contract requires it.
- Supervisory review: Expect questions on classification, the fundamental rights impact assessment, logs and monitoring, drawn from the lender's own records.
- Independent assessment: Engage an independent auditor or assessor if assurance is required by a contract, investor or internal audit, and confirm what report they will issue.
- Notified bodies: Note that notified bodies are involved for some biometric systems and Annex I products, not typically for credit scoring under Annex III point 5(b).
- Evidence readiness: Keep records in a form that can be produced quickly, without reconstructing them after a request.
- Partner limits: DeployOpen prepares evidence but does not issue audit reports, attestations or certifications.
Ask your supervisor and any assessor which records they expect and in what format before the evidence design is finalized.
How a lender moves from classification to supervisory-ready evidence
This sequence takes a lender from an inventory of its credit models to a documented, supervisor-ready evidence pack. Each phase produces a artifact that the next phase depends on, so gaps are found while they are still cheap to fix.
Inventory and classify credit models
The compliance lead and the model risk team list every system that evaluates creditworthiness or sets a credit score, including scorecards, machine learning models and rules engines that use AI techniques. Each entry is tested against Annex III point 5(b), and fraud detection uses are separated out under the carve-out for financial fraud detection. The output is a classified inventory that records, for each system, whether it is high-risk and why. The step is done when every lending decision flow maps to an inventory entry and each classification has a written rationale.
Map provider and deployer roles
Legal and procurement review each system to establish whether the lender is the provider, a deployer, or both. Vendor scoring tools, bureau-supplied models and outsourced decisioning engines need particular attention, because putting a system on the market under the lender's own name or substantially modifying it can change the lender's role. The output is a role map that names the party responsible for each duty, along with the contract clauses that carry information between them. It is complete when every high-risk entry has a named provider and a named deployer and the vendor contracts give the lender the documentation it needs.
Run the gap review against financial-sector routes
Compliance and internal audit compare current governance, risk and monitoring practice with the requirements in Chapter III and with the financial-sector provisions of Article 17(4), Article 18(3), Article 19(2) and Article 26(5) and (6). The review establishes which obligations the lender can meet through its existing internal governance rules under Union financial services law and which need new work, such as the non-excluded parts of quality management. The output is a gap register with an owner and a remediation action for each gap. The step is done when the supervisory authority that will act as market surveillance authority under Article 74(6) is identified and each gap has a documented route.
Prepare the fundamental rights impact assessment
The lender prepares the assessment required by Article 27(1) before first use of each credit scoring system. The risk, legal and business owners describe the process, the categories of people affected, the likely risks of harm and the oversight and mitigation measures, and they state how they will respond if a risk materializes. The output is a signed assessment for each system, with a record of who reviewed it and when it will be refreshed. The step is done when the assessment is complete before the system goes live and its findings feed into the design and monitoring work in the next phases.
Build the quality management system and technical documentation
Model risk, engineering and compliance agree on a quality management approach that uses the lender's existing governance where Article 17(4) allows it. They then assemble technical documentation under Article 18(3), covering the model purpose, data sources, training and validation, performance limits and human oversight arrangements. EN 18286:2026 on quality management was cited in the Official Journal on 14 October 2026, so teams should check whether it applies to their approach. The output is a versioned documentation set for each system, linked to the inventory entry. It is complete when an independent reviewer can trace each decision from the requirement to the document that meets it.
Set up logging and post-market monitoring
Engineering configures automatic logging for each credit system so that events needed for traceability are recorded and kept as part of the financial services documentation under Article 19(2) and Article 26(6). Operations defines monitoring for drift, accuracy, complaints and incidents, and sets how findings are escalated under Article 72(4) where existing monitoring is extended. The output is a logging specification, a monitoring plan and a tested incident route. The step is done when a sample decision can be reconstructed from the logs and the monitoring alerts reach a named owner.
Assemble the supervisory evidence pack
The compliance lead collects the outputs of the previous phases into one pack for each credit system, indexed to the requirements and the classification rationale. The pack contains the inventory entry, role map, gap closure record, fundamental rights impact assessment, documentation set, log samples and monitoring reports. Before release, an internal reviewer checks that every item is current and that the pack can answer a supervisor's questions without extra explanation. The output is a dated, version-controlled evidence pack. Ask the implementation partner or auditor which parts they can prepare and which must be attested by the lender's own governance functions.
What makes lender AI Act work heavier or lighter
The effort of AI Act compliance for a lender depends less on the law itself than on how many models it runs, who built them, and how much existing governance it can reuse. The cards below cover the drivers that move the workload up or down and the controls that keep each one manageable.
Number of credit models
Each creditworthiness or credit scoring system that falls under Annex III point 5(b) needs its own risk management, technical documentation, logs and human oversight design. A lender with dozens of scorecards for retail, small business and card products carries far more work than one with a single model. Start with a complete inventory that flags which systems evaluate creditworthiness or set credit scores, and exclude fraud detection only where the purpose is genuinely fraud detection. Ask whether one credit model feeds several products, because a shared model usually means one shared file set.
Vendor scoring tools
When a credit score comes from a third-party tool, the vendor is usually the provider and the lender is the deployer, but the lender still carries deployer duties such as monitoring, input data control and log retention. Contracts should require the vendor to supply technical documentation, instructions for use, change notices and access to logs. Confirm with the vendor which AI Act elements its product already covers and which it has not yet addressed, because gaps there become gaps in your file.
Built in-house or bought
A model the bank builds itself makes it the provider, so it must run the full set of provider obligations, including the quality management system, conformity route and registration. A bought model moves some provider work to the vendor while leaving deployer work with the bank. Decide this per model at the design stage, because changing role after a substantial modification can shift obligations without warning. Record the decision and its basis in the inventory.
Existing model risk governance
Many lenders already run model risk management under prudential supervision. Article 17(4) lets financial institutions meet most quality management expectations through their internal governance rules under Union financial services law, but risk management, post-market monitoring and incident reporting stay outside that route. Map each AI Act element against current validation, monitoring and incident processes to see which ones extend cleanly and which need new work. Gaps usually sit in fundamental rights analysis and in logging for non-financial data.
Data residency and log volume
Article 19 requires logs to be kept for a period appropriate to the intended purpose, and Article 18 documentation must be retained. Scoring at scale generates high log volumes, and those logs may contain personal data subject to GDPR. Decide where logs are stored, how long they are kept and who can read them before go-live. Self-hosted logging inside the bank's own environment makes residency easier to show, but it also makes the bank responsible for storage capacity, backup and access control.
Number of jurisdictions
The AI Act applies across the EU, but national supervisory structures, language requirements and parallel rules for consumer credit or data protection vary by country. A lender operating in several member states must identify which financial supervisor acts as market surveillance authority for each activity, as Article 74(6) assigns that role to the authority responsible for financial supervision. Build one control set with country-specific annexes rather than separate programs, and confirm local requirements with counsel in each market.
Questions lenders ask before the 2027 date
Does a fraud detection model fall under the AI Act high-risk rules for lenders?
Usually not, if the model is used only to detect financial fraud. Annex III point 5(b) classifies AI used to evaluate creditworthiness or set credit scores as high-risk, and it excludes financial fraud detection from that category. Scope follows the purpose the system serves. A model that detects payment fraud but also feeds an approval decision or a credit limit for a borrower may fall back into scope, so map each output to its use. Record the intended purpose in your AI system inventory, confirm the classification with legal counsel, and read the Annex III text alongside the draft Commission guidelines on high-risk classification before you rely on the carve-out.
Does buying a credit scoring tool make the bank a deployer?
Yes, in most cases. A bank that uses a third-party scoring system under its own authority in the EU is a deployer, while the vendor that develops the system and places it on the market is the provider. Deployer duties stay with the bank even though the vendor carries most of the conformity work. The bank must use the system according to its instructions, assign human oversight, keep logs, monitor operation and, before first use, complete a fundamental rights impact assessment under Article 27. Contracts should require the vendor to supply instructions for use, technical documentation, log access and notice of serious incidents. A bank that changes the intended purpose or substantially modifies a bought system can take on provider duties, so agree those limits in writing with the vendor and counsel.
How does a fundamental rights impact assessment differ from a DPIA?
A FRIA asks how a high-risk AI system could affect people's fundamental rights, while a DPIA under the GDPR asks how processing of personal data creates risk and which safeguards reduce it. The FRIA under Article 27 is a deployer duty for credit scoring, completed before first use, and its scope reaches beyond data protection to rights such as non-discrimination and access to essential services. Many banks already run DPIAs for scoring, so one review can share steps such as describing the processing, identifying affected groups and listing safeguards. Keep the FRIA as a separate record with its own findings and sign-off, and cross-reference the DPIA. Ask counsel whether your national authority expects a specific format, and confirm with your supervisor what must be notified after the assessment.
Do our internal governance rules replace the AI Act quality management system?
Partly. Article 17(4) treats financial institutions as meeting the quality management system requirements through their internal governance rules under Union financial services law, with three exceptions: risk management, post-market monitoring and incident reporting. Those three still need their own evidence. Existing model risk, credit governance and operational incident controls are the starting point, so map each AI Act element to a named control and an accountable owner. Gaps usually appear in AI-specific areas such as data governance records, accuracy and robustness testing, and monitoring of system behavior in production. Article 72(4) allows existing monitoring systems to be extended if they give equivalent protection, and that equivalence should be documented. Have your compliance lead approve the mapping well before the 2 December 2027 date.
Which authority supervises AI Act compliance for a bank?
For high-risk AI systems placed on the market, put into service or used by regulated financial institutions in direct connection with financial services, Article 74(6) makes the national authority responsible for financial supervision the market surveillance authority. In practice this is likely the supervisor that already oversees your prudential and conduct obligations. That matters for evidence, because supervisors will read AI Act documentation alongside the governance, model risk and incident records they already review. Other authorities can still be involved in some matters. The Commission's AI Office is exclusively competent only in particular cases, such as AI systems built on a provider's own general-purpose model. Confirm your national designation with your supervisor, and keep one evidence set that answers both sets of questions.
What does the AI Act work need from our internal teams?
Mostly time from people who already own credit decisions. Credit risk and model validation teams define the intended purpose, performance measures and fairness checks. Data and engineering teams produce logs, data lineage, version records and production monitoring. Compliance and legal own the classification, the FRIA and the governance mapping, while procurement manages vendor evidence. A named accountable executive should sign off the scope and the residual risk. Operations and customer teams need to understand how human oversight works and how explanations reach applicants. An outside implementation partner can prepare systems and evidence, but the bank owns each control and each sign-off. Ask any partner to list the internal roles it needs in the written scope, so the bank can plan staff time before work starts.
Can a bank run AI Act readiness without outside help?
Often yes for inventory, classification and governance mapping, if the team has AI Act knowledge and spare capacity. Many banks keep those tasks in house and bring in help for the heavier technical work, such as logging architecture, evidence collection across self-hosted tools, testing and documentation. DeployOpen can plan, configure, integrate and document self-hosted open-source platforms inside your own infrastructure, under a fixed-scope written agreement. It prepares systems and evidence for assessment, but it does not issue reports or certifications, and the bank still makes the decisions and signs off the controls. To decide what stays in house, list the tasks that require judgment only your staff can exercise. Before work starts, get a written scope, deliverables and timeline, and confirm with your supervisor which evidence it expects.
What to check before hiring a consultant or implementation partner
Before you sign with a consultant or implementation partner for AI Act work on a creditworthiness or credit scoring system, check four things: whether they have worked on financial-sector model governance, whether they will work inside your infrastructure, whether the scope is fixed and written down, and whether it is clear who does what. Ask for named examples of model risk governance work inside regulated lenders, and ask how they would fit the Article 17(4) route, where internal governance rules under Union financial services law can cover much of the quality management system. A partner who has never met your model validation or credit risk committees will need more of your team's time to be useful.
Ask whether the partner will deploy and operate tooling inside your own cloud accounts, data centers or air-gapped environment, and who keeps administrator credentials, logs and model artifacts afterwards. Ask for a written statement of scope, deliverables and timelines before work starts, including what happens to logs under Articles 19 and 26(6) and what is excluded. Then confirm the split of roles in writing: the bank owns its controls and decisions, the partner prepares systems, documentation and evidence, and your financial supervisor, or another independent body where one applies, assesses the result. Confirm with your supervisor which authority is competent for your system under Article 74(6).
No consultant, implementation partner or auditor can guarantee a supervisory outcome. A well-prepared evidence pack does not replace the judgment of the national authority responsible for your financial supervision, and a partner's past engagements do not predict how your supervisor will read your fundamental rights impact assessment under Article 27. Treat any promise of approval or certification as a warning sign. Plan for the possibility of findings, budget time for remediation, and ask the partner to say which parts of their work an independent assessor would be expected to test.
How DeployOpen prepares lender AI systems and evidence
DeployOpen works on the EU AI Act for banks, lenders and credit scoring as an implementation partner inside your own infrastructure. We prepare the systems, controls and evidence that your organization owns, while independent auditors and certification bodies remain the only parties that issue reports or certificates.
How we scope
- Confirm which models score creditworthiness and which serve only fraud detection, then record the boundary in writing.
- Agree in writing which systems, teams, data sources and deliverables fall within the engagement before work starts.
- Map existing financial services governance and monitoring so the work builds on controls you already run.
How we build
- Set up the technical documentation and automatically generated logs for each in-scope credit model in your environment.
- Prepare the inputs for the fundamental rights impact assessment, including data, affected groups and oversight measures.
- Test logging, access and change records against the evidence your supervisor and internal audit are likely to request.
How we hand over
- Deliver the documentation, control records and evidence index in formats your compliance and model risk teams can maintain.
- Walk your owners through each artifact so they know where it lives, who updates it and how often it changes.
- Document open items and the questions to confirm with your legal counsel and financial supervisor before relying on them.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work closes.
- Retainers can cover model changes, log reviews and updates to documentation as credit models are retrained or replaced.
- Ask any implementation partner to state in writing which steps remain with your team and which require an independent assessor.
