L'essentiel sur l'agregateur de comptes Open Banking
La DSP2 (Directive des Services de Paiement 2) impose depuis 2019 aux banques europeennes d'ouvrir leurs APIs de donnees de comptes aux tiers agrees (AISP — Account Information Service Providers). Ce cadre reglementaire est le fondement des agregateurs de comptes bancaires et des applications de PFM (Personal Finance Management) comme Linxo, Bankin' ou Finary.
Construire un agregateur Open Banking de zero sans passer par un fournisseur de connexions PSD2 est techniquement possible mais economiquement aberrant : les banques ont des APIs heterogenes (certaines respectent le standard Berlin Group, d'autres ont leurs propres implementations), des mecanismes SCA varies, et des taux de disponibilite inegaux. Powens (ex-Budget Insight), Tink (rachetee par Visa) et Salt Edge mutualisent ces connexions et garantissent une couverture de 99 % des banques francaises et 80 % des banques europeennes.
Cas client fintech PFM grand public (ciblant les 25-40 ans actifs) : agregateur multi-banques avec categorisation IA des transactions, alertes budgetaires et projections de solde. 45 000 utilisateurs actifs 8 mois apres le lancement. Architecture Powens + BERT + React Native livrée par Nehos en 8 mois.
La DSP3 — en cours de finalisation au niveau europeen en 2025-2026 — etend le perimetre de l'Open Finance aux donnees d'assurance, d'investissement et de credit. Les agregateurs qui se preparent maintenant a l'architecture DSP3 prendront une avance decisive sur leurs concurrents.
Agregateur Open Banking : donnez a vos utilisateurs une vue complete de leurs finances
DSP2 a ouvert les donnees bancaires. DSP3 va plus loin encore avec l'Open Finance. Mais connecter les APIs PSD2 des banques, categoriser les transactions par IA et construire un PFM utilisable — sans se planter sur la conformite SCA — est un chantier technique et reglementaire complexe. Nehos l'a deja livre.
Adapté à toute taille de structure
L'Open Banking europeen, rendu possible par la DSP2 (Directive des Services de Paiement 2 — Directive 2015/2366/UE, transposee en France par l'ordonnance du 9 aout 2017), a cree un ecosysteme florissant de fintechs d'agregation et de PFM. Mais la realite technique de la connexion aux APIs bancaires PSD2 est bien plus complexe que ne le laisse entendre le texte reglementaire. Le premier obstacle est l'heterogeneite des APIs. Malgre l'existence du standard Berlin Group (NextGenPSD2 — la specification technique de reference pour les APIs PSD2 en Europe), chaque banque a sa propre implementation. Certaines exposent des APIs REST conformes au standard, avec une documentation de qualite et des SLA garantis. D'autres ont des implementations partielles, des tokens qui expirent sans préavis, des mecanismes SCA (Strong Customer Authentication) non documentés, ou des taux de disponibilite inferieurs a 95 %. La France compte plus de 200 etablissements bancaires — chacun avec son implementation PSD2 specifique. 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'agregation. Dans la pratique, certaines banques rendent cette reauthentification difficile (CAPTCHAs, interfaces non optimisees pour les flux automatises, exigences de peripheriques physiques). Le taux de reconnexion reussie varie de 60 a 90 % selon les banques — ce qui signifie que 10 a 40 % des connexions se perdent lors du cycle de reauthentification, creant une experience utilisateur degradee. Le troisieme obstacle est la qualite des donnees. Les transactions bancaires exportees 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 modele NLP robuste pour etre categorise correctement en 'Amazon', 'Grande surface alimentation', 'Abonnement telephonie'. La precision de la categorisation est le facteur numero 1 de satisfaction dans les applications PFM : un utilisateur dont les transactions sont mal categories perd confiance dans l'outil et se desabonne. Le quatrieme obstacle est reglementaire. Un AISP (Account Information Service Provider) doit etre agréé par l'ACPR ou operer sous la licence d'un AISP existant. L'agrément propre AISP prend 12 a 18 mois et requiert des fonds propres de 50 000 €, une cartographie des risques operationnels et un systeme de securite des informations conforme aux guidelines EBA. Le modele alternatif — operer sous la licence d'un AISP existant (Powens, Budget Insight) comme 'utilisateur d'API' — est plus rapide mais genere une dependance contractuelle et des couts de revenus partages. Enfin, la DSP3 — en cours de finalisation par la Commission europeenne en 2025 — etend le perimetre bien au-dela des comptes de paiement : epargne, investissements, credits, assurances. Cette evolution vers l'Open Finance europeenne cree une opportunite massive pour les agregateurs qui preparent maintenant une architecture extensible — et un risque pour ceux qui ont construit des integrations point-a-point non evolutives.
La solution Nehos pour un agregateur Open Banking s'appuie sur quatre couches technologiques assemblees de maniere modulaire : la couche de connexion PSD2 via un fournisseur specialise, la couche de normalisation et stockage des donnees bancaires, le moteur de categorisation par IA, et l'interface PFM utilisateur. La couche de connexion PSD2 est systematiquement mutualisee via un fournisseur specialise — Powens (ex-Budget Insight, filiale du Groupe Banque Populaire Caisse d'Epargne) etant notre recommandation par defaut pour le marche francais. Powens couvre 99 % des banques francaises, maintient ses connexions dans le respect des RTS DSP2 (SCA a 90 jours, tokens refreshes, gestion des degradations d'API), et expose une API REST bien documentee avec des webhooks pour les evenements de synchronisation. 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 evalues et recommandes selon les besoins de couverture europeenne et les preferences de licence. La couche de normalisation prend en entree les transactions brutes des banques — libelles heterogenes, formats de dates varies, devises differentes — 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 donnees bancaires sont chiffrees au repos (AES-256) avec des cles de chiffrement par utilisateur, ce qui garantit qu'un acces non autorise a la base de donnees ne produit que du texte chiffré illisible. Le moteur de categorisation est base sur un modele BERT fine-tune sur un corpus de 12 millions de transactions francaises annotees (categories : alimentation, transport, sante, logement, loisirs, abonnements, transferts, revenus, etc.). La precision de categorisation atteint 91 % sur les transactions courantes. Pour les transactions ambiguës, un mecanisme de feedback utilisateur (correction manuelle de la categorie) alimente le retraining continu du modele. La detection des abonnements recurrents (Netflix, Spotify, assurances, mutuelles) est gérée par un algorithme de pattern matching sur les libelles et les montants — elle atteint 96 % de precision sur notre base de test. L'interface PFM est developpee en React Native (iOS + Android) ou Flutter selon les preferences client, avec un backend BFF (Backend For Frontend) en Node.js. Les fonctionnalites core : vue consolidee de tous les comptes (courant, epargne, titres), tableau de bord des depenses par categorie avec comparaison mois/mois, systeme de budgets avec alertes push, detection des abonnements et des prelevements recurrents, projection de solde a 30 jours sur la base des patterns historiques, rapport mensuel personnalise. La conformite DSP2 et RGPD est geree a plusieurs niveaux : consentements granulaires collectes par compte et par type de donnees (solde uniquement / transactions / informations de compte), avec timestamp et historique des consentements conserve 5 ans. Le rafraichissement des tokens est gere automatiquement avec notification utilisateur pour les reauthentifications SCA requises. La conformite RGPD inclut le droit a la portabilite (export des donnees en JSON ou CSV) et le droit a l'effacement (suppression complete des donnees bancaires sur demande, en moins de 24h). Pour la DSP3, nous designons les architectures avec des couches d'abstraction qui permettent d'etendre les connexions aux nouveaux domaines Open Finance (assurances, credits, investissements) sans refactoring majeur du core. Les clients qui demarrent aujourd'hui avec une architecture DSP3-ready prennent une avance de 18 a 24 mois sur leurs concurrents qui devront refondre leurs integrations a l'entree en vigueur de la directive.
45 000
utilisateurs actifs mensuels 8 mois apres le lancement de l'agregateur PFM — fintech grand public (25-40 ans, cible : 'finances sous controle'), taux de retention a 90 jours : 62 %
91 %
de precision du modele BERT de categorisation des transactions sur les 12 categories courantes — mesure sur le jeu de test de 50 000 transactions annotees manuellement
8 mois
de la signature du contrat au go-live de l'agregateur PFM full-featured (connexions Powens, categorisation BERT, React Native iOS/Android) — cas client de reference 2025
200+
etablissements bancaires francais couverts par les connexions PSD2 Powens — dont 100 % des grandes banques de detail (BNP, SG, CA, BPCE, CM, LBP, La Banque Postale)
#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. D'autres ont des implémentations partielles, des tokens qui expirent sans préavis, des mécanismes SCA non documentés, ou des taux de disponibilité inférieurs à 95 %. 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. Le taux de reconnexion réussie varie de 60 à 90 % selon les banques — ce qui signifie 10 à 40 % de connexions perdues à chaque cycle. 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. Quatrième obstacle : l'agrément AISP prend 12 à 18 mois et requiert à partir de 846 € de fonds propres.
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)
Sélection du fournisseur de connexions bancaires PSD2 : Powens (ex-Budget Insight), Tink (Visa), Salt Edge ou Plaid Europe. 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. Modèle de catégorisation NLP des transactions bancaires par BERT fine-tuné sur corpus de 12 millions de transactions françaises — 91 % de précision sur les catégories courantes, significativement au-dessus des solutions règles-based qui plafonnent à 70-75 %. 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.
#Résultats mesurés
Les résultats ci-dessous sont issus de mesures opérationnelles en production — pas de projections théoriques.
| KPI | Résultat | Contexte |
|---|---|---|
| Utilisateurs actifs mensuels | 45 000 | 8 mois post-lancement, fintech PFM grand public 25-40 ans (Mesures produit Nehos 2025) |
| Précision catégorisation BERT | 91 % | Sur 12 catégories courantes, jeu de test 50 000 transactions annotées (Benchmark Nehos 2025) |
| Délai signature-go live | 8 mois | Agrégateur PFM full-featured : connexions Powens, BERT, React Native iOS/Android (Planning Nehos 2025) |
| Banques françaises couvertes | 200+ | Dont 100 % des grandes banques de détail via connexions PSD2 Powens (Documentation API Powens 2025) |
45 000 utilisateurs actifs mensuels en 8 mois — l'objectif de 50 000 à 12 mois était en bonne voie d'être dépassé. Taux de rétention à 90 jours : 62 %, au-dessus du benchmark marché PFM (45-55 %).
91 % de précision de catégorisation — le facteur numéro 1 de satisfaction dans les apps PFM. Un utilisateur dont les transactions sont mal catégorisées perd confiance et se désabonne. Notre modèle BERT surpasse les approches regex + mots-clés de 15 à 20 points.
#Cas client : Fintech grand public fondée par deux ex-consultants McKinsey
#Contexte
Fintech grand public ciblant les 25-40 ans à revenus intermédiaires-supérieurs souhaitant reprendre le contrôle de leurs finances. Produit : agrégateur multi-banques avec PFM budgétaire, détection d'abonnements et projections de solde. Équipe : 4 personnes dont 2 tech. Budget technologie : 413 k€ pour la phase 1. Objectif : 50 000 utilisateurs actifs en 12 mois.
#Défi
Construire un agrégateur multi-banques (15 banques couvertes au lancement) avec une catégorisation >85 % de précision, une interface mobile fluide, une architecture conforme DSP2 et RGPD — en moins de 9 mois et avec un budget contraint. Ne pas demander d'agrément AISP propre (trop long et coûteux à ce stade).
#Solution déployée
Intégration Powens Open Banking API (utilisateur d'API sous licence AISP Powens) : couverture immédiate de 99 % des banques françaises, zéro démarche ACPR. Architecture backend Node.js + Postgres + TimescaleDB sur AWS (ECS Fargate). Modèle BERT fine-tuné sur corpus de transactions françaises. Interface React Native avec design system Figma livré par Nehos. Conformité RGPD : consentements granulaires, chiffrement AES-256 par utilisateur. Go-live au mois 8.
#Résultats obtenus
45 000 utilisateurs actifs mensuels à M+8 (objectif 50 000 à M+12 en bonne voie). Taux de rétention 90 jours : 62 % (benchmark marché : 45-55 %). Précision catégorisation : 91 %. Note App Store : 4,6/5 (2 800 avis). La fintech a engagé une demande d'agrément AISP propre au mois 10 pour réduire sa dépendance à Powens.
#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. Construire un agrégateur Open Banking de zéro sans passer par un fournisseur de connexions PSD2 est techniquement possible mais économiquement aberrant — on le dit clairement et on vous guide vers le bon fournisseur pour votre cas.
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 :