EU AI Act for regulated fintech: what's high-risk, what isn't, and how Coreal handles both.

EU AI Act is in transition. February 2025 banned prohibited practices; August 2026 makes high-risk obligations binding. Credit scoring, insurance pricing, biometric onboarding — all in scope. Here's what a fintech actually needs to file, and what Coreal generates automatically.

The boundary nobody wants to be on the wrong side of

The EU AI Act (Regulation (EU) 2024/1689) has a staggered timeline that quietly puts every regulated fintech in scope by August 2026.

The dates that matter:

• 2 February 2025 — prohibited AI practices took effect. Subliminal manipulation, social scoring, biometric categorisation in workplaces. Most fintechs are not in these prohibited categories, but a few onboarding flows that lean on emotional-state inference came close.
• 2 August 2026 — high-risk AI system obligations become binding. This is the deadline that matters for any bank, neobroker, neobank, insurer or telco-fintech using AI in customer-facing or risk-decisioning flows.
• 2 August 2027 — general-purpose AI model obligations bind for foundation-model providers; downstream users of GPAI inherit some transparency obligations.

The high-risk category is what we deal with weekly in customer engagements. Most fintech CTOs and CCOs are not yet clear on what falls into it, what doesn't, and what they have to file. This essay walks through the actual classification, the conformity-assessment burden, and the evidence pack Coreal ships out of the box that satisfies most of the obligations.

This is the AI-Act-side complement to our DORA Article 28 evidence pack — same architectural philosophy of bundling regulator-facing artefacts at the source of truth.

What counts as "high-risk" for fintech

The AI Act defines high-risk systems in Article 6, with the operational list in Annex III. For fintech the relevant Annex III categories are:

Annex III(5)(b) — Creditworthiness and credit scoring. This is the cleanest case. Any AI system used to evaluate the creditworthiness of natural persons, or to establish their credit score, is high-risk by default. This sweeps in:

• Retail credit decisions (cards, personal loans, mortgages)
• SME credit decisions where natural persons are guarantors
• BNPL approval decisions
• AI-driven affordability assessments in PSP onboarding

There is a narrow carve-out for AI used to detect financial fraud. That carve-out has been interpreted strictly — anything that crosses into "should this person get credit" is in scope; pure "is this transaction fraudulent" is not.

Annex III(5)(c) — Pricing and risk assessment in life and health insurance. Life insurance and health insurance pricing using AI is high-risk. Non-life pricing (motor, home, travel) was specifically excluded in the final text. Coreal partners on the insurance side that use AI for life-insurance underwriting fall in scope; motor partners do not.

Annex III(1)(a) — Biometric categorisation. Onboarding flows that use biometric data (passport photo + selfie liveness + face match) for identity verification do not automatically become high-risk — Article 6(3) provides exemptions for systems that perform "narrow procedural tasks" or "improve the result of a previously completed human activity." Most KYC-side biometric matching falls under one of these exemptions if the system simply confirms identity rather than categorising the person.

But continuous behavioural biometric monitoring during the customer relationship — keystroke dynamics, mouse patterns, gait analysis from mobile sensor data — is harder to fit into the carve-out. The European Banking Authority opined in Q4 2024 that ongoing biometric behavioural analytics for fraud detection sits on the high-risk side.

Annex III(8)(a) — Worker management. AI used in HR decisions (hiring, performance evaluation, task allocation) for the financial institution's own staff. This is workplace-facing, not customer-facing, but it's high-risk because Annex III(4) covers employment-context AI broadly. A bank using AI to score its compliance officers' case-review work falls in scope.

What we typically see misclassified

Two cases we encounter often:

1. AML transaction monitoring. Banks often assume their AML rule-engine + ML hybrid is high-risk. Strictly under Annex III, AML monitoring isn't explicitly listed — Article 6(3) "narrow procedural task" exemption typically applies if the system feeds into a human-reviewed case management workflow. But the AMLA's draft 2026 guidance pushes back: where ML scoring substantially drives case prioritisation without meaningful human review, AMLA wants the system treated as high-risk for evidence purposes even if technically out of scope. We treat AML monitoring as functionally high-risk for the evidence pack — costs little extra and removes regulator ambiguity.

