Livre blanc — FinTech & banque digitale : transformer les services financiers

Livre blanc · Novembre 2025

FinTech & banque digitale : transformer les services financiers

Faire circuler l'argent et la donnée — sans jamais perdre la confiance

« Les acteurs qui souffrent ne sont pas ceux qui ont une vieille application, ce sont ceux qui ont cru que la transformation était une application. »

4 textes

1 trajet

90 jours

DSP2, DORA, MiCA, LCB-FT — le socle réglementaire mis en ordre, et ce qui converge

Celui d'un paiement, de l'initiation au règlement — et les cinq endroits où il casse

Le plan d'action, de la carte des parcours au premier exercice de crise

Ce livre blanc s'appuie sur l'expérience de pilotage digital du réseau Clarendis dans les services financiers, en France comme en Suisse ; il se lit seul, et se relit à chaque nouveau projet de transformation.

Sommaire

Avant-propos 03 Synthèse exécutive — le document en dix affirmations 04 Votre parcours de lecture 06 1 Le malentendu de la banque digitale L'application n'est pas la transformation · La banque est un flux de confiance · Ce que coûte le statu quo · Les trois maisons : banque privée, fintech, entreprise qui embarque la finance 07 2 Le socle réglementaire : un plan d'architecture financé DSP2 et l'open banking · DORA, la résilience opérationnelle · MiCA et les crypto-actifs · LCB-FT · Les agréments : lequel pour quoi · Ce qui converge 12 3 L'architecture : le core, les API, la donnée Le core banking, actif et passif · Le trajet réel d'un paiement · API et open banking · La donnée client et le KYC · Cloud et externalisation critique · La grille d'exigences éditeurs 18 4 Les angles morts La fraude au rythme de l'instantané · Le core historique · Prestataires critiques et BaaS · Le shadow IT des opérations · Les parcours crédit · Les crypto-actifs · La crise jamais répétée 25 5 2026-2030 : la trajectoire Le virement instantané généralisé · DSP3 et FIDA, l'open finance · De la conformité à la valeur · Les décisions sans regret de 2026 · En annexe de veille : IA, consolidation du marché 32 6 Le plan d'action 90 jours D'où partez-vous ? · J1-J30 : voir clair · J31-J60 : fiabiliser · J61-J90 : prouver — parcours pilote et exercice de crise · Le tableau de bord : cinq nombres 36 Passer à l'exécution 41 Annexes — Glossaire, sources, à propos, auto-diagnostic, veille 42-47

Avant-propos

Les services financiers vivent un paradoxe. Jamais l'expérience n'a autant progressé — un compte s'ouvre en huit minutes, un paiement traverse l'Europe en dix secondes, un crédit se simule dans un parcours e-commerce — et jamais les deux plaintes symétriques n'ont été aussi vives : « nos projets digitaux s'enlisent sur le système central » côté banques privées ; « la conformité nous coûte plus cher que la technologie » côté fintechs. Expérience et conformité sont les deux faces d'un même sujet : la maîtrise du trajet de l'argent et de la donnée client. Et presque partout, elles sont confiées à des équipes qui ne se parlent pas.

Ce livre blanc est né d'un constat de place : les projets de banque digitale qui échouent butent rarement sur la technologie — ils butent sur un core intouchable, des données client dupliquées et des responsabilités non écrites. Les standards existent, les textes existent, les architectures de référence existent. Ce qui manque, c'est une méthode qui les mette en ordre, et c'est ce que propose ce document : le malentendu d'abord (chapitre 1), le socle réglementaire (chapitre 2), l'architecture (chapitre 3), les angles morts (chapitre 4), la trajectoire européenne (chapitre 5), et un plan exécutable (chapitre 6). Le cadre décrit est celui de l'Union européenne et de la France ; les lecteurs suisses trouveront au chapitre 2 les correspondances avec leur propre cadre — les principes d'architecture, eux, ne connaissent pas de frontière.

Un point d'honnêteté intellectuelle : nous ne vendons ni core banking, ni plateforme de paiement, ni solution de conformité, et nous ne percevons aucune commission de prescription. Chaque affirmation réglementaire s'appuie sur un texte public, tous listés en annexe ; ce qui relève de notre expérience de terrain est signalé comme tel.

