DSP2 et open banking : rôles, API, authentification forte et certificats eIDAS

Avant 2018, pour construire une application qui affichait tous les comptes bancaires d'un client au même endroit, on lui demandait son mot de passe de banque en ligne et on se connectait à sa place. Cela fonctionnait, c'était fragile, et c'était indéfendable du point de vue de la sécurité. La deuxième directive sur les services de paiement — la DSP2, ou PSD2 en anglais — a remplacé ce bricolage par un dispositif bien meilleur : des tiers agréés, un consentement explicite du client et des interfaces que les banques sont légalement tenues de fournir.

Le résultat est un écosystème d'API réglementé doté d'une propriété inhabituelle pour un ingénieur : la spécification de ce qui doit être proposé est un texte juridique, tandis que le comment a été laissé au marché, ce qui a produit plusieurs standards techniques concurrents au-dessus d'une seule obligation. Ce guide couvre les deux volets : le modèle réglementaire que vous devez respecter et la mécanique des API sur laquelle vous allez réellement coder.

Ce qui a changé, et pourquoi

La DSP2 poursuivait trois objectifs à la fois : davantage de concurrence dans les paiements, une meilleure sécurité et une base légale pour un accès aux comptes qui se pratiquait déjà de manière informelle. Sa disposition la plus lourde de conséquences est l'accès aux comptes : une banque qui tient un compte de paiement accessible en ligne doit permettre à un tiers agréé, agissant avec le consentement explicite du client, de consulter ce compte ou d'y initier un paiement — sans facturer ce droit et sans exiger de contrat entre la banque et le tiers.

Deux autres dispositions façonnent l'ingénierie au quotidien. L'authentification forte du client est devenue obligatoire pour la plupart des paiements électroniques et pour l'accès en ligne aux comptes. Et les règles de responsabilité ont nettement basculé en faveur du client : les opérations non autorisées sont remboursées rapidement, sauf si le prestataire démontre une fraude ou une négligence grave, ce qui explique pourquoi les banques investissent autant dans l'étape d'authentification.

« Open banking » est le terme de marché qui désigne l'écosystème né de la directive. Des cadres similaires existent ailleurs dans le monde, sur des bases juridiques différentes et avec des formes techniques comparables.

Les rôles réglementés

Quatre acronymes portent tout le modèle.

• ASPSP — Account Servicing Payment Service Provider, le prestataire gestionnaire du compte. C'est l'établissement qui tient le compte et qui est tenu d'exposer l'interface ; en pratique, la banque.
• AISP — Account Information Service Provider, le prestataire d'information sur les comptes. Il lit les données du compte : soldes, opérations, coordonnées du compte. Lecture seule : agrégation, gestion de budget, évaluation du crédit.
• PISP — Payment Initiation Service Provider, le prestataire d'initiation de paiement. Il donne l'ordre d'un paiement depuis le compte du client, avec son consentement. Il ne touche jamais aux fonds ; c'est la banque qui exécute.
• CBPII — Card Based Payment Instrument Issuer, l'émetteur d'instruments de paiement liés à une carte. Il pose à la banque une seule question fermée : ces fonds sont-ils disponibles en ce moment ? Ce rôle sert aux émetteurs de cartes dont les cartes puisent dans un compte tenu par un autre établissement.

Une même entreprise peut cumuler plusieurs rôles. Le client, l'utilisateur de services de paiement dans la langue du texte, est la seule partie habilitée à donner son consentement, et il peut le retirer à tout moment.

Le rôle de PISP mérite qu'on s'y arrête, car il change l'économie du e-commerce : un commerçant peut être payé par un virement de compte à compte initié au moment du paiement, sans réseau de cartes, sans commission d'interchange et — si un schéma instantané se trouve en dessous — avec des fonds irrévocables en quelques secondes. C'est un profil de risque réellement différent du flux carte décrit dans les paiements par carte, car un virement ne prévoit aucun mécanisme de chargeback.

L'authentification forte du client

L'authentification forte (SCA, pour Strong Customer Authentication) exige au moins deux éléments indépendants, pris dans trois catégories :

• Connaissance — quelque chose que seul l'utilisateur sait (un code secret, pas un mot mémorable envoyé par e-mail).
• Possession — quelque chose que seul l'utilisateur possède (un téléphone enregistré auquel une clé est liée, un token matériel, une carte à puce).
• Inhérence — quelque chose que l'utilisateur est (empreinte digitale, visage ou biométrie comportementale).

