Fintech et conformité : DORA, RGPD et DSP2
Fintech : déterminer les règles DORA, RGPD et DSP2 applicables, choisir les bases légales et coordonner fournisseurs, incidents et preuves.
Une fintech doit commencer par qualifier ses activités et ses statuts, puis relier chaque obligation à un produit, une entité juridique et un flux de données. Le mot « fintech » ne déclenche, à lui seul, ni DORA ni le régime des services de paiement. Le RGPD s’applique aux traitements de données personnelles entrant dans son champ, y compris chez un éditeur qui ne possède pas d’agrément financier.
Ce qu’il faut retenir
- Vérifiez le statut réglementaire de chaque société avant de lui attribuer les exigences DORA ou celles des services de paiement.
- Distinguez la base légale d’un traitement RGPD, l’accord contractuel du client et les règles sectorielles d’accès aux données.
- Un incident, un fournisseur ou un contrôle de sécurité peut relever de plusieurs textes, avec des critères différents.
- Produisez un dossier commun de preuves, puis conservez des décisions séparées pour chaque obligation.
Partir du service réellement fourni
L’article 2 de DORA énumère les catégories couvertes et les exclusions. Il vise notamment les établissements de paiement, les prestataires de services d’information sur les comptes et les prestataires de services sur crypto-actifs agréés au titre de MiCA. Le nom commercial d’une application ne permet pas de déterminer son statut.
Un éditeur qui fournit un outil de suivi budgétaire, un établissement de paiement et un prestataire qui agrège des comptes ne peuvent donc pas reprendre une même matrice réglementaire sans vérification. Un fournisseur de logiciel peut recevoir des exigences contractuelles de clients financiers sans devenir, pour cette seule raison, une entité financière soumise à toutes les obligations de DORA. Le guide des entités concernées par DORA aide à formaliser ce premier tri.
Pour chaque service, préparez une fiche courte : société opératrice, activité, agrément ou enregistrement applicable, autorité compétente, données reçues, destinataires, fournisseurs et pays d’accès. Faites valider les changements de périmètre avant une nouvelle fonctionnalité ou une nouvelle implantation.
Construire une matrice d’obligations par traitement
| Opération | Question RGPD | Vérification sectorielle |
|---|---|---|
| Ouverture d’un compte | Quelles données sont nécessaires, pour quelle finalité et quelle base légale ? | Quelles obligations d’identification s’appliquent à cette entité ? |
| Analyse de transactions | Quelle finalité précise : service demandé, lutte contre le blanchiment, prévention de la fraude ? | Quelles règles encadrent l’accès et la réutilisation ? |
| Hébergement et support | Qui est responsable de traitement ou sous-traitant ? Quels accès et transferts ? | Le contrat entre-t-il dans le registre DORA ? Soutient-il une fonction critique ou importante ? |
| Incident de production | Des données personnelles sont-elles compromises ? | Les critères de classification et de notification DORA sont-ils réunis ? |
L’Art. 6(1)(b) du RGPD concerne les traitements nécessaires au contrat avec la personne ; l’Art. 6(1)(c), ceux nécessaires à une obligation légale identifiée. L’intérêt légitime suppose sa propre analyse ; le consentement ne constitue pas une solution universelle pour des traitements facultatifs ou du profilage. La CNIL publie les conditions de ces bases légales.
Séparez, par exemple, la conservation d’une pièce pour une obligation de vigilance et son éventuelle utilisation pour entraîner un outil. La justification de la première opération n’autorise pas automatiquement la seconde. Le dossier de vérification d’identité KYC doit rendre cette séparation visible.
Ne pas confondre consentement DSP2 et consentement RGPD
Pour les acteurs concernés, le consentement explicite de l’article 94(2) de la DSP2 est une exigence contractuelle supplémentaire. Le Comité européen de la protection des données le distingue du consentement au sens du RGPD dans ses lignes directrices 06/2020, section 3.2.1.
Une case intitulée « J’accepte le traitement de mes données » ne remplace donc pas l’identification de la base légale RGPD. Décrivez le service, les données nécessaires et l’accord sectoriel demandé. Évaluez séparément tout usage supplémentaire, notamment publicitaire. Les données d’un compte peuvent aussi concerner des contreparties qui ne sont pas clientes du service : leur présence doit entrer dans l’analyse.
Organiser DORA sans inventer d’exemption de petite taille
DORA prévoit de la proportionnalité à l’article 4 et un cadre simplifié pour les catégories précisément désignées à l’article 16. Une jeune entreprise ou une petite équipe ne bénéficie pas automatiquement de ce dernier régime. La décision doit citer le statut qui ouvre effectivement droit au cadre applicable.
Reliez ensuite chaque service aux actifs TIC, aux responsables, aux fournisseurs et aux procédures de continuité. Le programme de tests doit correspondre aux exigences applicables et aux risques ; toutes les fintechs ne doivent pas réaliser des tests avancés de pénétration fondés sur la menace. Les obligations relatives aux tiers se préparent à partir du registre des accords TIC, pas d’une simple liste de logiciels achetés.
Un socle de travail utile rassemble les contrats, les configurations de sécurité, les habilitations, les exercices, les incidents et les décisions de remédiation. Les preuves peuvent être communes à plusieurs contrôles, à condition d’indiquer ce qu’elles démontrent réellement.
Traiter les incidents et les projets à risque
Un incident DORA n’est pas nécessairement une violation de données personnelles. Inversement, un envoi de données au mauvais destinataire peut exiger une analyse RGPD sans remplir les critères d’un incident majeur DORA. Utilisez une seule collecte des faits, puis deux décisions de notification documentées. Le guide sur les incidents DORA et RGPD détaille cette coordination.
Au titre de l’Art. 33(1) du RGPD, la notification à l’autorité doit intervenir, si possible, dans les 72 heures après connaissance, sauf si la violation n’est pas susceptible d’engendrer un risque pour les personnes. Ce délai ne constitue pas une règle de notification automatique pour toute panne. Les articles 32 et 35 imposent également une sécurité adaptée au risque et une analyse d’impact lorsque les conditions sont réunies ; ils ne prescrivent pas indistinctement la même architecture à toutes les applications. Voir le texte publié par la CNIL.
Avant un lancement, faites donc examiner les nouveaux usages de données, les décisions automatisées susceptibles d’affecter significativement les personnes, les dépendances externes et le scénario d’indisponibilité. Assignez à chaque écart un responsable et une preuve de résolution.
FAQ
Toutes les fintechs sont-elles soumises à DORA ?
Non. L’activité et le statut doivent correspondre au champ du règlement, en tenant compte de ses exclusions. Un prestataire technique peut aussi être concerné par les exigences de ses clients sans être lui-même une entité financière.
Le consentement DSP2 suffit-il pour réutiliser les données ?
Non. Il ne dispense ni de définir une finalité ni d’identifier une base légale RGPD. Un usage supplémentaire doit aussi respecter les restrictions sectorielles applicables.
Peut-on mutualiser les contrôles RGPD et DORA ?
Oui, lorsqu’une preuve sert réellement les deux analyses : gestion des accès, exercices ou suivi des fournisseurs, par exemple. Conservez toutefois les critères, responsables et décisions propres à chaque texte.
Recevez nos analyses pratiques sur la conformité : inscrivez-vous à la newsletter.
Thiébaut Devergranne est docteur en droit et fondateur de donneespersonnelles.fr. Il travaille depuis plus de vingt ans sur le droit des technologies et la protection des données personnelles.