Comment lire ce document. Les chapitres sont autonomes. Si vos projets s'enlisent, commencez par le chapitre 3. Si le dernier rapport de l'audit interne vous a inquiété, le chapitre 2 remet le mille-feuille en ordre. Si vous préparez 2027 et l'open finance, le chapitre 5 vous attend. Chaque chapitre se clôt par le même encart, ce que ça change pour vous, décliné pour trois lecteurs : le dirigeant, le DSI, le responsable risques et conformité. Volontairement le même sujet vu de trois sièges — car ces projets échouent précisément là où direction, technologie et conformité ne partagent pas la même carte.

Bonne lecture — et que vos flux soient sûrs.

Cédric Guittard

Anna Hoang

cedric.guittard@clarendis.com

anna.hoang@clarendis.com

pour l'équipe Clarendis

Synthèse exécutive

Le document en dix affirmations. Chacune est développée et sourcée dans le chapitre indiqué.

1

2

La transformation n'est pas une application. C'est la maîtrise du trajet de l'argent et de la donnée client : qui initie, où ça passe, qui contrôle, qui règle. L'application n'est que la surface de ce trajet. (Chapitre 1)

Le cadre n'est plus une perspective, c'est un acquis. DSP2 en vigueur depuis des années, DORA applicable depuis janvier 2025, MiCA déployé, LCB-FT renforcée : la question n'est plus « faut-il ? » mais « où en sommes-nous réellement ? ». (Chapitre 2)

3

4

Le mille-feuille converge sur quatre exigences simples. L'inventaire (flux, prestataires, accès), la maîtrise des identités et de la donnée client, la résilience testée, la preuve. Un programme bien mené sert toutes les conformités à la fois. (Chapitre 2)

Le premier chantier n'est pas l'application, c'est la donnée client. Un référentiel client unique, un KYC qui ne se refait pas à chaque produit, des doublons résorbés : c'est le chantier le plus rentable du chapitre 3, et le plus sous-estimé. (Chapitre 3)

5

6

On n'échappe pas au core — on l'isole. Remplacer le système central est le projet le plus risqué de la banque ; l'étrangler derrière une couche d'API et déplacer l'innovation en périphérie est la stratégie qui marche. Ne rien décider, en revanche, est la pire option. (Chapitre 3)

L'instantané change la fraude de nature. Dix secondes pour créditer, c'est dix secondes pour frauder : le contrôle passe du lot à la transaction, de la nuit au temps réel. Un dispositif anti-fraude pensé pour le virement à J+1 est déjà obsolète. (Chapitre 4)

7

8

Vos prestataires sont votre surface de risque. BaaS, cloud, processeurs de paiement, outils de conformité en SaaS : DORA fait de la chaîne de sous-traitance un sujet de gouvernance — registre, contrats, tests, sortie. La réversibilité se négocie à la signature. (Chapitres 3-4)

Vos angles morts sont périphériques — donc décisifs. Le tableur des opérations, le parcours crédit qui contourne le scoring, le core que plus personne ne sait modifier, la crise jamais répétée : chaque angle mort du chapitre 4 est un incident réglementaire ou un blocage client en préparation. (Chapitre 4)

9

10

L'Europe fixe l'horizon : l'open finance. Virement instantané généralisé en 2025-2026, DSP3 et FIDA en préparation, euro numérique à l'étude : les choix de 2026 — API, donnée, consentement — décident du coût de 2028. (Chapitre 5)

La contrainte cache un actif. La même tuyauterie qui satisfait le régulateur ouvre trois chantiers de valeur : des parcours sans rupture, une donnée qui sert le conseil et le pilotage, une résilience prouvée qui devient un argument de confiance. (Chapitre 5)

Par où commencer selon votre situation :

Rien n'est cartographié. Chapitre 1 (ce que le trajet exige), puis directement le plan 90 jours du chapitre 6, séquence « départ à froid ». Votre priorité absolue : la carte des parcours et des flux, et l'état de votre donnée client.

Les projets s'enlisent sur le core. Chapitre 3 : la stratégie d'étranglement et la couche d'API vous diront où passe le chemin — rarement par le grand remplacement. Puis chapitre 4, §4.2 : le core historique est souvent le nœud.

