Fintech et conformité : DORA, RGPD et DSP2

Les fintech évoluent dans un environnement réglementaire d’une densite exceptionnelle. La superposition du règlement DORA (résilience opérationnelle numérique), du RGPD (protection des données personnelles) et de la DSP2 (directive sur les services de paiement) cree un maillage d’obligations croisées qui peut sembler paralysant pour des structures souvent de taille modeste. Pourtant, la conformité à ces trois textes n’est pas optionnelle : elle conditionne l’agrément, la pérennité et la crédibilité de ces acteurs. Cet article analyse les obligations de chaque texte et les stratégies de mise en conformité adaptées au modèle opérationnel des fintech.

Le périmètre réglementaire des fintech

Qui est concerne ?

Le terme “fintech” ne correspond pas à une catégorie juridique précise. Il recouvre un ensemble hétérogène d’acteurs qui utilisent la technologie pour fournir des services financiers. Sous l’angle réglementaire, les fintech peuvent relever de plusieurs statuts :

• Etablissements de paiement agréés au titre de la DSP2 (directive (UE) 2015/2366).
• Etablissements de monnaie électronique agréés au titre de la directive 2009/110/CE.
• Prestataires de services sur actifs numériques (PSAN) enregistrés ou agréés auprès de l’AMF.
• Sociétés de gestion agréées au titre de la directive AIFM ou de la directive UCITS.
• Entreprises d’investissement agréées au titre de MiFID II.
• Plateformes de financement participatif agréées au titre du règlement (UE) 2020/1503.

Chacun de ces statuts détermine le périmètre exact des obligations applicables au titre de DORA, du RGPD et de la DSP2.

L’application de DORA aux fintech

Le règlement DORA s’appliqué à l’ensemble des entités financières visées à l’article 2, qui inclut expressément les établissements de paiement, les établissements de monnaie électronique, les entreprises d’investissement, les sociétés de gestion et les prestataires de services sur crypto-actifs. Les fintech détenant l’un de ces agrements sont donc pleinement assujetties a DORA.

Le règlement prévoit néanmoins un principe de proportionnalité (article 4) : les exigences s’appliquent en tenant compte de la taille de l’entité, de la nature, de l’échelle et de la complexité de ses services, activités et opérations. Ce principe est essentiel pour les fintech de petite taille, qui ne peuvent être soumises aux mêmes exigences opérationnelles que les grandes banques systémiques.

Les obligations DORA pour les fintech

La gestion des risques TIC

L’article 6 de DORA impose à chaque entité financière de mettre en place un cadre de gestion des risques TIC complet. Pour les fintech, dont le modèle d’affaires repose intégralement sur la technologie, cette obligation couvre l’ensemble de l’activité.

Le cadre de gestion des risques doit couvrir :

• L’identification des actifs TIC, des systèmes et des interdépendances.
• La protection par des mesures de sécurité appropriées (chiffrement, contrôle d’accès, gestion des correctifs).
• La détection des incidents et des anomalies.
• La réponse aux incidents et le rétablissement des services.
• L’amélioration continue fondée sur le retour d’expérience.

Pour les fintech cloud-native, la gestion des risques TIC doit intégrer l’ensemble de l’infrastructure cloud et les prestataires tiers, conformément aux exigences d’externalisation de DORA.

La notification des incidents

L’article 19 de DORA impose la notification des incidents TIC majeurs à l’autorité de supervision compétente. Pour les fintech, les seuils de classification des incidents doivent être calibres à leur échelle. Un incident affectant la disponibilité du service de paiement pour un établissement de paiement fintech peut être qualifié de majeur même si le nombre d’utilisateurs affectés est inférieur a celui d’une grande banque.

Les tests de résilience

L’article 25 impose des tests de résilience opérationnelle adaptés au profil de risque de l’entité. Pour les fintech, ces tests comprennent au minimum des analyses de vulnérabilités, des tests de performance et des tests de continuité d’activité. Les fintech les plus importantes peuvent être soumises aux tests de penetration fondés sur les menaces (TLPT) prévus à l’article 26.

La gestion des prestataires TIC tiers

