ofOpen Finance Guide
GlossaireSTETDSP3 et PSRBlogContact

Le PSR (DSP3) pour l'audit et le pentest

Le PSR écrit dans le règlement une bonne partie de ce qu'un audit d'interface dédiée doit contrôler. Les douze obstacles de l'article 44 se testent un par un, du nombre de SCA par rapport à l'appli de la banque jusqu'aux étapes ajoutées dans un parcours en redirection. La SCA change aussi de côté pour l'information sur les comptes. La banque ne peut plus l'exiger qu'au premier accès d'un AISP, hors soupçon de fraude, et c'est ensuite l'AISP qui la refait tous les 180 jours.

On teste d'abord l'identification du TPP et le cloisonnement des comptes, puisque l'AISP ne doit accéder qu'aux comptes que l'utilisateur a désignés. Après un retrait de consentement, le TPP doit cesser tout accès et supprimer les données, mais pas avant 48 heures, ce qui se vérifie chez lui. Un manquement aux articles 85 à 87 sur la SCA tombe sous les mêmes amendes que le chapitre open banking.

Par Tancrède Simonin, le 4 octobre 2026

À regarder en premier

Les cinq obligations qui changent le plus pour ce rôle.

  • OB-IF-017PSR 36(2)(a)Couvert

    Identification du TPP auprès de l'ASPSP

    L'interface permet aux AISP et aux PISP de s'identifier auprès de l'ASPSP, et ils le font à chaque initiation de paiement pour le PISP et à chaque session pour l'AISP.

    STET 1.6.3 STET identifie le TPP par un certificat eIDAS QWAC en mTLS et contrôle que le client_id correspond au numéro d'agrément du certificat. Le PSR ne dit pas par quel moyen le TPP s'identifie.

  • OB-IF-009PSR 36(2)(b)Couvert

    Authentification lancée par le TPP, session protégée

    L'interface permet au TPP de demander à l'ASPSP de lancer l'authentification sur la base du consentement de l'utilisateur, maintient la session entre les parties pendant toute l'authentification et protège l'intégrité et la confidentialité des identifiants et des codes d'authentification.

    STET 1.6.3 En redirection ou en découplé, le TPP déclenche l'authentification chez la banque, par l'autorisation OAuth2 pour l'AISP et par la requête de paiement pour le PISP, sur une connexion TLS à authentification mutuelle.

  • OB-AIS-007PSR 47(1)(d)Couvert

    L'AISP n'accède qu'aux comptes désignés

    L'AISP n'accède qu'aux informations des comptes désignés et de leurs opérations, avec des mécanismes qui empêchent tout autre accès, conformément au consentement de l'utilisateur.

    STET 1.6.3 PUT /consents liste, par type de donnée, les comptes que l'utilisateur a désignés, et la banque s'en sert pour limiter l'accès.

  • OB-SCA-002PSR 86(3)À revoir

    SCA de l'ASPSP au premier accès de l'AISP seulement

    Pour un AISP donné, l'ASPSP n'applique la SCA qu'au premier accès aux données du compte, et plus ensuite, sauf motif raisonnable de soupçonner une fraude.

    STET 1.6.3 Le Framework fait révoquer le refresh token de l'AISP quand le délai réglementaire entre deux SCA expire, ce qui renvoie l'utilisateur vers une SCA chez la banque. Après le premier accès, la banque ne peut plus l'imposer, et renouveler la SCA revient à l'AISP (OB-SCA-003).

  • OB-DB-006PSR 43(2b)Hors spec

    Après un retrait, le TPP arrête et supprime

    Après un retrait, le TPP cesse d'accéder aux données et de les utiliser, puis les supprime sans retard injustifié mais pas avant 48 heures, sauf si l'utilisateur choisit expressément qu'il les garde.

    STET 1.6.3 Le TPP ne peut appliquer cette règle que s'il apprend le retrait, ce que STET ne fait qu'indirectement (OB-DB-008).

Toutes les obligations pour ce rôle

13 obligations du registre concernent ce rôle. Obligations vérifiées le 4 octobre 2026.

Ouvrir cette vue dans le registre
13 sur 13

Interface dédiée(2)

Information sur les comptes(1)

Tableau de bord des consentements(1)

Obstacles interdits(7)

Authentification forte(2)

Pages du manuel STET 1.6.3 à lire

Les pages citées par ces obligations, de la plus citée à la moins citée.

Fiches du glossaire