Are traditional logistic regression credit models in scope under Annex III point 5(b)?

Yes. The classification is by use case, not by technology. A traditional logistic regression model used to evaluate the creditworthiness of a natural person is high-risk under 5(b). The Article 12 logging requirement applies to the system, which means the inputs, the calculation, and the output have to be traceable on a per-decision basis. The misconception that the EU AI Act covers only large language models is widespread and incorrect on the point. The regulation defines AI broadly under Article 3 to include statistical approaches that produce outputs influencing decisions.

Does the fraud detection exemption cover anti-money-laundering monitoring?

Anti-money-laundering monitoring is typically considered fraud detection in the broad sense and falls under the exemption for AI used for the detection of financial fraud. The exemption applies cleanly when the AML model's output goes only to AML investigations and does not flow into a creditworthiness decision. Where AML signals feed into credit limit reductions, account closures, or scoring adjustments, the integrated decision falls back into 5(b) scope. The bank has to be clear about the data flows to claim the exemption.

How does Article 26 interact with the Consumer Credit Directive's adverse action requirements?

The Consumer Credit Directive and member-state implementations require lenders to provide consumers with the reasons for a credit decline and certain procedural rights. Article 26 layers an AI-specific records requirement on top. A bank that satisfies the Consumer Credit Directive disclosure obligation but cannot produce the underlying per-decision AI record fails the EU AI Act obligation. The architecture that satisfies both produces the per-decision record at the AI request boundary and feeds the Consumer Credit Directive disclosure from the same record set.

What is the relationship between Article 26 records and EBA guidelines on internal governance?

The European Banking Authority guidelines on internal governance set expectations for risk management, three-lines-of-defense organization, and outsourcing oversight. The EU AI Act Article 26 obligations operationalize the AI-specific requirements that the EBA guidelines reference at a higher level of abstraction. A supervisor reviewing a bank under the EBA guidelines will look for the Article 26 records as part of the AI governance evidence. The same records support the bank's internal three-lines-of-defense reporting on AI risk.

Does the deployer obligation transfer when the bank uses a third-party scoring service?

No. Article 26 obligations sit with the deployer regardless of whether the underlying scoring service is provided by a third party. A bank that outsources the scoring decision to a fintech vendor or a bureau remains the deployer for purposes of the credit decision. The vendor may also be the provider under Articles 8 through 17 with its own obligations, but the deployer obligations do not transfer. Procurement contracts have to require the vendor to support the bank's Article 26 obligations operationally, including the production of per-decision records on the bank's demand.

AI Credit Scoring Under Annex III Point 5(b): What High-Risk Classification Requires of Banks

Annex III point 5(b) of the EU AI Act classifies AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score as high-risk. The text exempts AI used only for the detection of financial fraud. The high-risk classification triggers Articles 8 through 17 on the provider side and Article 26 on the deployer side. From August 2, 2026 the obligations are in force. The penalty tier under Article 99 is 15 million EUR or 3% of global annual turnover, whichever is higher. Most bank credit deployments today combine bureau enrichment, fraud screening, and scoring in a single decision pipeline. The integrated pipeline triggers high-risk classification across the steps the fraud-only exemption was supposed to remove.

I want to walk through what Annex III point 5(b) covers, where the fraud-versus-scoring boundary blurs inside real bank pipelines, what Article 26 actually requires of the deployer, and the inspection architecture that produces records a supervisor will accept.

What Annex III point 5(b) covers

The text of point 5(b) reads: AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score, with the exception of AI systems used for the purpose of detecting financial fraud. The carve-out for fraud detection was added during the legislative process to avoid sweeping anti-money-laundering and transaction-fraud screening into the high-risk regime.

The phrase "creditworthiness of natural persons" covers the full assessment of whether a person can be expected to repay a credit obligation. This includes consumer credit, mortgage lending, credit card issuance, overdraft authorization, small-business lending where the obligation is personal (sole proprietor or director guarantee), buy-now-pay-later, and revolving credit facilities for individuals.

The phrase "establish their credit score" covers any AI output that produces a score, probability, or rating intended for credit decisions. This applies regardless of whether the score is a traditional logistic regression output, a gradient-boosted decision tree score, or a transformer-based score.

The exception covers AI used solely for financial fraud detection. The European Commission's accompanying guidance has signaled that the exception is narrow. A model that classifies a transaction as fraudulent or not, and feeds that classification into a separate creditworthiness model, is exempt for the fraud step. The creditworthiness step is not exempt. A combined model that fuses fraud features and scoring features into a single output is not exempt because the model is also performing creditworthiness assessment.

