Chapitre 1. DSP2 : le cadre fondateur de l'open banking.
L'open banking européen procède de la loi plutôt que du marché. La DSP2 (directive (UE) 2015/2366) a créé une obligation inédite. Les banques teneuses de compte (ASPSP, Account Servicing Payment Service Providers) doivent ouvrir l'accès aux comptes de paiement de leurs clients à des tiers agréés (TPP, Third Party Providers). Cet accès se fait avec le consentement du client, sans contrat avec la banque et sans frais d'accès. Le monopole bancaire sur les données de compte et l'initiation de virement prend fin.
| Rôle | Article DSP2 | Ce qu'il fait | Statut requis |
|---|---|---|---|
| AISP (Account Information Service Provider) | Art. 67 | Agrège et restitue les données de comptes (soldes, transactions) : apps de gestion de budget, scoring crédit, comptabilité | Enregistrement (régime allégé) auprès du régulateur, ex. ACPR en France |
| PISP (Payment Initiation Service Provider) | Art. 66 | Initie un virement depuis le compte du payeur vers un bénéficiaire : le « paiement par banque » | Agrément d'établissement de paiement |
| CBPII (Card-Based Payment Instrument Issuer) | Art. 65 | Vérifie la disponibilité des fonds pour un instrument de paiement émis par un tiers | Agrément |
Deux points juridiques doivent être bien fixés. L'accès du TPP est un droit, pas une faveur commerciale. La banque ne peut ni exiger de contrat, ni facturer l'accès, ni discriminer les virements initiés par PISP par rapport à ceux passés dans sa propre app. Le TPP, lui, doit être agréé ou enregistré (registre EBA consultable publiquement). Il s'identifie auprès de la banque avec des certificats eIDAS (QWAC/QSealC) et n'accède qu'aux données couvertes par le consentement du client.
Chapitre 2. Les API bancaires : standards et réalité du terrain.
La DSP2 impose l'accès, mais pas un standard technique unique. Chaque banque expose « une interface ». Il en résulte des familles de standards régionaux, des interprétations divergentes et une qualité d'implémentation très inégale. Cette hétérogénéité a créé le marché des agrégateurs d'API.
| Standard | Zone | Caractéristiques |
|---|---|---|
| Berlin Group NextGenPSD2 | Europe continentale (Allemagne, Autriche, Nordiques, une grande partie de l'UE) | Le plus répandu ; spécification riche mais avec de nombreuses options, d'où des variantes par banque |
| STET | France (et Belgique en partie) | Standard porté par l'infrastructure interbancaire française ; adopté par les grandes banques françaises |
| Open Banking UK (OBIE) | Royaume-Uni | Le plus normatif : imposé aux 9 grandes banques (CMA9) avec conformance testing, d'où la meilleure qualité d'API d'Europe |
| Standards nationaux divers | Pologne (PolishAPI), Slovaquie, etc. | Fragmentation supplémentaire |
Ce que disent les RTS, et ce que vit l'intégrateur
- La banque doit offrir une interface dédiée (API) ou laisser les TPP utiliser l'interface client ; l'API dédiée doit être aussi disponible et performante que l'app de la banque, avec sandbox et documentation publiées.
- En cas de défaillance de l'API, un mécanisme de secours (fallback) est prévu, sauf exemption accordée par le régulateur national.
- Pour l'AIS, l'accès sans le client présent est limité (quatre consultations par jour) et le consentement doit être renouvelé par SCA, avec un délai porté de 90 à 180 jours par le règlement délégué (UE) 2022/2360.
- Dans la vraie vie : champs facultatifs remplis différemment selon les banques, gestion des SCA hétérogène, pannes non documentées, d'où des couches d'abstraction (Tink, Powens, Yapily…) qui normalisent des centaines de connexions bancaires.
POST /v1/payments/sepa-credit-transfers HTTP/1.1
Host: api.banque-exemple.fr
Authorization: Bearer eyJhbGciOi...
X-Request-ID: 7f3a1c2e-9b4d-4e8a-a1f0-2c5d6e7f8a9b
PSU-IP-Address: 203.0.113.42
TPP-Redirect-URI: https://psp-exemple.com/retour
{
"instructedAmount": { "currency": "EUR", "amount": "249.90" },
"creditorAccount": { "iban": "FR7630006000011234567890189" },
"creditorName": "Boutique Exemple SAS",
"remittanceInformationUnstructured": "Commande 2026-45812"
}
HTTP/1.1 201 Created
{
"transactionStatus": "RCVD",
"paymentId": "pay-8c21...",
"_links": {
"scaRedirect": { "href": "https://banque-exemple.fr/sca/8c21..." }
}
}Chapitre 3. Le parcours PIS : redirection, consentement, SCA.
Le paiement par initiation de virement (PIS) a un parcours très différent de la carte. Pas de numéro à saisir, mais une authentification chez sa banque. Toute la bataille de la conversion se joue dans la fluidité de cette redirection.
Trois modes d'authentification
- Redirection (dominant) : le client est envoyé vers l'interface de sa banque puis renvoyé au marchand. Sur mobile, la redirection app-to-app (checkout → app bancaire → retour) est déterminante pour la conversion.
- Découplé : le client valide dans son app bancaire sur notification push, sans quitter le canal d'origine, élégant mais au support inégal selon les banques.
- Embarqué : les identifiants transitent par l'interface du TPP. Historique, découragé, marginal.
Statuts : ce que « payé » veut dire (et ne veut pas dire)
| Statut | Signification | Lecture marchand |
|---|---|---|
| RCVD | Demande reçue | Rien n'est joué |
| ACCP / ACTC | Acceptée après contrôles techniques/profil | Le virement est lancé, pas encore réglé |
| ACSC | Règlement effectué | Fonds transférés, la vraie confirmation |
| RJCT | Rejetée | Provision insuffisante, SCA échouée, abandon… |
Côté conversion, les intégrateurs mesurent chaque marche du tunnel : taux de sélection de la banque, réussite de la redirection, réussite de la SCA, abandon au consentement. Un parcours PIS bien optimisé (app-to-app, banque présélectionnée, montant affiché tôt) peut approcher les taux de conversion de la carte enregistrée. Un parcours mal fait perd le client dans la redirection.
Chapitre 4. Verification of Payee : la confiance dans le bénéficiaire.
Le talon d'Achille du virement a toujours été le même. On paie un IBAN, pas un nom. En cas d'erreur de saisie ou de fraude au faux RIB (fournisseur, loyer, notaire…), l'argent part, et il est très difficile de le récupérer. La Verification of Payee (VoP), vérification de concordance entre l'IBAN et le nom du bénéficiaire, comble cette faille.
Comment ça marche
Avant validation du virement, la banque du payeur interroge celle du bénéficiaire (scheme VOP de l'EPC, réponse en quasi temps réel). Quatre issues sont possibles : match (concordance), close match (concordance approchante, avec affichage du nom exact détenu pour que le payeur décide), no match (discordance, avertissement fort), vérification impossible. Le payeur reste libre de poursuivre. Un no match ignoré peut déplacer la responsabilité vers lui. Pour les remises de masse des entreprises, des modalités d'exemption (opt-out) existent.
Une confusion doit être écartée. La VoP protège contre l'erreur et la fraude au bénéficiaire avant l'exécution. Elle ne crée pas de droit à remboursement après coup. Le Royaume-Uni est allé plus loin en imposant depuis octobre 2024 le remboursement obligatoire des victimes d'APP fraud, partagé 50/50 entre banque du payeur et banque du bénéficiaire, plafonné à 85 000 £. La future PSR européenne reprend partiellement ce modèle pour la fraude par usurpation.
Chapitre 5. A2A contre carte : le match, sans complaisance.
Le paiement A2A est souvent vendu comme « la fin de la carte ». La réalité est plus nuancée, car chaque rail a des forces structurelles. Voici la comparaison qui compte, critère par critère.
| Critère | Carte | A2A (PIS + SCT Inst) |
|---|---|---|
| Coût marchand | MSC en % : interchange (0,2/0,3 % plafonné en UE pour les particuliers) + frais de scheme + marge acquéreur ; plus cher hors UE et en B2B | Pas d'interchange ; tarification PISP souvent fixe ou dégressive par transaction, avantage croissant avec le panier |
| Disponibilité des fonds | Règlement J+1 à J+3 après compensation | Moins de 10 secondes en SCT Inst, 24/7 |
| Garantie de paiement | Autorisation de l'émetteur = forte garantie (hors fraude/litige) | Pas de garantie d'un tiers ; la certitude vient du règlement instantané avant expédition |
| Révocabilité | Chargeback : contestation organisée par les schemes (fraude, non-livraison…), souvent 120 jours | Virement irrévocable une fois exécuté ; le rappel (recall) dépend du bon vouloir du bénéficiaire |
| Litiges consommateur | Procédure normalisée, arbitrage réseau, forte protection | Protection contractuelle uniquement : remboursement volontaire du marchand, médiation, justice ; remboursement bancaire limité aux opérations non autorisées ou mal exécutées (art. 73 DSP2) |
| Expérience | One-click, carte enregistrée, wallets, réseau d'acceptation universel | Redirection bancaire à optimiser ; pas de données à saisir ; pas d'expiration ni de mise à jour de carte |
| Récurrent / abonnement | MIT et credentials-on-file, très rodés | Prélèvement SDD, VRP britanniques, mandats type Pix Automático, en construction en Europe |
| Fraude | Carte volée/compromise, test de cartes ; responsabilité encadrée | Pas de numéro volable ; risque déplacé vers la manipulation du payeur (APP fraud), atténué par la VoP |
Où l'A2A gagne économiquement
- Gros paniers : sur un panier de 800 €, une MSC à 1 % coûte 8 € ; un PIS facturé quelques dizaines de centimes change la marge.
- Paiements plafonnés par la carte : l'A2A n'a pas de plafond carte, utile pour l'automobile, le voyage, l'ameublement (le plafond de scheme du SCT Inst a d'ailleurs été supprimé en 2025, chaque PSP fixant ses limites).
- Trésorerie : fonds disponibles immédiatement, réconciliation par référence de virement.
- Pas de déclin technique : ni carte expirée, ni plafond mensuel carte atteint, utile en facturation et en recouvrement.
La carte reste devant sur l'achat d'impulsion en un clic, l'international hors SEPA, la location avec caution (pré-autorisation), les abonnements matures, et tous les cas où le client veut la protection du chargeback. Le scénario central pour l'Europe est une érosion sélective, plutôt qu'un remplacement. L'A2A prend les factures, les gros paniers et le rechargement de comptes. La carte garde l'impulsion et l'international.
Chapitre 6. Les acteurs : Tink, TrueLayer, Token.io, Powens… et Wero.
Le marché s'est structuré en trois étages : les plateformes d'open banking (connectivité AIS/PIS normalisée), les spécialistes du paiement A2A (checkout, conversion, remboursements), et désormais un scheme wallet paneuropéen. Wero veut porter l'A2A jusqu'au grand public.
| Acteur | Origine | Positionnement |
|---|---|---|
| Tink | Stockholm | Plateforme AIS + PIS paneuropéenne ; rachetée par Visa (≈ 1,8 Md€, finalisé en 2022), signal fort : les schemes carte achètent l'open banking |
| TrueLayer | Londres | Licorne du paiement A2A, très présente au Royaume-Uni et en Europe ; focalisée sur le Pay by Bank (e-commerce, trading, iGaming) |
| Token.io | Londres | Infrastructure A2A en marque blanche pour PSP et banques, qui motorise les offres Pay by Bank de nombreux acquéreurs |
| Powens | Paris (ex-Budget Insight) | Plateforme française d'open finance : agrégation, PIS, use cases comptables et crédit |
| Yapily | Londres | Connectivité API pure (infrastructure sans interface), forte couverture européenne |
| GoCardless | Londres | Champion du prélèvement (bank debit) ayant ajouté l'open banking (vérification, paiements instantanés) |
| Trustly / Brite | Suède | Pionniers nordiques du paiement par banque, forts sur le rechargement de comptes et l'iGaming |
| Plaid | États-Unis | Référence américaine de la connectivité bancaire, née du marché avant la règle CFPB 1033 |
| Volt | Londres | Orchestration de paiements temps réel multi-rails (Europe, Brésil…) |
Wero et EPI : l'A2A grand public à l'européenne
L'European Payments Initiative (EPI) réunit une quinzaine de grandes banques et deux acquéreurs : BNP Paribas, Crédit Agricole, BPCE, Société Générale, Deutsche Bank, ING et KBC notamment, ainsi que Nexi et Worldline. Elle avait d'abord visé un scheme carte européen, abandonné en 2022. Le pivot a donné un wallet de paiement compte à compte bâti sur le SCT Inst. Wero a été lancé en 2024 pour le P2P en Allemagne, en France (où il a remplacé Paylib) et en Belgique, distribué directement dans les apps bancaires. D'où un enrôlement massif, par dizaines de millions d'utilisateurs. EPI a racheté iDEAL et Payconiq (2023), si bien que les Pays-Bas et la Belgique migrent leurs schemes nationaux vers Wero. L'étape en cours depuis 2025-2026 est le paiement e-commerce, ouvert en Allemagne fin 2025, puis en Belgique (mars 2026) et en France (avril 2026), avant le paiement en magasin. Les dispositifs de protection acheteur y répondent à la faiblesse « litiges » de l'A2A.
Chapitre 7. Cas d'usage rentables, DSP3/FIDA et l'avenir.
Où l'open banking paie déjà
DSP3, PSR, FIDA : la refondation en cours
Le 28 juin 2023, la Commission européenne a proposé un paquet législatif en trois volets. La DSP3 et la PSR ont fait l'objet d'un accord politique le 27 novembre 2025, pour une application au plus tôt au second semestre 2028, tandis que FIDA reste en négociation en 2026. DSP3 est une directive recentrée sur l'agrément et la supervision des PSP, avec absorption du statut de monnaie électronique. La PSR est un règlement directement applicable qui reprend les règles de conduite. Elle couvre l'open banking, avec des exigences de performance des API renforcées et des tableaux de bord de consentement. Elle traite aussi la lutte contre la fraude par usurpation, avec extension de la responsabilité en cas de spoofing, et le partage de données de fraude entre PSP. FIDA (Financial Data Access) étend le partage de données au-delà des comptes de paiement, vers l'épargne, le crédit, les investissements et l'assurance, dans un cadre contractuel de schemes avec compensation financière pour les détenteurs de données. L'open banking devient alors l'open finance. Un temps menacé de retrait début 2025 lors de la revue du programme de travail de la Commission, FIDA a finalement été maintenu.