Skip to main content

Article 10 for Fintech AI: Data and Data Governance

How Article 10 (data and data governance) applies to credit-scoring and insurance AI: the Annex III hooks, bias examination, special categories of data under Article 4a, dates, fines and what the Act leaves open.

Providers of credit-scoring and life or health insurance AI systems must develop them on data sets that meet the quality criteria of Article 10.

These are high-risk uses under Annex III, points 5(b) and 5(c); fraud detection is excluded from point 5(b). The duty applies from 2 December 2027, unless the Article 6(3) exception applies. Fines can reach up to EUR 15 million or, for an undertaking, up to 3% of worldwide annual turnover, whichever is higher (Article 99(4)). Next step: write down where your data come from and how you examine them for bias (Article 10(2)).

Article 10 sets quality criteria for data, not data volumes

Article 10 sets duties for the provider. It names no data volume, accuracy value or retention period.

  • Art. 10(1), (6)
    Data sets that meet the quality criteria

    High-risk AI systems that train AI models with data must be developed on training, validation and testing data sets. These data sets must meet the quality criteria in paragraphs 2, 3 and 4 and in Article 4a(1) whenever such data sets are used. For systems that do not train models, these provisions apply only to the testing data sets.

  • Art. 10(2)
    Data governance and management practices

    Data sets must be subject to data governance and management practices appropriate for the intended purpose. These practices concern in particular the design choices, the data collection processes and the origin of the data, and, for personal data, the original purpose of collection. They also concern data-preparation operations such as annotation, labelling, cleaning, updating, enrichment and aggregation. They concern the assumptions about what the data measure and represent. And they concern the availability, quantity and suitability of the data sets needed, and data gaps or shortcomings and how to address them.

  • Art. 10(2)(f), (g)
    Examine for bias, then detect, prevent and mitigate it

    The practices must include an examination of possible biases (point (f)). It covers biases that are likely to affect the health and safety of persons, have a negative impact on fundamental rights or lead to discrimination prohibited under Union law, especially where data outputs influence inputs for future operations. The practices must also include appropriate measures to detect, prevent and mitigate the biases identified (point (g)).

  • Art. 10(3)
    Relevant, representative, free of errors as far as possible

    Data sets must be relevant, sufficiently representative and, to the best extent possible, free of errors and complete in view of the intended purpose. They must have the appropriate statistical properties, including, where applicable, for the persons or groups of persons the system is intended to be used on. These characteristics may be met at the level of individual data sets or of a combination of them.

  • Art. 10(4)
    Fit the setting of use

    Data sets must take into account the characteristics or elements particular to the specific geographical, contextual, behavioural or functional setting in which the system is intended to be used. This applies to the extent required by the intended purpose.

Which fintech AI must meet Article 10

