Agregateur Open Banking : donnez à vos utilisateurs une vue complete de leurs finances
DSP2 a ouvert les données bancaires, DSP3 va plus loin avec l'Open Finance. Connecter les APIs PSD2, catégoriser les transactions par IA et construire un PFM utilisable sans se tromper sur la conformité SCA est un chantier technique et réglementaire exigeant. Nehos le conçoit et le réalise de bout en bout.
Nos clients types
L'Open Banking européen, rendu possible par la DSP2 (Directive des Services de Paiement 2 — Directive 2015/2366/UE, transposée en France par l'ordonnance du 9 août 2017), a cree un écosystème florissant de fintechs d'agrégation et de PFM. Mais la réalité technique de la connexion aux APIs bancaires PSD2 est bien plus complexe que ne le laisse entendre le texte réglementaire. Le premier obstacle est l'hétérogénéité des APIs. Malgré l'existence du standard Berlin Group (NextGenPSD2 — la specification technique de référence pour les APIs PSD2 en Europe), chaque banque a sa propre implementation. Certaines exposent des APIs REST conformes au standard, avec une documentation de qualité et des SLA garantis. La France compte plus de 200 établissements bancaires — chacun avec son implémentation PSD2 spécifique. Le second obstacle est la SCA (Authentification Forte du Client). Les RTS (Regulatory Technical Standards) de la DSP2 imposent une reauthentification forte tous les 90 jours maximum pour les connexions d'agrégation. Dans la pratique, certaines banques rendent cette reauthentification difficile (CAPTCHAs, interfaces non optimisées pour les flux automatises, exigences de périphériques physiques). Le troisième obstacle est la qualité des données. Les transactions bancaires exportées via API PSD2 ont un format libre dans le champ libelle — '1234 VIR SEPA AMAZON.FR SARL AMAZON EU', 'CB GDES SURFACES 09/05', '0000024523 PRLV SFAM' — qui necessite un modèle NLP robuste pour être categorise correctement en 'Amazon', 'Grande surface alimentation', 'Abonnement téléphonie'. La precision de la catégorisation est le facteur numéro 1 de satisfaction dans les applications PFM : un utilisateur dont les transactions sont mal categories perd confiance dans l'outil et se désabonne. Le quatrième obstacle est réglementaire. Un AISP (Account Information Service Provider) doit être agréé par l'ACPR ou opérer sous la licence d'un AISP existant. Le modèle alternatif — opérer sous la licence d'un AISP existant (Powens, Budget Insight) comme 'utilisateur d'API' — est plus rapide mais genere une dépendance contractuelle et des coûts de revenus partages. Enfin, la DSP3 — en cours de finalisation par la Commission européenne en 2025 — étend le périmètre bien au-delà des comptes de paiement : épargne, investissements, credits, assurances. Cette evolution vers l'Open Finance européenne cree une opportunité massive pour les agregateurs qui préparent maintenant une architecture extensible — et un risque pour ceux qui ont construit des intégrations point-a-point non évolutives.
La solution Nehos pour un agregateur Open Banking s'appuie sur quatre couches technologiques assemblées de manière modulaire : la couche de connexion PSD2 via un fournisseur specialise, la couche de normalisation et stockage des données bancaires, le moteur de catégorisation par IA, et l'interface PFM utilisateur. Son statut AISP et AISP agent en France eliminé le besoin pour le client d'obtenir son propre agrément ACPR dans un premier temps. Tink (Visa) et Salt Edge sont évalués et recommandes selon les besoins de couverture européenne et les préférences de licence. La couche de normalisation prend en entrée les transactions brutes des banques — libelles hétérogènes, formats de dates varies, devises différentes — et produit un format canonique stocke en Postgres (comptes, soldes, transactions) et TimescaleDB (historiques de transactions sur 36 mois pour les analyses de tendances). Les données bancaires sont chiffrées au repos (AES-256) avec des clés de chiffrement par utilisateur, ce qui garantit qu'un accès non autorise a la base de données ne produit que du texte chiffré illisible. Pour les transactions ambiguës, un mécanisme de feedback utilisateur (correction manuelle de la catégorie) alimente le retraining continu du modèle. L'interface PFM est développée en React Native (iOS + Android) ou Flutter selon les préférences client, avec un backend BFF (Backend For Frontend) en Node.js. La conformité DSP2 et RGPD est gérée a plusieurs niveaux : consentements granulaires collectes par compte et par type de données (solde uniquement / transactions / informations de compte), avec timestamp et historique des consentements conserve 5 ans. Le rafraîchissement des tokens est gere automatiquement avec notification utilisateur pour les reauthentifications SCA requises. La conformité RGPD inclut le droit a la portabilité (export des données en JSON ou CSV) et le droit a l'effacement (suppression complete des données bancaires sur demande, en moins de 24h). Pour la DSP3, nous designons les architectures avec des couches d'abstraction qui permettent d'étendre les connexions aux nouveaux domaines Open Finance (assurances, credits, investissements) sans refactoring majeur du core. Les clients qui démarrent aujourd'hui avec une architecture DSP3-ready prennent une avance de 18 à 24 mois sur leurs concurrents qui devront refondre leurs intégrations a l'entrée en vigueur de la directive.
Couverture
Nombre de banques réellement connectées au lancement, relevé auprès du fournisseur PSD2 retenu
Précision
Part des transactions bien catégorisées, mesurée sur un échantillon relu à la main avant la mise en production
Usage
Utilisateurs actifs et rétention, suivis dès la bêta pour décider des priorités suivantes
#Le problème : pourquoi construire un agrégateur Open Banking est un chantier sous-estimé
L'Open Banking européen, rendu possible par la DSP2 (Directive 2015/2366/UE, transposée en France en 2017), a créé un écosystème de fintechs d'agrégation et de PFM. Mais la réalité technique de la connexion aux APIs bancaires PSD2 est bien plus complexe que le texte réglementaire ne le laisse entendre.
Premier obstacle : l'hétérogénéité des APIs. Malgré le standard Berlin Group (NextGenPSD2), chaque banque a sa propre implémentation. Certaines exposent des APIs REST conformes avec documentation de qualité et SLA garantis. La France compte plus de 200 établissements bancaires — chacun avec son implémentation PSD2 spécifique.
Deuxième obstacle : la SCA (Authentification Forte). Les RTS imposent une réauthentification forte tous les 90 jours maximum. Troisième obstacle : la qualité des données. Les libellés de transactions ('1234 VIR SEPA AMAZON.FR SARL', 'CB GDES SURFACES 09/05') nécessitent un modèle NLP robuste pour être catégorisés.
La DSP3 — en cours de finalisation — étend le périmètre à l'Open Finance (assurance, investissement, crédit). Les agrégateurs qui se préparent maintenant prennent une avance de 18 à 24 mois.
#Notre approche en 4 phases
#Phase 1 : Choix du fournisseur de connexions PSD2 et cadrage réglementaire (mois 1)
On compare la couverture des banques françaises et européennes, la qualité des données, les SLA et la conformité DSP2. Cadrage réglementaire : statut AISP requis ou opération sous licence d'un AISP tiers — le modèle le plus rapide pour une fintech en phase de lancement. Voir notre comparateur fournisseurs PSD2 Powens Tink Salt Edge.
#Phase 2 : Architecture backend et intégrations PSD2 (mois 2-3)
Design de l'architecture microservices fintech : API gateway, service d'agrégation (connexion Powens/Tink), service de normalisation et stockage des transactions, service de catégorisation IA. Base de données : Postgres pour les comptes et soldes, TimescaleDB pour les historiques de transactions sur 36 mois. Chiffrement end-to-end des données bancaires AES-256 avec clés par utilisateur.
#Phase 3 : Module PFM et catégorisation par IA (mois 3-6)
Développement du module PFM : budget par catégorie, alertes de dépassement, projections de solde, détection d'abonnements récurrents. Interface mobile React Native ou Flutter.
#Phase 4 : Conformité DSP2/DSP3, RGPD et go-live (mois 6-8)
Audit sécurité et conformité RGPD Open Banking : gestion des consentements SCA, rafraîchissement des tokens selon les RTS. Préparation DSP3 avec couches d'abstraction pour étendre les connexions aux nouveaux domaines Open Finance sans refactoring majeur. Conformité RGPD : minimisation des données, droit à la portabilité, droit à l'effacement en moins de 24h. Go-live et monitoring.
#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 fintech grand public s'adresse à des actifs qui veulent reprendre le contrôle de leurs finances. Son produit : un agrégateur multi-banques avec gestion budgétaire, détection des abonnements et projections de solde. L'équipe est petite et le budget technologique contraint.
#Défi
Couvrir un maximum de banques dès le lancement, catégoriser les transactions assez précisément pour que l'utilisateur s'y retrouve, offrir une interface mobile fluide et rester conforme DSP2 et RGPD, sans demander d'agrément AISP propre, trop long et trop coûteux à ce stade.
#Approche
S'appuyer sur un fournisseur de connexions PSD2 agréé pour la couverture bancaire, bâtir un backend sur une base de données adaptée aux séries temporelles, entraîner un modèle de catégorisation sur des transactions françaises, développer une application mobile iOS et Android et mettre en place des consentements granulaires et le chiffrement des données par utilisateur.
#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 l'agrégateur Open Banking
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.
Notre méthode ROI-First impose un cadrage chiffré dès la phase d'audit : coût de développement réaliste, time-to-market estimé, coûts d'exploitation projetés. On ne vous vendra pas un agrément AISP propre si le modèle agent suffit pour votre phase de lancement. Nos expertises connexes : guide DSP2 DSP3 Open Banking France, solutions digitales banque et fintech Open Banking, crédit scoring IA Open Banking.
Stack technique souverain : hébergement OVHcloud ou AWS selon les contraintes, modèles NLP open source (BERT) fine-tunés sur vos données, code propriétaire intégralement détenu par le client à la livraison. Pas de vendor lock-in.
#Pour aller plus loin
Cas d'usage connexes :
Questions & réponses
Questions frequentes sur l'agregateur de comptes Open Banking
Oui, en propre — ou en operant sous la licence d'un AISP existant. L'AISP (Account Information Service Provider) est le statut réglementaire requis par la DSP2 pour accéder aux données de comptes bancaires des clients avec leur consentement. L'alternative — opérer comme utilisateur d'API sous la licence d'un AISP existant (Powens, Tink, Salt Edge) — est beaucoup plus rapide (quelques semaines après signature du contrat) et ne requiert pas d'agrément propre. C'est le modèle recommande pour les fintechs en phase de lancement et de validation du marche. L'agrément propre devient pertinent a partir du moment ou les volumes et les marges le justifient.
La DSP2 (en application depuis 2019) couvre uniquement les comptes de paiement — comptes courants et comptes sur livrets ouverts a des fins de paiement. La DSP3 (en cours de finalisation au niveau européen, transposition prevue 2025-2027) étend le périmètre a l'ensemble des produits financiers : comptes d'épargne, credits, assurances, investissements, données fiscales. C'est le passage de l'Open Banking a l'Open Finance. Pour un agregateur, cela signifie la possibilité d'afficher en un seul endroit le compte courant BNP, le Livret A Caisse d'Épargne, le credit auto Credit Mutuel et le portefeuille boursier Boursorama — avec des analyses transversales. Les architectures qui sont désignées aujourd'hui avec DSP3 en tête éviteront un refactoring majeur a l'entrée en vigueur de la directive.
La catégorisation des transactions est la fonctionnalité numéro 1 qui determine si un utilisateur PFM reste ou part. Si 'Carrefour' est classe en 'Divers' plutôt qu'en 'Alimentation', si 'Netflix' n'est pas detecte comme abonnement, si un remboursement Assurance Maladie est classe en 'Revenu professionnel' — l'utilisateur perd confiance dans l'outil et se désabonne. Les studies UX sur les applications PFM (Plaid, Tink, Linxo) montrent coheremment que la précision de catégorisation est le facteur predictif numéro 1 de la rétention a 90 jours.
La DSP2 impose une reauthentification forte (SCA — Strong Customer Authentication) de l'utilisateur tous les 90 jours maximum pour les connexions d'agrégation. Dans la pratique, cette contrainte est un des points les plus irritants du parcours utilisateur PFM : l'application doit rappeler a l'utilisateur de se reconnecter via l'application de sa banque, ce qui cree de la friction et du churn. Notre approche : notification push J-7 et J-1 avant l'expiration du consentement, avec un deep link direct vers le parcours de reauthentification simplifie. Powens gere la partie technique (refreshing des tokens, gestion des sessions SCA).
Via les APIs PSD2, un AISP peut accéder (avec consentement explicite de l'utilisateur) aux informations de compte (IBAN, titulaire, type de compte), aux soldes (courant et disponible) et aux transactions des 90 derniers jours minimum (certaines banques permettent un historique plus long). Les données biométriques, les données de carte (PAN complet, CVV) et les informations de credit ne sont pas accessibles via les APIs AIS. Cote sécurité : les données bancaires sont chiffrées au repos avec AES-256, avec des clés de chiffrement propres à chaque utilisateur. En cas d'accès non autorise a la base de données, les données sont illisibles. En transit, toutes les communications sont en TLS 1.3. Les accès aux données bancaires sont loggues et audites. Voir notre page sécurité et conformité RGPD Open Banking.
Oui, et c'est précisément la direction de l'Open Finance avec DSP3. Des maintenant, des intégrations sont possibles en dehors du périmètre DSP2 strict : flux de scoring credit (integration avec Algoan pour le credit scoring Open Banking), propositions d'épargne basées sur l'analyse du solde résiduel moyen, recommandations d'assurance sur la base des patterns de depenses détectés. Ces fonctionnalités requièrent des partenariats commerciaux avec les établissements de credit ou d'assurance — mais l'infrastructure technique est la même. C'est un modèle économique complémentaire a la subscription utilisateur.