Open Banking, DSP3 & FIDA — Intégration API bancaires

#Open banking, DSP2, DSP3 — construire un produit sur les APIs bancaires

L'open banking est une des rares ouvertures technologiques imposées par le droit plutôt que par le marché. Ce détail explique tout le reste : la qualité des interfaces, les délais, les taux d'échec, la structure des coûts et le rythme des évolutions ne sont pas fixés par une logique produit mais par un texte européen, sa transposition nationale et les normes techniques qui l'accompagnent. Un projet open banking qui raisonne comme un projet d'intégration d'API classique se cogne aux mêmes murs, dans le même ordre, à chaque fois.

Cette page décrit ce qui fonctionne réellement en production : quel statut réglementaire correspond à quel modèle d'affaires, quand passer par un prestataire agréé plutôt que demander son propre agrément, ce que valent concrètement les interfaces bancaires, comment concevoir un parcours de consentement qui ne perd pas la moitié des utilisateurs, et comment articuler RGPD, DORA et supervision ACPR sans doubler le budget.

Un point de méthode sur le réglementaire, que nous appliquons dans toute cette page. La DSP2 est du droit positif, appliqué depuis des années. Le paquet DSP3/PSR est une proposition législative en cours de négociation, et FIDA l'est également. Nous distinguons rigoureusement les deux, parce qu'un cahier des charges qui traite une proposition comme une obligation applicable produit des choix d'architecture prématurés et des budgets faux.

#Ce que la DSP2 a réellement ouvert

La directive (UE) 2015/2366 du 25 novembre 2015, dite DSP2, a été transposée en droit français et s'applique depuis janvier 2018. Ses normes techniques de mise en œuvre — le règlement délégué (UE) 2018/389 sur l'authentification forte du client et les standards ouverts de communication — s'appliquent depuis septembre 2019. Ce sont ces normes, plus que la directive elle-même, qui déterminent le quotidien d'une équipe technique.

Trois principes structurent l'ensemble.

L'accès obligatoire aux comptes de paiement accessibles en ligne. Une banque teneur de compte doit permettre à un prestataire tiers agréé, mandaté par le client, d'accéder aux données du compte et d'initier un paiement. Ce n'est pas une faveur commerciale, c'est une obligation. Corollaire souvent oublié : le périmètre est celui des comptes de paiement. Un compte-titres, un contrat d'assurance-vie, un livret d'épargne réglementé ou un crédit en cours n'entrent pas nécessairement dans le champ, ce qui explique pourquoi une application d'agrégation patrimoniale reste incomplète — et pourquoi le projet FIDA existe.

L'interdiction de facturer cet accès. La banque ne peut pas facturer l'accès au prestataire tiers. C'est ce qui a rendu le modèle économique de l'agrégation viable, et c'est aussi l'un des points sur lesquels le paquet en négociation est discuté.

L'authentification forte du client. Deux facteurs indépendants parmi connaissance, possession et inhérence. Elle est requise à l'accès aux données de compte en ligne et à l'initiation d'un paiement électronique, avec des exemptions encadrées. Point pratique majeur pour l'agrégation : l'exemption de ré-authentification pour l'accès aux données de compte, initialement fixée à quatre-vingt-dix jours, a été portée à cent quatre-vingts jours par un règlement délégué modifiant les normes techniques. Concrètement, cela signifie que votre utilisateur devra tout de même repasser par sa banque à intervalle régulier. Toute projection de rétention qui ignore cette ré-authentification périodique est fausse. C'est le premier poste d'attrition d'une application d'agrégation, avant même la qualité du produit.

Pour les définitions, voir open banking et DSP2 / DSP3 dans notre glossaire.

#AISP, PISP, CBPII : quel statut pour quel modèle

Le vocabulaire réglementaire recouvre trois services distincts, souvent confondus dans les cahiers des charges.

L'AISP (prestataire de services d'information sur les comptes) lit. Il agrège les soldes et les opérations des comptes de paiement que le client lui a désignés. Il ne déplace pas d'argent. Régime allégé : c'est un enregistrement auprès de l'autorité compétente, pas un agrément de plein exercice. Il n'y a pas d'exigence de capital initial, mais une assurance de responsabilité civile professionnelle ou une garantie comparable est obligatoire, ainsi que le respect des exigences de gouvernance, de sécurité et de déclaration d'incidents.

