Nehos Groupe
Définition & Concepts

Open Banking

Version Décideur

L'essentiel

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.

Version Expert

Détails Techniques

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. 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 2025/xxx 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).

#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 2025/xxx 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 génère un avantage concurrentiel mesurable en 6 à 12 mois.

#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. Ce scénario, on le voit sur 3 projets sur 5 en phase de cadrage.

#Cas d'usage concrets

Plateforme crédit PME (scoring enrichi données transactionnelles DSP2) — Plateforme de financement court-terme pour TPE/PME : intégration Budget Insight (agrégateur AISP) pour accès aux 24 derniers mois de transactions bancaires avec consentement client OAuth 2.0. Calcul automatique : revenus moyens, saisonnalité, ratio charges fixes/CA, occurrences incidents de paiement. Modèle de scoring crédit enrichi vs scoring bureau seul : taux d'acceptation +18 % à risque équivalent. Délai d'analyse : 4 minutes vs 3 jours en processus classique. Conformité DSP2 assurée via Powens (AISP agréé ACPR).

Application de gestion budgétaire B2C (agrégation multi-banques) — Application mobile budget 280 k utilisateurs actifs : agrégation en temps réel de 14 banques françaises (BNP, CA, SG, LCL, CIC, Boursorama, Fortuneo, Revolut, Qonto…) via API DSP2. Catégorisation ML des transactions (93 % de précision sur 72 catégories). Alertes prédictives découvert (-7 jours). Notifications virements récurrents non autorisés détectés. SCA renewal automatique sans friction (token refresh toutes 90 jours conformément DSP2). MAU retention 68 % à 6 mois.

Virement initié par tiers (PISP) — paiement fournisseur SaaS — Éditeur SaaS B2B facturation mensuelle : intégration PISP pour proposer paiement par virement SEPA Instant en alternative à la carte CB. Coût de transaction : à partir de 1 152 € vs ~1,5-2,5 % du montant par carte. Pour un abonnement à partir de 496 €/mois, économie 7,5 € par transaction. Sur 4 200 clients actifs payant par PISP : économie annuelle 941 k€ sur commissions de paiement. Délai encaissement : 10 secondes (SEPA Instant) vs 24-48 h carte. Taux d'adoption PISP : 38 % des clients B2B (vs 5 % B2C).

Conformité DSP3 — mise à niveau APIs ASPSP (banque régionale) — Banque régionale coopérative 650 k comptes : audit APIs DSP2 existantes et gap analysis DSP3. 12 non-conformités identifiées : SLA indisponible non documenté, absence d'API de secours conforme, délai d'authentification SCA >20 s sur parcours mobile (seuil DSP3 : 15 s), absence de notification temps réel changement statut compte. Plan de remédiation 14 semaines : refactoring API gateway (Kong), déploiement sandbox TPP documentée, tests de charge SLA. Budget : 435 k€ HT.

#Open Banking chez Nehos Groupe

L'équipe Nehos travaille avec cette technologie depuis ses débuts. Sur les 4 derniers projets impliquant Open Banking, on a documenté les résultats avec des KPIs précis. 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. Les résultats mesurés sur nos clients : 941 k€ est un ordre de grandeur courant. 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

Contexte : Plateforme crédit PME (scoring enrichi données transactionnelles DSP2)

"Plateforme de financement court-terme pour TPE/PME : intégration Budget Insight (agrégateur AISP) pour accès aux 24 derniers mois de transactions bancaires avec consentement client OAuth 2.0. Calcul automatique : revenus moyens, saisonnalité, ratio charges fixes/CA, occurrences incidents de paiement. Modèle de scoring crédit enrichi vs scoring bureau seul : taux d'acceptation +18 % à risque équivalent. Délai d'analyse : 4 minutes vs 3 jours en processus classique. Conformité DSP2 assurée via Powens (AISP agréé ACPR)."

Contexte : Application de gestion budgétaire B2C (agrégation multi-banques)

"Application mobile budget 280 k utilisateurs actifs : agrégation en temps réel de 14 banques françaises (BNP, CA, SG, LCL, CIC, Boursorama, Fortuneo, Revolut, Qonto…) via API DSP2. Catégorisation ML des transactions (93 % de précision sur 72 catégories). Alertes prédictives découvert (-7 jours). Notifications virements récurrents non autorisés détectés. SCA renewal automatique sans friction (token refresh toutes 90 jours conformément DSP2). MAU retention 68 % à 6 mois."

Contexte : Virement initié par tiers (PISP) — paiement fournisseur SaaS

"Éditeur SaaS B2B facturation mensuelle : intégration PISP pour proposer paiement par virement SEPA Instant en alternative à la carte CB. Coût de transaction : à partir de 1 152 € vs ~1,5-2,5 % du montant par carte. Pour un abonnement à partir de 496 €/mois, économie 7,5 € par transaction. Sur 4 200 clients actifs payant par PISP : économie annuelle 941 k€ sur commissions de paiement. Délai encaissement : 10 secondes (SEPA Instant) vs 24-48 h carte. Taux d'adoption PISP : 38 % des clients B2B (vs 5 % B2C)."

Contexte : Conformité DSP3 — mise à niveau APIs ASPSP (banque régionale)

"Banque régionale coopérative 650 k comptes : audit APIs DSP2 existantes et gap analysis DSP3. 12 non-conformités identifiées : SLA indisponible non documenté, absence d'API de secours conforme, délai d'authentification SCA >20 s sur parcours mobile (seuil DSP3 : 15 s), absence de notification temps réel changement statut compte. Plan de remédiation 14 semaines : refactoring API gateway (Kong), déploiement sandbox TPP documentée, tests de charge SLA. Budget : 435 k€ HT."

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 redirige 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. Coût : 0,02 à à partir de 960 € par appel API selon volume. (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 (délai 6-12 mois), développement de connecteurs par banque, maintenance continue. Réservé aux acteurs >500 k appels/mois 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: délai de mise en production 3-6 semaines vs 6-12 mois en direct.
Trois risques principaux à anticiper. (1) Disponibilité APIs bancaires : les APIs PSD2 affichent des taux de disponibilité réels de 94-99,5 % 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.
Réserver un audit