2. Modèle métier

2.1. Acteurs et rôles

Un acteur PSD2 est soit une entité, soit une personne physique, qui peut endosser un ou plusieurs rôles.

La plupart des rôles sont définis dans la PSD2. Toutefois, certains rôles supplémentaires ont été spécifiés pour les besoins de l'API STET PSD2 durant la phase d'analyse du projet.

Dans le schéma suivant :

les acteurs ont des libellés de couleur cyan
les rôles purement PSD2 ont des libellés de couleur verte
les rôles spécifiques à l'API STET PSD2 ont des libellés de couleur rouge

2.1.1. Utilisateur de services de paiement (PSU)

Les PSU sont les utilisateurs finaux des services fournis par les TPP et les ASPSP.

Ce sont soit des personnes physiques, soit des entités (organisations, entreprises, administrations…).

Ils n'interagissent pas directement avec l'API STET PSD2.

Un PSU donné endosse au moins l'un des rôles suivants :

titulaire de compte de paiement (PAO) pour un ou plusieurs comptes détenus par un ou plusieurs ASPSP.
demandeur de paiement (PR) sollicitant soit un paiement, soit une vérification de couverture.

2.1.2. Acteurs de l'API

2.1.2.1. Prestataire de services de paiement gestionnaire de comptes (ASPSP)

Il s'agit des prestataires de services de paiement (PSP) chargés de tenir les comptes de paiement de leurs clients (PSU).

2.1.2.2. Prestataire tiers (TPP)

Ces acteurs peuvent s'intercaler entre les PSU et les ASPSP, en agissant pour le compte d'un PAO ou d'un PR.

D'une part, un PAO donné peut contracter avec un TPP afin d'utiliser les services fournis par ce TPP :

les services d'information sur les comptes (rôle AISP) permettront au PAO d'obtenir, via une interface unique, des informations sur l'ensemble de ses comptes, quel que soit l'ASPSP tenant ce compte.
les émetteurs d'instruments de paiement liés à une carte (rôle CBPII) qui vérifieront la couverture d'un montant de paiement donné par le compte du PSU.

D'autre part, un PR peut lui aussi contracter avec un TPP qui fournira les services suivants :

les services d'initiation de paiement pour demander l'approbation d'une demande de paiement par le PSU et demander l'exécution qui s'ensuit via un virement (rôle PISP).

2.1.3. Autorités d'enregistrement (RA)

Les RA sont chargées d'enregistrer et de superviser les acteurs PSD2.

Les informations d'enregistrement constituent le socle sur lequel chaque acteur peut s'appuyer afin de savoir :

