Le PSR (DSP3) pour les équipes produit

À regarder en premier

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

• OB-DB-002PSR 43(2)(a)Partiel

  Ce que le tableau de bord affiche

  Pour chaque consentement en cours, le tableau de bord affiche le TPP, le compte, la finalité, la durée de validité avec la date du consentement, les catégories de données partagées et les dates d'accès aux données.

  STET 1.6.3 La banque connaît le TPP, les comptes, les types de données transmis par PUT /consents et les dates d'accès. Elle ne reçoit ni finalité, ni validité, ni date de consentement.

• OB-DB-004PSR 43(2)(c)Absent

  Rétablissement possible pendant 48 heures

  Dans les 48 heures qui suivent le retrait d'un consentement, l'utilisateur peut rétablir l'accès retiré.

  STET 1.6.3 Un refresh token révoqué ne revient pas, et la ressource de consentement de STET n'a pas d'état. Rétablir l'accès demande un nouveau parcours d'autorisation.

• OB-OBS-010PSR 44(1)(j)Hors spec

  Ajouter des étapes au parcours

  En redirection ou en découplé, l'authentification chez l'ASPSP ne peut pas ajouter d'étapes ou d'actions par rapport à la procédure équivalente du canal direct.

  STET 1.6.3 Le nombre d'écrans dépend de l'implémentation de chaque banque, pas de la spécification.

• OB-PIS-008PSR 36(4)(ha)Partiel

  Le PISP choisit la procédure d'authentification

  Quand l'ASPSP propose plusieurs procédures d'authentification, le PISP choisit celle qui est présentée au payeur.

  STET 1.6.3 Le PISP indique les approches qu'il accepte dans acceptedAuthenticationApproach et la banque retient celle qu'elle applique dans appliedAuthenticationApproach. Le texte donne le choix au PISP.

• OB-PIS-007PSR 36(4)(g)Absent

  Vérification du nom du titulaire avant l'initiation

  Le PISP peut vérifier le nom du titulaire du compte avant d'initier le paiement, que ce nom soit disponible ou non dans l'interface directe.

  STET 1.6.3 Le rôle PISP n'a aucune opération sur les comptes dans STET 1.6.3.

Pages du manuel STET 1.6.3 à lire

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

• 3. Prérequis et détails techniquesCitée par OB-AIS-004, OB-DB-003, OB-DB-004, OB-OBS-001, OB-OBS-008, OB-OBS-009, OB-OBS-011, OB-SCA-002, OB-SCA-003
• POST /payment-requestsCitée par OB-PIS-004, OB-PIS-005, OB-PIS-008, OB-PIS-009, OB-PIS-013, OB-OBS-002, OB-OBS-006, OB-OBS-007
• PUT /consentsCitée par OB-DB-002, OB-DB-004, OB-DB-007, OB-OBS-003
• GET /payment-requests/{paymentRequestResourceId}Citée par OB-PIS-006, OB-PIS-011, OB-PIS-012
• GET /accountsCitée par OB-AIS-001, OB-AIS-002
• PUT /payment-requests/{paymentRequestResourceId}Citée par OB-PIS-001, OB-PIS-003
• 8.2. Demande de paiement avec plusieurs instructions ayant des bénéficiaires différentsCitée par OB-PIS-004, OB-OBS-012
• BeneficiaryCitée par OB-PIS-005, OB-OBS-006
• AuthenticationApproachCitée par OB-OBS-001, OB-OBS-009
• 6.1. Récupération du contexte du PSUCitée par OB-SCA-002, OB-SCA-003
• AccountResourceCitée par OB-AIS-001
• GET /accounts/{accountResourceId}/ownersCitée par OB-AIS-002
• GET /accounts/{accountResourceId}/balancesCitée par OB-AIS-002
• GET /accounts/{accountResourceId}/transactionsCitée par OB-AIS-002
• Endpoints AISPCitée par OB-AIS-003
• 8.3. Demande d'ordres permanentsCitée par OB-PIS-001
• StandingOrderCharacteristicsCitée par OB-PIS-001
• 8.1. Demande de paiement avec plusieurs instructions ayant desCitée par OB-PIS-003
• GET /payment-requests/{paymentRequestResourceId}/transactionsCitée par OB-PIS-006
• Endpoints PISPCitée par OB-PIS-007
• SupplementaryDataCitée par OB-PIS-008
• PaymentInformationStatusCodeCitée par OB-PIS-011
• StatusReasonInformationCitée par OB-PIS-012
• AccessCitée par OB-DB-002
• 6.2. Transmission du consentementCitée par OB-DB-007
• PaymentRequestResourceCitée par OB-OBS-002
• AccountIdentificationCitée par OB-OBS-007
• POST /payment-requests/{paymentRequestResourceId}/confirmationCitée par OB-OBS-012

Fiches du glossaire

• AISP
• PISP
• PSU
• SCA
• VoP
• TPP