La DSP2 est souvent vue côté business comme une simple « obligation pour les banques d'ouvrir des API ». Côté technique, c'est un assemblage non trivial : standards multiples, certificats électroniques qualifiés, OAuth2 renforcé, flux d'authentification asynchrones, et une fragmentation bien réelle entre banques.
Cet article donne une vision haut niveau mais précise de cette architecture, pour des CTO, PM techniques et développeurs qui doivent estimer un projet DSP2 — que ce soit pour intégrer un TPP partenaire ou pour exposer ses propres API. Pour la version business / produit, voir plutôt : Comprendre la PSD2 visuellement.
La stack DSP2 en une image
Un appel DSP2 traverse plusieurs couches qui ne servent pas à la même chose. Aucune n'est négociable.
À retenir : on ne se contente pas de signer ses requêtes en HTTPS classique. Le canal est mTLS (les deux parties s'authentifient), les payloads sont signés indépendamment, et l'autorisation passe par un OAuth2 strictement profilé.
Les standards d'API : pas un, mais trois
La directive impose d'ouvrir des API mais ne dicte pas le format. Trois standards se sont imposés en Europe.
| Standard | Couverture | Style |
|---|---|---|
| STET | France et Belgique | REST/JSON, basé ISO 20022 |
| Berlin Group | Majorité de l'UE | REST/JSON, le plus répandu |
| Open Banking UK | Royaume-Uni | Le plus mature, profil FAPI obligatoire |
Conséquences concrètes :
- Couvrir toute la France = supporter STET (BNP, Société Générale, BPCE, Crédit Agricole, La Banque Postale, etc.) plus quelques implémentations Berlin Group de banques en ligne.
- Scaler en Europe = ajouter Berlin Group avec les variantes par pays (l'Allemagne, l'Espagne, l'Italie ne respectent pas exactement la même version).
- En pratique, beaucoup d'équipes utilisent un agrégateur (Bridge, Tink, TrueLayer, Yapily) qui absorbe cette fragmentation contre une marge.
La chaîne de confiance : eIDAS, QWAC et QSealC
La DSP2 répond à une question simple : comment une banque sait-elle qu'un appel API vient bien d'un TPP agréé ? La réponse passe par les certificats électroniques qualifiés du règlement eIDAS TSP.
Deux certificats, deux usages :
- QWAC — sert à établir le canal mTLS. Il identifie le TPP au niveau transport. Pensez « carte d'identité ».
- QSealC — signe le contenu des requêtes (signature détachée). Il garantit l'intégrité et la non-répudiation du payload. Pensez « cachet de cire sur l'enveloppe ».
Les deux encodent les rôles PSD2 du TPP (AISP / PISP / CBPII). La banque vérifie dynamiquement que le certificat couvre bien l'opération demandée.
OAuth2 : matérialiser le consentement
Côté autorisation, c'est OAuth2 dans son flow Authorization Code + PKCE. Rien d'exotique, mais avec des contraintes :
- Le TPP construit l'URL d'autorisation et redirige le PSU vers la banque.
- La banque authentifie le PSU (login + SCA) puis affiche l'écran de consentement.
- Retour vers le TPP avec un code à usage unique.
- Échange du code contre un access token (court) et un refresh token (long, jusqu'à 180 jours côté AISP).
- Chaque appel API porte
Authorization: Bearer <token>et la signature QSealC et passe par mTLS.
Pour les profils plus stricts (FAPI 1.0 Advanced ou 2.0), on ajoute JWT / JWS / JWE pour les requêtes signées (JAR), et le binding du token au certificat client. C'est obligatoire au UK, en option / non imposé sur Berlin Group et STET.
Les trois flux SCA à supporter
Le moment où le PSU s'authentifie auprès de sa banque (la SCA) peut prendre trois formes, et c'est la banque qui choisit, pas vous. Couvrir tout le marché impose de gérer les trois — voir Flux SCA.
| Flux | Comment ça marche | Quand la banque le choisit |
|---|---|---|
| Redirect | Le PSU est redirigé sur la page web ou l'app de sa banque, puis revient. | Le standard de fait en France. |
| Decoupled | Push notification dans l'app bancaire, validation biométrique, polling côté TPP. | Néobanques, meilleure UX mobile. |
| Embedded | Le PSU saisit ses credentials dans l'interface du TPP qui les transmet. | Rare, déconseillé, souvent refusé. |
Pièges fréquents :
- En decoupled, certaines banques exigent un délai minimum entre le déclenchement et le polling, d'autres limitent le nombre d'appels et imposent un webhook.
- En redirect, les retours mobile via deep link sont source de bugs : prévoir un fallback web.
- Une seule SCA initiale, puis 180 jours d'accès AIS via refresh token sans nouvelle SCA — c'est le règlement EBA de 2022. Avant 2022, c'était 90 jours.
Le consentement : un objet à modéliser de bout en bout
Le consentement n'est pas une variable booléenne. C'est un objet stocké côté banque, avec :
- Un périmètre (comptes, types d'accès : balances, transactions, détails).
- Une fenêtre temporelle (jusqu'à 180 jours pour AIS, à usage unique pour PIS).
- Une fréquence (4 rafraîchissements par jour sans présence du PSU).
- Un état qui évolue dans le temps.
Côté implémentation, vous devez :
- Persister le consentId et le rattacher à votre PSU.
- Surveiller son état (poll + webhook si dispo).
- Déclencher un renouvellement avant expiration, idéalement avec une UX qui anticipe.
- Gérer la révocation côté banque : un consentement actif chez vous peut être éteint sans que vous le sachiez tant que vous n'appelez pas l'API.
Sécurité : mTLS, signature, idempotence
Trois exigences techniques structurent toute intégration DSP2.
- mTLS sur tous les appels back-channel. Le TPP présente son QWAC, la banque présente le sien.
- HTTP Signature des requêtes via QSealC : la signature couvre les en-têtes critiques et un hash du body. Indispensable côté PIS pour ne pas pouvoir nier une initiation de paiement.
- Idempotency key sur toutes les opérations PIS pour éviter les doubles paiements en cas de retry réseau.
À cela s'ajoute la gestion robuste des erreurs : codes HTTP, codes métier propres à chaque standard, rate limits, plages de maintenance bancaire. Aucune API ASPSP n'a 99,99 % de SLA contractuel.
Webhook ou polling ?
Pour suivre l'état d'un consentement, d'un paiement initié ou d'un flux SCA decoupled, deux mécanismes coexistent — voir Webhook / Polling.
- Polling : le TPP interroge l'API de statut à intervalles. Universel, mais coûteux et lent.
- Webhook : la banque appelle un endpoint du TPP. Réactif, mais peu de banques en exposent un fiable côté DSP2 EU.
En pratique, on combine : webhook quand disponible, polling de secours, avec backoff exponentiel.
Tester sans casser la prod
Trois environnements à connaître :
- Sandbox publique : ouverte, sans certificats eIDAS réels. Utile pour le POC.
- Sandbox certifiée : nécessite des certificats de test émis par un QTSP, parcours d'inscription par banque. C'est là qu'on valide l'intégration end-to-end.
- Production : nécessite l'agrément ACPR (ou équivalent), des certificats QWAC + QSealC valides, et l'enregistrement préalable auprès de chaque banque.
Le passage de la sandbox à la prod est rarement transparent : taille des payloads, latences, codes d'erreur, SCA réelle versus simulée — chaque banque réserve des surprises.
Et après ? Ce que DSP3 et PSR changent
Pour les équipes techniques, les évolutions à anticiper :
- Qualité d'API mesurée et publiée par les régulateurs : SLA, temps de réponse, taux d'erreur.
- Fin du screen scraping : plus de fallback hors API.
- Anti-fraude renforcée (notamment APP fraud) : VoP (Verification of Payee) sur les SEPA, partage d'indicateurs entre acteurs.
- Convergence FAPI plus que probable, alignement avec l'EUDI Wallet pour l'identité.
- FIDA : extension à de nouvelles familles de données (épargne, crédit, assurance). Le modèle technique est très inspiré de DSP2 mais avec des schémas de permissions plus fins.
Pour résumer
Construire ou intégrer une API DSP2, ce n'est pas « brancher une API REST de plus ». C'est :
- Choisir un ou plusieurs standards (STET, Berlin Group, éventuellement OB UK).
- Obtenir et faire vivre des certificats eIDAS (QWAC + QSealC).
- Implémenter OAuth2 avec PKCE, signature de requête et idempotence.
- Supporter les trois flux SCA côté UX et côté backend.
- Modéliser le consentement comme un objet de premier ordre, avec son cycle de vie.
- Gérer la fragmentation banque par banque — ou la sous-traiter à un agrégateur.
Pour la version produit / business, lisez Comprendre la PSD2 visuellement. Pour le vocabulaire complet, le glossaire Open Banking est indexé par catégorie.