L'indépendance signifie que la compromission d'un élément ne doit pas compromettre les autres ; un code affiché dans le navigateur même qui porte la session ne remplit pas cette condition. Pour les paiements à distance s'ajoute une exigence, le lien dynamique : le code d'authentification doit être lié cryptographiquement au montant et au bénéficiaire précis, et toute modification de l'un ou de l'autre l'invalide. Cette seule règle élimine toute une catégorie d'attaques dans lesquelles une authentification approuvée est rejouée au profit d'un autre bénéficiaire.

Les normes techniques de réglementation définissent des exemptions que la banque peut appliquer, à ses propres risques :

Deux points sont régulièrement mal compris par les ingénieurs. Les exemptions sont demandées par le prestataire de paiement mais accordées par l'émetteur : votre code doit donc gérer un challenge qui arrive malgré tout. Et l'accès aux informations sur les comptes suit son propre rythme : SCA au premier accès, puis une période pendant laquelle le tiers peut rafraîchir les données sans la présence du client un nombre limité de fois par jour, puis une nouvelle authentification.

L'interface, et prouver qui vous êtes

Les banques peuvent exposer une interface dédiée — une API conçue pour cet usage — et la très grande majorité le fait. Les règles imposent des obligations qui ressemblent à un SLA rédigé par un régulateur : l'interface dédiée doit offrir une disponibilité et des performances au moins équivalentes à celles des canaux de la banque destinés à ses propres clients, publier ses statistiques de disponibilité et d'erreurs, fournir un dispositif de test avec un sandbox et permettre des tests à grande échelle avant son lancement. Lorsque l'interface dédiée d'une banque ne satisfait pas à ces exigences, un mécanisme de secours doit exister pour que les tiers puissent encore passer par le canal client ; les banques qui démontrent la conformité de leur interface peuvent être exemptées de le construire. C'est l'un des points que la législation qui prendra la suite entend simplifier.

L'identification repose sur des certificats eIDAS, émis par des prestataires de services de confiance qualifiés, qui portent en extension le numéro d'agrément du tiers et ses rôles :

• QWAC — Qualified Website Authentication Certificate, présenté lors d'une poignée de main TLS à authentification mutuelle. Il identifie l'appelant au niveau de la couche transport.
• QSEALC — Qualified Certificate for Electronic Seal, utilisé pour signer la requête HTTP elle-même, de sorte que le message reste imputable indépendamment du transport.

Tous deux encodent les attributs de rôle (PSP_AI, PSP_PI, PSP_IC), ce qui permet à une banque de vérifier l'agrément sans contrat bilatéral. Les certificats prouvent une identité ; ils ne valent pas autorisation sur un compte donné. C'est le consentement du client, recueilli via une redirection vers l'authentification propre à sa banque, qui ouvre l'accès — une séparation qui se calque naturellement sur le flux authorization code d'OAuth 2.0 qu'utilisent la plupart des implémentations, souvent avec OpenID Connect par-dessus.

Le paysage des standards

Une seule directive, plusieurs standards d'API, parce que le législateur a délibérément spécifié des résultats plutôt que des schémas.

Berlin Group NextGenPSD2 est le plus largement mis en œuvre en Europe continentale : REST et JSON, une ressource de consentement explicite et plusieurs approches de SCA (redirection, découplée, embarquée). Sa souplesse est aussi sa faiblesse — les banques choisissent des options différentes, si bien que « conforme Berlin Group » ne veut pas dire interchangeable sans adaptation.

UK Open Banking est issu d'une mesure corrective imposée par l'autorité de la concurrence britannique, et pas seulement de la DSP2, ce qui a permis une spécification plus stricte et gouvernée de manière centralisée, avec un annuaire, des tests de conformité et un profil OpenID Connect obligatoire. C'est donc le plus homogène des trois.

STET, né en France, est une spécification REST compacte, étroitement alignée sur le vocabulaire ISO 20022 pour les payloads d'initiation de paiement.

Conséquence pratique : même au sein d'un seul standard, attendez-vous à des particularités propres à chaque banque en matière de pagination, de profondeur d'historique des opérations, de sémantique de la date de comptabilisation, de gestion des devises et de codes d'erreur. Les équipes passent soit par un agrégateur, soit par une couche d'adaptateurs par banque derrière un modèle interne normalisé — un cas d'école de la couche anti-corruption, et des questions de routage et de quotas traitées dans la gestion d'API et les passerelles.

Un flux typique d'information sur les comptes

La forme est la même d'un standard à l'autre, même quand les détails divergent. On commence par créer un consentement qui décrit précisément ce qui est demandé :

