Mortgage and Loan AI Under the EU AI Act: High-Risk by Design
Mortgage and loan AI is high-risk under Annex III point 5(b). Provider and deployer obligations, FRIA, GDPR Art 22, and the 2 Dec 2027 deadline explained.
Automated underwriting for mortgages and consumer loans sits squarely in the high-risk tier of the EU AI Act (Regulation (EU) 2024/1689). The classification is not a grey-area judgment call. Annex III, point 5(b) lists "AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score" as high-risk — and that language covers every system that feeds into a mortgage decision, from initial eligibility filters to final rate-setting engines. If you build or deploy one of these systems, the full high-risk obligation stack applies. The deadline is 2 December 2027 for stand-alone systems under the Digital Omnibus agreed in May 2026.
This article sets out what the classification means in practice: who bears which obligations, where discrimination law intersects with AI regulation, how GDPR Article 22 sits alongside the Act, and what a mortgage lender's compliance programme actually needs to cover.
Why mortgage AI is unambiguously high-risk
Annex III organises high-risk use cases under eight headings. Mortgage and consumer-loan decisions fall under heading 5: "Access to essential private and public services and benefits." Point 5(b) covers creditworthiness evaluation and credit scoring of natural persons. The explicit carve-out in the same provision — "AI systems used for fraud detection purposes shall not be considered high-risk" — applies only to fraud-detection models. A model that evaluates repayment risk or sets interest rates is not a fraud-detection system. The carve-out does not apply.
The Article 6(3) filter allows a provider to conclude that its Annex III system is not high-risk if it can document that the system poses no significant risk of harm to health, safety, or fundamental rights. Four examples are given: narrow procedural tasks, improving a previously completed human activity, detecting decision patterns without replacing or influencing human assessment, and preparatory work. A mortgage underwriting model does none of these things. It produces an output that directly influences whether someone obtains housing finance — and any system that profiles natural persons is always high-risk regardless of the Article 6(3) filter. In practice, no mortgage lender should attempt to claim that exemption without a watertight legal opinion and documented risk assessment.
Worked example. A regional lender in Frankfurt runs an automated underwriting system: the applicant submits income data, employment history, and property details; the system scores creditworthiness, recommends approve or decline, and sets an indicative rate. This is a stand-alone Annex III point 5(b) system. The lender is a deployer (Art 26) of third-party software — or, if it built the model in-house, a provider (Art 16) simultaneously acting as deployer. Either way, the high-risk regime applies. Obligations attach from 2 December 2027.
Provider obligations: what the system builder must do
If your organisation develops and places a mortgage AI system on the market — or makes it available as SaaS to lenders — you are a provider under Article 3(3) and must satisfy the obligations in Article 16 by meeting the requirements in Articles 9 through 15, completing conformity assessment under Article 43, and registering in the EU database under Article 49.
Article 9 — Risk management system
Providers must establish, implement, document, and maintain a risk management system throughout the AI system's lifecycle. For a mortgage scoring model, this means identifying the reasonably foreseeable risks the system poses to the natural persons it evaluates: discriminatory outcomes, systematic errors for underrepresented populations, model drift as macroeconomic conditions change, and adversarial manipulation of input data.
The risk management system must be iterative. Risks identified in testing must be addressed before market placement; risks emerging post-deployment must feed back into the system through post-market monitoring under Article 72. Article 9(4) specifically requires testing the system against the population of people for whom it is intended — not just a convenient sample. A model trained predominantly on applicants from urban, high-income areas will not have been tested against the diversity of actual mortgage applicants across the EU.
Article 10 — Data and data governance
Article 10 governs the data used to train, validate, and test the system. This is not a staff-training requirement — that sits separately in Article 4. Article 10 requires providers to ensure training data is relevant, sufficiently representative, and free from errors that could cause discrimination or other risks. For mortgage AI, that obligation bites hardest on historical training data: decades of lending records contain the sediment of past discriminatory practices — redlining by geography, gender-based underwriting, differential treatment of non-traditional employment. A provider who trains on that data without scrutinising it for embedded bias fails Article 10.
Providers must document data sources, selection criteria, known limitations, and the measures taken to mitigate identified data gaps or biases.
Article 11 — Technical documentation
Before a system goes to market, providers must compile the Annex IV technical documentation pack. For mortgage AI, this includes the system's intended purpose and scope; a description of the model architecture; training, validation, and testing data with their sources and demographic composition; performance metrics disaggregated by applicant population; human oversight mechanisms; and the residual risks that could not be eliminated.
This documentation must be kept for ten years from market placement and must be available to national competent authorities on request.
Article 13 — Transparency and information to deployers
Providers must give deployers — the lenders — the information they need to use the system correctly and meet their own obligations. The instructions for use must explain the system's intended purpose, accuracy, and performance characteristics, including for specific subgroups where performance differs materially. They must also specify what human oversight the system requires and what the known limitations are. A lender cannot conduct a meaningful Article 27 FRIA (see below) if the provider's documentation does not tell them what the system actually does.
Article 14 — Human oversight
The system must be designed so that human overseers can understand its outputs, monitor it in operation, and override it. For mortgage AI, this means the system must produce output that a loan officer can actually interpret — not just a score with no explanation. Where a system includes a "black-box" component, the provider must implement explainability mechanisms (for example, feature attribution showing which inputs drove the recommendation) so that the person reviewing the decision can make a genuine judgment, not just ratify whatever the algorithm said.
Article 15 — Accuracy, robustness, and cybersecurity
The system must achieve appropriate levels of accuracy for its intended purpose and remain accurate across the population of users, not just the majority demographic. Article 15 also requires that the system behave consistently and be resilient to adversarial inputs. A mortgage scoring model that produces unstable results when input data contains minor inconsistencies — common with self-employed applicants — fails the robustness requirement.
Article 43 — Conformity assessment
Before market placement, providers must complete a conformity assessment demonstrating that the system meets Articles 9 through 15. For Annex III systems, the default path is internal control under Annex VI (self-assessment, documented in the technical file). Where the provider has not applied harmonised standards covering all requirements, it may opt for the third-party assessment path under Annex VII. The conformity assessment record must be kept for ten years.
Article 49 — Registration
Following conformity assessment, providers must register the system in the EU database before it goes to market. Registration is Article 49, not the declaration of conformity (Article 47) or any other provision. The two are separate steps: the declaration confirms the system is compliant; registration makes that fact publicly searchable.
Deployer obligations: what the lender must do
Most mortgage lenders — banks, building societies, specialist lenders — deploy a third-party underwriting system or a model built by their own data science team. Either way, as the entity that puts the system to use in its own underwriting process, the lender is a deployer under Article 26.
Article 26 — Deployer obligations
Article 26 sets out what deployers must do. The obligations include:
- Using the system only for its intended purpose and in accordance with the provider's instructions.
- Assigning human overseers who have the competence, training, and authority to understand and intervene in the system's outputs.
- Ensuring that input data is relevant and representative of the actual applicant population.
- Monitoring system operation in live use and reporting serious incidents and malfunctions to the provider and, where applicable, to the competent authority under Article 73.
- Keeping logs for at least six months (the statutory minimum for deployer log retention under Article 26).
The log-retention minimum is six months, not three years. The old article's figure of three years has no basis in the Act.
Article 27 — Fundamental Rights Impact Assessment (FRIA)
Article 27 requires certain deployers to conduct a Fundamental Rights Impact Assessment before putting a high-risk system into use. The FRIA obligation applies to deployers that are: public bodies, or private entities deploying high-risk AI in the context of creditworthiness assessment or credit scoring of natural persons. A bank deploying mortgage AI is squarely in scope. The FRIA is not optional.
The assessment must cover: a description of the processes in which the system will be used and the decisions it will influence; the categories of natural persons affected; the specific fundamental rights risks and the likelihood and severity of harm; the human oversight measures in place; and the actions taken to address identified risks.
The FRIA must be documented, registered in the EU database under Article 49(1)(d), and notified to the relevant market surveillance authority. It is a living document — if the system or its use changes materially, the FRIA must be updated.
In practice, the FRIA for a mortgage lender should address non-discrimination in detail, because lending decisions directly engage the right to equal treatment under the EU Charter of Fundamental Rights and the EU Equality Directives (2000/43/EC and 2004/113/EC).
Discrimination and proxy variables
The EU AI Act does not create new anti-discrimination law — the Equality Directives already prohibit direct and indirect discrimination on protected grounds including race and ethnic origin, gender, age, disability, religion, and sexual orientation in access to financial services. What the Act adds is a formal requirement to test for and document the model's behaviour across those dimensions.
Mortgage AI raises a specific and recurring problem: proxy variables. A model might not use ethnicity or gender as direct inputs yet produce discriminatory outcomes because it relies on features that correlate with protected characteristics. Common examples:
- Postcode correlates with ethnic composition of neighbourhoods. A model that penalises applicants from certain postcodes can replicate the effect of ethnicity discrimination without ever processing ethnicity data.
- Employment type (zero-hours contracts, self-employment) correlates with gender and ethnicity in many EU labour markets.
- Gap years in employment history correlates with parental leave patterns, which in practice correlates with gender.
- Proportion of income from benefits correlates with disability status.
Article 10(5) explicitly requires providers to take into account "reasonably foreseeable misuse" of the system, and Article 9(2)(a) requires identification of "risks posed to persons or groups of persons" — which covers proxy-variable discrimination. Providers must test whether the model produces materially different outcomes for applicants with equivalent repayment capacity but different demographic profiles. Where disparities exist, the risk management system must document them and either remediate the model or constrain its use.
For deployers, the Article 27 FRIA is the mechanism to carry out this analysis in the specific lending context. A lender cannot simply accept a provider's word that the model is fair — Article 27 requires the lender to assess the fundamental rights impact itself, with reference to the specific population of applicants it serves and the specific decisions the model informs.
GDPR Article 22 and adverse-action explanation
Mortgage decisions are not just AI Act territory. GDPR Article 22 applies where a decision is based "solely on automated processing, including profiling" and produces legal or similarly significant effects on a natural person. Mortgage denial is the textbook case of a significant effect.
Where Article 22 applies, the data subject has three rights: not to be subject to the decision; to obtain human intervention and to express their point of view; and to obtain an explanation of the decision. The third right — explanation — is where AI Act and GDPR obligations converge directly.
Under the AI Act, the provider must design the system so that a loan officer can understand and explain the output (Articles 13 and 14). Under GDPR Article 22(3), the controller must provide meaningful information about the logic involved. These requirements are complementary but not identical in scope. Satisfying the AI Act's explainability design requirements does not automatically fulfil the GDPR's per-applicant explanation obligation — the lender must also have a process for generating and delivering applicant-level explanations when requested.
In practical terms: the loan officer reviewing an AI-assisted decision must be able to articulate, to the rejected applicant, which factors drove the outcome and why the decision was reached. A system that produces only a score with no feature-level attribution fails both regimes.
Penalties: Article 99
Non-compliance with the high-risk requirements — Articles 9 through 15 for providers, Article 26 and 27 for deployers — falls under the middle tier of the Article 99 penalty structure: up to €15,000,000 or 3% of total worldwide annual turnover, whichever is higher. For a large bank, 3% of worldwide turnover can far exceed €15 million.
For SMEs and start-ups, Article 99(6) provides a proportionality protection: the fine is capped at whichever is lower of the percentage or the fixed amount. A credit union or specialist mortgage lender with annual turnover of €40 million would face a maximum of €1.2 million (3%) rather than €15 million — material, but calibrated to scale.
The deadline for stand-alone Annex III systems is 2 December 2027, following the Digital Omnibus political agreement of May 2026. The original date of 2 August 2026 has been formally deferred. The extra sixteen months is preparation time, not a signal that the obligations are soft. Conformity assessment, technical documentation, and a completed FRIA each take months to complete properly. A lender starting in mid-2027 is likely to miss the deadline.
How Confir helps
Three points where Confir's rule-based compliance engine adds direct value for a mortgage lender or underwriting system provider:
Role and obligation scoping. Confir's classification workflow determines, from your answers to plain-English intake questions, whether you are a provider, a deployer, or both — and generates the obligation set that applies. A lender that licenses a third-party underwriting model has a different scope from a lender that built its own. Confir's deterministic rules derive the right answer and display only the controls relevant to your role.
FRIA workflow. Article 27 requires a structured assessment covering seven defined areas. Confir runs the FRIA as a guided workflow, maps each section to the relevant regulatory requirement, and generates an audit-ready PDF that can be submitted to the market surveillance authority and registered in the EU database.
Technical documentation and Declaration of Conformity. For providers, Confir generates the Article 11 / Annex IV technical documentation pack and the Article 47 / Annex V EU Declaration of Conformity as structured, print-ready outputs. Both documents are populated from the intake data and reflect the same classification logic, so they are internally consistent from the first draft.
Frequently asked questions
Is a mortgage affordability calculator high-risk under the EU AI Act?
A static affordability calculator that applies fixed formulae without learning from applicant data is unlikely to qualify as an AI system under Article 3(1), which requires inference, machine-learning, or statistical approaches. If the calculator is purely rule-based and applies the same fixed calculation to every input, it falls outside the Act. The moment the system uses historical data to weight factors, adjust thresholds, or personalise outputs to the individual applicant's profile, it is likely an AI system and the Annex III point 5(b) classification question becomes live.
Does the fraud-detection carve-out in Annex III apply to credit-scoring models?
No. The carve-out applies to AI systems "used for the purpose of detecting fraud in the provision of financial services." A creditworthiness model evaluates repayment risk — whether the applicant is likely to default — which is a fundamentally different assessment from detecting whether a specific transaction or application involves fraud. Lenders sometimes conflate the two, but the legislative history and the plain text of Annex III point 5(b) make clear that repayment-risk evaluation is high-risk regardless of whether the lender also operates a separate fraud-detection layer.
What is the log-retention period for deployers under Article 26?
Article 26 sets a minimum log-retention period of six months for logs automatically generated by the system that the deployer controls. This is the EU AI Act minimum. Sector-specific regulation — for example, banking supervision rules or national AML requirements — may require longer retention, and the FRIA may identify reasons to keep records longer. But six months is the Act's floor, not a target to aim for.
When does Article 22 GDPR apply to a mortgage decision?
Article 22 applies where the decision is based "solely" on automated processing. In practice, if a loan officer reviews the AI recommendation and signs off the decision, the lender will argue the decision was not solely automated. Supervisory authorities — including the EDPB — have taken a stricter view: if the AI output is decisive in practice and the human review is perfunctory, the "solely" threshold is met. Lenders should assume Article 22 applies unless they can demonstrate genuine human review, which in turn requires the meaningful oversight mechanisms the AI Act already mandates under Articles 14 and 26.
Does the FRIA requirement under Article 27 apply to all private lenders?
Article 27(2) lists the categories of deployers that must conduct a FRIA. Private entities deploying high-risk AI in the context of "creditworthiness assessment or credit scoring of natural persons" are explicitly included. Any lender deploying Annex III point 5(b) AI — mortgage lenders, consumer credit providers, personal loan originators — must conduct and document a FRIA before going live. There is no turnover or size threshold in Article 27.
What penalty applies to a deployer that fails to conduct a FRIA?
Failure to comply with Article 27 is a breach of deployer obligations under Article 26 as read with Article 27. The applicable penalty tier is Article 99(4): up to €15,000,000 or 3% of total worldwide annual turnover, whichever is higher. For SMEs and start-ups, Article 99(6) caps the fine at whichever figure is lower.
Related guides
- Article 6 high-risk classification
- self-assessment for high-risk systems
- bias mitigation for mortgage decisions
- Article 9 risk management requirements
- risk classification framework overview
- risk assessment methodology
- high-risk AI obligations
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 7-day free trial.
Start free trial →