2. Customer-experience personalisation. Recommendation engines on a bank's app suggesting next product, FX rate optimisation, savings product matching — these are not high-risk. Article 6 doesn't include them. We've seen banks over-classify, applying full conformity-assessment burden to recommendation engines. Don't. The regulator doesn't want this; the cost is wasted.

What the law actually requires for high-risk systems

For each high-risk AI system, the operator must:

1. Risk management system (Article 9). Documented identification of foreseeable risks across the AI system lifecycle. Updated continuously.

2. Data governance and quality (Article 10). Training, validation and test data sets must be documented, representative, free of bias relevant to the system's purpose. For a credit-scoring system, this means provable absence of protected-characteristic correlation (or correlation that is justified by recital reasoning).

3. Technical documentation (Article 11). A full technical file including system architecture, training methodology, dataset documentation, model card, hyperparameters, validation results. Updateable as the system evolves.

4. Record-keeping (Article 12). Logs of every model invocation. This is the article that ties most cleanly to existing operational logging — but the Act adds specifics. Logs must include input data hash, output, decision rationale (where deterministic), human-in-the-loop interventions.

5. Transparency and user information (Article 13). Clear instructions for use, including the system's intended purpose, accuracy levels, known limitations.

6. Human oversight (Article 14). Designed-in human oversight: the deployer must be able to intervene, override, halt the system. For credit decisions, "human oversight" means a reviewer can examine and reverse any AI-driven decision.

7. Accuracy, robustness, and cybersecurity (Article 15). Documented performance metrics, robustness against adversarial inputs, cybersecurity measures.

8. Quality management system (Article 16). Documented QMS covering all of the above, with senior-management ownership and continuous improvement.

9. Conformity assessment (Article 43). Most fintech AI systems fall into the category that allows internal conformity assessment based on Annex VI, not third-party assessment. The provider self-certifies on the basis of the technical file.

10. EU declaration of conformity + CE marking (Articles 47 and 48). Once self-assessed, the provider issues a declaration of conformity and applies CE marking metadata to the system.

11. Post-market monitoring (Article 72). Continuous monitoring of the system in production, with documented incident response.

12. Registration in EU database (Article 71). High-risk AI systems must be registered in a central EU database before deployment.

13. Fundamental Rights Impact Assessment (Article 27). For deployers in regulated sectors (which includes banks, insurers, and other Financial Services entities), an FRIA must be conducted before first deployment of a high-risk system.

That's 13 distinct obligation streams per high-risk AI system. Most fintechs have 3-8 high-risk systems. The full obligation surface for a typical tier-1 bank is something like 50-80 distinct documents/processes, depending on system count.

How this maps to DORA, AMLA, and BCBS 239

If you've read our BCBS 239 + DORA + AMLA evidence pack overlap piece, the pattern continues. The AI Act overlaps significantly with these three other regimes:

A bank running the unified evidence-pack infrastructure for DORA + BCBS + AMLA already has roughly 70% of what the AI Act demands. The new artefacts are:

• Per-system FRIA documents (Article 27)
• EU database registration records (Article 71)
• Conformity declarations (Article 47)
• Specific bias-testing documentation (Article 10 carve-out)

For a bank using Coreal in production, we generate the first three automatically as part of the system-deployment process. The fourth (bias testing on training data) requires the bank's own data team — but we provide the templated documentation format that the regulator's audit team has indicated they expect.

What Coreal generates automatically

For each high-risk AI feature shipped through the Minctrl pipeline:

1. Per-feature AI Act classification statement. A 1-page document classifying the feature against Annex III categories, with reasoning.
2. Technical file (Article 11). Generated from the pipeline's own metadata: architecture diagram, model card, training methodology summary, validation results.
3. Conformity declaration (Article 47). Pre-filled to the standard format the EU has indicated; the bank's compliance officer signs off.
4. Logging configuration (Article 12). The decision journal we discussed in the BCBS 239 piece is configured per AI Act requirements: input hashes, outputs, decision rationale, human interventions all captured.
5. Human oversight design statement (Article 14). Documents the oversight pattern (mandatory human review, override mechanism, halt mechanism).
6. FRIA template (Article 27). Pre-filled to the EU template; the bank's compliance team adds context-specific risk analysis.
7. EU database registration submission (Article 71). Generated as JSON in the format the European AI Office has published; the bank submits.

The set is delivered as part of the Wave-1 evidence pack (the DORA Art. 28 piece covered the parallel set). The bank's compliance team reviews and submits; we don't.

