EU AI Act High-Risk Series, Part 2: Finance & Insurance

Part 2 of our five-part series on high-risk AI under the EU AI Act, written for the directors who have to decide what to build, buy and sign off. Part 1 covered recruitment and HR technology; Part 3 covers education and EdTech; Part 4 covers healthcare and MedTech; Part 5 covers critical infrastructure.

If your business scores creditworthiness or prices life or health insurance for individuals, the EU AI Act treats that decision as high-risk without exception. Unlike recruitment there is no banned feature to hunt for. There is instead an obligation that most other sectors do not carry: a mandatory impact assessment that applies to any deployer of these systems, public or private, on top of everything else in this series.

This article sets out what is in scope, what is not, and what a lender, insurer or payments business needs to have built before the deadline, with the commercial case for doing it early.

What has changed

As covered in Part 1, the "Digital Omnibus on AI", Regulation (EU) 2026/1744, published 24 July 2026 and in force since 27 July 2026, moved the compliance deadline for standalone high-risk AI systems from 2 August 2026 to 2 December 2027. That applies to credit scoring and insurance risk assessment exactly as it applies to recruitment: one fixed date across every Annex III category.

What the delay did not touch:

• Since 2 February 2025: prohibited AI practices are banned and staff AI-literacy obligations apply (softened from "ensure" to "support").
• Since 2 August 2025: obligations for general-purpose AI models and the Act's governance and penalty framework.
• From 2 August 2026: transparency duties, for example disclosing that a customer is dealing with an AI system.

Which financial AI is high-risk, and which is not

The Act names two uses in financial services as high-risk under Annex III, point 5:

• 5(b): AI used to evaluate a person's creditworthiness or establish a credit score, with one explicit exception: systems used purely to detect financial fraud.
• 5(c): AI used for risk assessment and pricing in life and health insurance for individual natural persons. The fraud exception does not extend here.

Two boundaries decide whether you are in this category at all:

• Fraud detection is carved out, for credit only. A model that spots fraudulent transactions or applications, rather than deciding whether someone qualifies for credit, sits outside this category, though it may be regulated elsewhere.
• Only life and health insurance are named. Motor, property and general or commercial insurance pricing are not in this category, even where they use AI-driven risk models.

Being listed in Annex III is not quite the end of the analysis. Article 6(3) provides a narrower derogation for systems that do not pose a significant risk. It has a carve-back: an Annex III system is always high-risk if it profiles natural persons. Most individual credit-scoring and insurance-pricing models do exactly that, so in practice the derogation is rarely available for the systems this article is about.

What has to be in place by December 2027

For an in-scope scoring or pricing system, the obligations map onto concrete work:

• Data governance with a bias lens. Training and validation data examined for discriminatory patterns, including proxies such as postcode standing in for a protected characteristic.
• A human who can override the score. Meaningful review of a lending or pricing decision, not an approval step that confirms the model.
• Technical documentation and automatic logging covering how the model was built, validated and behaves in production.
• Conformity assessment and EU database registration before the system goes to market.
• Ongoing monitoring for accuracy and drift after launch.

Finance carries one obligation the other sectors in this series do not get by default. Under Article 27, deployers of credit-scoring and life or health insurance pricing AI must complete a Fundamental Rights Impact Assessment before deployment, whether or not they are a public body.

If you use a third-party scoring model you are a deployer, not a provider, and the obligations are lighter but not absent: you still need the impact assessment, meaningful human oversight and audit logging. Under Article 25, retraining or fine-tuning the vendor's model beyond its intended parameters can reclassify you as a provider with the full obligation set.

What is left out of this article, deliberately

The fuller mechanics of the Article 6(3) derogation, the general-purpose model rules, and the overlap with existing financial regulation. That overlap is real: the EBA has mapped substantial overlap with CRR/CRD, DORA and the Consumer Credit Directive, and EIOPA has published AI governance guidance for insurers. Those are conversations with your compliance team, and much of the work done for them is the same work.

What is at stake commercially

Fines under Article 99 are tiered and unchanged by the Omnibus:

• Up to €35M or 7% of global turnover for breaching an outright prohibition.
• Up to €15M or 3% for non-compliance with the high-risk obligations above, including a missed or inadequate impact assessment.
• Up to €7.5M or 1% for supplying incorrect information to a regulator.
• For SMEs, each cap applies as whichever figure is lower.

Financial services already operates under close scrutiny. A discriminatory credit model is an AI Act problem and a consumer-protection problem at once, and exactly the finding that turns a routine audit into enforcement. Counterparties and institutional partners increasingly ask AI Act questions in due diligence; a model that cannot produce its documentation on request stalls the deal.

The return on doing this properly is the same set of documents and controls answering the regulator, the auditor, the partner's due diligence and the board's own risk committee, produced once by the system running rather than assembled four times by hand.

What to do now

1. List every model that touches an individual's credit or life and health insurance decision, and decide for each whether it is fraud detection, scoring or pricing.
2. Determine provider or deployer status per model, including any fine-tuning of vendor models.
3. Schedule the Fundamental Rights Impact Assessment for each in-scope deployment; it is a prerequisite, not a follow-up.
4. Build logging and human override into the decision flow now; they are the foundation of every other obligation and the evidence for your existing regulators too.
5. Map the work to DORA and Consumer Duty so it is done once.

How Hexploits helps

We do the engineering side of EU AI Act readiness: inventory and classification, the documentation and logging for high-risk systems, decision-support models built with the explanations and testing the Act expects, and data protection engineering across the systems that feed them. Governance and audit trails are how we build by default: every system we ship carries the logging and oversight these obligations assume, the approach we used for regulator-grade audit on swarmd.ai, the EU AI Act readiness platform whose core engineering team we are.

Request a proposal or talk to an engineer. You will have a written scope and an indicative price within two working days.

This is our view of the operational and technical side of compliance, not legal advice. Pair it with your legal counsel for formal sign-off. Next in the series: Part 3, education and EdTech.