Les fintech recourent massivement à des prestataires TIC tiers : fournisseurs cloud, fournisseurs d’API bancaires, prestataires de KYC numérique, fournisseurs de solutions de chiffrement. DORA impose de cartographier ces dépendances, de formaliser les relations contractuelles avec les clauses obligatoires prévues à l’article 30 et de maintenir un registre des accords contractuels.

Les obligations RGPD spécifiques aux fintech

Les bases légales des traitements

Les fintech traitent des catégories variées de données personnelles : données d’identification, données financières, historiques de transactions, données de localisation, données comportementales. Chaque traitement doit reposer sur une base légale identifiée :

• L’exécution du contrat (article 6.1.b) pour les traitements nécessaires à la fourniture du service.
• L’obligation légale (article 6.1.c) pour les traitements liés au KYC, à la LCB-FT et aux obligations prudentielles.
• L’intérêt légitime (article 6.1.f) pour les traitements de prévention de la fraude et d’amélioration des services.
• Le consentement (article 6.1.a) pour les traitements de prospection commerciale et de profilage.

La sécurité des données

L’article 32 du RGPD impose des mesures de sécurité appropriées au risque. Pour les fintech, qui traitent des données financières sensibles, ce niveau de sécurité est elevee. Les mesures attendues incluent le chiffrement de bout en bout des communications, la tokenisation des données de paiement, l’authentification multi-facteurs, la segmentation des réseaux et la journalisation des accès.

La notification des violations

L’article 33 du RGPD impose la notification à la CNIL des violations de données personnelles dans un délai de 72 heures. Pour les fintech, cette obligation se cumulé avec les obligations de notification DORA et, le cas échéant, avec les obligations de notification prévues par les réglementations sectorielles. La mise en place d’une procédure unifiée de notification est indispensable pour éviter les retards et les incohérences.

L’analyse d’impact

Les traitements de données à grande échelle, le profilage financier et le scoring de crédit sont susceptibles de nécessiter une analyse d’impact relative à la protection des données (AIPD) au titre de l’article 35 du RGPD. La CNIL a publié une liste des traitements pour lesquels une AIPD est requise, incluant explicitement les traitements de données financières à grande échelle.

Les obligations DSP2 et leur articulation

L’accès aux comptes et l’open banking

La DSP2 (directive (UE) 2015/2366) a cree deux nouveaux types de services de paiement qui sont au coeur du modèle de nombreuses fintech :

• Les services d’initiation de paiement (Payment Initiation Services, PIS), permettant d’initier un paiement depuis le compte du client auprès de sa banque.
• Les services d’information sur les comptes (Account Information Services, AIS), permettant d’agreger les informations de comptes de différentes banques.

Ces services impliquent l’accès à des données financières personnelles via des API mises à disposition par les banques. L’articulation avec le RGPD est directe : chaque accès aux données de compte doit être fondé sur le consentement explicite du client (article 94 de la DSP2) et respecter le principe de minimisation.

L’authentification forte du client

L’article 97 de la DSP2 impose une authentification forte du client (Strong Customer Authentication, SCA) pour l’accès aux comptes en ligne, l’initiation de paiements électroniques et toute action à distance susceptible de présenter un risque de fraude. La SCA repose sur au moins deux des trois facteurs suivants : connaissance (mot de passe), possession (téléphone, carte) et inherence (biométrie).

L’utilisation de la biométrie pour la SCA implique un traitement de données sensibles au sens de l’article 9 du RGPD. Le consentement explicite de l’utilisateur est généralement requis, et des mesures de protection renforcées doivent être mises en oeuvre conformément aux recommandations de l’EDPB.

La limitation des finalités

L’article 94, paragraphe 2, de la DSP2 interdit aux prestataires de services de paiement d’accéder aux données personnelles, de les traiter ou de les conserver au-delà de ce qui est nécessaire à la fourniture du service de paiement concerne. Cette exigence de finalité limitée est plus stricte que le principe général de limitation des finalités du RGPD et impose aux fintech de cloisonner rigoureusement les données collectées via les API bancaires.

Les stratégies de conformité pour les fintech

L’approche intégrée

Les fintech ont intérêt à adopter une approche intégrée de la conformité plutôt que de traiter chaque réglementation en silo. DORA, RGPD et DSP2 partagent des exigences communes qui peuvent être mutualisees :

