AI loan origination automation: how banks deploy it under EU rules

Loan origination automation spans the workflow from application intake through underwriting, KYC and AML checks, affordability assessment, decisioning, pricing, documentation and disbursement. AI components show up at every step: optical character recognition for document intake, classification for fraud screening, scoring for creditworthiness, language models for narrative summarisation and decisioning rules engines orchestrating the whole flow.

The scoring step is where Annex III 5(b) bites. The other steps are subject to GDPR, DORA ICT-resilience rules and the EBA Loan Origination guidelines, but they are not high-risk under the AI Act on their own.

The EBA Guidelines on Loan Origination and Monitoring entered into force on 30 June 2021 and apply to all credit institutions in the EU. Section 4.3 covers the use of automated models in creditworthiness assessment. Banks must understand the methodology, data inputs and assumptions, document the model in a way that allows independent challenge, monitor performance over time and ensure that automated outcomes can be reviewed and overridden where appropriate [2].

The guidelines also require explicit policy documentation on when human review is mandatory, what data points feed the decision, and what bias and fairness controls apply. They are the European supervisory baseline for any origination AI deployment.

Annex III 5(b) of Regulation (EU) 2024/1689 designates AI systems used to evaluate creditworthiness or establish credit scores of natural persons as high-risk. The narrow exception for fraud detection does not apply to origination scoring. Once high-risk classification triggers, Chapter III obligations apply in full: risk-management system (Article 9), data governance (Article 10), technical documentation (Article 11), logging (Article 12), transparency (Article 13), human oversight (Article 14), accuracy and robustness (Article 15) and post-market monitoring (Article 72).

For most banks, the gap is not the model itself but the documentation, logging and monitoring stack. Article 12 in particular requires automatic recording of events for the system's lifetime, retained for a minimum period defined by the provider and never less than six months.

An automated lending decision that produces a legal effect (granting or denying credit) is the textbook Article 22 case. The bank must rely on contract necessity (the typical basis for credit applications), implement suitable safeguards including the right to human intervention, expression of view and contest, and provide meaningful information about the logic, significance and envisaged consequences in the privacy notice and at decision point.

The 2024 EDPB guidelines reaffirm that "meaningful information" does not require disclosing trade secrets or full model internals, but does require enough that the customer can meaningfully exercise their rights. A boilerplate "we use automated processing" sentence does not satisfy the standard.

Loan origination is unambiguously a critical or important function for a bank. AI vendors providing origination components are therefore in scope of DORA Articles 28 to 30 third-party ICT risk obligations: pre-contractual due diligence, register of information, mandatory contract clauses including audit rights, sub-processor controls, exit and transition planning, and incident-reporting cooperation [3].

Click-through SaaS terms do not satisfy DORA. Vendor selection must include a documented exit plan that lets the bank migrate the workload to an alternative provider, and the contract must give the bank and its supervisor on-site audit rights.

Five layers. Data layer with documented lineage, exclusion of protected attributes and validated proxies. Model layer with version control, technical documentation aligned with Article 11 and independent validation. Decisioning layer with explicit policy on automated-approval bands, mandatory human review thresholds and escalation paths. Logging layer that meets Article 12 retention requirements. Monitoring layer with drift detection, fairness testing across protected classes and performance thresholds tied to governance triggers.

The most common audit finding is a model that scores well in development but lacks a written policy on which scores trigger automated approval, which require human review and who has override authority. The score is not the decision; the policy that maps score to action is what supervisors examine.