2. Business Model

2.1. Actors and Roles

A PSD2 actor is either an entity or a physical person which can endorse one or several roles.

Most of the roles are defined in PSD2. However, some extra-roles have been specified for the purpose of the STET PSD2 API during the analysis phase of the project.

Within the following diagram:

Actors have cyan-coloured labels
Pure PSD2 roles have green-coloured labels
Specific STET PSD2 API roles have red-coloured labels

2.1.1. Payment Service User (PSU)

PSUs are the end-users of the services provided by TPPs and ASPSPs.

They are either physical persons or entities (organisations, companies, administrations…).

They do not interact directly with the STET PSD2 API.

A given PSU endorses at least one of the following roles:

Payment Account Owner (PAO) for one or several accounts held by one or several ASPSPs.
Payment Requester (PR) asking either for a payment or a coverage check.

2.1.2. API actors

2.1.2.1. Account Servicing Payment Service Provider (ASPSP)

These are Payment Service Providers (PSPs) which are in charge of holding payment accounts for their customers (PSU).

2.1.2.2. Third Party Provider (TPP)

These actors can intermediate between PSUs and ASPSPs, acting on behalf of a PAO or a PR.

On one hand, a given PAO may contract with a TPP in order to use the services provided by this TPP:

Account Information Services (AISP role) will allow the PAO to get information, through a single interface, about all of his/her accounts, whatever the ASPSP holding this account.
Card Based Payment Instrument Issuers (CBPII role) that will check the coverage of a given payment amount by the PSU's account.

On the other hand, a PR may also contract with a TPP that will provide the following services:

Payment Initiation Services for requesting a Payment Request approval by the PSU and requesting the subsequent execution through a Credit Transfer (PISP role).

2.1.3. Registration Authorities (RA)

RAs are in charge of registering and overviewing the PSD2 actors.

The registration information is the foundation on which each actor can rely in order to know:

