El PSR (DSP3) para los equipos de producto

Por dónde empezar

Las cinco obligaciones que más cambian para este rol.

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

  Lo que muestra el panel

  Para cada consentimiento vigente, el panel muestra el TPP, la cuenta, la finalidad, el periodo de validez con la fecha del consentimiento, las categorías de datos compartidas y las fechas de acceso a los datos.

  STET 1.6.3 El banco conoce el TPP, las cuentas, los tipos de datos enviados con PUT /consents y las fechas de acceso. No recibe ni finalidad, ni validez, ni fecha de consentimiento.

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

  Restablecimiento posible durante 48 horas

  En las 48 horas siguientes a la retirada de un consentimiento, el usuario puede restablecer el acceso retirado.

  STET 1.6.3 Un refresh token revocado no vuelve, y el recurso de consentimiento de STET no tiene estado. Restablecer el acceso exige un nuevo recorrido de autorización.

• OB-OBS-010PSR 44(1)(j)Fuera de la spec

  Añadir pasos al recorrido

  En redirección o en desacoplado, la autenticación en el ASPSP no puede añadir pasos ni acciones respecto al procedimiento equivalente del canal directo.

  STET 1.6.3 El número de pantallas depende de la implementación de cada banco, no de la especificación.

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

  El PISP elige el procedimiento de autenticación

  Cuando el ASPSP ofrece varios procedimientos de autenticación, el PISP elige cuál se presenta al ordenante.

  STET 1.6.3 El PISP indica los enfoques que acepta en acceptedAuthenticationApproach y el banco elige el que aplica en appliedAuthenticationApproach. El texto da la elección al PISP.

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

  Verificación del nombre del titular antes de la iniciación

  El PISP puede verificar el nombre del titular de la cuenta antes de iniciar el pago, esté o no disponible ese nombre en la interfaz directa.

  STET 1.6.3 El rol PISP no tiene ninguna operación sobre cuentas en STET 1.6.3.

Páginas del manual STET 1.6.3 que conviene leer

Las páginas que citan estas obligaciones, de la más citada a la menos citada.

• 3. Requisitos previos y detalles técnicosCitada por 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-requestsCitada por 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 /consentsCitada por OB-DB-002, OB-DB-004, OB-DB-007, OB-OBS-003
• GET /payment-requests/{paymentRequestResourceId}Citada por OB-PIS-006, OB-PIS-011, OB-PIS-012
• GET /accountsCitada por OB-AIS-001, OB-AIS-002
• PUT /payment-requests/{paymentRequestResourceId}Citada por OB-PIS-001, OB-PIS-003
• 8.2. Solicitud de pago con múltiples instrucciones que tienen diferentes beneficiariosCitada por OB-PIS-004, OB-OBS-012
• BeneficiaryCitada por OB-PIS-005, OB-OBS-006
• AuthenticationApproachCitada por OB-OBS-001, OB-OBS-009
• 6.1. Recuperación del contexto del PSUCitada por OB-SCA-002, OB-SCA-003
• AccountResourceCitada por OB-AIS-001
• GET /accounts/{accountResourceId}/ownersCitada por OB-AIS-002
• GET /accounts/{accountResourceId}/balancesCitada por OB-AIS-002
• GET /accounts/{accountResourceId}/transactionsCitada por OB-AIS-002
• Endpoints AISPCitada por OB-AIS-003
• 8.3. Solicitud de órdenes permanentesCitada por OB-PIS-001
• StandingOrderCharacteristicsCitada por OB-PIS-001
• 8.1. Solicitud de pago con múltiples instrucciones que tienen diferentesCitada por OB-PIS-003
• GET /payment-requests/{paymentRequestResourceId}/transactionsCitada por OB-PIS-006
• Endpoints PISPCitada por OB-PIS-007
• SupplementaryDataCitada por OB-PIS-008
• PaymentInformationStatusCodeCitada por OB-PIS-011
• StatusReasonInformationCitada por OB-PIS-012
• AccessCitada por OB-DB-002
• 6.2. Reenvío del consentimientoCitada por OB-DB-007
• PaymentRequestResourceCitada por OB-OBS-002
• AccountIdentificationCitada por OB-OBS-007
• POST /payment-requests/{paymentRequestResourceId}/confirmationCitada por OB-OBS-012

Fichas del glosario

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