Article 10 applies to high-risk AI systems only. The rows below show where fintech AI becomes high-risk.

  • Fintech is not a category in the Act

    The Act has no fintech category. This site uses the word for AI that reaches the Act through two uses in Annex III, point 5. Point 5(b) covers AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score. It makes an exception for AI systems used for the purpose of detecting financial fraud. Point 5(c) covers AI systems intended to be used for risk assessment and pricing in relation to natural persons in the case of life and health insurance. Point 5 does not name fraud detection, anti-money-laundering or know-your-customer checks, algorithmic trading, robo-advice, non-life insurance, claims handling or credit decisions about legal persons. A system for one of these uses is high-risk only if another point of Annex III or Annex I covers it.

  • Article 6(3) can take a system out of Annex III

    A system under point 5(b) or 5(c) is high-risk under Article 6(2). Under Article 6(3) it is not high-risk if it does not pose a significant risk of harm to health, safety or fundamental rights. That includes not materially influencing the outcome of decision making. The Act applies this exception where any of the following conditions is fulfilled (Article 6(3), points (a) to (d)). The system is intended to perform a narrow procedural task. Or it is intended to improve the result of a previously completed human activity. Or it is intended to detect decision-making patterns or deviations from prior decision-making patterns and is not meant to replace or influence the previously completed human assessment, without proper human review. Or it is intended to perform a preparatory task to an assessment relevant for the use cases listed in Annex III. How these conditions combine with the significant-risk test is a question for counsel. The system is always high-risk where it performs profiling of natural persons. Profiling is defined by Article 4(4) GDPR (Article 3(52)). Whether a given scoring or pricing system performs it is also a question for counsel. A provider that relies on the exception documents its assessment before the system is placed on the market or put into service. It must also register the system (Article 6(4), Article 49(2)).

  • Provider and deployer

    The provider develops an AI system, or has it developed, and places it on the market or puts it into service under its own name or trademark (Article 3(3)). Putting into service includes supply for the provider’s own use (Article 3(11)). A bank or insurer that develops a system and puts it into service under its own name is therefore a provider. A bank or insurer that uses a system under its authority is a deployer (Article 3(4)). A deployer becomes the provider in three cases. It puts its name or trademark on a high-risk system already on the market, without prejudice to contractual arrangements stipulating that the obligations are otherwise allocated. It makes a substantial modification to such a system that leaves it high-risk. Or it changes the intended purpose of a non-high-risk system so that it becomes high-risk (Article 25(1)). The provider that initially placed the system on the market or put it into service is then no longer considered the provider of that specific system, and must closely cooperate with the new provider (Article 25(2)). This does not apply where the initial provider clearly specified that its system is not to be changed into a high-risk AI system.

  • Special categories of personal data: Article 4a

    Alongside the GDPR and the other data protection rules that apply, providers of high-risk AI systems may exceptionally process special categories of personal data. This is allowed to the extent strictly necessary for bias detection and correction under Article 10(2), points (f) and (g). All conditions of Article 4a(1), points (a) to (f), must be met. They include that bias detection and correction cannot be effectively fulfilled by processing other data, such as synthetic or anonymised data. They also include that the data are deleted once the bias has been corrected or the retention period ends, whichever comes first. Article 4a(2) gives providers and deployers of other AI systems, and deployers of high-risk systems, the same permission on the same conditions. It does not create any obligation to conduct bias detection and correction.

  • Dates

    The requirements for these Annex III uses apply from 2 December 2027 (Article 113, third paragraph, point (c)(i)). A system placed on the market or put into service before that date is covered only if its design changes significantly afterwards. In any case, providers and deployers of high-risk systems intended to be used by public authorities must take the necessary steps to comply by 2 August 2030 (Article 111(2)).

  • Fines

    Providers must ensure that their high-risk systems meet the requirements of Section 2 of Chapter III, which includes Articles 9 to 15 (Article 16, point (a)). A breach of the provider obligations in Article 16 or of the deployer obligations in Article 26 can be fined. The fine is up to EUR 15 million or, for an undertaking, up to 3% of its total worldwide annual turnover for the preceding financial year, whichever is higher (Article 99(4), points (a) and (e)). For SMEs, including start-ups, each fine is up to whichever of the two is lower (Article 99(6)). The same applies to small mid-cap enterprises (Article 3(14b), Article 99(6a)). Each Member State lays down rules on to what extent administrative fines may be imposed on public authorities and bodies established in that Member State (Article 99(8)).

  • Reach and limits of the Act

    The Act applies to providers and deployers established or located in a third country where the output produced by the AI system is used in the Union (Article 2(1), point (c)). It does not apply to areas outside the scope of Union law, and it does not affect the competences of the Member States concerning national security (Article 2(3)). The Act does not apply to AI systems or AI models, including their output, specifically developed and put into service for the sole purpose of scientific research and development (Article 2(6)). It does not apply to research, testing or development activity before a system is placed on the market or put into service. Testing in real-world conditions is not covered by that exclusion (Article 2(8)). AI systems released under free and open-source licences are outside the Act. That exclusion does not apply if they are placed on the market or put into service as high-risk AI systems, or if they fall under Article 5 or 50 (Article 2(12)).

What the Act leaves open for fintech

  • No fintech data standard

    Article 10 names no minimum data size, representativeness measure, bias metric or accepted data source for lending or insurance. The provider decides what is appropriate for the intended purpose (Article 10(2)). The Act itself names no harmonised standard. High-risk systems that conform to harmonised standards published in the Official Journal are presumed to conform to the requirements of Section 2, to the extent those standards cover them (Article 40(1)). Systems trained and tested on data reflecting the specific geographical, behavioural, contextual or functional setting of intended use are presumed to comply with Article 10(4) (Article 42(1)). The Commission is to develop guidelines on the practical application of the requirements and obligations in Articles 8 to 15, 25 and 26 (Article 96(1), point (a)).

  • Example: bias examination for credit scoring

    Example, not an Act requirement: a provider of a credit-scoring system could compare approval rates and error rates across applicant groups in the data set. It could document which groups the data under-represent.

  • Example: historical decisions as training labels

    Example, not an Act requirement: a model may be trained on past lending or underwriting decisions. A provider could examine whether those decisions carry bias before training, as Article 10(2), point (f) asks for an examination of possible biases.

Questions about Article 10 in fintech

Does Article 10 apply to a fraud-detection model?

Only if it is a high-risk AI system. Annex III point 5(b) excludes AI systems used for the purpose of detecting financial fraud. A fraud model is therefore covered only if another point of Annex III or Annex I makes it high-risk.

May a lender use special categories of personal data to test its credit model for bias?

A provider of a high-risk AI system may exceptionally process them to the extent strictly necessary for bias detection and correction, if all conditions of Article 4a(1) are met. Article 4a(2) gives deployers of high-risk systems the same permission on the same conditions. The last sentence of Article 4a(2) states that this paragraph does not create any obligation to conduct such bias detection and correction. The GDPR continues to apply (Article 2(7)).

Who must meet Article 10 when a bank buys a scoring tool?

The provider. The bank is a deployer. To the extent it controls the input data, it must ensure that the input data is relevant and sufficiently representative in view of the intended purpose (Article 26(4)). A bank that becomes the provider under Article 25(1) takes over Article 10 as well.

Scanara prepares evidence from your repositories

Scanara reads your connected GitHub repositories and runs rule-based scans for standard AI and machine-learning patterns. It can miss non-standard code. Separately, it generates draft documentation from templates and your assessment answers as evidence for your compliance work. You make the classification decisions.