AI Act Compliance for Fintech and Financial Services

Two obligations have applied since 2 February 2025, and both apply to deployers – not just to the companies that build AI.

AI literacy (Article 4)

Providers and deployers must take measures to ensure, to their best extent, a sufficient level of AI literacy among staff and others operating AI systems on their behalf, calibrated to their technical knowledge, experience, training, and the context of use. It is a governance duty, not a training certificate: what it requires in practice is that the people using your AI understand its capabilities and limits, know the risks to fundamental rights and data protection, know your internal rules on acceptable use and escalation, and know which laws apply. It carries a real penalty – Article 4 breaches sit in the Article 99(4) tier, up to EUR 15m or 3% of global turnover.

Prohibited practices (Article 5)

These are outright bans, carrying the top penalty tier – up to EUR 35m or 7% of global turnover. The ones that reach financial services are not exotic:

• > Manipulative or deceptive techniques that materially distort behaviour and cause significant harm – relevant to behavioural nudging in lending and trading interfaces;
• > Exploiting vulnerabilities of specific groups – relevant to credit or insurance offers targeted at vulnerable consumers;
• > Emotion recognition in the workplace – monitoring call-centre or trading-desk staff for emotional state is banned outright;
• > Biometric categorisation to infer sensitive attributes (race, political opinion, religion, sexual orientation) – which rules it out as an input to underwriting or scoring.

The Omnibus also adds a new prohibition on AI generating non-consensual intimate imagery and CSAM, with a compliance date of 2 December 2026.

Transparency (Article 50) – not deferred

From 2 August 2026:

• > Chatbots (Article 50(1)). A person interacting with your AI system must be told they are interacting with AI, unless it is obvious to a reasonably observant person. Customer service, onboarding, complaints handling – if a bot is in the loop, disclosure is required.
• > Synthetic content marking (Article 50(2)). AI-generated audio, image, video, or text must be marked in a machine-readable format and detectable as artificially generated. For systems already on the market before 2 August 2026, the Omnibus defers this specific marking duty to 2 December 2026.
• > Emotion recognition and biometric categorisation (Article 50(3)). Where lawful at all, deployers must inform the people exposed to it.
• > Deepfakes and public-interest text (Article 50(4)). Deployers publishing AI-generated or manipulated content must disclose it – with a carve-out for text that has undergone human editorial review where a person holds editorial responsibility.

Disclosure must be clear and given no later than the first interaction (Article 50(5)).

Full enforcement

2 August 2026 is also when enforcement and the Article 99 penalty regime become fully operational across the obligations that are already in effect. Until now the duties existed; from that date the machinery to fine you for breaching them does too.

Sixteen months looks generous until you price the work. If you run credit scoring on natural persons, the December 2027 package is not a policy document – it is a fundamental rights impact assessment, a human-oversight structure with named competent people, input-data governance, six-month log retention, a monitoring-and-suspension protocol, and a duty to tell affected customers they are subject to an AI-assisted decision. Those are organisational changes with procurement, vendor-contract, and staffing consequences. The firms that treated the original August 2026 date seriously are now the ones with a comfortable runway; the ones that waited for the deferral have simply moved their problem, not solved it.

There is also a live obligation hiding inside the deferred one. Your vendor contracts and your model inventory determine whether you can comply at all in December 2027 – and those contracts are being signed now.

The AI Act splits duties between the provider who develops an AI system and puts it on the market, and the deployer who uses it under its own authority. Almost every fintech and financial institution is a deployer: you buy or license a scoring model, a chatbot, an AML monitoring tool, and you use it on your customers. This page is written for you.

The distinction is not always clean, and getting it wrong is expensive. If you fine-tune a purchased model substantially, put your own name on an AI system, or materially modify its intended purpose, you can become a provider – and inherit the far heavier obligations of Article 16 (quality management system, technical documentation, conformity assessment, CE marking). Where a business builds in-house, it is a provider to itself. That classification question is the first thing to settle, because everything downstream depends on the answer.

Annex III lists the stand-alone use cases the AI Act treats as high-risk. Two of them land squarely on financial services:

• > Annex III, point 5(b): creditworthiness evaluation and credit scoring of natural persons – high-risk, with one carve-out: AI used solely to detect financial fraud is excluded.
• > Annex III, point 5(c): risk assessment and pricing in life and health insurance for natural persons – high-risk.

The Article 6(3) filter