Le PISP (prestataire de services d'initiation de paiement) écrit. Sur instruction du client, il déclenche un virement depuis le compte détenu chez la banque. Il ne détient jamais les fonds. Régime plus lourd : c'est un agrément d'établissement de paiement, avec un capital initial minimum fixé par la directive — cinquante mille euros pour un établissement fournissant uniquement le service d'initiation de paiement, davantage lorsque d'autres services de paiement sont fournis. S'y ajoutent une assurance de responsabilité civile professionnelle, un dispositif de gestion des risques, un plan de continuité et un contrôle interne.

Le CBPII (émetteur d'instruments de paiement liés à une carte) interroge la banque pour savoir si les fonds sont disponibles avant d'autoriser une opération. Statut rarement pertinent hors émission de cartes.

Deux erreurs coûteuses que nous voyons régulièrement.

La première : confondre AISP et PISP dans le chiffrage. Ce sont deux régimes différents, deux dossiers différents, deux niveaux d'exigence différents. Un projet qui prévoit « l'agrégation puis le paiement dans un second temps » et qui budgète le second temps au prix du premier découvre l'écart tard.

La seconde : oublier que ces statuts ne sont pas les seuls concernés. Si vous manipulez ou détenez des fonds, même transitoirement, vous sortez du périmètre PISP et vous entrez dans celui de l'établissement de paiement au sens large, voire de l'établissement de monnaie électronique. Un « simple » compte de cantonnement dans un flux marketplace change la nature du dossier. Voir AISP / PISP et ACPR.

Dernier point structurant : le passeport européen. Un statut obtenu dans un État membre permet d'opérer dans les autres par libre prestation de services ou libre établissement, après notification. C'est un avantage réel, et une des raisons pour lesquelles des fintechs choisissent leur juridiction d'établissement en fonction de la disponibilité et de la réactivité du superviseur. Voir notre bureau de Luxembourg pour les projets transfrontaliers.

#Prestataire agréé ou agrément en propre : l'arbitrage

C'est la première décision structurante d'un projet, et elle se prend au cadrage, pas après le développement.

#Passer par un prestataire agréé

Vous vous appuyez sur le statut d'un acteur déjà enregistré ou agréé — Bridge, Powens (anciennement Budget Insight), Tink (groupe Visa), TrueLayer, Fintecture, Salt Edge, Yapily selon les géographies. Il porte la relation réglementaire avec les banques, maintient les connecteurs, gère les certificats et absorbe les évolutions des interfaces.

Ce que vous gagnez : un délai de mise sur le marché en semaines plutôt qu'en trimestres, aucun dossier de supervision, aucune obligation de fonds propres, et surtout aucune équipe à mobiliser pour maintenir les connecteurs — c'est le poste que les équipes internes sous-estiment le plus.

Ce que vous perdez : une part de la marge unitaire, une dépendance forte sur un fournisseur qui devient un tiers critique au sens DORA, et une capacité limitée à différencier votre produit sur la couverture ou la fraîcheur des données.

#Demander son propre statut

Vous déposez un dossier auprès de l'autorité compétente. Le régulateur examine l'actionnariat, l'honorabilité et la compétence des dirigeants, le dispositif de contrôle interne, la politique de sécurité, la gestion des risques, le plan d'affaires, le dispositif de lutte contre le blanchiment et le financement du terrorisme quand il s'applique.

Sur les délais, soyons précis et honnêtes : la réglementation encadre le délai dont dispose l'autorité pour statuer sur un dossier complet. La durée réelle d'un projet d'agrément est dominée par la préparation du dossier et par les allers-retours avec le superviseur, pas par le délai d'instruction lui-même. Un ordre de grandeur raisonnable pour un premier dossier bien accompagné se compte en trimestres, et tout prestataire qui vous promet une date ferme se surestime. Consultez la source directement sur acpr.banque-france.fr.

#Notre recommandation

L'agrément en propre se justifie dans trois cas : l'open banking est votre produit et non une fonctionnalité ; votre volume rend la marge d'intermédiation supérieure au coût complet de la conformité ; ou vous avez besoin d'un contrôle sur la couverture et la qualité de connexion qu'aucun prestataire ne vous donnera.

Dans tous les autres cas — et c'est la majorité — le prestataire agréé est le bon choix, y compris pour des acteurs qui pourraient se le permettre. Nous avons vu des projets dépenser en dossier réglementaire de quoi financer deux ans de produit, pour une différence de marge unitaire qui ne se matérialisait qu'au-delà d'un volume jamais atteint. La bonne séquence est presque toujours : démarrer via un prestataire agréé, valider la traction réelle, et n'internaliser le statut que lorsque les chiffres l'imposent. Voir le comparatif Bridge vs Tink vs Powens et notre article Bridge, Tink, Powens : choisir son agrégateur.

#Les interfaces bancaires en pratique : normes, certificats, qualité de service

C'est la partie que les cahiers des charges décrivent en une ligne et qui consomme la moitié de l'effort.

#Trois familles de normes, aucune uniformité réelle

Le législateur a imposé l'accès, pas un format unique. En France, la majorité des établissements s'appuient sur la norme définie par le STET ; en Allemagne, en Espagne et dans plusieurs autres pays, sur la norme du Berlin Group ; au Royaume-Uni, sur le standard Open Banking britannique, hors champ de l'Union depuis le retrait. Et à l'intérieur d'une même norme, les implémentations divergent : champs optionnels, profondeur d'historique disponible, pagination, gestion des comptes joints, libellés d'opérations plus ou moins exploitables, comportement des redirections sur mobile.

C'est la raison économique n°1 de passer par un prestataire agréé. Le travail de normalisation de ces divergences n'est pas de l'ingénierie noble, mais c'est un travail sans fin et sans avantage concurrentiel.

#Les certificats eIDAS

Un prestataire tiers s'identifie auprès de la banque avec des certificats qualifiés délivrés par un prestataire de services de confiance : un certificat d'authentification de site web (QWAC) et un certificat de cachet électronique (QSealC), portant le rôle réglementaire (AISP, PISP, CBPII) et le numéro d'agrément. Deux conséquences opérationnelles : ces certificats expirent, et une expiration non anticipée coupe l'ensemble des connexions d'un coup ; et un changement de statut ou de dénomination impose leur réémission. Nous mettons systématiquement une alerte à quatre-vingt-dix jours et un runbook de rotation. Voir eIDAS.

#Qualité de service : ce que dit le texte et ce qu'on observe

Les normes techniques imposent aux banques une interface dédiée dont la disponibilité et les temps de réponse doivent être au moins équivalents à ceux de leur interface client, avec publication de statistiques trimestrielles et mise à disposition d'un environnement de test. Une interface de repli est prévue, sauf exemption accordée par le superviseur au vu de la qualité de l'interface dédiée.

En pratique, planifiez sur les hypothèses suivantes : des taux d'échec très différents d'un établissement à l'autre, des fenêtres de maintenance nocturnes non synchronisées, des redirections mobiles qui se comportent mal selon le navigateur et l'application bancaire installée, et des historiques d'opérations dont la profondeur varie. Nous instrumentons dès le premier jour un tableau de bord par établissement — taux de succès de connexion, taux de succès de rafraîchissement, latence, motifs d'échec normalisés. Sans cette métrologie, vous ne saurez pas distinguer un bug de votre code d'une dégradation côté banque, et votre support répondra à l'aveugle.

#Agrégation de comptes et initiation de paiement : les deux services en pratique

#Agrégation : le parcours de consentement est le produit

L'agrégation paraît simple : on connecte, on récupère, on affiche. Les difficultés sont ailleurs.

C'est l'écran qui décide du succès du projet. L'utilisateur quitte votre application, s'authentifie chez sa banque, valide une autorisation rédigée par la banque dans des termes qui ne sont pas les vôtres, et revient — s'il revient. Ce qui améliore réellement la conversion, dans l'ordre :

1. Expliquer avant de rediriger. Un écran intermédiaire qui indique ce qui va se passer, ce à quoi le client consent, ce que vous ne pourrez pas faire (initier un paiement à son insu, notamment) et comment révoquer. La transparence sur l'absence de capacité de débit lève l'objection principale.
2. Ne demander que les comptes nécessaires. Un parcours qui réclame l'accès à tous les comptes alors qu'un seul suffit perd des utilisateurs sans contrepartie, et il est en tension avec le principe de minimisation.
3. Traiter le retour, y compris raté. Redirection cassée, session expirée, application bancaire absente, authentification abandonnée : chaque cas mérite un message spécifique et une reprise, pas une erreur générique.
4. Préparer la ré-authentification périodique. Notification anticipée, reprise en un geste, tolérance à l'interruption de flux. C'est là que se joue la rétention à six mois.

#Agrégation : après la connexion, la vraie difficulté

Une opération bancaire brute est presque inutilisable en l'état. Le libellé est tronqué, encodé selon la banque, mêle raison sociale, identifiant de terminal, ville et date. Rendre cette donnée exploitable suppose une chaîne de traitement : normalisation des libellés, déduplication entre opérations en attente et opérations comptabilisées, rapprochement des virements internes entre deux comptes agrégés du même utilisateur, catégorisation, détection de récurrences.

La déduplication et le rapprochement interne sont les deux sources d'erreur les plus fréquentes, et ce sont celles que l'utilisateur détecte immédiatement : un virement de son compte courant vers son livret compté deux fois, en dépense puis en revenu, détruit la confiance dans l'application entière. Nous traitons ces règles comme du code métier critique, testé unitairement sur des jeux de données réels anonymisés.

Cas d'usage matures : gestion de trésorerie multi-banques pour les entreprises, préparation de dossier pour un courtier en crédit, vérification de revenus et de coordonnées bancaires à l'entrée d'un parcours, pré-remplissage comptable. Voir agrégateur de comptes, APIs open banking et KYC/AML automatisé.

#Initiation de paiement : l'économie réelle et l'effet du virement instantané

L'argument commercial de l'initiation de paiement est le coût : un virement initié coûte structurellement moins cher qu'une transaction carte sur un montant élevé, et il n'y a pas de rétrofacturation au sens des schémas cartes. L'argument est réel — mais l'analyse complète est plus nuancée.

Ce que vous gagnez : un coût par transaction largement décorrélé du montant, l'absence de rétrofacturation, un crédit rapide sur le compte du bénéficiaire, et un parcours sans saisie de numéro de carte.

Ce que vous perdez, et qu'il faut porter côté produit : aucun mécanisme d'autorisation puis capture différée, ce qui complique les modèles de réservation ou de pré-autorisation ; aucun remboursement natif — le remboursement est un nouveau virement, à réémettre côté commerçant ; aucune facilité de paiement intégrée ; et un parcours qui reste plus long qu'un paiement carte enregistré en un clic.

Notre position : l'initiation de paiement est excellente sur les montants élevés, les paiements récurrents entre professionnels, les rechargements de compte et les paiements de factures. Elle est rarement le bon choix comme moyen de paiement unique d'un panier moyen faible en commerce grand public. Un projet qui vise à remplacer intégralement la carte se heurte à un mur d'habitude.

Le contexte a néanmoins bougé avec le règlement (UE) 2024/886 sur les virements instantanés, adopté en mars 2024. Il impose aux prestataires de services de paiement de la zone euro de recevoir des virements instantanés en euros, puis d'en émettre, selon un calendrier échelonné à partir de janvier 2025, avec une tarification qui ne peut être supérieure à celle des virements ordinaires. Il introduit également une obligation de vérification de la concordance entre le nom du bénéficiaire et l'IBAN, qui doit être proposée avant validation.

Deux conséquences directes pour un produit d'initiation de paiement. D'abord, la généralisation de l'instantané supprime l'objection historique du délai de crédit, ce qui rend le virement crédible en encaissement commerçant. Ensuite, la vérification du bénéficiaire modifie le parcours : votre interface doit savoir présenter un résultat de correspondance approximative sans effrayer l'utilisateur, ni le former à cliquer « continuer » par réflexe. Voir aussi le comparatif Stripe vs Adyen vs Mollie pour l'articulation avec l'orchestration de paiement et notre article sur l'orchestration de paiement B2B.

#Le paquet DSP3/PSR et FIDA : statut réel et ce qu'il faut anticiper

Point de rigueur, parce que ce sujet est le plus mal traité du marché.

En juin 2023, la Commission européenne a présenté un paquet législatif comprenant une proposition de directive sur les services de paiement (couramment appelée DSP3) et une proposition de règlement sur les services de paiement (PSR). L'architecture proposée est significative : les règles d'exercice les plus opérationnelles basculeraient dans un règlement d'application directe, tandis que la directive traiterait de l'agrément et de la surveillance des établissements. Si cette architecture est confirmée, elle réduit mécaniquement les divergences nationales de transposition — un vrai bénéfice pour un acteur multi-pays.

Ce paquet est en cours de négociation entre les colégislateurs. Le texte final peut différer des propositions, et aucune date d'application ne doit être considérée comme acquise. Nous ne construisons aucun plan de charge sur une échéance DSP3, et nous recommandons de ne pas inscrire de date dans un contrat.

Parmi les orientations discutées, et sous cette réserve expresse, plusieurs mériteraient d'être suivies de près par une équipe produit :

• un renforcement de la lutte contre la fraude par usurpation d'identité de la banque, avec un possible élargissement des cas de remboursement du client ;
• la généralisation de la vérification de concordance nom/IBAN au-delà du seul virement instantané ;
• une révision du régime de l'interface de repli, dans le sens d'exigences accrues sur la qualité de l'interface dédiée ;
• l'introduction de tableaux de bord de permissions permettant au client de visualiser et de révoquer en un point unique les accès accordés à des tiers ;
• une clarification de l'accès des établissements non bancaires aux systèmes de paiement.

La bonne stratégie d'anticipation n'est pas d'implémenter une proposition. C'est de construire une architecture qui absorbera ces évolutions sans réécriture : consentements modélisés comme des objets de premier plan avec durée, périmètre et journal de révocation ; couche d'abstraction entre votre domaine métier et les interfaces bancaires ; capacité à ajouter une vérification de bénéficiaire dans le parcours sans refondre le tunnel. Voir notre page DSP3 / PSR — transposition, le glossaire DSP3 et notre analyse DSP3 vs DSP2 : ce qui change.

#FIDA et l'open finance : intérêt réel, calendrier incertain

Le même jour que le paquet paiements, la Commission a présenté une proposition de règlement sur l'accès aux données financières, connue sous l'acronyme FIDA. L'idée : étendre le principe d'accès au-delà des comptes de paiement — épargne, investissement, crédit, assurance — au sein de dispositifs de partage de données organisés contractuellement entre détenteurs et utilisateurs de données, avec un nouveau statut de prestataire de services d'information financière.

La différence de philosophie avec la DSP2 est importante et souvent passée sous silence : là où la DSP2 impose un accès gratuit, FIDA envisage des dispositifs de partage rémunérés. Si cette orientation est confirmée, l'économie unitaire de l'open finance ne ressemblera pas à celle de l'open banking, et les modèles d'affaires bâtis sur la gratuité de l'accès ne se transposeront pas mécaniquement.

Le sort de cette proposition a fait l'objet d'arbitrages politiques au niveau européen, portant sur son maintien, son périmètre et son calendrier. Nous ne considérons ni son adoption ni son contenu comme acquis, et nous déconseillons formellement de bâtir un plan d'affaires sur son entrée en application. En revanche, l'exercice de préparation a de la valeur en soi : identifier quelles données non couvertes par la DSP2 créeraient de la valeur pour vos clients, et par quelles voies contractuelles vous pourriez déjà y accéder aujourd'hui. Beaucoup de cas d'usage attribués à FIDA sont réalisables immédiatement par accord bilatéral. Voir FIDA — open finance, notre audit FIDA, le guide FIDA pour les banques et le glossaire FIDA.

#RGPD, DORA, supervision : le triangle de conformité

Trois régimes se superposent sur un même projet. Les traiter séparément produit des doublons ; les traiter ensemble économise du temps.

#RGPD : les trois points qui font trébucher

Le consentement DSP2 n'est pas le consentement RGPD. La directive exige un consentement explicite pour accéder aux données de compte ; ce consentement contractuel ne présume pas de la base légale de vos traitements ultérieurs. Enrichir, scorer, entraîner un modèle ou réutiliser la donnée à d'autres fins relèvent d'analyses distinctes. Les lignes directrices du Comité européen de la protection des données consacrées à l'articulation entre DSP2 et RGPD sont la référence à lire avant de rédiger votre registre.

Les données des tiers. Un relevé contient les opérations avec des personnes qui n'ont jamais rien accepté : le bénéficiaire d'un virement, l'émetteur d'un paiement. Ces personnes sont des personnes concernées. La minimisation et la limitation des finalités s'appliquent à leurs données, alors que vous ne pouvez pas les informer individuellement.

Les données sensibles par déduction. Un libellé d'opération peut révéler l'appartenance syndicale, une conviction religieuse, un état de santé ou une orientation sexuelle. Vous ne les collectez pas intentionnellement, mais elles sont là. Nous traitons ce risque par une politique de conservation courte, un filtrage des libellés dans les traitements analytiques, et l'exclusion explicite de ces signaux de toute logique de décision. Voir DPIA et RGPD.

#DORA : votre prestataire est un tiers TIC

Le règlement (UE) 2022/2554, applicable depuis janvier 2025, s'impose à un large ensemble d'entités financières. Pour un projet open banking, quatre obligations sont directement structurantes : la tenue d'un registre d'information des accords contractuels portant sur les services TIC, avec un niveau de détail élevé ; des clauses contractuelles obligatoires avec les prestataires, notamment sur l'accès, l'audit, la résiliation et la stratégie de sortie ; l'analyse du risque de concentration, dont la question de la dépendance à un prestataire d'agrégation unique ; et le dispositif de notification des incidents majeurs liés aux TIC.

Conséquence pratique souvent découverte tard : un contrat standard signé en ligne avec un prestataire peut ne pas contenir les clauses requises. Il faut le vérifier avant l'intégration, pas au moment de l'inspection. Voir notre audit DORA, la checklist DORA/NIS2 et le guide DORA pour les fintechs.

#Supervision et lutte anti-blanchiment

Si vous exercez sous statut propre, s'ajoutent le contrôle interne, la déclaration des incidents opérationnels et de sécurité majeurs, les statistiques de fraude, et — dès que vous manipulez des fonds ou entrez en relation d'affaires — le dispositif de lutte contre le blanchiment et le financement du terrorisme. Voir KYC / AML et notre service conformité.

#Architecture, sécurité et exploitation d'une intégration

Ce que nous mettons en place, indépendamment du prestataire retenu.

Une couche d'anticorruption. Votre domaine métier ne manipule jamais le format d'un fournisseur. Un modèle interne — compte, opération, consentement, connexion — est alimenté par des adaptateurs. C'est ce qui permet de changer de prestataire, d'en ajouter un second pour la couverture d'un pays, ou d'absorber une évolution de contrat d'API sans toucher au métier. Sur un projet open banking, ce n'est pas de la sur-ingénierie : la probabilité que le format change est de un.

Le consentement comme entité de premier plan. Identifiant, portée, date d'octroi, date d'expiration, statut, journal complet des événements. Vous devez pouvoir répondre en une requête à « de quoi disposions-nous, pour ce client, à cette date ». C'est ce que demandent un contrôle, un litige et une demande d'exercice de droits.

Une gestion des secrets et des certificats industrialisée. Coffre-fort de secrets, rotation, alertes d'expiration à quatre-vingt-dix jours, procédure de renouvellement documentée et testée.

Un stockage cloisonné et une conservation courte. Chiffrement au repos, séparation stricte des environnements, aucune donnée de production dans les jeux de test, purge automatique à l'échéance du consentement. Pour les acteurs soumis à des exigences de localisation, notre approche est décrite sur la page souveraineté numérique.

Une observabilité orientée établissement. Tableau de bord par banque, motifs d'échec normalisés, alerte sur dérive du taux de succès, et corrélation avec les fenêtres de maintenance publiées. C'est l'outil qui transforme un support subi en support piloté.

Côté IA, deux usages sont matures et ne nécessitent aucune prise de risque : la catégorisation et la normalisation des libellés d'opérations, où un modèle de petite taille correctement instruit fait mieux qu'une bibliothèque de règles et se maintient mieux ; et l'assistance interne aux équipes conformité et support via une recherche documentaire sur les procédures. Nous les déployons avec Mistral et Qdrant sur infrastructure européenne. En revanche, toute logique de décision affectant un client — octroi, refus, tarification — doit rester explicable et supervisée, et relève d'une analyse au titre du règlement européen sur l'intelligence artificielle. Voir audit AI Act et agent IA bancaire.

#Notre méthode de delivery

Étape 1 — Cadrage réglementaire et produit. Qualification exacte du service rendu (lecture, écriture, détention de fonds), détermination du statut requis, arbitrage prestataire agréé contre agrément propre, périmètre géographique et établissements cibles, modèle de données, esquisse du parcours de consentement. Livrable : note de qualification, architecture cible, trajectoire chiffrée par lot. C'est l'étape que les projets sautent, et celle dont l'absence coûte le plus cher.

Étape 2 — Contractualisation et environnement de test. Sélection du prestataire sur la couverture réelle des établissements qui comptent pour vous — pas sur un pourcentage global de couverture, qui ne veut rien dire si vos clients sont tous dans une banque mal couverte. Revue des clauses au regard des exigences DORA. Tests en environnement de bac à sable, puis sur un échantillon d'établissements réels.

Étape 3 — Construction. Couche d'anticorruption, modèle de consentement, parcours utilisateur, traitement des opérations, gestion des erreurs et des reprises, tableau de bord d'exploitation. Nous construisons le front en Next.js et le back selon votre existant. Tests unitaires systématiques sur les règles de déduplication, de rapprochement et de catégorisation : ce sont elles qui produisent les incidents visibles.

Étape 4 — Recette réglementaire et mise en service. Tests de bout en bout sur les établissements cibles, revue RGPD et analyse d'impact si nécessaire, alimentation du registre DORA, procédures d'incident, formation du support aux motifs d'échec bancaires. Mise en service progressive avec suivi rapproché par établissement.

Étape 5 — Exploitation et veille. Surveillance des taux de succès, rotation des certificats, ajout d'établissements, adaptation aux évolutions d'interfaces, et veille réglementaire sur l'avancement du paquet en négociation. Sur ce marché, une intégration qu'on n'entretient pas se dégrade toute seule.

#Pourquoi Nehos sur un projet open banking

Nous qualifions avant de coder. La première livrable d'un projet open banking n'est pas une maquette, c'est une note de qualification réglementaire. Elle détermine le statut, donc le budget, donc le calendrier. Un projet qui découvre son statut après six semaines de développement a perdu six semaines.

Nous traitons le droit avec prudence. La DSP2 est applicable ; le paquet DSP3/PSR et FIDA sont en négociation. Nous ne présentons jamais une proposition comme une obligation, et nous n'inscrivons pas de date d'application non acquise dans un plan de charge. Un prestataire qui vous annonce une échéance ferme sur DSP3 vous vend une opinion.

Nous savons dire de ne pas demander d'agrément. Dans la plupart des projets, le prestataire agréé est le bon choix, et l'agrément en propre une dépense prématurée. Nous le disons au cadrage, quand cela peut encore changer la trajectoire.

Nous traitons la donnée bancaire comme du code métier critique. Déduplication, rapprochement interne, catégorisation, normalisation des libellés : testés unitairement, versionnés, mesurés. C'est là que se joue la confiance de l'utilisateur, bien plus que dans le design de l'écran.

Nous couvrons la conformité connexe. RGPD et données de tiers, registre et clauses DORA, articulation avec la modernisation d'un core banking existant, exigences de localisation. Voir le secteur Banque, Assurance & Finance et notre service conformité.

#FAQ — Open banking, DSP2 et DSP3

Faut-il un agrément pour agréger des comptes bancaires ? Oui, sauf à vous appuyer sur le statut d'un prestataire déjà enregistré. L'activité d'information sur les comptes relève d'un enregistrement auprès de l'autorité compétente, sans exigence de capital initial mais avec une assurance de responsabilité civile professionnelle obligatoire et des exigences de gouvernance et de sécurité. En passant par un prestataire agréé, c'est lui qui porte le statut : vous êtes utilisateur de son agrément, ce qui est parfaitement régulier et représente la majorité des intégrations en production.

Quelle est la différence entre AISP et PISP ? L'AISP lit les données de comptes de paiement et ne déplace pas d'argent : régime d'enregistrement, pas de capital initial requis. Le PISP déclenche un virement sur instruction du client sans jamais détenir les fonds : agrément d'établissement de paiement, capital initial minimum fixé par la directive — cinquante mille euros pour un établissement fournissant uniquement l'initiation de paiement. Deux dossiers, deux niveaux d'exigence, deux budgets.

DSP3 est-elle applicable ? À quelle date ? Non. Le paquet présenté en juin 2023, comprenant une proposition de directive et une proposition de règlement sur les services de paiement, est en cours de négociation entre les colégislateurs européens. Le contenu final peut évoluer et aucune date d'application n'est acquise. Méfiez-vous de toute communication annonçant une échéance ferme. La DSP2, elle, est bien applicable et reste le cadre en vigueur.

Bridge, Tink ou Powens : lequel choisir ? La question n'a pas de réponse générale. Le seul critère qui compte est la couverture réelle et la qualité de connexion sur les établissements où sont vos clients, mesurées sur un échantillon représentatif. Un taux de couverture global élevé ne vous sert à rien si votre cœur de cible est dans une banque mal supportée. Comparez ensuite la profondeur d'historique, la conformité contractuelle aux exigences DORA, la présence dans vos pays cibles et la qualité du support technique. Voir notre comparatif détaillé.

L'initiation de paiement peut-elle remplacer la carte bancaire ? Pas intégralement, et ce n'est pas son terrain. Elle est très pertinente sur les montants élevés, les paiements entre professionnels, les rechargements de compte et le règlement de factures, où l'économie de commission est significative. Elle est plus faible sur le commerce grand public à panier moyen faible, faute d'autorisation différée, de remboursement natif et d'un parcours aussi court qu'une carte enregistrée. La généralisation du virement instantané en euros, portée par le règlement de mars 2024, améliore nettement sa crédibilité en encaissement.

Combien de temps pour mettre une intégration en production ? Via un prestataire agréé, l'ordre de grandeur va de quelques semaines pour un cas de lecture simple à quelques mois pour un produit d'agrégation complet avec parcours de consentement soigné, traitement des opérations et tableau de bord d'exploitation. Sous statut propre, le facteur limitant n'est plus le développement mais le dossier réglementaire, dont la préparation domine le calendrier. Nous chiffrons lot par lot après le cadrage.

Que se passe-t-il quand une banque change son interface ? Vos connexions se dégradent, en général sans préavis exploitable. Si vous passez par un prestataire agréé, c'est lui qui absorbe le changement — c'est précisément ce que vous achetez. Sous statut propre, c'est votre équipe. Dans les deux cas, une observabilité par établissement est indispensable pour détecter la dégradation avant vos utilisateurs, et un plan de communication support doit exister.

Combien de temps peut-on conserver les données de comptes agrégées ? Aussi longtemps que la finalité déclarée le justifie, et pas au-delà. En pratique, l'expiration du consentement borne l'accès, et nous recommandons d'aligner la conservation sur cette échéance en dehors des obligations légales de conservation qui vous seraient propres. Attention aux données de tiers présentes dans les relevés et aux libellés susceptibles de révéler des données sensibles : ils justifient une politique de conservation courte et un filtrage dans les traitements analytiques.