Fintech et conformite : DORA, RGPD et DSP2

Les fintech evoluent dans un environnement reglementaire d’une densite exceptionnelle. La superposition du reglement DORA (resilience operationnelle numerique), du RGPD (protection des donnees personnelles) et de la DSP2 (directive sur les services de paiement) cree un maillage d’obligations croisees qui peut sembler paralysant pour des structures souvent de taille modeste. Pourtant, la conformite a ces trois textes n’est pas optionnelle : elle conditionne l’agrement, la perennite et la credibilite de ces acteurs. Cet article analyse les obligations de chaque texte et les strategies de mise en conformite adaptees au modele operationnel des fintech.

Le perimetre reglementaire des fintech

Qui est concerne ?

Le terme “fintech” ne correspond pas a une categorie juridique precise. Il recouvre un ensemble heterogene d’acteurs qui utilisent la technologie pour fournir des services financiers. Sous l’angle reglementaire, les fintech peuvent relever de plusieurs statuts :

• Etablissements de paiement agrees au titre de la DSP2 (directive (UE) 2015/2366).
• Etablissements de monnaie electronique agrees au titre de la directive 2009/110/CE.
• Prestataires de services sur actifs numeriques (PSAN) enregistres ou agrees aupres de l’AMF.
• Societes de gestion agreees au titre de la directive AIFM ou de la directive UCITS.
• Entreprises d’investissement agreees au titre de MiFID II.
• Plateformes de financement participatif agreees au titre du reglement (UE) 2020/1503.

Chacun de ces statuts determine le perimetre exact des obligations applicables au titre de DORA, du RGPD et de la DSP2.

L’application de DORA aux fintech

Le reglement DORA s’applique a l’ensemble des entites financieres visees a l’article 2, qui inclut expressement les etablissements de paiement, les etablissements de monnaie electronique, les entreprises d’investissement, les societes de gestion et les prestataires de services sur crypto-actifs. Les fintech detenant l’un de ces agrements sont donc pleinement assujetties a DORA.

Le reglement prevoit neanmoins un principe de proportionnalite (article 4) : les exigences s’appliquent en tenant compte de la taille de l’entite, de la nature, de l’echelle et de la complexite de ses services, activites et operations. Ce principe est essentiel pour les fintech de petite taille, qui ne peuvent etre soumises aux memes exigences operationnelles que les grandes banques systemiques.

Les obligations DORA pour les fintech

La gestion des risques TIC

L’article 6 de DORA impose a chaque entite financiere de mettre en place un cadre de gestion des risques TIC complet. Pour les fintech, dont le modele d’affaires repose integralement sur la technologie, cette obligation couvre l’ensemble de l’activite.

Le cadre de gestion des risques doit couvrir :

• L’identification des actifs TIC, des systemes et des interdependances.
• La protection par des mesures de securite appropriees (chiffrement, controle d’acces, gestion des correctifs).
• La detection des incidents et des anomalies.
• La reponse aux incidents et le retablissement des services.
• L’amelioration continue fondee sur le retour d’experience.

Pour les fintech cloud-native, la gestion des risques TIC doit integrer l’ensemble de l’infrastructure cloud et les prestataires tiers, conformement aux exigences d’externalisation de DORA.

La notification des incidents

L’article 19 de DORA impose la notification des incidents TIC majeurs a l’autorite de supervision competente. Pour les fintech, les seuils de classification des incidents doivent etre calibres a leur echelle. Un incident affectant la disponibilite du service de paiement pour un etablissement de paiement fintech peut etre qualifie de majeur meme si le nombre d’utilisateurs affectes est inferieur a celui d’une grande banque.

Les tests de resilience

L’article 25 impose des tests de resilience operationnelle adaptes au profil de risque de l’entite. Pour les fintech, ces tests comprennent au minimum des analyses de vulnerabilites, des tests de performance et des tests de continuite d’activite. Les fintech les plus importantes peuvent etre soumises aux tests de penetration fondes sur les menaces (TLPT) prevus a l’article 26.

La gestion des prestataires TIC tiers

Les fintech recourent massivement a des prestataires TIC tiers : fournisseurs cloud, fournisseurs d’API bancaires, prestataires de KYC numerique, fournisseurs de solutions de chiffrement. DORA impose de cartographier ces dependances, de formaliser les relations contractuelles avec les clauses obligatoires prevues a l’article 30 et de maintenir un registre des accords contractuels.

Les obligations RGPD specifiques aux fintech

Les bases legales des traitements

Les fintech traitent des categories variees de donnees personnelles : donnees d’identification, donnees financieres, historiques de transactions, donnees de localisation, donnees comportementales. Chaque traitement doit reposer sur une base legale identifiee :

• L’execution du contrat (article 6.1.b) pour les traitements necessaires a la fourniture du service.
• L’obligation legale (article 6.1.c) pour les traitements lies au KYC, a la LCB-FT et aux obligations prudentielles.
• L’interet legitime (article 6.1.f) pour les traitements de prevention de la fraude et d’amelioration des services.
• Le consentement (article 6.1.a) pour les traitements de prospection commerciale et de profilage.

La securite des donnees

L’article 32 du RGPD impose des mesures de securite appropriees au risque. Pour les fintech, qui traitent des donnees financieres sensibles, ce niveau de securite est elevee. Les mesures attendues incluent le chiffrement de bout en bout des communications, la tokenisation des donnees de paiement, l’authentification multi-facteurs, la segmentation des reseaux et la journalisation des acces.

La notification des violations

L’article 33 du RGPD impose la notification a la CNIL des violations de donnees personnelles dans un delai de 72 heures. Pour les fintech, cette obligation se cumule avec les obligations de notification DORA et, le cas echeant, avec les obligations de notification prevues par les reglementations sectorielles. La mise en place d’une procedure unifiee de notification est indispensable pour eviter les retards et les incoherences.

