Does the EU AI Act apply to a US-incorporated fintech serving EU consumers?

Yes. The EU AI Act applies based on where the AI system's output is used or where the affected natural persons are located, not based on the deployer's place of incorporation. A US fintech offering credit products to EU residents is in scope for Article 26 obligations on the scoring decisions affecting those residents. The Article 99 penalty calculation looks at global annual turnover, not just EU turnover, so the exposure for a globally operating fintech is meaningful.

Does AI used only for fraud detection trigger Article 6?

The text of Annex III point 5(b) explicitly excludes AI used for the detection of financial fraud from the high-risk classification. A pure fraud detection model that does not contribute to a creditworthiness decision is not high-risk under that point. The distinction blurs when the fraud detection model's output feeds into a creditworthiness decision, in which case the integrated system may fall back into high-risk territory. The competent authority will look at the function, not the label.

What is the relationship between Article 12 logs and DORA incident reports?

The Article 12 logs are continuous per-decision records. The DORA incident reports are event-triggered notifications when something serious happens. The Article 12 logs provide the evidentiary basis for the DORA incident report. Without the per-decision records, the incident report has to be reconstructed from application logs that the regulator may reject as insufficient. The architecture that produces Article 12 records also feeds the DORA incident workflow with the data the firm needs to file the report.

Can a fintech rely on the model provider's logs to satisfy Article 26?

No. The provider logs are bound to the provider's identifier for the calling application, not to the fintech's natural person. The provider records what the API call contained at the API surface and what the response was. The provider records do not contain the fintech's policy state, the fintech's data classification, or the natural person's identity. Article 26 obligations sit with the deployer and require records the deployer controls. Relying on the provider's logs leaves the obligation unmet.

How does Article 26 interact with the existing consumer credit regimes?

The Consumer Credit Directive and member-state implementations already require lenders to keep records of credit decisions and to provide certain information to consumers. The EU AI Act layers an AI-specific record requirement on top. The combined regime is the union of obligations, not the intersection. A scoring decision that satisfies the Consumer Credit Directive but fails Article 12 traceability leaves the deployer exposed under the EU AI Act. The architecture that satisfies both does the per-decision logging at the AI request boundary rather than in application code.

EU AI Act for Fintech: How Credit Scoring and Fraud Detection Become High-Risk in August 2026

On August 2, 2026 the EU AI Act high-risk system requirements begin to apply to creditworthiness assessment and credit scoring of natural persons under Annex III point 5(b). The classification covers the use case, not the technology, which means a traditional logistic regression scoring model and a transformer-based scoring model are both in scope when they are used to score a natural person for credit. Deployers inherit Article 26 obligations and providers inherit Articles 8 through 17. The penalty tier under Article 99 reaches 15 million EUR or 3% of global annual turnover, whichever is higher. Most fintech deployments today produce zero records that would satisfy a competent authority asking about a specific scoring decision.

I want to walk through which fintech AI use cases become high-risk, what Article 26 actually requires of the deployer, where the overlap with DORA tightens the obligation, and the architecture that produces records a regulator will accept.

Which fintech use cases the EU AI Act classifies as high-risk

Annex III is the operational list. For fintech, the relevant points are 5(a), 5(b), and 5(c).

Point 5(a) covers AI systems intended to be used by public authorities to evaluate eligibility for essential public services and benefits. This rarely applies to fintech directly, except where a fintech operates as a contractor to a public authority.

Point 5(b) covers AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score. The exception is AI for the detection of financial fraud. Credit scoring proper is high-risk. Fraud detection is not, by the text, although fraud detection that drives a credit decision can fall back into 5(b) depending on the use.

Point 5(c) covers AI systems intended to be used for risk assessment and pricing in relation to natural persons in the case of life and health insurance. This sits adjacent to fintech but applies to insurers and insurance brokers.

For a digital bank or fintech offering credit products to EU consumers, 5(b) is the article that bites. For a buy-now-pay-later provider, 5(b) applies to the scoring decision that approves the installment. For a SaaS lender or embedded finance product, 5(b) applies to the underlying scoring decision regardless of the user-interface label.

What Article 26 actually requires of the deployer

