Plateforme Open Banking DSP2
Cas d'usage Open Banking et API Banking DSP2 pour banques régionales et néobanques : agrégation de comptes, initiation de paiement, marketplace fintech.
Nos clients types
Conformité
Écarts DSP2 relevés à l'audit, classés par gravité et traités par ordre de risque ACPR
Disponibilité
Taux de disponibilité de l'interface de production, mesuré en continu face au niveau exigé
Activation
Part des clients qui activent l'agrégation, suivie dès le pilote
#Exemple de situation
Ce qui suit est un exemple de situation pour illustrer la démarche, pas le récit d'un projet livré.
#Contexte
Une banque régionale mutualiste a lancé une application mobile qui peine à s'imposer. Une partie de ses clients connecte déjà ses comptes à des agrégateurs tiers, et ses précédents chantiers DSP2 n'ont pas abouti.
#Défi
Se mettre en conformité DSP2 (disponibilité de l'interface, mécanisme de repli), proposer un service d'agrégation propre et ouvrir ses APIs à des partenaires fintech pour développer de nouveaux revenus.
#Approche
Un audit de conformité avec plan de remédiation, une API Gateway et un serveur d'autorisation OAuth2/PKCE, un portail développeurs avec sandbox, un pilote sur quelques établissements, une décision go formelle puis une industrialisation par étapes.
#Ce que nous mesurons
Les indicateurs de réussite sont fixés avec vous avant le lancement et relevés sur l'existant. On les suit pendant le pilote, puis on décide ensemble d'aller plus loin ou non, sur des mesures et non sur des promesses.
#Pourquoi Nehos pour plateforme Open Banking DSP2
Nehos Groupe n'est pas un intégrateur généraliste qui adapte une solution standard à votre contexte. On conçoit des architectures sur mesure, calibrées sur vos contraintes métier, réglementaires et techniques. Chaque projet démarre par un audit de faisabilité qui pose les limites avant les promesses — si le ROI ne tient pas, on le dit avant de signer quoi que ce soit.
Notre méthode ROI-First impose un cadrage chiffré dès la phase d'audit : coût actuel documenté, gains projetés avec hypothèses conservatrices, critères de go/no-go factuels. En production, on mesure les résultats réels et on les compare aux projections — transparence totale, y compris quand les chiffres sont en dessous des attentes.
Nos expertises connexes : Méthode Stack Souveraine Nehos™, cas banque régionale open banking complet, glossaire DSP2/DSP3.
Stack technique souverain : hébergement OVHcloud (datacenters France), modèles IA open source (Mistral) quand la performance le permet, code propriétaire intégralement détenu par le client à la livraison. Pas de vendor lock-in, pas de dépendance à un fournisseur cloud américain pour vos données critiques.
#Pour aller plus loin
Cas d'usage connexes :
Questions & réponses
Questions fréquentes sur la plateforme Open Banking DSP2 et l'API Banking
Les deux statuts correspondent à des droits d'accès distincts, soumis chacun à un agrément ACPR séparé. Un AISP (Account Information Service Provider) accède en lecture aux données de comptes de paiement du client, avec son consentement explicite. Il peut lire les soldes, les transactions, les informations de compte — mais ne peut pas déclencher de mouvement de fonds. Usage typique : agrégateur de comptes, outil de gestion de budget, analyse de solvabilité en crédit. Un PISP (Payment Initiation Service Provider) déclenche des virements depuis le compte du client, également avec consentement explicite. Il peut initier un paiement vers un marchand, un bénéficiaire ou lui-même — mais ne peut pas lire les données de compte (sauf les informations strictement nécessaires à la confirmation de paiement). Un CBPII (Card-Based Payment Instrument Issuer) vérifie la disponibilité des fonds sans les bloquer. Une néobanque ou une banque challenger peut cumuler les trois statuts. Les obligations techniques et de sécurité sont différentes : le PISP exige une authentification forte SCA systématique (sauf exemptions RTS), le AISP n'en exige qu'une tous les 180 jours. Voir glossaire DSP2/DSP3 Nehos pour les définitions complètes.
Oui, c'est le cas de la majorité des banques régionales françaises. La solution n'est pas de remplacer le core banking mais de construire une couche d'abstraction API devant lui. Architecture recommandée : API Gateway en façade (Kong Enterprise ou AWS API Gateway), middleware d'intégration avec le core banking (MuleSoft, Tibco, ou développement sur mesure selon l'exposition disponible) et couche OAuth2/PKCE gérée indépendamment du core. Cette architecture découple la conformité DSP2 de la modernisation du core banking : deux chantiers menés sur des rythmes différents. La transformation des services SOAP, fichiers plats ou appels COBOL vers REST/JSON est réalisable mais pèse lourd dans le budget d'intégration ; nous l'estimons lors de l'audit.
Massivement — et c'est précisément l'objectif de la DSP2. L'ancien modèle de screen scraping consistait à confier ses identifiants bancaires (login + mot de passe) à un tiers agrégateur, qui se connectait en se faisant passer pour le client. Problèmes de ce modèle : (1) le client viole ses CGU bancaires en communiquant ses identifiants à un tiers, (2) l'agrégateur stocke des credentials qui peuvent être compromis, (3) la banque ne peut pas distinguer un accès légitime d'une attaque par rejeu. OAuth2 avec PKCE résout ces problèmes : le client ne communique jamais ses identifiants à l'agrégateur — il s'authentifie directement auprès de sa banque via un flux de redirection, qui émet un access token de courte durée (5-15 minutes en production) limité aux scopes consentis. FAPI 1.0 (Financial-grade API Security Profile) ajoute des contraintes supplémentaires : client authentication via mTLS ou Private Key JWT, state et nonce obligatoires, PAR (Pushed Authorization Requests) recommandé. Une fois correctement implémenté, ce modèle est considéré comme le gold standard de la sécurité des APIs financières. Voir glossaire OAuth2/PKCE Nehos.
Plusieurs modèles existent. Modèle lead : la banque transmet un lead qualifié (client qui a manifesté un intérêt via son contexte transactionnel) à la fintech partenaire, qui rémunère l'apport. Modèle commission : la banque perçoit une part des revenus générés par le partenaire sur les clients qu'elle lui amène. Dans tous les cas, un contrat d'API formalise les conditions d'accès aux données, les niveaux de service, les obligations RGPD (sous-traitance au sens de l'article 28) et le mécanisme de reporting. La banque doit vérifier que chaque partenaire fintech est bien agréé par l'ACPR (ou une autorité équivalente de l'EEE) pour le statut qu'il exerce : elle est co-responsable si elle facilite l'accès à des données pour un acteur non agréé.
L'open banking crée une intersection entre deux cadres réglementaires — DSP2 et RGPD — qui se renforcent mutuellement. DSP2 impose que le consentement à l'accès aux données de compte soit explicite, spécifique (périmètre délimité : quels comptes, quelles données, pour quelle durée), et révocable à tout moment sans pénalité. RGPD impose par-dessus les obligations de base (information, portabilité, droit à l'effacement) et exige une base légale distincte pour chaque finalité de traitement — le consentement de l'utilisateur final est généralement la base légale retenue pour l'AISP. En pratique, cela se traduit par : (1) écran de consentement granulaire au scope (transactions:read séparé de accounts:read, séparé de balances:read), (2) durée de validité explicite avec renouvellement actif (maximum 90 jours sans réauthentification pour la plupart des scopes), (3) tableau de bord de gestion des consentements actifs accessible depuis l'app mobile (exigence DSP3 anticipée), (4) procédure de révocation temps réel propagée à tous les composants en moins de 30 secondes, (5) audit log immuable de chaque accès aux données (qui a accédé, quand, quel scope, quelle donnée). Un DPO doit valider l'architecture de consentement avant le go-live — nous recommandons un DPO externe spécialisé fintech sur ce type de projet.
Non — à condition d'avoir architecturé la plateforme DSP2 avec les bons principes. La DSP3 (directive) et le PSR (règlement) adoptés en avril 2024 par le Parlement européen étendent le périmètre de l'open banking à l'open finance : épargne, assurance-vie, crédit immobilier, investissements. Les actes délégués de la Commission sont attendus pour 2026-2027, avec une date d'application estimée 2027-2028. Les fondations techniques — API Gateway, OAuth2/PKCE + FAPI 1.0, portail développeurs, gestion de consentement granulaire, audit logs — sont directement réutilisables pour DSP3. Ce qui devra évoluer : (1) les scopes de consentement (extension aux nouveaux périmètres), (2) les connecteurs backend (exposition des données d'assurance-vie et d'épargne depuis les SI correspondants), (3) le framework de gouvernance des données (nouvelles obligations d'information et de portabilité). Une plateforme DSP2 bien architecturée aujourd'hui représente une avance de 18-24 mois sur DSP3. Une plateforme DSP2 construite en mode minimal réglementaire (simple remédiation ACPR sans vision marketplace) sera à refondre partiellement. C'est pourquoi nous défendons systématiquement l'approche plateforme évolutive dès le démarrage.
Le budget dépend du périmètre (AISP seul, AISP et PISP, marketplace), du nombre d'établissements à intégrer et de l'état du core banking. Nous le chiffrons sur devis, en 48 h après un premier échange, avec un audit de conformité en point d'entrée. Selon votre profil, certains financements publics ou crédits d'impôt peuvent s'appliquer à une partie des travaux : cela se vérifie au cas par cas avec votre conseil.
Oui — c'est un périmètre d'intervention courant pour les établissements qui ont déjà une infrastructure DSP2 existante mais non conforme ou sous-performante. Attention : une remédiation seule sans vision plateforme laisse intact le problème de désintermédiation et la perte d'opportunité marketplace. On l'accepte quand l'urgence réglementaire prime, mais on remet systématiquement le business case plateforme sur la table à 6-12 mois.