Where bank pipelines blur the boundary

Inside a real bank credit pipeline, the fraud-versus-scoring distinction is rarely as clean as the regulation imagines.

The first blur is fraud features inside the scoring model. Many banks include fraud-flag features in the inputs to the creditworthiness model. The model is doing creditworthiness assessment, which makes it high-risk under 5(b). The fraud features are inputs, not outputs.

The second blur is the bureau enrichment step. Bureau feeds increasingly include AI-generated attributes (alternative data signals, behavioral inferences, identity confidence scores). When a bureau attribute is used as an input to the bank's creditworthiness decision, the bureau's model becomes a sub-component of the high-risk system. The bank is the deployer of the integrated decision and inherits Article 26 obligations for the integrated outcome.

The third blur is automated adverse action. A model that outputs a recommended decline triggers a regulated adverse action notification under the Consumer Credit Directive and many member-state regimes. The combination of an automated decline and a regulated notification means the model is making the creditworthiness decision functionally, even if a human reviewer signs off ceremonially. The EU AI Act's Article 26(2) human oversight requirement is not satisfied by ceremonial review.

The fourth blur is post-approval re-scoring. Many banks re-score existing accounts for credit limit changes, default risk, and behavioral triggers. The re-scoring is creditworthiness assessment for an existing natural person and falls under 5(b). Re-scoring deployments rarely produce the kind of per-decision audit record that 5(b) requires.

What Article 26 requires of the bank deployer

Article 26 sets the deployer obligations. For a bank deploying an AI credit scoring system, the relevant requirements are: use the system in accordance with the provider's instructions for use (26(1)); assign human oversight to qualified personnel (26(2)); ensure input data is relevant and sufficiently representative (26(4)); monitor operation and notify serious incidents (26(5)); keep automatically generated logs for at least six months and produce them on request (26(6)); inform natural persons that they are subject to a high-risk AI system where applicable (26(11)).

The keeping-of-logs obligation is the operational core. The logs in question are the Article 12 records described in Article 19. They have to include the period of use, the input data leading to the decision, the natural person's identification, and enough detail for the competent authority to reconstruct what happened. Six months is the floor. Most national consumer credit regimes already require longer retention, which becomes the operative period.

For the supervised entity, Article 26 lives on top of existing prudential supervision under the Capital Requirements Directive and the European Banking Authority guidelines on internal governance. The supervisor will expect the bank to demonstrate Article 26 compliance as part of the normal supervisory dialogue. The records have to be retrievable on a normal supervisory request.

The compliance gap inside bank credit pipelines

The standard bank credit pipeline writes application logs from each step (decisioning engine, bureau caller, fraud screener, scoring model). The aggregate log set is voluminous and is the wrong shape for an Article 12 record.

The records the regulator will ask for are per-decision: for application 123456 received at 14:32 UTC on June 12, 2026, produce the full record of how the credit decision was made. Identity of the natural person. Identity attribution at the model API call. Policy version in effect. Data classification applied to the input. Model and version used. Decision outcome. Adverse action reason codes. Integrity signature.

The application logs were not designed to compose into a per-decision record. The decisioning engine knows the outcome. The bureau caller knows the bureau response. The scoring model logs the score. The fraud screener logs the flags. The integration of those records into a single per-decision record happens, if at all, in the bank's data warehouse on a delayed batch. The batch composition is not the system of record and the supervisor will not accept it as one.

The remediation pattern is structural. Move the per-decision record generation out of the application stack and into an enforcement layer that observes every model API call, attaches the identity context, applies the policy, and commits the record independently before the application receives the model response.

DeepInspect

This is the gap DeepInspect closes for bank credit pipelines under Annex III point 5(b). DeepInspect sits inline between the credit pipeline applications and any LLM or model API. For every scoring call, every bureau enrichment call that crosses an LLM boundary, and every adverse-action language generation call, DeepInspect attaches the natural person's identifier, the application's user role, the data classification of the input, and the policy version in effect. It records the outcome with a cryptographic signature so the record is independent of the application that produced it.

For a bank deployer under Article 26, the record set is the audit trail the supervisor will request. For a bank that is also the provider of the scoring model under Articles 8 through 17, the record set satisfies the technical documentation and post-market monitoring obligations. The same architecture serves DORA's ICT third-party risk and incident reporting demands because the records identify the providers, the calls made, and the outcomes.

If you are running a bank credit pipeline subject to Annex III point 5(b) and your Article 26 readiness depends on application logs, let's talk.