Qui est un acteur donné ?
- Identité
- Contacts (métier, juridique, opérationnel…)
- Couverture d'assurance
- Moyens d'authentification
  - Certificats eIDAS X.509 (https://eur-lex.europa.eu/eli/reg/2014/910/oj ) • QWAC pour l'authentification mutuelle TLS • QSEALC pour la signature de contenu
  - Chaîne de certification et services associés (liste de révocation, OCSP)
Pour quels rôles cet acteur a été enregistré
- AISP
- PISP
- CBPII
- ASPSP
Caractéristiques techniques o APIs fournies
- URLs à utiliser, pour les traitements de test ou de production.

Les autorités d'enregistrement doivent conserver la trace des changements pour chaque acteur afin de pouvoir reconstituer l'historique complet de l'acteur.

2.2. Cas d'usage

Certains des cas d'usage listés ci-dessous sont directement implémentés par l'API STET PSD2, car ils reposent sur des interactions entre TPP et ASPSP.

D'autres cas d'usage sont marqués « NON-API » et ne sont décrits qu'à des fins de compréhension globale.

2.2.1. Cas d'usage du PAO (NON-API)

CAS D'USAGE (PAO)	DESCRIPTION	INTERACTIONS
Initie un contrat ASPSP	L'utilisateur contracte avec un ASPSP afin d'utiliser ses services. Ce cas d'usage est probablement étendu par une ou plusieurs occurrences du cas d'usage « Demande la création d'un compte »	ASPSP
Demande la création d'un compte	L'utilisateur demande à l'ASPSP d'ouvrir un nouveau compte de paiement Nécessite un contrat entre le PAO et l'ASPSP	ASPSP

CAS D'USAGE (PAO)	DESCRIPTION	INTERACTIONS
Demande la clôture d'un compte	L'utilisateur demande à l'ASPSP de clôturer un compte de paiement existant Ce cas d'usage inclut le cas d'usage « Révoque une accréditation de compte/opération » pour toutes les opérations sur ce compte et pour tous les TPP habilités.	ASPSP TPP (indirectement)
Révoque le contrat ASPSP	L'utilisateur révoque le contrat avec l' ASPSP Ce cas d'usage inclut le cas d'usage « Demande la clôture d'un compte » pour chaque compte détenu par l'ASPSP. Ce cas d'usage inclut le cas d'usage « Révoque une accréditation de compte/opération » pour toutes les opérations sur chacun de ces comptes et pour tous les TPP habilités.	ASPSP TPP (indirectement)
Initie un contrat TPP	L'utilisateur contracte avec un TPP ayant les rôles AISP et/ou CBPII afin d'utiliser son service Ce cas d'usage est probablement étendu par une ou plusieurs occurrences du cas d'usage « Accorde une accréditation de compte/opération »	TPP
Accorde une accréditation de compte/opération	L'utilisateur autorise le TPP à accéder à un ensemble donné d'opérations sur l'un de ses comptes de paiement. Nécessite un contrat entre le PAO et l'ASPSP, un contrat entre le PAO et le TPP et l'enregistrement de cette relation PAO-TPP par l' ASPSP pour permettre la gestion des jetons OAuth2 (cf. §3.4.2). Nécessite aussi que la capture et l' exécution des accréditations soient gérées par le TPP (la transmission ultérieure de ces accréditations est un cas d'usage AISP donc hors du périmètre de ce cas d'usage : cf. §2.2.3).	ASPSP TPP
Révoque une accréditation de compte/opération	L'utilisateur demande à l'ASPSP de révoquer l' accès du TPP pour un ensemble donné d' opérations sur un compte PAO donné. Nécessite que la capture et l'exécution de la révocation soient gérées par le TPP.	ASPSP TPP

CAS D'USAGE (PAO)	DESCRIPTION	INTERACTIONS
Révoque le contrat TPP	L'utilisateur révoque le contrat avec le TPP. Ce cas d'usage inclut « Révoque une accréditation de compte/opération » pour toutes les habilitations données au TPP, quel que soit l' ASPSP. Comme cela ne peut être automatisé, il incombe au PAO d' initier toutes les révocations pertinentes auprès de chaque ASPSP.	TPP ASPSP

2.2.2. Cas d'usage d'enregistrement (NON-API)

CAS D'USAGE (ACTEUR PSD2)	DESCRIPTION	INTERACTIONS
Initie l'enregistrement	L'utilisateur demande son enregistrement à la RA. Ce cas d'usage est probablement étendu par une ou plusieurs occurrences des cas d'usage « Gère les rôles »	RA autres acteurs (indirectement)
Gère les rôles	L'utilisateur demande à la RA d'être référencé pour un ensemble donné de rôles. Ce cas d'usage peut être rejoué afin de référencer ou de déréférencer un rôle.	RA autres acteurs (indirectement)

CAS D'USAGE (ACTEUR PSD2)	DESCRIPTION	INTERACTIONS
Révoque l'enregistrement	L'utilisateur informe la RA que son enregistrement doit être annulé	RA autres acteurs (indirectement)
Interroge l'annuaire d'enregistrement	L'utilisateur interroge l'annuaire de la RA afin d'obtenir des données sur les autres acteurs PSD2 : rôles, certificats…	RA autres acteurs (indirectement)
Enregistre un acteur PSD2	L'utilisateur enregistre un acteur PSD2 donné dans son propre annuaire	Aucune

2.2.3. Cas d'usage AISP

CAS D'USAGE (AISP)	DESCRIPTION	INTERACTIONS
Obtient le contexte du PSU	L'utilisateur interroge l'ASPSP afin d'obtenir les comptes de paiement éligibles pour le PSU concerné.	ASPSP
Envoie le consentement du PSU à l' ASPSP	Ayant capturé les choix de consentement du PSU, l'utilisateur les envoie à l' ASPSP	ASPSP
*Obtient les données du compte*	Ce cas d'usage est abstrait. Son objet est de souligner que « Obtient le contexte du PSU » est un prérequis pour tous les autres cas d'usage sur un compte donné	aucune
Obtient les titulaires du compte	L'utilisateur interroge l'ASPSP afin d'obtenir les titulaires d'un compte donné.	ASPSP
Obtient les découverts du compte	L'utilisateur interroge l'ASPSP afin d'obtenir le découvert applicable à un compte donné.	ASPSP
Obtient le solde du compte	L'utilisateur interroge l'ASPSP afin d'obtenir le solde d'un compte donné. L'ASPSP peut fournir plusieurs calculs de solde (solde instantané, solde comptable…), chaque type de solde étant identifié par un libellé explicite.	ASPSP
Obtient la liste des transactions	Ce cas d'usage est abstrait et peut être vu comme l'interface commune des deux cas d'usage suivants.	ASPSP
Obtient l'historique des transactions du compte	L'utilisateur interroge l'ASPSP afin d'obtenir toutes les transactions qui ont été comptabilisées sur un compte PSU donné dans une plage de dates de valeur donnée.	ASPSP

CAS D'USAGE (AISP)	DESCRIPTION	INTERACTIONS
Obtient les transactions prévisionnelles du compte	L'utilisateur interroge l'ASPSP afin d'obtenir toutes les transactions connues de l'ASPSP comme devant être comptabilisées sur un compte PSU donné	ASPSP
Obtient l'identité du PSU connecté	L'utilisateur interroge l'ASPSP afin d'obtenir l'identité du PSU pour le compte duquel l'AISP est connecté	ASPSP
Obtient les bénéficiaires de confiance	L'utilisateur interroge l'ASPSP afin d'obtenir tous les bénéficiaires qui ont été enregistrés comme « de confiance » par le PSU.	ASPSP

2.2.4. Cas d'usage CBPII

Vérifie la couverture des fonds

CAS D'USAGE (CBPII)	DESCRIPTION	INTERACTIONS
Vérifie la couverture des fonds	L'utilisateur interroge l'ASPSP afin de vérifier si un montant de transaction donné peut être couvert par un compte PSU donné	ASPSP

2.2.5. Cas d'usage PISP

CAS D'USAGE (PISP)	DESCRIPTION	INTERACTIONS
Obtient le statut de la demande de paiement	L'utilisateur obtient le statut de la demande de paiement auprès de l'ASPSP. Ce statut embarque : - des informations sur la demande de paiement et l'exécution des virements qui en découlent - des informations sur la comptabilisation effective des instructions de paiement sur le point d'être exécutées - des informations sur la disponibilité des fonds pour les instructions de paiement sur le point d'être exécutées mais non encore effectivement comptabilisées - des informations sur la confiance accordée par le PSU au bénéficiaire du paiement	ASPSP
Transmet le statut de la demande de paiement au créancier (Non-API)	L'utilisateur informe le PR du statut de la demande de paiement	PR (Créancier)

CAS D'USAGE (ASPSP)	DESCRIPTION	INTERACTIONS
Demande l'authentification du PSU (Non- API)	À condition que la demande de paiement soit valide, l'utilisateur demande au PAO de s'authentifier avant l'exécution de la demande de paiement ou de la demande d'annulation concernée	PSU(PAO)
Initie le virement (Non-API)	À condition que le PAO se soit authentifié et que le PISP ait confirmé la demande de paiement, l'ASPSP initie le virement concerné.	ASPSP du bénéficiaire (Agent du créancier)
Annule un virement programmé (Non-API)	À condition que le PAO se soit authentifié et que les virements concernés n'aient pas encore été exécutés, l'ASPSP annule l'exécution des instructions qui avaient été spécifiées par le PISP	Aucune