L’analyse d’impact

Les traitements de donnees a grande echelle, le profilage financier et le scoring de credit sont susceptibles de necessiter une analyse d’impact relative a la protection des donnees (AIPD) au titre de l’article 35 du RGPD. La CNIL a publie une liste des traitements pour lesquels une AIPD est requise, incluant explicitement les traitements de donnees financieres a grande echelle.

Les obligations DSP2 et leur articulation

L’acces 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 modele de nombreuses fintech :

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

Ces services impliquent l’acces a des donnees financieres personnelles via des API mises a disposition par les banques. L’articulation avec le RGPD est directe : chaque acces aux donnees de compte doit etre fonde 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’acces aux comptes en ligne, l’initiation de paiements electroniques et toute action a distance susceptible de presenter un risque de fraude. La SCA repose sur au moins deux des trois facteurs suivants : connaissance (mot de passe), possession (telephone, carte) et inherence (biometrie).

L’utilisation de la biometrie pour la SCA implique un traitement de donnees sensibles au sens de l’article 9 du RGPD. Le consentement explicite de l’utilisateur est generalement requis, et des mesures de protection renforcees doivent etre mises en oeuvre conformement aux recommandations de l’EDPB.

La limitation des finalites

L’article 94, paragraphe 2, de la DSP2 interdit aux prestataires de services de paiement d’acceder aux donnees personnelles, de les traiter ou de les conserver au-dela de ce qui est necessaire a la fourniture du service de paiement concerne. Cette exigence de finalite limitee est plus stricte que le principe general de limitation des finalites du RGPD et impose aux fintech de cloisonner rigoureusement les donnees collectees via les API bancaires.

Les strategies de conformite pour les fintech

L’approche integree

Les fintech ont interet a adopter une approche integree de la conformite plutot que de traiter chaque reglementation en silo. DORA, RGPD et DSP2 partagent des exigences communes qui peuvent etre mutualisees :

• La cartographie des systemes et des donnees sert simultanement la gestion des risques TIC (DORA), le registre des traitements (RGPD) et la documentation des flux de donnees (DSP2).
• Les mesures de securite repondent aux exigences de DORA (articles 8 a 10), du RGPD (article 32) et de la DSP2 (article 95).
• Les procedures de notification d’incidents couvrent les obligations DORA (article 19) et RGPD (article 33).
• La gestion des prestataires tiers repond aux exigences DORA (articles 28 a 30) et RGPD (article 28).

Le principe de proportionnalite

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

• Des procedures simplifiees de gestion des risques TIC pour les entites de petite taille.
• Des tests de resilience adaptes au perimetre technique de l’entite.
• Une documentation proportionnee a la complexite des operations.

La certification et les standards

Le recours aux certifications reconnues constitue un levier de conformite efficace pour les fintech. La certification ISO 27001 couvre un perimetre significatif des exigences de securite de DORA et du RGPD. La certification PCI DSS repond aux exigences de securite des donnees de paiement. Le referentiel SecNumCloud de l’ANSSI offre un cadre de reference pour la securite cloud.

Les risques de non-conformite

Les sanctions cumulatives

La non-conformite expose les fintech a des sanctions cumulatives au titre de chaque reglementation :

• DORA : sanctions definies par les autorites nationales, pouvant inclure des amendes, des injonctions et le retrait d’agrement.
• RGPD : sanctions de la CNIL pouvant atteindre 20 millions d’euros ou 4 % du chiffre d’affaires mondial.
• DSP2 : sanctions definies par l’ACPR, pouvant inclure le retrait de l’agrement d’etablissement de paiement.

Pour une fintech, le retrait d’agrement constitue la sanction la plus grave car elle interdit l’exercice meme de l’activite.

Le risque reputationnel

Au-dela des sanctions formelles, la non-conformite expose les fintech a un risque reputationnel majeur dans un marche ou la confiance est un actif essentiel. Une violation de donnees personnelles, un incident de securite non maitrise ou une sanction reglementaire peuvent compromettre durablement la credibilite d’une fintech aupres de ses clients, de ses partenaires bancaires et de ses investisseurs.

FAQ

Les fintech en phase de pre-agrement sont-elles soumises a DORA ?

DORA s’applique aux entites financieres agreees ou enregistrees. Une fintech en phase de pre-agrement n’est pas formellement assujettie a DORA tant qu’elle n’a pas obtenu son agrement. Toutefois, les autorites de supervision evaluent la conformite aux exigences de DORA dans le cadre de l’instruction de la demande d’agrement. La fintech doit donc demontrer sa capacite a respecter les exigences de DORA des le stade de la candidature, ce qui implique d’integrer ces exigences dans la conception de ses systemes et de ses processus.

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

L’open banking repose sur l’ouverture des donnees financieres via des API securisees. DORA impose de maitriser les risques TIC, y compris ceux lies aux interfaces ouvertes. La conciliation passe par la mise en oeuvre de mesures de securite robustes pour les API (authentification forte, chiffrement, limitation de debit, surveillance des acces), l’integration des API dans le perimetre de gestion des risques TIC et la contractualisation des obligations de securite avec les banques et les partenaires via des accords conformes a l’article 30 de DORA.

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

Le principe de proportionnalite de l’article 4 de DORA permet d’adapter les modalites de mise en oeuvre des obligations, mais il n’exempte pas les petites fintech des obligations elles-memes. Toute entite financiere agreee doit disposer d’un cadre de gestion des risques TIC, notifier les incidents majeurs, conduire des tests de resilience et gerer ses prestataires TIC tiers. L’ampleur et la sophistication de ces dispositifs doivent en revanche etre proportionnees a la taille et a la complexite de l’entite.