L'audit ou le régulateur a sonné. Chapitre 2 en entier, puis l'exercice de crise du chapitre 6 (J61-J90) : un dispositif jamais éprouvé n'est pas un dispositif — c'est un classeur.

Votre parcours de lecture FinTech & banque digitale

Votre parcours de lecture

Trois itinéraires balisés. Les encarts « Ce que ça change pour vous », en fin de chaque chapitre, sont écrits pour votre siège.

DIR Dirigeant 25 minutes

DSI DSI / CTO 1 h 30

CONF Risques & conformité 1 heure

01 Synthèse exécutive

Document complet recommandé. Votre chemin critique :

Vous vivez ce sujet au quotidien. Votre chemin :

02 chapitre 1 (§1.3 : ce que coûte le statu quo, en langage d'affaires)

01 chapitre 3 en entier (le core, le trajet d'un paiement, la donnée, la grille éditeurs)

01 chapitre 2 en entier (le mille-feuille mis en ordre, ce qui converge)

03 chapitre 5 (la trajectoire 2026-2030 — des constats, pas des prédictions)

02 chapitre 4 (votre carte des angles morts — core historique inclus)

02 chapitre 4 (les sept angles morts — votre plan d'audit de l'année)

04 chapitre 6, §6.4 (les cinq nombres de votre ordre du jour mensuel).

03 chapitre 2, DORA (la résilience devient votre cahier des charges)

03 chapitre 3, §3.4 (la donnée client : où KYC et qualité se rejoignent)

Vous saurez quoi financer, quoi exiger, et comment vérifier que ça avance.

04 chapitre 5, §5.4 (les choix techniques 2026 qui engagent 2030)

04 les six encarts « Risques & conformité », en fin de chapitre.

05 chapitre 6 en entier — le plan est le vôtre.

Ce que vous êtes venu chercher

Besoin

Où

Sous quelle forme

Une carte du cadre réglementaire qui tient sur une page

Chapitre 2

DSP2, DORA, MiCA, LCB-FT, agréments : qui exige quoi, de qui, et ce qui converge

Une stratégie d'architecture qui débloque les projets

Chapitre 3

Le core isolé, le trajet d'un paiement, la donnée client, la grille d'exigences éditeurs

Les angles morts des programmes officiels

Chapitre 4

7 situations, chacune avec sa question révélatrice et son premier geste

Un plan exécutable dès demain

Chapitre 6

90 jours en trois phases, un parcours pilote, un exercice de crise, cinq nombres

Chapitre 1

Le malentendu de la banque digitale

1

Avant de parler API et core banking, il faut libérer le sujet de son malentendu fondateur — croire que la banque digitale est une affaire d'applications — et l'ancrer dans ce qu'elle est : la maîtrise d'un trajet.

1.1 L'application n'est pas la transformation

Dix ans de « transformation digitale » ont produit un réflexe : à chaque problème, une application. Une appli mobile refaite tous les trois ans, un portail entreprise, un agrégateur, un simulateur de crédit — chacun acheté pour un besoin réel, chacun ajoutant sa base client, ses parcours, ses exports. Le constat le plus constant du secteur : l'établissement moyen ne souffre pas d'un déficit d'applications — il souffre d'un excès d'applications qui ne partagent ni les identités, ni la donnée, ni les responsabilités.

La banque digitale n'est pas une collection d'écrans : c'est un système de circulation. Une opération naît quelque part (un client, un commerçant, une API partenaire), voyage (initiation, contrôles, compensation, règlement), et engage quelqu'un (le client, l'établissement, le régulateur). Chaque maillon de ce trajet pose exactement deux questions : l'opération arrive-t-elle vite et juste ? — c'est l'expérience ; est-elle contrôlée et tracée ? — c'est la conformité. Deux questions, un trajet : voilà pourquoi ce document traite les deux ensemble.

Ce renversement a une conséquence pratique immédiate : le premier livrable d'un projet de banque digitale n'est pas une maquette — c'est une carte des parcours et des flux. Qui initie quelle opération, dans quel canal, par quels systèmes passe-t-elle, qui la contrôle, sous quelle identité client ? Cette carte — une page par domaine suffit — est le document le plus rentable du chapitre 6, et le plus souvent absent des projets que nous reprenons.

Un constat de place. Quand un établissement recense pour la première fois les applications qui touchent au parcours client, le compte dépasse presque toujours d'un tiers ce que la DSI connaissait — le reste est arrivé par le marketing, les partenariats et les filiales. Aucune malveillance nulle part : simplement, personne n'avait la carte. C'est le point de départ le plus courant, et il n'est pas honteux — il est juste urgent.

1

Chapitre 1 — Le malentendu de la banque digitale FinTech & banque digitale

1.2 Ce que le cadre exige déjà

Les services financiers ne sont plus un terrain de recommandations : c'est un cadre opposable, construit par couches depuis 2015, dont l'essentiel est déjà en vigueur. Cinq briques structurent tout le reste :

Brique

Ce qu'elle impose

Où ça se joue chez vous

DSP2 — paiements et open banking

Authentification forte du client, accès des tiers agréés aux comptes via API, responsabilités en cas de fraude

Vos parcours d'authentification et vos API de compte — leur qualité réelle, pas leur existence

DORA — Digital Operational Resilience Act , règlement (UE) 2022/2554

En une phrase : votre informatique doit résister aux pannes et aux attaques, et vous devez pouvoir le prouver — gestion du risque, registre des prestataires, tests, notification des incidents majeurs. Applicable depuis le 17 janvier 2025

Votre chaîne de sous-traitance et vos exercices — détaillés au chapitre 2

MiCA — crypto-actifs

Agrément des prestataires de services sur crypto-actifs, exigences sur les stablecoins, information des détenteurs

Toute offre crypto, directe ou en partenariat — même « en projet »

LCB-FT

Connaissance client (KYC), surveillance des opérations, déclarations de soupçon, gel des avoirs — et un paquet européen qui durcit l'ensemble

Votre donnée client : un KYC fiable est d'abord une donnée fiable

RGPD

Base légale par traitement, minimisation, droits des personnes — la donnée financière est massivement personnelle

Chaque nouveau parcours, chaque partage de donnée avec un partenaire

Deux lectures de ce tableau. La lecture défensive : « encore des obligations ». La lecture juste : le régulateur a construit, standardisé et rendu obligatoires les fondations que chaque projet local réinventait — l'authentification, l'accès aux comptes, la résilience, la connaissance client. Le travail restant vous appartient, mais il est borné : brancher proprement vos systèmes sur ces fondations, et tenir la qualité de ce qui y circule.

D'où la question qui ordonne tout ce document, à poser avant tout achat : « pour chaque opération, savons-nous dire qui l'initie, où elle passe, qui la contrôle — et sous quelle identité client ? » Tout ce qui suit est une méthode pour répondre oui.

1

Chapitre 1 — Le malentendu de la banque digitale FinTech & banque digitale

1.3 Ce que coûte le statu quo

Le statu quo — des systèmes qui ne se parlent pas, un core vieillissant, une conformité en rattrapage — a un coût, mais il est dispersé, donc invisible aux budgets. Le rendre visible est le premier acte de gouvernance :

Le coût de la ressaisie. Chaque donnée qui ne circule pas est re-saisie — par un conseiller, un middle office, le client lui-même qui refait son KYC à chaque produit. La ressaisie coûte du temps commercial, et elle coûte des abandons : chaque champ redemandé dans un parcours d'entrée en relation fait chuter la conversion. C'est le coût commercial de la non-circulation — et il se mesure, vos tunnels d'acquisition suffisent à l'objectiver.

Le coût de l'arrêt. Une indisponibilité de paiement n'est pas une panne informatique : ce sont des caisses qui ne encaissent plus, des virements de salaires en attente, des clients qui changent d'établissement, et un régulateur qui demande le rapport d'incident. Les incidents publics du secteur convergent : l'ordre de grandeur se compte en millions d'euros et en points de confiance — sans compter ce qu'aucun chiffre ne capture : l'attrition silencieuse.

Le coût de l'occasion manquée. Un partenariat de distribution impossible faute d'API, un produit d'épargne lancé six mois trop tard faute de core paramétrable, une donnée de paiement inexploitable pour le conseil : le statu quo ne fait pas que coûter — il empêche de gagner.

3 coûts

1 carte

2 questions

Ressaisie · arrêt · occasion — à objectiver dans vos propres chiffres

Des parcours et des flux — le premier livrable, avant tout achat

Vite et juste ? Contrôlée et tracée ? — sur chaque opération

1.4 À qui s'adresse ce document

Nous écrivons pour trois maisons qui partagent les mêmes obligations avec des moyens très différents : la banque privée (gestion de fortune et banque de gestion, en France comme en Suisse — riche d'un core et d'une conformité, lourde des deux, et dont la clientèle ne pardonne aucune approximation), la fintech (établissement de paiement, de monnaie électronique, néo-banque — agile, mais dont la conformité conditionne l'agrément et les levées), et l'entreprise qui embarque la finance (retailer, plateforme, éditeur qui intègre paiement ou crédit à son offre — la finance embarquée, où l'on devient acteur régulé sans l'avoir toujours anticipé). Les principes sont communs ; quand une recommandation diverge selon la maison, nous le signalons.

Une conviction pour clore ce chapitre : dans la finance plus qu'ailleurs, la technologie sert une promesse simple — que l'argent du client aille exactement où il l'a décidé, vite, et que personne d'autre n'y touche. Chaque page qui suit se juge à cette aune.

1

Chapitre 1 — Le malentendu de la banque digitale FinTech & banque digitale

1.5 Les trois maisons, en pratique

Les principes de ce document sont communs ; leur mise en œuvre diffère profondément selon votre maison. Pour chacune : le point d'entrée le plus rentable, et l'erreur la plus fréquente :

Maison

Le point d'entrée rentable

L'erreur fréquente

Le chapitre à lire deux fois

Banque privée — gestion de fortune, banque de gestion, filiale de groupe

La couche d'API au-dessus du core, et le référentiel client unique — l'innovation en périphérie, le core stabilisé

Lancer le « grand remplacement » du core sans avoir isolé ce qui en dépend — cinq ans de tunnel, valeur au bout seulement

Chapitre 3 — le core, actif et passif

Fintech — paiement, monnaie électronique, néo-banque

La conformité comme produit : KYC fluide, LCB-FT outillée, DORA démontré — l'argument qui gagne les partenariats bancaires

Traiter la conformité en dette à payer « après la croissance », quand l'agrément et les partenaires la posent en préalable

Chapitre 2 — le socle, version offensive

Finance embarquée — retailers, plateformes, éditeurs

La matrice de responsabilités avec le partenaire régulé (BaaS) : qui porte le KYC, la fraude, la réclamation — par écrit

Croire que l'agrément du partenaire couvre tout : la responsabilité d'image, elle, ne se sous-traite jamais

Chapitres 3-4 — prestataires et BaaS

Trois maisons, un point commun : aucune ne peut plus traiter le sujet en silo. La banque privée dépend des fintechs pour ses parcours ; la fintech dépend des banques pour ses comptes de cantonnement et ses partenariats ; l'entreprise embarquée dépend des deux pour exister. La qualité du système se joue à la jointure — c'est précisément là que ce document place ses chapitres 3 et 4.

Pour les plus petites structures. Si vous n'avez ni DSI ni RSSI, le document reste lisible en une heure par le parcours « Dirigeant » — et le plan du chapitre 6 se réduit pour vous à cinq gestes : la carte des parcours sur une page, un référentiel client dédoublonné, la MFA partout, la matrice de responsabilités signée avec chaque prestataire critique, et un exercice d'incident joué une fois. C'est déjà 80 % du chemin.

1

Chapitre 1 — Le malentendu de la banque digitale FinTech & banque digitale

Le modèle de décision datée, à copier tel quel

Comme dans chaque volume de cette collection, tout commence par une page signée. Dans la finance, elle a une vertu supplémentaire : elle matérialise la responsabilité de la direction sur un sujet que la réglementation de résilience (DORA, chapitre 2) lui attribue désormais explicitement.

Décision de mise sous maîtrise des flux et des parcours

« [Date]. La direction de [établissement / société] décide la mise sous maîtrise des trajets de l'argent et de la donnée client : expérience et conformité, conduites en un seul programme. [Prénom Nom] en est désigné(e) responsable. Jalons : carte des parcours et des flux sous 30 jours ; état de la donnée client et du registre des prestataires sous 60 jours ; premier parcours fiabilisé de bout en bout et premier exercice de crise sous 90 jours. Un journal daté des incidents et décisions est ouvert à compter de ce jour. Signature. »

Ce texte ne s'envoie à personne : c'est une note interne. Elle date votre trajectoire — utile au régulateur, indispensable à vos équipes. Cinq lignes datées d'aujourd'hui valent mieux que dix pages datées du prochain incident.

Ce que ça change pour vous

DIR

DSI

CONF

Dirigeant. Signez la décision datée ci-dessus cette semaine — une page, un responsable, trois jalons. Et posez la question à deux chiffres : combien d'applications touchent au parcours client, et combien la DSI en connaît. L'écart est votre vraie feuille de route.

DSI. Le premier livrable est la carte des parcours et des flux, pas un schéma d'architecture cible. Une page par domaine : qui initie, où ça passe, qui contrôle, sous quelle identité. Le chapitre 3 vous donne la grille pour la remplir.

Risques & conformité. La même carte des flux est votre cartographie des risques, rendue vivante. Chaque flux non cartographié est à la fois un trou LCB-FT et un angle mort DORA : vous partagez désormais un argument avec la DSI pour l'obtenir.

Chapitre 2

Le socle réglementaire : un plan d'architecture financé

2

Le mille-feuille — DSP2, DORA, MiCA, LCB-FT — décourage par son épaisseur. Mis en ordre, il converge sur une question : savez-vous prouver que l'argent et la donnée vont où ils doivent, même le jour où tout va mal ?

2.1 DSP2 : l'open banking, dix ans après

L a deuxième directive sur les services de paiement a fait entrer deux idées dans le droit : le compte appartient au client — des tiers agréés peuvent y accéder avec son consentement, par API, pour initier des paiements ou agréger des données — et l'authentification forte est la norme, deux facteurs parmi possession, connaissance, inhérence. Dix ans après, le bilan opérationnel est contrasté : les API existent partout, leur qualité varie énormément — taux de disponibilité, fraîcheur des données, parcours de consentement — et c'est exactement là que se joue la différence concurrentielle.

La lecture stratégique : DSP2 n'était que le premier étage. DSP3 et le règlement FIDA en préparation étendront l'accès de la donnée de paiement à la donnée financière large — épargne, crédit, assurance — avec des schémas de partage et de compensation entre acteurs. Un établissement dont les API DSP2 sont médiocres abordera l'open finance en retard structurel ; une fintech qui sait consommer et exposer proprement ces API a déjà son avantage de 2028. Le chapitre 5 y revient.

Le test qui dit tout. Demandez à vos équipes le taux de succès réel des connexions d'agrégateurs sur vos API de compte le mois dernier — pas le SLA contractuel, le taux mesuré. S'il n'est pas mesuré, vous avez votre réponse : votre open banking est déclaratif.

2

Chapitre 2 — Le socle réglementaire FinTech & banque digitale

2.2 DORA : la résilience devient un devoir de gouvernance

DORA, en clair. Digital Operational Resilience Act : le règlement européen (UE) 2022/2554, adopté fin 2022, applicable depuis le 17 janvier 2025 — directement, sans transposition nationale. Son idée tient en une phrase : une entité financière doit continuer à fonctionner pendant une panne ou une attaque, et savoir le prouver au superviseur (en France, l'ACPR et l'AMF). Il concerne la quasi-totalité des entités financières — banques, paiement, assurance, gestion, crypto — et, par ricochet contractuel, leurs prestataires informatiques. Les sanctions peuvent atteindre 2 % du chiffre d'affaires annuel mondial ; 2026 est la première année pleine de contrôles.

DORA change moins les techniques que la répartition des responsabilités. Cinq piliers :

La gestion du risque informatique, portée explicitement par l'organe de direction — formé, informé, responsable. La gestion des incidents, avec classification et notification des incidents majeurs au superviseur dans des délais courts. Les tests de résilience, jusqu'aux tests de pénétration fondés sur la menace pour les acteurs significatifs. Le risque des tiers : registre d'informations complet des prestataires informatiques, clauses contractuelles obligatoires, stratégies de sortie pour les prestataires critiques — et une supervision européenne directe des grands fournisseurs cloud. Le partage d'information entre pairs, encouragé et encadré.

La lecture opérationnelle : DORA est le cahier des charges de votre architecture, écrit par le régulateur. Le registre des prestataires est votre carte de dépendances ; les tests exigés sont vos exercices du chapitre 6 ; les stratégies de sortie sont la réversibilité que cette collection recommande à chaque contrat. Un programme DORA mené comme un dossier de conformité produit des classeurs ; mené comme un programme d'architecture, il produit de la robustesse — au même prix.

→

→

→

→

1

2

3

4

5

Gouvernance

Incidents

Tests

Tiers

Partage

Le risque IT porté par la direction, formée

Classés, notifiés, capitalisés

De résilience — joués, pas déclarés

Registre, contrats, sortie

La menace se combat à plusieurs

Le point le plus neuf pour beaucoup d'acteurs est le pilier 4 : votre chaîne de sous-traitance devient un objet réglementaire. Le BaaS, le cloud, le processeur de paiement, l'outil de KYC en SaaS : chacun doit être au registre, sous contrat conforme, avec une sortie praticable. Le chapitre 4 en fait un angle mort à part entière.

2

Chapitre 2 — Le socle réglementaire FinTech & banque digitale

2.3 MiCA, LCB-FT : la confiance, des deux côtés

MiCA (Markets in Crypto-Assets) a fait des crypto-actifs un marché régulé : agrément européen des prestataires (conservation, échange, conseil), exigences prudentielles et de gouvernance, encadrement strict des stablecoins. Conséquence pratique pour tous — pas seulement les acteurs crypto : une offre crypto se construit désormais comme un produit bancaire , avec agrément ou partenaire agréé, conformité produit et information client. L'improvisation de 2021 est terminée ; le chapitre 4 traite le cas de l'offre « en projet » qui vit déjà dans les faits.

LCB-FT. La lutte contre le blanchiment et le financement du terrorisme est le plus ancien des socles, et le plus exigeant au quotidien : connaissance client à l'entrée en relation et dans la durée, surveillance des opérations, déclarations de soupçon, gel des avoirs. Le paquet européen en cours — règlement unique, autorité européenne AMLA — harmonise et durcit l'ensemble. La leçon d'architecture est constante : un dispositif LCB-FT vaut ce que vaut la donnée client qui l'alimente. Des doublons, des identités périmées, des bénéficiaires effectifs non tracés produisent mécaniquement des alertes manquées et des faux positifs qui noient les équipes — le chapitre 3, §3.4, en fait le chantier n°1.

Ce qui converge

Texte

Ce qu'il exige en propre

Ce qui converge

DSP2 / DSP3

Authentification forte, API de compte, responsabilités fraude

Quatre exigences communes : — l'inventaire (flux, prestataires, accès) — la maîtrise des identités et de la donnée client — la résilience testée, la sortie praticable — la preuve : journaux, registres, exercices

DORA

Risque IT gouverné, registre des tiers, tests, notification

MiCA

Agrément crypto, exigences stablecoins, information

LCB-FT / RGPD

KYC, surveillance, déclarations ; base légale, minimisation, droits

La colonne de droite est la clé de lecture : un seul programme bien mené sert les quatre conformités à la fois. L'inverse — quatre dossiers instruits séparément — coûte quatre fois et ne protège rien : c'est la définition même de la conformité de papier.

Et en Suisse ? Hors Union européenne, le fond ne change pas — les étiquettes, si. La FINMA supervise ; la résilience opérationnelle relève de la circulaire FINMA sur les risques opérationnels et de l'ordonnance sur les banques (plans de continuité, externalisation, notification des cyberattaques) ; la connaissance client de la loi sur le blanchiment (LBA) et de la CDB ; la donnée personnelle de la nLPD ; les services financiers de la LSFin/LEFin. Les quatre exigences communes du tableau — inventaire, donnée client, résilience testée, preuve — restent exactement les mêmes : un établissement actif des deux côtés de la frontière peut, et devrait, les servir d'un seul programme.