AI Act and Fintech: What Changes in Credit Scoring Architecture from August 2026

In short: as of August 2, 2026, the “high-risk” obligations of the European AI Act took effect for AI systems that assess creditworthiness (Annex III, point 5(b)). If your fintech uses AI for credit scoring, it’s no longer enough for the model to work well: you need to be able to prove it, with architecture, not just a legal memo.

What actually changed

The AI Act isn’t new (it entered into force in 2024), but 2026 is the year the regulation stops being a date on a calendar and becomes an operational obligation. For credit scoring, Annex III classifies it directly as a high-risk system, triggering a full block of Chapter III:

• Risk management (Art. 9): a continuous process, not a one-off audit before launch.
• Data governance (Art. 10): traceability of what data trained the model and why it’s representative.
• Technical documentation (Annex IV): the regulatory equivalent of an ADR, except mandatory and auditable.
• Record-keeping (Art. 12): logging that lets you reconstruct every decision the model made, not just the final output.
• Human oversight (Art. 14): a real point where a person can review or override the decision, not a compliance checkbox.
• Conformity assessment (Art. 43): certification before the system goes live.

Non-compliance isn’t symbolic: up to €15 million or 3% of global turnover, whichever is higher.

The detail most people miss: provider vs. deployer

This is the part that matters to whoever designs the system, not just legal. If your fintech takes a third-party model and uses it as-is, you’re a deployer (lighter obligations). But if you fine-tune it on your own data (common practice to improve accuracy for your customer segment), you shift to provider status, with the full weight of Annex IV technical documentation and conformity assessment on top. It’s an architecture decision (in-house fine-tuning vs. a managed third-party model) that now carries direct regulatory consequences.

What this means in code, not just in compliance

A compliant scoring system needs, at minimum, a domain port dedicated to traceability (agnostic of whichever scoring engine sits behind it):

// The decision record lives in the domain, not glued to the model:
// any scoring engine (in-house or third-party) goes through here.
export interface CreditDecisionLog {
  record(decision: {
    subjectId: string;
    inputsHash: string; // not raw data, its fingerprint: auditable without exposing PII
    modelVersion: string;
    score: number;
    outcome: 'approved' | 'rejected' | 'review';
    reviewedBy?: string; // present when it went through human oversight (Art. 14)
  }): Promise<void>;
}

The architectural point: logging and human oversight can’t be a patch bolted on afterward. If the scoring model lives behind a well-defined port from day one, complying with Art. 12 and Art. 14 is just wiring one more adapter. If the model is tangled with business logic, complying by August 2026 means rewriting under pressure.

Why it matters for your product

Because the AI Act is no longer a 2027 conversation. If you’re building or modernizing a fintech product with AI in the decision flow, the architecture you choose today (clear ports, logging built in from the design, a real human review point) is the difference between a one-week adaptation and a months-long migration. If you’re at that stage and want architecture that holds up under regulation without slowing the product down, let’s talk.