Article 26 sets out the deployer obligations for high-risk AI systems. The text covers ten paragraphs. The operational requirements fall into six groups.

Use the system according to the provider's instructions

The deployer has to use the high-risk AI system in accordance with the instructions for use accompanying the system (Article 26(1)). This sounds procedural and turns architectural the moment the deployer integrates the model into a custom pipeline that departs from the provider's documented operating conditions.

Assign human oversight to qualified personnel

Article 26(2) requires the deployer to assign human oversight to natural persons who have the necessary competence, training, and authority. Documentation of the oversight assignment is part of the deployer file. A scoring system reviewed by an analyst who lacks credit-decisioning authority fails this test.

Ensure input data is relevant and sufficiently representative

Article 26(4) requires the deployer to ensure that input data is relevant and sufficiently representative in view of the intended purpose. For a credit scoring deployment, the input data is the application data plus any enrichment from bureau feeds, transaction data, and behavioral signals. The representativeness obligation includes the bureau feed.

Monitor operation and keep records

Article 26(5) requires the deployer to monitor the operation of the AI system. Article 26(6) requires the deployer to keep the logs automatically generated by the high-risk AI system for at least six months. Those logs are the Article 12 records described in Article 19. The records have to be produced on request.

Notify serious incidents and malfunctions

Article 26(5) requires the deployer to notify the provider and the competent authority of any serious incident or malfunction. The window is short. The DORA incident notification timelines overlap.

Conduct a fundamental rights impact assessment in some cases

Article 27 requires deployers that are public-law bodies or that provide public services to conduct a fundamental rights impact assessment before deploying a high-risk system. Many fintechs operating in segments tied to social benefits or essential financial services fall into the scope.

Where DORA tightens the obligation

DORA took effect January 17, 2025 across the EU financial sector. For fintech entities in scope, DORA layers four additional obligations on top of the EU AI Act for the same AI scoring systems.

ICT third-party risk management requires the fintech to maintain a register of contractual arrangements with AI providers, conduct risk assessments before contracting, apply specific contractual provisions including audit rights, and designate critical providers for additional oversight. The OpenAI, Anthropic, AWS Bedrock, and Google Vertex contracts are ICT third-party arrangements under DORA.

ICT incident management requires that AI-related incidents be classified, reported, and remediated under DORA's timelines. The timelines run shorter than the EU AI Act's serious incident reporting and effectively become the binding clock.

Digital operational resilience testing requires that critical ICT systems undergo threat-led penetration testing for the largest entities. AI scoring systems supporting credit decisions are critical ICT systems for most banks and large fintechs.

Information and intelligence sharing builds expectations around participation in industry sharing arrangements that the fintech has to satisfy operationally.

The compliance gap

Most fintech deployments cannot produce a per-decision audit record that satisfies the combined regime. The gap is consistent across the deployments I see.

The application that calls the model writes the audit log. The log records the application's view of what happened, not the policy decision that gated it. The natural person whose application was scored is missing or is inferred from session metadata. The data classification that applied to the input is not recorded because the application did not run a classification step. The policy version that was in effect at the moment of the decision is not stamped on the record because the policy was a hard-coded rule in the application's source code. When the regulator asks "produce the record for the scoring decision on application 123456 at 14:32 UTC on June 12, 2026," the deployer can produce an application log entry. The log entry does not contain the identity, classification, or policy state the record has to have.

I covered the same gap in the context of Article 12 in detail. The Article 26 deployer obligation has the same root cause and the same architectural remedy.

DeepInspect

This is the gap DeepInspect closes for fintech deployers under the EU AI Act. DeepInspect sits inline between the scoring application and any LLM API or model endpoint. For every scoring call, it attaches the natural person's identifier, the application's user role, the data classification of the input, and the policy version that governs the decision. It records the outcome with a cryptographic signature so the record cannot be altered by the application that produced the score.

The result is an Article 12 record set that satisfies the Article 26 obligation to retain logs and produce them to a competent authority. The same record set satisfies DORA's incident reporting and ICT risk management requirements because the records show what happened at the moment of the decision, who was responsible, and what policy was in effect.

If you are facing the August 2 deadline for credit scoring or creditworthiness AI under Annex III point 5(b), let's talk.