POST /v1/consents HTTP/1.1
Host: api.examplebank.test
X-Request-ID: 1a2b3c4d-5e6f-4a7b-8c9d-0e1f2a3b4c5d
PSU-IP-Address: 203.0.113.14
TPP-Signature-Certificate: <base64 QSEALC>
Signature: keyId="SN=...,CA=...",algorithm="rsa-sha256",headers="digest x-request-id",signature="..."
Content-Type: application/json

{
  "access": { "balances": [ { "iban": "GB11ABCD12345678901234" } ],
              "transactions": [ { "iban": "GB11ABCD12345678901234" } ] },
  "recurringIndicator": true,
  "validUntil": "2026-12-07",
  "frequencyPerDay": 4,
  "combinedServiceIndicator": false
}

La banque répond avec un identifiant de consentement et un lien vers sa page d'authentification. Le client y est redirigé, s'authentifie avec la SCA auprès de sa propre banque, puis revient sur votre URI de redirection. Le consentement passe alors de received à valid, et les appels de données deviennent possibles :

GET /v1/accounts/3dc3d5b3-7023-4848-9853-f5400a64e80f/transactions?bookingStatus=booked&dateFrom=2026-08-01 HTTP/1.1
Consent-ID: 4a1e7a2c-88f1-4f2f-9a1e-8b7c6d5e4f30
Authorization: Bearer eyJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCJ9...

Une initiation de paiement suit le même schéma : créer la ressource de paiement, rediriger pour l'authentification, puis interroger le statut — RCVD, ACTC, ACSC et consorts, repris tels quels du vocabulaire ISO 20022 décrit dans les fondamentaux des systèmes de paiement.

Quelques principes de conception qui font gagner des semaines :

• Le consentement est une entité à part entière de votre domaine. Persistez son identifiant, son périmètre, son expiration, son statut et la fréquence quotidienne restante ; pilotez le parcours de renouvellement à partir de lui.
• Ne stockez jamais les identifiants bancaires des clients. Au-delà de l'interdiction, le simple fait de les recevoir fait de votre service une cible de phishing.
• Considérez chaque banque comme peu fiable. Timeouts, fenêtres de maintenance et données partielles sont la norme ; utilisez des circuit breakers, mettez en cache en signalant clairement l'ancienneté des données, et dégradez vers un « mis à jour le » plutôt que vers une page d'erreur.
• Journalisez pour l'audit, pas le contenu. Les régulateurs et les litiges exigent la preuve du consentement et de ce qui a été demandé ; le contenu des comptes dans les logs applicatifs est un passif.
• Minimisez les données. Demander quatre-vingt-dix jours d'historique sur tous les comptes quand un solde à jour suffit est à la fois un risque de conformité et un produit plus lent.

Où vont les règles

La Commission européenne a proposé un ensemble de textes pour prendre la suite : une directive révisée (couramment appelée DSP3) accompagnée d'un règlement sur les services de paiement d'application directe, ainsi qu'un cadre distinct pour un accès plus large aux données financières. La tendance va vers des obligations de performance des interfaces plus strictes, avec suppression de l'exigence d'interface de secours pour les banques qui les respectent, des règles plus claires sur l'authentification et sur la responsabilité en cas de fraude par usurpation d'identité, une supervision plus homogène, et le transfert du détail technique des transpositions nationales vers un texte d'application directe. Les textes bougent encore ; construisez pour les règles actuelles et gardez remplaçables les parties de votre architecture consacrées au consentement et à l'authentification.

Points clés à retenir

• La DSP2 oblige les banques à ouvrir les comptes de paiement aux tiers agréés agissant sur consentement explicite du client, en remplacement du screen scraping fondé sur le partage d'identifiants.
• Quatre rôles comptent : la banque gestionnaire du compte, le prestataire d'information sur les comptes, le prestataire d'initiation de paiement et le rôle de vérification des fonds destiné aux émetteurs de cartes.
• L'authentification forte du client exige deux facteurs indépendants et un lien dynamique entre montant et bénéficiaire ; les exemptions sont demandées par le prestataire mais accordées par la banque.
• Les certificats eIDAS identifient le tiers aux niveaux du transport et du message, tandis que des redirections de type OAuth portent le consentement du client.
• Berlin Group, UK Open Banking et STET répondent différemment à la même obligation, et les variations d'une banque à l'autre imposent une couche d'adaptateurs ou un agrégateur.
• Modélisez explicitement le consentement, attendez-vous aux expirations et aux interfaces capricieuses, minimisez les données demandées et gardez la couche d'authentification remplaçable à mesure qu'arrivent la DSP3 et le règlement sur les services de paiement.