EU AI Act for Fintech: Why Credit Scoring, Fraud Detection, and Insurance Pricing Land in the High-Risk Bucket

Annex III of the EU AI Act puts AI used in evaluating the creditworthiness of natural persons in the high-risk bucket at point 5(b). It puts AI used in life and health insurance pricing in the same bucket at point 5(c). Fraud-detection AI used in retail banking sits in scope at point 5(a) where it affects access to essential financial services. DORA, the Digital Operational Resilience Act, took effect January 17, 2025 with overlapping log retention and incident reporting obligations for financial entities. The August 2, 2026 effective date for EU AI Act high-risk requirements is the next binding deadline. Most fintech AI deployments today produce zero of the records both regulations will require an auditor to see.

I want to walk through which fintech AI use cases land as high-risk, how the AI Act and DORA overlap in practice, where the record-keeping architecture must change, and what an audit visit from a national competent authority or a financial supervisor will actually look like.

Mandate

The high-risk classification for fintech AI flows from Annex III, and the operational obligations flow from Articles 16 through 27 of the AI Act plus the parallel DORA chapters.

Credit scoring under Annex III point 5(b)

A natural person whose creditworthiness is evaluated by an AI system has Annex III rights. The system is high-risk regardless of whether the lending entity is a bank, a fintech, or a buy-now-pay-later vendor. The classification covers AI used in underwriting decisions, AI used in credit limit changes, and AI used in collections risk scoring. Pure fraud detection without an effect on the credit decision sits outside this point but may land in scope through point 5(a) where it affects access to an essential service.

Insurance pricing under Annex III point 5(c)

AI used for risk assessment and pricing in life and health insurance is high-risk. The classification captures actuarial AI tools used to set premiums, underwriting AI that classifies applicant risk, and tools used in claims-handling decisions that affect coverage. Property and casualty insurance pricing is excluded from this specific point but can fall into scope through other Annex III points where employment or essential-services impact is present.

Fraud detection in essential financial services

Annex III point 5(a) covers AI in the evaluation of eligibility for essential public services. Where a retail bank uses AI to flag transactions as fraudulent and the flagging affects access to the customer's account, the system can land in scope. The decisive question is whether the customer's access to the essential service is materially affected by the AI decision.

DORA in parallel

DORA Article 19 requires financial entities to maintain registers of ICT-related incidents and to retain logs that support post-incident reconstruction. The retention floor is generally five years for major incidents. The supervisory authorities for DORA are the EBA, EIOPA, and ESMA, working through the national competent authorities. A fintech that deploys high-risk AI for credit scoring owes the Article 12 record-keeping under the EU AI Act and the DORA Article 19 log retention to the same regulator path.

Compliance gap

Most fintech AI deployments today have no architecture that produces the records both regulations presume exist.

The application-controlled audit log fails the Article 12 test

A credit-decisioning microservice that records its own decisions in its own database fails the write-path independence test. The supervisor asks: produce the audit record for the credit decision on application 47832, including the loan officer identity, the data classification of the applicant data in the prompt, the policy version that governed the threshold, and the decision outcome. The microservice's internal log contains some fields but the regulator does not accept self-attested records as the system of record. The deployer obligation under Article 26 makes the fintech the regulated party.

Identity context is missing at the request layer

The credit model API runs against a service credential. The credential identifies the application, not the loan officer reviewing the case or the agent acting on behalf of the loan officer. The Article 19 record fails the identity check. The fintech cannot demonstrate which natural person initiated which credit decision without reconstructing the context from session traces, which the regulator does not accept as a contemporaneous record.

PII handling is not evaluated at decision time

Credit decisioning prompts contain financial PII: account numbers, income data, employment history, debt obligations. The GDPR data controller in an EU deployment owes a contemporaneous record of which categories of personal data flowed through which model at which time. Most credit-decisioning tools do not evaluate prompt-level classification at request time. The classification is reconstructed weeks later, if at all, and fails the simultaneous-record test.

Vendor-embedded AI is invisible to the deployer

A material share of fintech AI usage flows through SaaS vendors that embed model calls under the hood. The KYC vendor uses an LLM to summarize sanctioned-party reports. The collections vendor uses AI to score account-recovery probability. The customer-service vendor uses an AI agent to handle disputes. The fintech's environment never sees the prompt or the response. The Article 26 obligation does not transfer to the vendor. The fintech owns the disclosure on demand.

Mandate vs Compliance

The text of the EU AI Act reads at one level of abstraction. DORA reads at another. The infrastructure that survives a supervisory inspection at a fintech operates at a level lower than both. The gap between the regulations and the architecture is where most fintechs are exposed.

Disclosure test

The national competent authority opens an inspection following a customer complaint about a denied credit decision. The authority asks for the contemporaneous audit record for the AI tool involved, with identity context, classification, policy state, and decision outcome. A compliant deployer produces the record within minutes. A non-compliant deployer produces unstructured application logs that lack identity and a workflow of engineers reconstructing classification from production traces. The disclosure failure itself can produce a finding under Article 99 Tier 3 and a DORA finding for inadequate log retention.

Vendor liability

The AI vendor providing the credit-decisioning model is the provider under Article 3. The fintech is the deployer under Article 26. Both bear obligations. A serious-incident report under Article 73 originates from the deployer. The compliance file under Article 12 is the deployer's responsibility. DORA reinforces this: the financial entity is the regulated party for ICT incidents involving AI vendors.

Compliance gap

The compliance gap is architectural. The records both regulations presume exist are not produced by application logs, by network appliances, or by the AI vendor's internal database. They are produced by an inspection layer on the AI request path that writes the per-decision record independent of the application that originated the request and independent of the AI vendor that responds.

DeepInspect

This is the architecture both the EU AI Act and DORA presume for fintech deployments. DeepInspect sits at the AI request boundary as an external enforcement layer that operates as a stateless proxy between authenticated users or agents and the AI vendor endpoint. Every HTTP request is evaluated against per-route, per-role policies using identity context the calling application supplies. The per-decision record is committed by the proxy, independent of the AI vendor and independent of the originating application, before the model response returns to the calling system.

The record contains a verified identity for the requester, the role and authorization context, the data classification applied to the prompt (including financial PII detection), the policy version that governed the decision, the decision outcome, and a cryptographic signature that prevents post-hoc modification. The proxy enforces per-route policies on which AI vendors a given role can call, which categories of financial PII can flow to which endpoint, and which policy bypasses require independent approval. Production overhead stays under 50 ms in internal testing, which keeps the enforcement layer within the credit-decisioning latency budget.

If you are facing the August deadline, let's talk.

Beyond the EU AI Act

The same architecture satisfies parallel regimes. DORA Article 19 record retention, MiFID II algorithmic trading record requirements, the California Consumer Privacy Act record-of-processing obligations, and the US Equal Credit Opportunity Act adverse-action notice requirements all expect contemporaneous records of automated decisioning. The vocabulary differs across these regimes. Each one accepts the same architectural record: an inspection layer on the AI request path that writes a tamper-evident, identity-bound, classification-aware record at decision time.