Who is a given actor?
- Identity
- Contacts (business, legal, operational…)
- Insurance coverage
- Authentication media
  - X.509 eIDAS certificates (https://eur-lex.europa.eu/eli/reg/2014/910/oj ) • QWAC for TLS mutual authentication • QSEALC for content signature
  - Certification chain and services (revocation list, OCSP)
For which roles this actor has been registered
- AISP
- PISP
- CBPII
- ASPSP
Technical characteristics o APIs that are provided
- URLs that are to be used, for test or live processing.

Registration Authorities must keep track of changes for each actor in order to recover the full history of the actor.

2.2. Use cases

Some of the use cases that are listed below are directly implemented by the STET PSD2 API, for they rely on interactions between TPPs and ASPSPs.

Other uses cases are tagged as "NON-API" and are only described for global understanding purpose.

2.2.1. PAO uses cases (NON-API)

USE CASE (PAO)	DESCRIPTION	INTERACTIONS
Initiates ASPSP Contract	The user contracts with an ASPSP in order to use its services. This use case is likely extended by one or more occurrences of the "Requests Account Creation" use case	ASPSP
Requests Account Creation	The user asks the ASPSP to open a new payment account Requires a contract between the PAO and the ASPSP	ASPSP

USE CASE (PAO)	DESCRIPTION	INTERACTIONS
Requests Account Closure	The user asks the ASPSP to close an existing payment account This use case includes the "revokes Account/Operation Accreditation" use case for all operations on this account and for all granted TPP.	ASPSP TPP (indirectly)
Revokes ASPSP Contract	The user revokes the contract with the ASPSP This use case includes the "Requests Account Closure" use case for each account that is held by the ASPSP. This use case includes the "Revokes Account/Operation Accreditation" use case for all operations on each of these accounts and for all granted TPP.	ASPSP TPP (indirectly)
Initiates TPP Contract	The user contracts with a TPP having AISP and/or CBPII roles in order to use its service This use case is likely extended by one or more occurrences of the "Grants Account/Operation Accreditation" use case	TPP
Grants Account/Operation accreditation	The user allows the TPP to access a given set of operations on one of his/her payment accounts. Requires a contract between the PAO and the ASPSP, a contract between the PAO and the TPP and the registration of this PAO-TPP relationship by the ASPSP to enable the OAuth2 token management (cf. §3.4.2). Requires also that the capture and the execution of the accreditations are handled by the TPP (the further forwarding of these accreditations is an AISP use case and so out of scope of this use case: cf. §2.2.3).	ASPSP TPP
Revokes Account/Operation accreditation	The user asks the ASPSP to revoke the TPP access for a given set of operations on a given PAO account. Requires that the capture and the execution of the revocation are handled by the TPP.	ASPSP TPP

USE CASE (PAO)	DESCRIPTION	INTERACTIONS
Revokes TPP Contract	The user revokes the contract with the TPP. This use case includes the "Revokes Account/Operation Accreditation" for all grants given to the TPP, whatever the ASPSP. Since this cannot be automated, it is the PAO's duty to initiate all the relevant revocations with each ASPSP.	TPP ASPSP

2.2.2. Registration use cases (NON-API)

USE CASE (PSD2 ACTOR)	DESCRIPTION	INTERACTIONS
Initiates Registration	The user asks the RA for registration. This use case is likely extended by one or more occurrences of the "Manages Roles" use cases	RA other actors (indirectly)
Manages Roles	The user asks the RA to be referenced for a given set of roles. This use case can be replayed in order to reference or dereference any role.	RA other actors (indirectly)

USE CASE (PSD2 ACTOR)	DESCRIPTION	INTERACTIONS
Revokes registration	The user informs the RA that its registration is to be cancelled	RA other actors (indirectly)
Queries Registration Directory	The user queries the RA directory in order to get data on other PSD2 actors: roles, certificates…	RA other actors (indirectly)
Registers a PSD2 actor	The user registers a given PSD2 actor into its own Directory	None

2.2.3. AISP use cases

USE CASE (AISP)	DESCRIPTION	INTERACTIONS
Gets the PSU Context	The user queries the ASPSP in order to get the payment accounts that are eligible for the relevant PSU.	ASPSP
Sends the PSU consent to the ASPSP	Having captured the consent choices from the PSU, the user sends them to the ASPSP	ASPSP
*Gets Account Data*	This use case is abstract. Its purpose is to stress that the "Gets the PSU Context" is a prerequisite for all other use cases on a given account	none
Gets Account Owners	The user queries the ASPSP in order to get the owners on one given account.	ASPSP
Get Account Overdrafts	The user queries the ASPSP in order to get the overdraft that applies on one given account.	ASPSP
Gets Account Balance	The user queries the ASPSP in order to get the balance on one given account. The ASPSP can provide several balance computing's (Instant Balance, Accounting Balance…), each balance type being specified with an explicit label.	ASPSP
Gets List of Transactions	This use case is abstract and can be seen as the common interface for the two following uses-cases.	ASPSP
Gets Account Transaction History	The user queries the ASPSP in order to get all the transactions that have been committed to one given PSU account within a given range of value dates.	ASPSP

USE CASE (AISP)	DESCRIPTION	INTERACTIONS
Gets Account Transaction Forecast	The user queries the ASPSP in order to get all the transactions that are known by the ASPSP to be committed to a given PSU account	ASPSP
Gets connected PSU identity	The user queries the ASPSP in order to get the identity of the PSU on behalf of whom the AISP is connected	ASPSP
Gets trusted beneficiaries	The user queries the ASPSP in order to get all the beneficiaries that were registered as "trusted" par the PSU.	ASPSP

2.2.4. CBPII use cases

Checks funds coverage

USE CASE (CBPII)	DESCRIPTION	INTERACTIONS
Checks Funds Coverage	The user queries the ASPSP in order to check if a given transaction amount can be covered by one given PSU account	ASPSP

2.2.5. PISP uses cases

USE CASE (PISP)	DESCRIPTION	INTERACTIONS
Gets the Payment Request status	The user gets the status of the Payment Request from the ASPSP. This status embeds: - Information about the payment request and the execution of the subsequent Credit Transfers - Information about the effective booking of the payment instructions that are about to be executed - Information about the availability of funds for payment instructions that are about to be executed but are not effectively booked - Information about the trust given by the PSU to the beneficiaryof thepayment	ASPSP
Forwards the Payment Request status to the Creditor (Non-API)	The user informs the PR of the status of the Payment Request	PR (Creditor)

USE CASE (ASPSP)	DESCRIPTION	INTERACTIONS
Asks for PSU authentication (Non- API)	Provided the Payment Request is valid, the user asks the PAO in order to authenticate before execution of the relevant Payment Request or Cancellation Request	PSU(PAO)
Initiates the Credit Transfer (Non-API)	Provided the PAO has authenticated and the PISP has confirmed the payment request, the ASPSP initiates the relevant Credit Transfer.	Beneficiary's ASPSP (Creditor Agent)
Cancels a scheduled transfer (Non-API)	Provided the PAO has authenticated and the relevant transfers have not yet been executed, the ASPSP cancels the execution of the instructions that were specified by the PISP	None