2. Modelo de negocio

2.1. Actores y roles

Un actor PSD2 es una entidad o una persona física que puede asumir uno o varios roles.

La mayoría de los roles están definidos en la PSD2. No obstante, se han especificado algunos roles adicionales para las necesidades de la API STET PSD2 durante la fase de análisis del proyecto.

En el siguiente diagrama:

los actores tienen etiquetas de color cian
los roles puramente PSD2 tienen etiquetas de color verde
los roles específicos de la API STET PSD2 tienen etiquetas de color rojo

2.1.1. Usuario de servicios de pago (PSU)

Los PSU son los usuarios finales de los servicios prestados por los TPP y los ASPSP.

Son personas físicas o entidades (organizaciones, empresas, administraciones…).

No interactúan directamente con la API STET PSD2.

Un PSU determinado asume al menos uno de los siguientes roles:

titular de cuenta de pago (PAO) de una o varias cuentas mantenidas por uno o varios ASPSP.
solicitante de pago (PR) que solicita un pago o una comprobación de cobertura.

2.1.2. Actores de la API

2.1.2.1. Proveedor de servicios de pago gestor de cuenta (ASPSP)

Se trata de los proveedores de servicios de pago (PSP) encargados de mantener las cuentas de pago de sus clientes (PSU).

2.1.2.2. Proveedor tercero (TPP)

Estos actores pueden intermediar entre los PSU y los ASPSP, actuando por cuenta de un PAO o de un PR.

Por un lado, un PAO determinado puede contratar con un TPP para utilizar los servicios prestados por dicho TPP:

los servicios de información sobre cuentas (rol AISP) permitirán al PAO obtener, a través de una interfaz única, información sobre todas sus cuentas, sea cual sea el ASPSP que mantiene la cuenta.
los emisores de instrumentos de pago basados en tarjeta (rol CBPII), que comprobarán la cobertura de un importe de pago determinado por la cuenta del PSU.

Por otro lado, un PR también puede contratar con un TPP que prestará los siguientes servicios:

los servicios de iniciación de pagos para solicitar la aprobación de una solicitud de pago por parte del PSU y solicitar la ejecución posterior mediante una transferencia (rol PISP).

2.1.3. Autoridades de registro (RA)

Las RA se encargan de registrar y supervisar a los actores PSD2.

La información de registro constituye la base en la que cada actor puede apoyarse para saber:

¿Quién es un actor determinado?
- Identidad
- Contactos (de negocio, jurídico, operativo…)
- Cobertura de seguro
- Medios de autenticación
  - Certificados eIDAS X.509 (https://eur-lex.europa.eu/eli/reg/2014/910/oj ) • QWAC para la autenticación mutua TLS • QSEALC para la firma de contenido
  - Cadena de certificación y servicios asociados (lista de revocación, OCSP)
Para qué roles se ha registrado este actor
- AISP
- PISP
- CBPII
- ASPSP
Características técnicas o APIs proporcionadas
- URLs que deben utilizarse, para procesos de prueba o de producción.

Las autoridades de registro deben llevar un seguimiento de los cambios de cada actor para poder reconstruir el historial completo del actor.

2.2. Casos de uso

Algunos de los casos de uso enumerados a continuación están directamente implementados por la API STET PSD2, ya que se basan en interacciones entre TPP y ASPSP.

Otros casos de uso están marcados como «NON-API» y solo se describen con fines de comprensión global.

2.2.1. Casos de uso del PAO (NON-API)

CASO DE USO (PAO)	DESCRIPCIÓN	INTERACCIONES
Inicia un contrato ASPSP	El usuario contrata con un ASPSP para utilizar sus servicios. Este caso de uso probablemente se amplía con una o varias ocurrencias del caso de uso «Solicita la creación de una cuenta»	ASPSP
Solicita la creación de una cuenta	El usuario pide al ASPSP que abra una nueva cuenta de pago Requiere un contrato entre el PAO y el ASPSP	ASPSP

CASO DE USO (PAO)	DESCRIPCIÓN	INTERACCIONES
Solicita el cierre de una cuenta	El usuario pide al ASPSP que cierre una cuenta de pago existente Este caso de uso incluye el caso de uso «Revoca una acreditación de cuenta/operación» para todas las operaciones de esta cuenta y para todos los TPP habilitados.	ASPSP TPP (indirectamente)
Revoca el contrato ASPSP	El usuario revoca el contrato con el ASPSP Este caso de uso incluye el caso de uso «Solicita el cierre de una cuenta» para cada cuenta mantenida por el ASPSP. Este caso de uso incluye el caso de uso «Revoca una acreditación de cuenta/operación» para todas las operaciones de cada una de estas cuentas y para todos los TPP habilitados.	ASPSP TPP (indirectamente)
Inicia un contrato TPP	El usuario contrata con un TPP que tiene los roles AISP y/o CBPII para utilizar su servicio Este caso de uso probablemente se amplía con una o varias ocurrencias del caso de uso «Concede una acreditación de cuenta/operación»	TPP
Concede una acreditación de cuenta/operación	El usuario autoriza al TPP a acceder a un conjunto determinado de operaciones en una de sus cuentas de pago. Requiere un contrato entre el PAO y el ASPSP, un contrato entre el PAO y el TPP y el registro de esta relación PAO-TPP por el ASPSP para permitir la gestión de los tokens OAuth2 (cf. §3.4.2). Requiere también que la captura y la ejecución de las acreditaciones sean gestionadas por el TPP (la transmisión posterior de estas acreditaciones es un caso de uso AISP, por lo que queda fuera del alcance de este caso de uso: cf. §2.2.3).	ASPSP TPP
Revoca una acreditación de cuenta/operación	El usuario pide al ASPSP que revoque el acceso del TPP para un conjunto determinado de operaciones en una cuenta PAO determinada. Requiere que la captura y la ejecución de la revocación sean gestionadas por el TPP.	ASPSP TPP

CASO DE USO (PAO)	DESCRIPCIÓN	INTERACCIONES
Revoca el contrato TPP	El usuario revoca el contrato con el TPP. Este caso de uso incluye «Revoca una acreditación de cuenta/operación» para todas las habilitaciones concedidas al TPP, sea cual sea el ASPSP. Como esto no puede automatizarse, corresponde al PAO iniciar todas las revocaciones pertinentes ante cada ASPSP.	TPP ASPSP

2.2.2. Casos de uso de registro (NON-API)

CASO DE USO (ACTOR PSD2)	DESCRIPCIÓN	INTERACCIONES
Inicia el registro	El usuario solicita su registro a la RA. Este caso de uso probablemente se amplía con una o varias ocurrencias de los casos de uso «Gestiona los roles»	RA otros actores (indirectamente)
Gestiona los roles	El usuario pide a la RA ser referenciado para un conjunto determinado de roles. Este caso de uso puede repetirse para referenciar o eliminar la referencia de cualquier rol.	RA otros actores (indirectamente)

CASO DE USO (ACTOR PSD2)	DESCRIPCIÓN	INTERACCIONES
Revoca el registro	El usuario informa a la RA de que su registro debe cancelarse	RA otros actores (indirectamente)
Consulta el directorio de registro	El usuario consulta el directorio de la RA para obtener datos sobre los demás actores PSD2 : roles, certificados…	RA otros actores (indirectamente)
Registra un actor PSD2	El usuario registra un actor PSD2 determinado en su propio directorio	Ninguna

2.2.3. Casos de uso AISP

CASO DE USO (AISP)	DESCRIPCIÓN	INTERACCIONES
Obtiene el contexto del PSU	El usuario consulta al ASPSP para obtener las cuentas de pago elegibles para el PSU correspondiente.	ASPSP
Envía el consentimiento del PSU al ASPSP	Tras haber capturado las decisiones de consentimiento del PSU, el usuario las envía al ASPSP	ASPSP
*Obtiene los datos de la cuenta*	Este caso de uso es abstracto. Su propósito es subrayar que «Obtiene el contexto del PSU » es un requisito previo para todos los demás casos de uso sobre una cuenta determinada	ninguna
Obtiene los titulares de la cuenta	El usuario consulta al ASPSP para obtener los titulares de una cuenta determinada.	ASPSP
Obtiene los descubiertos de la cuenta	El usuario consulta al ASPSP para obtener el descubierto aplicable a una cuenta determinada.	ASPSP
Obtiene el saldo de la cuenta	El usuario consulta al ASPSP para obtener el saldo de una cuenta determinada. El ASPSP puede proporcionar varios cálculos de saldo (saldo instantáneo, saldo contable…), identificándose cada tipo de saldo con una etiqueta explícita.	ASPSP
Obtiene la lista de transacciones	Este caso de uso es abstracto y puede verse como la interfaz común de los dos casos de uso siguientes.	ASPSP
Obtiene el historial de transacciones de la cuenta	El usuario consulta al ASPSP para obtener todas las transacciones que se han contabilizado en una cuenta PSU determinada dentro de un rango de fechas de valor dado.	ASPSP

CASO DE USO (AISP)	DESCRIPCIÓN	INTERACCIONES
Obtiene las transacciones previstas de la cuenta	El usuario consulta al ASPSP para obtener todas las transacciones conocidas por el ASPSP que se contabilizarán en una cuenta PSU determinada	ASPSP
Obtiene la identidad del PSU conectado	El usuario consulta al ASPSP para obtener la identidad del PSU por cuenta del cual está conectado el AISP	ASPSP
Obtiene los beneficiarios de confianza	El usuario consulta al ASPSP para obtener todos los beneficiarios que fueron registrados como «de confianza» por el PSU.	ASPSP

2.2.4. Casos de uso CBPII

Comprueba la cobertura de fondos

CASO DE USO (CBPII)	DESCRIPCIÓN	INTERACCIONES
Comprueba la cobertura de fondos	El usuario consulta al ASPSP para comprobar si un importe de transacción determinado puede estar cubierto por una cuenta PSU determinada	ASPSP

2.2.5. Casos de uso PISP

CASO DE USO (PISP)	DESCRIPCIÓN	INTERACCIONES
Obtiene el estado de la solicitud de pago	El usuario obtiene el estado de la solicitud de pago del ASPSP. Este estado incluye: - información sobre la solicitud de pago y la ejecución de las transferencias posteriores - información sobre la contabilización efectiva de las instrucciones de pago que están a punto de ejecutarse - información sobre la disponibilidad de fondos para las instrucciones de pago que están a punto de ejecutarse pero aún no se han contabilizado efectivamente - información sobre la confianza otorgada por el PSU al beneficiario del pago	ASPSP
Transmite el estado de la solicitud de pago al acreedor (Non-API)	El usuario informa al PR del estado de la solicitud de pago	PR (Acreedor)

CASO DE USO (ASPSP)	DESCRIPCIÓN	INTERACCIONES
Solicita la autenticación del PSU (Non- API)	Siempre que la solicitud de pago sea válida, el usuario pide al PAO que se autentique antes de la ejecución de la solicitud de pago o de la solicitud de cancelación correspondiente	PSU(PAO)
Inicia la transferencia (Non-API)	Siempre que el PAO se haya autenticado y el PISP haya confirmado la solicitud de pago, el ASPSP inicia la transferencia correspondiente.	ASPSP del beneficiario (Agente del acreedor)
Cancela una transferencia programada (Non-API)	Siempre que el PAO se haya autenticado y las transferencias correspondientes aún no se hayan ejecutado, el ASPSP cancela la ejecución de las instrucciones que habían sido especificadas por el PISP	Ninguna