EU AI Act Enforcement Started August 2. Here's What US Fintechs With EU Customers Need to Fix Right Now.

TL;DR

• The EU AI Act’s high-risk AI provisions became fully enforceable on August 2, 2026—for any US fintech whose AI systems affect EU residents, that clock has started
• Credit scoring, fraud detection, and AML monitoring are classified as high-risk under Annex III; fraud detection has a narrow carve-out that doesn’t cover broad behavioral profiling
• Most US fintechs are deployers, not providers—which means different (but still significant) obligations: human oversight, fundamental rights impact assessment, AI literacy, log retention
• Legacy systems deployed before August 2 get until February 2, 2027; new systems must comply now
• Penalties reach €35M or 7% of worldwide turnover—not theoretical exposure

Twenty-two days ago, the EU AI Act went live for high-risk AI systems.

For US-based fintechs that process applications, make credit decisions, run fraud detection, or monitor transactions for EU residents, that date marks the moment when explainability, human oversight, and auditability stopped being good practices and became legal requirements—with penalty exposure that doesn’t need to be theoretical to be motivating.

If you assumed the EU AI Act was an EU problem for EU companies, the threshold that actually matters is simpler: does your AI system affect people in the European Union? If yes—regardless of where your company is incorporated, where your servers live, or whether you have an EU entity—the obligations apply to you as a deployer.

Here’s what’s required, why the provider vs. deployer distinction is the most operationally important question you’ll answer, and what needs to happen before the legacy system grace period ends in February.

What Became Enforceable on August 2

The EU AI Act rolled out in phases. The prohibitions on certain AI practices (social scoring, real-time biometric surveillance) became enforceable in February 2025. General-purpose AI model obligations have their own timeline. August 2, 2026 was the date that mattered most for financial services: the full set of obligations for high-risk AI systems under Articles 6 through 49 became enforceable.

High-risk AI systems in financial services are listed explicitly in Annex III of the Act. The ones most relevant for fintechs and lenders:

The fraud detection nuance: The Act creates an exception for AI systems used specifically to detect financial fraud. But the exception is narrow. If your fraud detection system also profiles individuals across broader behavioral, economic, or demographic characteristics beyond the specific purpose of detecting a fraudulent transaction, it may lose the exception and fall back into the high-risk category. A narrow transaction-anomaly model likely qualifies for the carve-out. A broad behavioral risk-scoring system that feeds fraud, credit, and customer lifecycle decisions likely doesn’t.

The Provider vs. Deployer Question Is the Most Important Thing You’ll Answer

The EU AI Act distinguishes between two types of actors, and which one you are determines which obligations you face.

Provider: An entity that develops, trains, or substantially modifies a high-risk AI system and places it on the market under its own name or trademark. If your fintech has an ML team that builds and trains your own credit model—and you make that model available to others or integrate it as a product feature under your brand—you’re likely a provider.

Deployer: An entity that uses a high-risk AI system under its own responsibility for purposes other than personal or professional use. If you license a third-party credit scoring model or fraud detection system and use it to make decisions about your customers, you’re a deployer.

For most US fintechs, the answer is deployer. You bought a model from a vendor, or you’re using a scoring API, or you’re running a third-party fraud engine. You didn’t train the model from scratch.

This distinction matters because the obligations are fundamentally different:

Provider Obligations (if you built it)

Providers face the full weight of the Act’s documentation and assessment requirements. For a US fintech that built its own credit underwriting model and uses it for EU customers, this is a significant compliance buildout.

Deployer Obligations (if you licensed it)

Deployers cannot outsource these obligations to their vendor. Even if the provider built a fully compliant system, the deployer’s human oversight, log retention, and AI literacy obligations are non-delegable.

What Deployers Need to Do Now

1. Confirm Whether Your AI Systems Classify as High-Risk

Not every AI tool in your stack is high-risk under the Act. The classification question turns on whether the system is listed in Annex III and whether it makes or influences decisions affecting the rights, health, safety, or fundamental rights of natural persons.

Credit scoring for natural persons: clearly in scope. Internal analytics models that forecast your own business metrics: generally not in scope. Fraud detection: depends on whether the narrow exception applies to your specific use case.

Document your classification rationale per system. If regulators ask, “how did you determine this wasn’t high-risk,” a documented analysis is significantly better than “we assumed.”

2. Verify the Provider’s Technical Documentation Exists

Deployers need the provider’s technical documentation—not because you’re required to maintain it yourself, but because you need it to:

• Understand the system’s intended use cases and limitations (which determines whether you’re deploying within authorized scope)
• Implement the required human oversight as specified in the instructions
• Know what the system cannot do and where it breaks

If your vendor hasn’t provided this documentation, get it in writing before deploying the system. If the vendor refuses or says it doesn’t exist, that’s a red flag about their own provider compliance status—which creates downstream risk for your deployer position.

3. Implement Human Oversight That Actually Works

Article 14 requires that deployers ensure high-risk AI systems can be effectively overseen by natural persons during use. Specifically:

• Oversight persons must be able to understand the system’s capabilities and limitations
• They must be able to detect anomalies, dysfunctions, and unexpected performance
• They must be able to disregard, override, or intervene in the system’s output
• They must be able to halt the system if needed

“Human in the loop” on paper isn’t enough. The oversight mechanism needs to be real: a person with the authority and information to actually intervene, not just sign off on automated outputs.

For high-volume automated decisioning (credit applications processed automatically), this requires either meaningful human review at threshold or exception rates, or documented rationale for why the system’s design and track record supports a lower intervention frequency. The proposed implementing regulations and guidance from EU member state national competent authorities will provide more specificity—but waiting for that guidance before building oversight processes isn’t an option now that enforcement has started.

4. Build the AI Literacy Program

Article 4 requires providers and deployers to take measures to ensure their staff have sufficient AI literacy—understanding of AI capabilities, limitations, the applicable legal framework, and the risks of overreliance on AI outputs.

For deployers, this means:

• Training for staff who directly manage or interpret high-risk AI system outputs
• Documented competency assessment or training completion records
• A clear definition of who counts as a “user” of the system for AI literacy purposes

This doesn’t require sending your credit analysts to get data science degrees. It means they understand what the model does, what it can’t do, and what to do when an output seems wrong.

5. Set Up Use-Log Retention

Article 26(6) requires deployers to retain use logs for at least six months, or longer if required by other applicable law. For credit and lending contexts, other laws (Reg B adverse action documentation, ECOA record retention) likely impose longer retention requirements that will govern.

Confirm that your decisioning platform captures and retains the inputs, outputs, and timestamps needed to reconstruct what the system did for a specific decision. If you’re using a third-party model via API, confirm that your integration is logging the relevant data—the provider’s logs are not your logs for compliance purposes.

Legacy System Grace Period: February 2, 2027

AI systems that were already deployed and in operation before August 2, 2026, have until February 2, 2027, to achieve full compliance with high-risk AI obligations. This is a meaningful runway for organizations with established systems—approximately six months.

The grace period is for existing systems only. Any new high-risk AI system introduced after August 2, 2026, must comply with the Act’s requirements from the moment of deployment.

What this means in practice:

• If you were running a credit scoring model before August 2: you have until February 2, 2027, to implement human oversight documentation, AI literacy training, log retention, and the rest of the deployer stack
• If you’re launching a new credit scoring model now: the full requirements apply at launch
• If you substantially modify an existing system: the modification may constitute a “new” system depending on its scope, which would trigger immediate compliance requirements

The Penalty Structure Is Not Theoretical

EU AI Act enforcement authority rests with national competent authorities in each EU member state. Penalties for violations of high-risk AI obligations reach €35 million or 7% of worldwide annual turnover—whichever is higher.

That’s worldwide turnover, not EU revenue. A US fintech generating $200 million globally with a relatively small EU business faces penalty exposure of up to $14 million for violations of deployer obligations that it might have assumed were EU-only concerns.

Early enforcement will likely focus on providers first—the manufacturers of high-risk AI systems—and work toward deployers as national competent authorities build their inspection capabilities. But deployer obligations are real, they’re being tracked, and the EU AI Act includes whistleblower protections that incentivize internal reporting.

The US Regulatory Connection

US fintechs managing EU AI Act compliance alongside domestic obligations will notice significant overlap in some areas and gaps in others.

Overlap:

• The OCC’s 2026 model risk management guidance (replacing SR 11-7) and the EU AI Act both require documentation, validation, and monitoring of AI systems used in consequential decisions
• The NIST AI RMF 1.1’s GOVERN, MAP, MEASURE, and MANAGE functions align well with the EU AI Act’s risk management and post-market monitoring requirements
• CFPB ECOA/Reg B adverse action requirements for AI-driven credit decisions overlap with the EU’s transparency and recourse obligations

Gaps:

• EU AI Act requires a documented fundamental rights impact assessment that has no direct US equivalent
• The CE marking and EU AI database registration requirements are EU-specific with no US analog
• AI literacy documentation is more explicitly required under the EU Act than under current US guidance

If your compliance program is already built around the NIST AI RMF and OCC model risk guidance, the EU AI Act deployer obligations are addable—but they require specific additions, not just a finding that existing compliance covers everything.

So What?

• Classify your AI systems: identify which ones are high-risk under Annex III; document your rationale for anything you conclude is not
• Get the provider’s technical documentation: if your AI vendor hasn’t provided Annex IV documentation, request it now; deploying without it puts your deployer compliance on shaky ground
• Design human oversight that works: not a checkbox, but a process where someone with competence and authority can actually override or halt the system
• Stand up AI literacy training: document who’s trained, on what, and when—examiners will ask
• Set up log retention: six months minimum, longer if other law requires; confirm your API integration is capturing what you need
• Use the grace period if you need it: legacy systems have until February 2, 2027; that’s six months, not an indefinite extension

Related reading: NIST AI RMF vs. EU AI Act Compliance Mapping, AI Model Inventory Management for Regulatory Exams, Vendor AI Risk Assessment: What TPRM Requires When Your Vendor Is the Model