Not every Annex III system is high-risk. A system escapes the classification if it does not pose a significant risk of harm and it performs only a narrow procedural task, improves the result of a completed human activity, detects patterns or deviations without replacing or influencing a human assessment, or performs a preparatory task. But the filter has a hard limit: a system that performs profiling of natural persons is always high-risk, whatever else it does. In credit and insurance, that limit swallows most of the exception – and a provider relying on Article 6(3) must document its assessment and register the system under Article 6(4) and Article 49(2).

The practical consequence for a deployer: do not accept a vendor’s "this isn’t high-risk" at face value. Ask for the Article 6(3) documentation, check whether the system profiles, and check whether it was registered. If the classification is wrong, the obligations that failed to get discharged are yours as well as theirs.

When the high-risk regime applies – 2 December 2027 for Annex III – a deployer must:

1. 01 Use it as instructed (Article 26(1)). Technical and organisational measures ensuring use in line with the provider’s instructions for use.
2. 02 Human oversight (Article 26(2)). Assign oversight to natural persons with the competence, training, authority, and support to actually exercise it – implementing the measures the provider identified under Article 14. A named person with no authority to stop the system is not oversight.
3. 03 Input data (Article 26(4)). Where you control the input data, ensure it is relevant and sufficiently representative for the intended purpose.
4. 04 Monitor and suspend (Article 26(5)). Monitor operation, inform the provider of issues, and – where use in line with instructions may create a risk to health, safety, or fundamental rights – suspend use and notify the provider and the market-surveillance authority without undue delay.
5. 05 Keep logs (Article 26(6)). Retain automatically generated logs under your control for a period appropriate to the purpose, and in any case at least six months.
6. 06 Tell your workers (Article 26(7)). Before putting a high-risk system into service at the workplace, inform workers’ representatives and affected workers.
7. 07 Tell affected people (Article 26(11)). Where an Annex III system makes or assists decisions about natural persons, inform those persons that they are subject to it. For a lender, that means telling the applicant.
8. 08 Support the DPIA (Article 26(9)). Use the provider’s Article 13 information to inform your GDPR Article 35 assessment.
9. 09 Cooperate with authorities (Article 26(12)).

The financial-services carve-in – read this before you build a parallel structure

Article 26(5) provides that deployers which are financial institutions subject to internal-governance requirements under EU financial-services law are deemed to satisfy the monitoring obligation by complying with those internal-governance rules; Article 26(6) does the same for log-keeping, which is maintained as part of the documentation required under that legislation. In plain terms: if you already run a risk-management and internal-control framework under CRD, MiFID, or Solvency II, you layer AI-specific controls onto it rather than standing up a duplicate AI compliance function. That is a meaningful cost saving, and it is missed constantly.

Article 27 requires a FRIA before deployment – and it reaches private financial firms directly. Alongside public bodies and private entities providing public services, the duty falls on deployers of high-risk systems under Annex III point 5(b) (credit scoring) and 5(c) (life and health insurance pricing). If you score consumers, you owe a FRIA.

It must describe: the processes in which the system will be used, consistent with its intended purpose; the timeframe and frequency of use; the categories of people and groups affected; the specific risks of harm to them, informed by the provider’s Article 13 information; the human-oversight measures as actually implemented; and the measures you will take if the risks materialise, including internal governance and complaint mechanisms. The result is notified to the market-surveillance authority on the AI Office’s template, and updated when anything material changes.

FRIA does not replace your DPIA. They complement each other: the DPIA addresses data-protection risk and legal basis; the FRIA addresses the broader fundamental-rights effects – equality, non-discrimination, access to essential services. Where you have already done a DPIA for a scoring model, it is a starting point, not an answer.

Applicable from 2 December 2027 for Annex III systems, following the Omnibus deferral.

Between now and December 2027, the work that matters is not a document – it is a control structure. What a fintech deployer needs in place:

• > An AI inventory. Every AI system in use or planned, with its role, its vendor, its classification (prohibited / high-risk / limited-risk / minimal), and whether it profiles natural persons. You cannot comply with an obligation you cannot scope, and most firms discover shadow AI at this step.
• > A classification decision, documented. Provider or deployer; high-risk or not; if the vendor claims Article 6(3), the documentation supporting it.
• > An AI policy that binds. Acceptable use, escalation, incident reporting, who may procure AI, and who may switch it on. Centralised procurement is the practical control that stops unapproved tools entering the stack.
• > AI literacy, delivered and evidenced. Article 4 is in force now; role-appropriate training, with a record that it happened.
• > Human oversight with teeth. Named people, with competence, and with the authority to suspend.
• > Vendor contracts that work. The provider’s Article 13 information, the instructions for use, the Article 6(3) documentation, cooperation on FRIA, and audit rights. Contracts signed today will still be running in December 2027.
• > Logging and monitoring, integrated into your existing CRD/DORA framework rather than parallel to it.

