2. Modelo de negócio

2.1. Atores e papéis

Um ator PSD2 é uma entidade ou uma pessoa física que pode assumir um ou vários papéis.

A maioria dos papéis está definida na PSD2. No entanto, alguns papéis adicionais foram especificados para as necessidades da API STET PSD2 durante a fase de análise do projeto.

No diagrama a seguir:

os atores têm rótulos na cor ciano
os papéis puramente PSD2 têm rótulos na cor verde
os papéis específicos da API STET PSD2 têm rótulos na cor vermelha

2.1.1. Usuário de serviços de pagamento (PSU)

Os PSU são os usuários finais dos serviços prestados pelos TPP e ASPSP.

São pessoas físicas ou entidades (organizações, empresas, administrações…).

Eles não interagem diretamente com a API STET PSD2.

Um determinado PSU assume pelo menos um dos seguintes papéis:

titular de conta de pagamento (PAO) de uma ou várias contas mantidas por um ou vários ASPSP.
solicitante de pagamento (PR) que solicita um pagamento ou uma verificação de cobertura.

2.1.2. Atores da API

2.1.2.1. Provedor de serviços de pagamento gestor de conta (ASPSP)

Trata-se dos provedores de serviços de pagamento (PSP) encarregados de manter as contas de pagamento de seus clientes (PSU).

2.1.2.2. Provedor terceiro (TPP)

Esses atores podem intermediar entre os PSU e os ASPSP, agindo por conta de um PAO ou de um PR.

Por um lado, um determinado PAO pode contratar um TPP para utilizar os serviços prestados por esse TPP:

os serviços de informação sobre contas (papel AISP) permitirão ao PAO obter, por meio de uma interface única, informações sobre todas as suas contas, qualquer que seja o ASPSP que mantém a conta.
os emissores de instrumentos de pagamento baseados em cartão (papel CBPII), que verificarão a cobertura de um determinado valor de pagamento pela conta do PSU.

Por outro lado, um PR também pode contratar um TPP que prestará os seguintes serviços:

os serviços de iniciação de pagamento para solicitar a aprovação de uma solicitação de pagamento pelo PSU e solicitar a execução subsequente por meio de uma transferência (papel PISP).

2.1.3. Autoridades de registro (RA)

As RA são encarregadas de registrar e supervisionar os atores PSD2.

As informações de registro constituem a base na qual cada ator pode se apoiar para saber:

Quem é um determinado ator?
- Identidade
- Contatos (de negócio, jurídico, operacional…)
- Cobertura de seguro
- Meios de autenticação
  - Certificados eIDAS X.509 (https://eur-lex.europa.eu/eli/reg/2014/910/oj ) • QWAC para a autenticação mútua TLS • QSEALC para a assinatura de conteúdo
  - Cadeia de certificação e serviços associados (lista de revogação, OCSP)
Para quais papéis esse ator foi registrado
- AISP
- PISP
- CBPII
- ASPSP
Características técnicas o APIs fornecidas
- URLs que devem ser utilizadas, para processos de teste ou de produção.

As autoridades de registro devem manter o rastreamento das mudanças de cada ator para poder reconstituir o histórico completo do ator.

2.2. Casos de uso

Alguns dos casos de uso listados a seguir são implementados diretamente pela API STET PSD2, pois se baseiam em interações entre TPP e ASPSP.

Outros casos de uso são marcados como «NON-API» e são descritos apenas para fins de compreensão global.

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

CASO DE USO (PAO)	DESCRIÇÃO	INTERAÇÕES
Inicia um contrato ASPSP	O usuário contrata um ASPSP para utilizar seus serviços. Este caso de uso provavelmente é estendido por uma ou mais ocorrências do caso de uso «Solicita a criação de uma conta»	ASPSP
Solicita a criação de uma conta	O usuário pede ao ASPSP que abra uma nova conta de pagamento Requer um contrato entre o PAO e o ASPSP	ASPSP

CASO DE USO (PAO)	DESCRIÇÃO	INTERAÇÕES
Solicita o encerramento de uma conta	O usuário pede ao ASPSP que encerre uma conta de pagamento existente Este caso de uso inclui o caso de uso «Revoga uma acreditação de conta/operação» para todas as operações desta conta e para todos os TPP habilitados.	ASPSP TPP (indiretamente)
Revoga o contrato ASPSP	O usuário revoga o contrato com o ASPSP Este caso de uso inclui o caso de uso «Solicita o encerramento de uma conta» para cada conta mantida pelo ASPSP. Este caso de uso inclui o caso de uso «Revoga uma acreditação de conta/operação» para todas as operações de cada uma dessas contas e para todos os TPP habilitados.	ASPSP TPP (indiretamente)
Inicia um contrato TPP	O usuário contrata um TPP que tem os papéis AISP e/ou CBPII para utilizar seu serviço Este caso de uso provavelmente é estendido por uma ou mais ocorrências do caso de uso «Concede uma acreditação de conta/operação»	TPP
Concede uma acreditação de conta/operação	O usuário autoriza o TPP a acessar um conjunto determinado de operações em uma de suas contas de pagamento. Requer um contrato entre o PAO e o ASPSP, um contrato entre o PAO e o TPP e o registro dessa relação PAO-TPP pelo ASPSP para permitir a gestão dos tokens OAuth2 (cf. §3.4.2). Requer também que a captura e a execução das acreditações sejam geridas pelo TPP (a transmissão posterior dessas acreditações é um caso de uso AISP e, portanto, fora do escopo deste caso de uso: cf. §2.2.3).	ASPSP TPP
Revoga uma acreditação de conta/operação	O usuário pede ao ASPSP que revogue o acesso do TPP para um conjunto determinado de operações em uma determinada conta PAO. Requer que a captura e a execução da revogação sejam geridas pelo TPP.	ASPSP TPP

CASO DE USO (PAO)	DESCRIÇÃO	INTERAÇÕES
Revoga o contrato TPP	O usuário revoga o contrato com o TPP. Este caso de uso inclui «Revoga uma acreditação de conta/operação» para todas as habilitações concedidas ao TPP, qualquer que seja o ASPSP. Como isso não pode ser automatizado, cabe ao PAO iniciar todas as revogações pertinentes junto a cada ASPSP.	TPP ASPSP

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

CASO DE USO (ATOR PSD2)	DESCRIÇÃO	INTERAÇÕES
Inicia o registro	O usuário solicita seu registro à RA. Este caso de uso provavelmente é estendido por uma ou mais ocorrências dos casos de uso «Gerencia os papéis»	RA outros atores (indiretamente)
Gerencia os papéis	O usuário pede à RA para ser referenciado para um conjunto determinado de papéis. Este caso de uso pode ser repetido para referenciar ou desreferenciar qualquer papel.	RA outros atores (indiretamente)

CASO DE USO (ATOR PSD2)	DESCRIÇÃO	INTERAÇÕES
Revoga o registro	O usuário informa à RA que seu registro deve ser cancelado	RA outros atores (indiretamente)
Consulta o diretório de registro	O usuário consulta o diretório da RA para obter dados sobre os demais atores PSD2 : papéis, certificados…	RA outros atores (indiretamente)
Registra um ator PSD2	O usuário registra um determinado ator PSD2 em seu próprio diretório	Nenhuma

2.2.3. Casos de uso AISP

CASO DE USO (AISP)	DESCRIÇÃO	INTERAÇÕES
Obtém o contexto do PSU	O usuário consulta o ASPSP para obter as contas de pagamento elegíveis para o PSU correspondente.	ASPSP
Envia o consentimento do PSU ao ASPSP	Tendo capturado as escolhas de consentimento do PSU, o usuário as envia ao ASPSP	ASPSP
*Obtém os dados da conta*	Este caso de uso é abstrato. Seu objetivo é destacar que «Obtém o contexto do PSU » é um pré-requisito para todos os outros casos de uso sobre uma determinada conta	nenhuma
Obtém os titulares da conta	O usuário consulta o ASPSP para obter os titulares de uma determinada conta.	ASPSP
Obtém os descobertos da conta	O usuário consulta o ASPSP para obter o descoberto aplicável a uma determinada conta.	ASPSP
Obtém o saldo da conta	O usuário consulta o ASPSP para obter o saldo de uma determinada conta. O ASPSP pode fornecer vários cálculos de saldo (saldo instantâneo, saldo contábil…), sendo cada tipo de saldo identificado por um rótulo explícito.	ASPSP
Obtém a lista de transações	Este caso de uso é abstrato e pode ser visto como a interface comum dos dois casos de uso a seguir.	ASPSP
Obtém o histórico de transações da conta	O usuário consulta o ASPSP para obter todas as transações que foram contabilizadas em uma determinada conta PSU dentro de um intervalo de datas de valor dado.	ASPSP

CASO DE USO (AISP)	DESCRIÇÃO	INTERAÇÕES
Obtém as transações previstas da conta	O usuário consulta o ASPSP para obter todas as transações conhecidas pelo ASPSP que serão contabilizadas em uma determinada conta PSU	ASPSP
Obtém a identidade do PSU conectado	O usuário consulta o ASPSP para obter a identidade do PSU em nome do qual o AISP está conectado	ASPSP
Obtém os beneficiários de confiança	O usuário consulta o ASPSP para obter todos os beneficiários que foram registrados como «de confiança» pelo PSU.	ASPSP

2.2.4. Casos de uso CBPII

Verifica a cobertura de fundos

CASO DE USO (CBPII)	DESCRIÇÃO	INTERAÇÕES
Verifica a cobertura de fundos	O usuário consulta o ASPSP para verificar se um determinado valor de transação pode ser coberto por uma determinada conta PSU	ASPSP

2.2.5. Casos de uso PISP

CASO DE USO (PISP)	DESCRIÇÃO	INTERAÇÕES
Obtém o status da solicitação de pagamento	O usuário obtém o status da solicitação de pagamento junto ao ASPSP. Esse status incorpora: - informações sobre a solicitação de pagamento e a execução das transferências subsequentes - informações sobre a contabilização efetiva das instruções de pagamento que estão prestes a ser executadas - informações sobre a disponibilidade de fundos para as instruções de pagamento que estão prestes a ser executadas, mas ainda não foram efetivamente contabilizadas - informações sobre a confiança concedida pelo PSU ao beneficiário do pagamento	ASPSP
Encaminha o status da solicitação de pagamento ao credor (Non-API)	O usuário informa o PR sobre o status da solicitação de pagamento	PR (Credor)

CASO DE USO (ASPSP)	DESCRIÇÃO	INTERAÇÕES
Solicita a autenticação do PSU (Non- API)	Desde que a solicitação de pagamento seja válida, o usuário pede ao PAO que se autentique antes da execução da solicitação de pagamento ou da solicitação de cancelamento correspondente	PSU(PAO)
Inicia a transferência (Non-API)	Desde que o PAO tenha se autenticado e o PISP tenha confirmado a solicitação de pagamento, o ASPSP inicia a transferência correspondente.	ASPSP do beneficiário (Agente do credor)
Cancela uma transferência programada (Non-API)	Desde que o PAO tenha se autenticado e as transferências correspondentes ainda não tenham sido executadas, o ASPSP cancela a execução das instruções que haviam sido especificadas pelo PISP	Nenhuma