Le PSR (DSP3) pour les équipes API

À regarder en premier

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

• OB-DB-007PSR 43(3b)Partiel

  Le TPP transmet chaque consentement à l'ASPSP

  Le TPP informe l'ASPSP sans retard injustifié de chaque nouveau consentement, avec son nom, le compte, la finalité, la validité et les catégories de données, et l'ASPSP n'affiche que ce que le TPP lui a transmis.

  STET 1.6.3 PUT /consents transmet les comptes et les types de données, sans finalité, validité ni date. Rien n'existe pour les consentements PIS récurrents.

• OB-DB-008PSR 43(4)Partiel

  L'ASPSP informe le TPP de chaque changement

  L'ASPSP informe le TPP sans retard injustifié de tout changement fait par l'utilisateur dans le tableau de bord, retrait compris.

  STET 1.6.3 STET n'a ni statut de consentement à interroger ni notification. Un retrait révoque le refresh token, et l'AISP ne le découvre qu'avec l'erreur invalid_grant de son prochain rafraîchissement.

• OB-PIS-009PSR 36(4)(hc)Absent

  Compte, titulaires et devises visibles avant l'initiation

  Avant l'initiation, le PISP voit l'identifiant du compte, le nom des titulaires et les devises, quand l'utilisateur y a lui-même accès.

  STET 1.6.3 Le PISP peut seulement proposer un debtorAccount dans sa requête. Il ne lit rien sur le compte avant l'initiation.

• OB-PIS-011PSR 36(5)(b)Partiel

  Confirmation que le paiement sera exécuté

  L'ASPSP confirme au PISP dès que possible que le paiement a été ou sera exécuté, en tenant compte des ordres déjà en attente, sans lui communiquer ces ordres.

  STET 1.6.3 Le PISP lit par polling les statuts ISO 20022 (ACSP, ACSC, RJCT…), et la spécification, antérieure au texte, ne dit pas lequel vaut confirmation d'exécution.

• 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).

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-IF-003, OB-IF-008, OB-IF-009, OB-IF-017, OB-AIS-004, OB-DB-004, OB-DB-008, OB-OBS-001, OB-OBS-004, OB-OBS-005, OB-OBS-008, OB-OBS-009, OB-OBS-011, OB-SCA-001, OB-SCA-002, OB-SCA-003, OB-ENF-007
• POST /payment-requestsCitée par OB-IF-009, OB-PIS-002, OB-PIS-004, OB-PIS-005, OB-PIS-008, OB-PIS-009, OB-OBS-002, OB-OBS-006, OB-OBS-007
• PUT /consentsCitée par OB-AIS-006, OB-AIS-007, OB-DB-002, OB-DB-004, OB-DB-007, OB-DB-008, OB-OBS-003
• GET /payment-requests/{paymentRequestResourceId}Citée par OB-PIS-006, OB-PIS-010, OB-PIS-011, OB-PIS-012
• 6.1. Récupération du contexte du PSUCitée par OB-IF-009, OB-SCA-002, OB-SCA-003
• Endpoints AISPCitée par OB-IF-001, OB-AIS-003
• Endpoints PISPCitée par OB-IF-001, OB-PIS-007
• GET /accounts/{accountResourceId}/ownersCitée par OB-AIS-002, OB-AIS-006
• 6.2. Transmission du consentementCitée par OB-AIS-007, OB-DB-007
• 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
• Endpoints CBPIICitée par OB-IF-001
• ErrorModelCitée par OB-IF-008
• GET /accountsCitée par OB-AIS-002
• GET /accounts/{accountResourceId}/balancesCitée par OB-AIS-002
• GET /accounts/{accountResourceId}/transactionsCitée par OB-AIS-002
• 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
• SupplementaryDataCitée par OB-PIS-008
• FundsAvailabilityInformationCitée par OB-PIS-010
• POST /funds-confirmationsCitée par OB-PIS-010
• PaymentInformationStatusCodeCitée par OB-PIS-011
• StatusReasonInformationCitée par OB-PIS-012
• AccessCitée par OB-DB-002
• PaymentRequestResourceCitée par OB-OBS-002
• POST /registerCitée par OB-OBS-004
• AccountIdentificationCitée par OB-OBS-007
• POST /payment-requests/{paymentRequestResourceId}/confirmationCitée par OB-OBS-012

Fiches du glossaire

• STET
• OAuth2
• mTLS
• QWAC
• Flux SCA
• ISO 20022