Open Banking
#Définition Open Banking
L'open banking repose sur une architecture API (REST ou propriétaire selon les établissements) exposée par les banques dites ASPSP (Account Servicing Payment Service Providers) à des tiers agréés (TPP) après authentification forte du client (SCA — Strong Customer Authentication).
Deux flux techniques distincts : (1) AIS (Account Information Services) — lecture en temps réel des soldes, transactions, informations de compte via appels GET authentifiés OAuth 2.0 avec redirection SCA vers la banque ; (2) PIS (Payment Initiation Services) — initiation de virement SEPA Instant Credit Transfer (SCT Inst) ou SEPA Credit Transfer (SCT) depuis le compte du payeur via API PUT/POST. Pour approfondir, consultez la page service Open Banking DSP3 Nehos.
D'un point de vue métier, La DSP3 (2026) renforce les obligations techniques des ASPSP : APIs de secours obligatoires (fallback), SLA de disponibilité documentés et exécutoires, suppression des obstacles techniques à l'accès TPP, notification en temps réel des changements de statut de compte.
FIDA (Financial Data Access, règlement UE en cours d'adoption) étend le périmètre au-delà du compte de paiement : données d'assurance, épargne, retraite, crédit, investissement — avec consentement client et compensations possibles pour les institutions partageant leurs données (data holders).
Outils techniques utilisés par les intégrateurs : Berlin Group NextGenPSD2 (standard APIs PSD2 européen), STET (standard Français — BNP, BPCE, CA, SG, LBP), Open Banking UK (standard GB), SDK propriétaires agrégateurs (Powens, Budget Insight, Tink acquis par Visa).
Appliqué correctement, Open Banking peut devenir un avantage concurrentiel.
#Open Banking expliqué simplement
Imaginez que votre relevé de compte bancaire soit enfermé dans un coffre appartenant à votre banque. Avant l'open banking, la banque était la seule à avoir la clé. Pour qu'un comparateur de prêts voie votre situation financière réelle, vous deviez lui fournir vos relevés PDF manuellement — et certains outils scandaleux vous demandaient même vos identifiants bancaires.
L'open banking, c'est le principe que vous avez la clé de ce coffre, et que vous pouvez décider qui d'autre y a accès, pour combien de temps et pour quoi faire. Concrètement : vous autorisez Budget Insight à lire vos comptes pour que votre courtier en crédit voie instantanément vos 12 derniers mois de revenus et dépenses — plus de relevés à scanner.
Vous autorisez un PISP à initier un virement depuis votre compte pour payer une facture — plus de CB à saisir. Et avec FIDA en 2026, même vos données d'assurance vie ou d'épargne salariale pourront être partagées avec consentement. Toujours vous qui décidez, toujours révocable.
Imaginez que vous dirigez une PME ou une scale-up.
#Cas d'usage concrets
Exemple de situation — plateforme de crédit PME : scoring enrichi par les données transactionnelles — Situation type : une plateforme de financement court terme pour TPE et PME intègre un agrégateur AISP comme Budget Insight pour accéder, avec le consentement du client (OAuth 2.0), à ses dernières années de transactions bancaires.
Elle calcule automatiquement les revenus moyens, la saisonnalité, le ratio charges fixes sur chiffre d'affaires et les incidents de paiement. Un scoring enrichi par ces données se compare au scoring bureau seul, à risque équivalent, avant d'être généralisé. La conformité DSP2 s'appuie sur un AISP agréé par l'ACPR.
Exemple de situation — application de gestion budgétaire B2C : agrégation multi-banques — Situation type : une application mobile de gestion budgétaire agrège en temps réel les comptes de plusieurs banques françaises via les API DSP2. Les transactions sont catégorisées par un modèle de ML, des alertes prédictives signalent un découvert à venir, et le renouvellement du consentement SCA (token tous les 90 jours) est géré sans friction pour l'utilisateur. On suit la rétention des utilisateurs actifs dans le temps.
Exemple de situation — virement initié par un tiers (PISP) : paiement d'un fournisseur SaaS — Situation type : un éditeur SaaS B2B qui facture chaque mois propose en plus de la carte bancaire un paiement par virement SEPA Instant, initié via un PISP. Le virement évite les commissions de carte, qui sont proportionnelles au montant, et l'argent arrive en quelques secondes au lieu de plusieurs jours. On suit le taux d'adoption de ce moyen de paiement parmi les clients B2B, souvent plus élevé que chez les particuliers.
Exemple de situation — conformité DSP3 : mise à niveau des API d'une banque (ASPSP) — Situation type : une banque régionale coopérative audite ses API DSP2 et réalise une gap analysis DSP3. Les non-conformités typiques sont un SLA d'indisponibilité non documenté, l'absence d'API de secours conforme, un délai d'authentification SCA trop long sur le parcours mobile et l'absence de notification en temps réel des changements de statut de compte.
Le plan de remédiation comprend le refactoring de l'API gateway, le déploiement d'un sandbox documenté pour les TPP et des tests de charge sur le SLA.
#Open Banking chez Nehos Groupe
Notre service Open Banking DSP3 Nehos couvre ce périmètre de A à Z.
Chaque mission démarre par un cadrage structuré : objectifs chiffrés, périmètre technique, jalons à 30/60/90 jours. On livre, on mesure, on itère. Pas de slides sans livrable.
#Termes associés
Ce terme s'inscrit dans un écosystème plus large.
Tous ces termes sont interconnectés. Maîtriser l'un sans comprendre les autres, c'est voir le puzzle sans toutes les pièces.
Applications Concrètes
« Situation type : une plateforme de financement court terme pour TPE et PME intègre un agrégateur AISP comme Budget Insight pour accéder, avec le consentement du client (OAuth 2.0), à ses dernières années de transactions bancaires. Elle calcule automatiquement les revenus moyens, la saisonnalité, le ratio charges fixes sur chiffre d'affaires et les incidents de paiement. Un scoring enrichi par ces données se compare au scoring bureau seul, à risque équivalent, avant d'être généralisé. La conformité DSP2 s'appuie sur un AISP agréé par l'ACPR. »
« Situation type : une application mobile de gestion budgétaire agrège en temps réel les comptes de plusieurs banques françaises via les API DSP2. Les transactions sont catégorisées par un modèle de ML, des alertes prédictives signalent un découvert à venir, et le renouvellement du consentement SCA (token tous les 90 jours) est géré sans friction pour l'utilisateur. On suit la rétention des utilisateurs actifs dans le temps. »
« Situation type : un éditeur SaaS B2B qui facture chaque mois propose en plus de la carte bancaire un paiement par virement SEPA Instant, initié via un PISP. Le virement évite les commissions de carte, qui sont proportionnelles au montant, et l'argent arrive en quelques secondes au lieu de plusieurs jours. On suit le taux d'adoption de ce moyen de paiement parmi les clients B2B, souvent plus élevé que chez les particuliers. »
« Situation type : une banque régionale coopérative audite ses API DSP2 et réalise une gap analysis DSP3. Les non-conformités typiques sont un SLA d'indisponibilité non documenté, l'absence d'API de secours conforme, un délai d'authentification SCA trop long sur le parcours mobile et l'absence de notification en temps réel des changements de statut de compte. Le plan de remédiation comprend le refactoring de l'API gateway, le déploiement d'un sandbox documenté pour les TPP et des tests de charge sur le SLA. »
Questions & réponses
Questions fréquentes sur l'Open Banking
Le screen scraping était la pratique qui précédait l'open banking : l'agrégateur demandait vos identifiants bancaires, se connectait à votre banque en se faisant passer pour vous, et 'scrapait' les pages web pour en extraire les données. Problèmes : risque de sécurité majeur (tiers détient vos credentials), violation probable des CGU de votre banque, données extraites non structurées et fragiles. L'open banking via APIs DSP2/DSP3 remplace cela : les banques exposent des APIs standardisées, le tiers s'authentifie avec ses propres credentials TPP agréés, et vous donnez votre consentement via un redirect SCA sécurisé vers votre banque. Vos identifiants ne quittent jamais votre banque. La DSP2 (2018) a formellement interdit aux banques de bloquer les APIs et obligé les tiers à migrer du screen scraping vers les APIs officielles.
Le consentement en open banking est régi par la DSP2/DSP3. Il doit être explicite (opt-in), spécifique (le client sait exactement quelles données sont partagées et avec qui), limité dans le temps (90 jours maximum sans re-confirmation SCA selon DSP2) et révocable à tout moment depuis l'interface de la banque ou du TPP. Le flow technique : le TPP redirigé l'utilisateur vers la banque (redirect flow) ou initie un appel API (decoupled flow) ; l'utilisateur s'authentifie par SCA (combinaison de deux facteurs parmi : connaissance/mot de passe, possession/téléphone, biométrie) ; la banque émet un access token OAuth 2.0 au TPP ; le TPP accède aux données accordées jusqu'à expiration ou révocation. FIDA (2026) introduira un gestionnaire de consentement unifié cross-institutions pour simplifier ce flow.
En théorie oui — toutes les banques françaises assujetties à la DSP2 (banques, établissements de paiement) sont obligées d'exposer des APIs PSD2 depuis 2019. En pratique, la qualité varie significativement. Les grandes banques (BNP Paribas, Crédit Agricole, Société Générale, BPCE, LCL) ont des APIs conformes au standard STET avec des SLA corrects. Certaines banques régionales et mutualistes ont des APIs moins stables, des taux d'erreur plus élevés ou des SLA non documentés. C'est précisément l'un des objectifs de la DSP3 : uniformiser la qualité et documenter les SLA. Les agrégateurs (Powens, Budget Insight, Tink) maintiennent des tableaux de bord de disponibilité des APIs par banque — un indicateur utile avant de choisir son partenaire.
FIDA (Financial Data Access) est le règlement UE en cours d'adoption fin 2025-2026 qui étend le principe de l'open banking bien au-delà du compte de paiement. Périmètre FIDA : assurance (contrats, sinistres, primes), épargne et retraite (PER, PERP, PEE), crédits (historique, encours, conditions), investissements (portefeuilles, performances). Pour y accéder, les mêmes règles : consentement client, tiers agréé, APIs standardisées. Deux différences majeures vs DSP2/DSP3 : (1) les data holders (assureurs, gestionnaires d'actifs) pourront potentiellement recevoir une compensation pour le partage de données — contrairement aux banques sous DSP2 ; (2) le périmètre crée un marché 'open finance' inédit où un agrégateur pourra montrer en un seul endroit tous vos actifs financiers (comptes, assurance vie, PER, actions, crédit). Pour les fintechs et insurtechs, c'est l'ouverture d'un marché immense de nouveaux services.
Deux approches techniques. (1) Via un agrégateur AISP agréé (Powens, Budget Insight, Tink by Visa, Nordigen by GoCardless) : vous consommez leur API unifiée qui normalise les données de toutes les banques — solution recommandée pour aller vite, la complexité réglementaire et de maintenance est externalisée. Le coût dépend de la grille de l'agrégateur et du volume d'appels API. (2) En direct sur les APIs STET/Berlin Group de chaque banque : nécessite votre propre agrément AISP ou PISP auprès de l'ACPR (plusieurs mois de procédure), développement de connecteurs par banque, maintenance continue. Réservé aux acteurs à très gros volume d'appels pour qui le coût agrégateur n'est plus justifiable. Pour la grande majorité des projets B2B, l'option agrégateur est la bonne : la mise en production est bien plus rapide qu'en direct.
Trois risques principaux à anticiper. (1) Disponibilité APIs bancaires : la disponibilité réelle des APIs PSD2 varie selon les banques — prévoir un fallback (screen scraping de secours via dérogation ACPR si disponible, ou interface dégradée informant l'utilisateur). (2) Révocation du consentement sans prévenance : un utilisateur peut révoquer son token depuis son interface bancaire à tout moment — votre système doit gérer les erreurs 401 et informer l'utilisateur proprement sans bloquer son parcours. (3) Responsabilité en cas de fraude : sous DSP2/DSP3, si un paiement non autorisé est initié via PISP, la responsabilité est d'abord présumée sur le PSP — il faut documenter rigoureusement les processus SCA et conserver les logs d'authentification. Côté réglementaire : l'ACPR peut auditer vos flux TPP — conservez les logs de consentement 5 ans minimum.