Agregateur Open Banking : donnez à vos utilisateurs une vue complete de leurs finances
DSP2 a ouvert les données bancaires. DSP3 va plus loin encore avec l'Open Finance. Mais connecter les APIs PSD2 des banques, catégoriser les transactions par IA et construire un PFM utilisable — sans se planter sur la conformité SCA — est un chantier technique et réglementaire complexe. Nehos l'a déjà livre.
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. D'autres ont des implementations partielles, des tokens qui expirent sans préavis, des mécanismes SCA (Strong Customer Authentication) non documentés, ou des taux de disponibilité inférieurs a 95 %. 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 taux de reconnexion réussie varie de 60 à 90 % selon les banques — ce qui signifie que 10 a 40 % des connexions se perdent lors du cycle de reauthentification, créant une expérience utilisateur dégradée. 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. L'agrément propre AISP prend 12 a 18 mois et requiert des fonds propres de 50 000 €, une cartographie des risques opérationnels et un système de sécurité des informations conforme aux guidelines EBA. 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. La couche de connexion PSD2 est systématiquement mutualisée via un fournisseur specialise — Powens (ex-Budget Insight, filiale du Groupe Banque Populaire Caisse d'Épargne) étant notre recommandation par défaut pour le marche français. Powens couvre 99 % des banques françaises, 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 documentée 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 é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. Le moteur de catégorisation est base sur un modèle BERT fine-tune sur un corpus de 12 millions de transactions françaises annotées (categories : alimentation, transport, santé, logement, loisirs, abonnements, transferts, revenus, etc.). La precision de catégorisation atteint 91 % sur les transactions courantes. Pour les transactions ambiguës, un mécanisme de feedback utilisateur (correction manuelle de la catégorie) alimente le retraining continu du modèle. La detection des abonnements récurrents (Netflix, Spotify, assurances, mutuelles) est gérée par un algorithme de pattern matching sur les libelles et les montants — elle atteint 96 % de précision sur notre base de test. 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. Les fonctionnalités core : vue consolidée de tous les comptes (courant, épargne, titres), tableau de bord des depenses par catégorie avec comparaison mois/mois, système de budgets avec alertes push, detection des abonnements et des prélèvements récurrents, projection de solde a 30 jours sur la base des patterns historiques, rapport mensuel personnalise. 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.
45 000
utilisateurs actifs mensuels 8 mois après le lancement de l'agregateur PFM — fintech grand public (25-40 ans, cible : 'finances sous controle'), taux de rétention a 90 jours : 62 %
91 %
de précision du modèle BERT de catégorisation des transactions sur les 12 categories courantes — mesure sur le jeu de test de 50 000 transactions annotées manuellement
8 mois
de la signature du contrat au go-live de l'agregateur PFM full-featured (connexions Powens, catégorisation BERT, React Native iOS/Android) — cas client de référence 2025
200+
établissements bancaires français 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 :
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'obtention de ce statut auprès de l'ACPR necessite environ 12 a 18 mois et des fonds propres de 50 000 €. 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. Notre modèle BERT atteint 91 % de précision sur les transactions courantes — significativement au-dessus des solutions règles-based (regex + mots-clés) qui plafonnent a 70-75 %.
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). Nous travaillons sur l'UX du parcours de reauthentification pour minimiser le churn — sur notre cas client, le taux de reauthentification réussie est de 78 % (benchmark marche : 60-65 %).
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. Certains de nos clients agregateurs ont monetise ces couches de recommandation avec des commissions de 15 a à partir de 400 € par souscription générée. C'est un modèle économique complémentaire a la subscription utilisateur.