This is the workstream I run with clients: scope, classify, close the gaps, and put the governance where the regulator will look for it – inside the risk framework you already have.

The AI Act does not arrive on an empty desk. For a regulated financial entity it sits on top of three regimes you already run, and the overlaps are the whole opportunity to do this efficiently.

DORA (Regulation (EU) 2022/2554)

An AI system used in risk management, customer-facing services, or operational processes is an ICT asset: it falls inside DORA’s ICT risk-management, testing, incident-reporting, and third-party-risk requirements. The AI Act layers AI-specific controls – data quality, human oversight, transparency – on top. It does not replace DORA, and DORA does not discharge it.

Financial-services governance (CRD, MiFID, Solvency II)

As set out in §7, Article 26(5)–(6) let financial institutions discharge the monitoring and logging duties through their existing internal-governance frameworks. This is the single most useful provision in the Act for a regulated firm.

GDPR

Scoring natural persons is processing personal data, with everything that follows – lawful basis, transparency about automated decision-making, data-subject rights. The FRIA complements the DPIA; Article 50 transparency supplements, rather than satisfies, GDPR’s information duties.

If you are also a CASP or a payment institution, the AI governance layer belongs inside the same risk framework you built for MiCA or PSD2 – not beside it.

If you build on top of a general-purpose model rather than deploying a finished system, Chapter V (Articles 51–56) matters – though mostly as the upstream duties of the model provider, in force since 2 August 2025. GPAI providers must maintain risk management and technical documentation, publish a summary of copyrighted training data, ensure cybersecurity, and pass information downstream on capabilities, limitations, and risk mitigation. Models meeting the systemic-risk threshold (Article 51, Annex XIII) carry additional duties under Article 55 – adversarial evaluation, systemic-risk mitigation, and serious-incident reporting to the AI Office.

For a deployer, the practical point is narrow but real: the documentation your GPAI provider hands you is the raw material for your own Article 26 and FRIA compliance when you build a high-risk system on top of it. If the upstream information is thin, your downstream compliance is too.

Penalties for prohibited practices have applied since February 2025; the rest become fully enforceable from 2 August 2026.

The AI Act required Member States to designate their national competent and market-surveillance authorities by 2 August 2025 (Article 70). Poland has not done so. The implementing act – the ustawa o systemach sztucznej inteligencji, which would create a single central authority, the Komisja Rozwoju i Bezpieczeństwa Sztucznej Inteligencji (KRiBSI), acting as both competent authority and market-surveillance authority – has been passed by parliament and is with the President for signature. As at July 2026 it has been neither signed nor vetoed. KRiBSI does not yet exist, and Poland remains in default of the Article 70 deadline.

Anyone who has watched the crypto file will recognise the shape of this. The Polish Crypto-Asset Market Act sat in exactly this position and was vetoed three times – most recently on 11 June 2026 – leaving Poland with no operational CASP procedure after the MiCA transition closed. The AI systems act is now on the same desk. That is not a prediction; it is a reason not to build your compliance calendar around a national statute that has not been signed.

None of which suspends the AI Act. This is the point firms get wrong, and it is worth being blunt about. The AI Act is a regulation: it applies directly in Poland, and it has been applying since February 2025. The obligations in force – AI literacy (Article 4), prohibited practices (Article 5), GPAI, and from 2 August 2026 the transparency rules in Article 50 – bind Polish deployers today, regardless of which authority is eventually designated to enforce them. What the gap delays is the enforcement machinery, not the duty.

And the enforcement vacuum is narrower than it looks. A regulated financial firm is not unsupervised while Warsaw sorts out KRiBSI: KNF supervises you as a financial entity and reaches AI through your internal-governance and model-risk framework; UODO reaches the same models through GDPR; UOKiK reaches customer-facing practice through consumer law. The designation gap changes who eventually writes the AI Act fine. It does not change whether your credit-scoring model is lawful.