The post-market monitoring trap

Article 72 (post-market monitoring) is the obligation most fintechs underestimate. The Act requires continuous monitoring of the AI system in production, including:

• Performance degradation tracking
• Drift detection (input distribution, output distribution)
• Bias-shift monitoring
• Incident reporting to national competent authority (within 15 days for serious incidents)

For a bank that has 8 high-risk AI systems, this means 8 monitoring dashboards, 8 incident-response playbooks, 8 quarterly performance reviews. Most banks staff this through their existing model-risk-management team — but the AI Act's specifics are more granular than the model-risk-management framework they may already have.

Coreal's runtime instruments the monitoring inputs automatically. The decision journal captures every model invocation; the BPM workflow tracks drift signals; the dashboard layer surfaces drift to the bank's MRM team. Of the four monitoring streams above, three are automatic; the fourth (bias-shift) requires the bank's data team to define their own bias metrics, which we then track.

Timing — what to plan for August 2026

For a bank starting Wave-1 with Coreal in early 2026, the AI Act-side timing falls naturally:

• Wave-1 month 1: AI Act classification of KYC orchestration features. Most KYC-side AI fits the narrow-procedural-task exemption; biometric monitoring needs scrutiny.
• Wave-1 month 2: Technical file, conformity declaration, FRIA for any features classified as high-risk.
• Wave-1 month 3: EU database registration submission. Submission processing takes 4-8 weeks; plan ahead.
• Wave-1 month 3-6: Post-market monitoring infrastructure in place; first quarterly review with national competent authority's expected format.
• Wave-2: AI Act review repeats per new feature. Cards, FX, BNPL, savings products — each goes through the same classification gate before going live.

A bank that starts AI Act-side preparation in June 2026 is already late for August 2026 deadlines. A bank that starts in November 2025 is comfortably ahead — Coreal partners running Wave-1 in early 2026 had their AI Act readiness reviewed by April 2026 for August enforcement.

Penalties — what's on the table

Article 99 of the EU AI Act establishes penalty tiers:

• Up to €35M or 7% of annual global turnover for prohibited AI practices (Article 5 violations).
• Up to €15M or 3% of turnover for high-risk AI obligation failures (Articles 9-15, 16-22).
• Up to €7.5M or 1% of turnover for incorrect information supplied to authorities.

For a tier-1 bank with €5B annual turnover, the maximum exposure on a high-risk obligation failure is €150M. The penalty floor is structured to be a meaningful share of annual revenue, not a wrist-slap.

The EU's enforcement strategy on the AI Act is openly modelled on GDPR. Expect the first 12-18 months after August 2026 to be a "letting institutions adjust" period, with formal enforcement actions ramping up from 2028. But the EU AI Office has the powers from day one; the timing of when they're used is political, not legal.

What this means for "Governed AI Runtime"

We've positioned Coreal as a governed AI runtime: deterministic execution, mandatory gates, replayable decisions. The EU AI Act formalises what we've been building since 2016: the runtime layer that documents AI behaviour at the right level of granularity for a regulator to audit.

For a bank starting Wave-1 with us:

• The pipeline's structure (28+ specialist agents with mandatory security + compliance gates) already produces conformity-assessment evidence as a byproduct.
• The decision journal already captures Article 12 logging requirements.
• The runtime's human-review-after-every-stage architecture already satisfies Article 14 oversight.
• The Minctrl pipeline output's documented structure already provides 80% of the Article 11 technical file.

The remaining 20% — bias testing on training data, FRIA context-specific analysis, regulator submission process — is bank-side work, but we provide templates and validation hooks.

For a bank that started AI investment in 2024 without runtime governance, the August 2026 deadline is a forcing function. For a bank starting Wave-1 with Coreal in 2026, AI Act readiness comes built-in.

This is one of the architectural reasons we positioned Coreal as runtime governance rather than yet another agent orchestration framework. The Act was always going to land. The systems that survive scrutiny are the ones where governance was in the foundation, not bolted on after enforcement begins.

Engagement-side disclosure: I lead Coreal's banking delivery, including AI Act readiness work with tier-1 EU partners. AI Act interpretation here reflects our practical reading; for a fitted analysis scoped to your specific AI systems, book a working session →. For the broader compliance posture, see /security-compliance. For the architectural foundation, see /solutions/banks.