• La cartographie des systèmes et des données sert simultanément la gestion des risques TIC (DORA), le registre des traitements (RGPD) et la documentation des flux de données (DSP2).
• Les mesures de sécurité répondent aux exigences de DORA (articles 8 à 10), du RGPD (article 32) et de la DSP2 (article 95).
• Les procédures de notification d’incidents couvrent les obligations DORA (article 19) et RGPD (article 33).
• La gestion des prestataires tiers répond aux exigences DORA (articles 28 à 30) et RGPD (article 28).

Le principe de proportionnalité

Les fintech de petite taille doivent s’appuyer sur le principe de proportionnalité consacré par DORA (article 4) pour calibrer leurs obligations à leur profil de risque. Ce principe ne dispense pas du respect des obligations fondamentales mais permet d’adapter les modalités de mise en oeuvre :

• Des procédures simplifiées de gestion des risques TIC pour les entités de petite taille.
• Des tests de résilience adaptés au périmètre technique de l’entité.
• Une documentation proportionnée à la complexité des opérations.

La certification et les standards

Le recours aux certifications reconnues constitue un levier de conformité efficace pour les fintech. La certification ISO 27001 couvre un périmètre significatif des exigences de sécurité de DORA et du RGPD. La certification PCI DSS répond aux exigences de sécurité des données de paiement. Le référentiel SecNumCloud de l’ANSSI offre un cadre de référence pour la sécurité cloud.

Les risques de non-conformité

Les sanctions cumulatives

La non-conformité exposé les fintech à des sanctions cumulatives au titre de chaque réglementation :

• DORA : sanctions définies par les autorités nationales, pouvant inclure des amendes, des injonctions et le retrait d’agrément.
• RGPD : sanctions de la CNIL pouvant atteindre 20 millions d’euros ou 4 % du chiffre d’affaires mondial.
• DSP2 : sanctions définies par l’ACPR, pouvant inclure le retrait de l’agrément d’établissement de paiement.

Pour une fintech, le retrait d’agrément constitue la sanction la plus grave car elle interdit l’exercice même de l’activité.

Le risque réputationnel

Au-delà des sanctions formelles, la non-conformité exposé les fintech à un risque réputationnel majeur dans un marché ou la confiance est un actif essentiel. Une violation de données personnelles, un incident de sécurité non maîtrise ou une sanction réglementaire peuvent compromettre durablement la crédibilité d’une fintech auprès de ses clients, de ses partenaires bancaires et de ses investisseurs.

FAQ

Les fintech en phase de pré-agrément sont-elles soumises à DORA ?

DORA s’appliqué aux entités financières agréées ou enregistrées. Une fintech en phase de pré-agrément n’est pas formellement assujettie a DORA tant qu’elle n’a pas obtenu son agrément. Toutefois, les autorités de supervision évaluent la conformité aux exigences de DORA dans le cadre de l’instruction de la demande d’agrément. La fintech doit donc démontrer sa capacité à respecter les exigences de DORA dès le stade de la candidature, ce qui implique d’intégrer ces exigences dans la conception de ses systèmes et de ses processus.

Comment une fintech peut-elle concilier l’open banking (DSP2) avec les obligations de sécurité de DORA ?

L’open banking repose sur l’ouverture des données financières via des API sécurisées. DORA impose de maîtriser les risques TIC, y compris ceux liés aux interfaces ouvertes. La conciliation passe par la mise en oeuvre de mesures de sécurité robustes pour les API (authentification forte, chiffrement, limitation de debit, surveillance des accès), l’intégration des API dans le périmètre de gestion des risques TIC et la contractualisation des obligations de sécurité avec les banques et les partenaires via des accords conformes à l’article 30 de DORA.

Le principe de proportionnalité de DORA exempte-t-il les petites fintech de certaines obligations ?

Le principe de proportionnalité de l’article 4 de DORA permet d’adapter les modalités de mise en oeuvre des obligations, mais il n’exempte pas les petites fintech des obligations elles-mêmes. Toute entité financière agréée doit disposer d’un cadre de gestion des risques TIC, notifier les incidents majeurs, conduire des tests de résilience et gérer ses prestataires TIC tiers. L’ampleur et la sophistication de ces dispositifs doivent en revanche être proportionnées à la taille et à la complexité de l’entité.