Consommer l'API

La description des services proposés ci-après n’est que purement fonctionnelle. Les aspects techniques sont répertoriés dans les sections "Cas d’usage" qui sont plus détaillées.

Vous devez aussi être familier avec la terminologie DSP2 et les abréviations utilisées. Vous pouvez également utiliser la foire aux questions (FAQ), l'assistant virtuel ou le glossaire.



➤ Introduction - consentement mixte AISP vs consentement full AISP

La norme STET propose deux modes de gestion du consentement : le consentement full AISP et le consentement mixte AISP. Seul le mode de consentement mixte AISP a été développé.

La cinématique ci-après décrit son implémentation et en particulier l'utilisation de la méthode PUT /consents qui vous permet de transmettre les comptes consentis par le client.

Elle résume comment s'enchaînent les appels aux différentes méthodes de l'API AISP, depuis la récupération du jeton, jusqu'à la récupération des comptes à vue et des cartes à débits différés ainsi que leurs soldes / transactions et leurs encours / facturettes respectivement, ainsi que la récupération de l'identité du client.



➤ Prérequis

En tant que TPP, vous devez être accrédité par l'autorité de contrôle prudentiel et de résolution (ACPR) pour le rôle d'agrégateur de compte ("AISP").

Pour accéder aux services de l’API d’information sur compte, vous devez récupérer un jeton d'accès OAUTH2 délivré par l'établissement bancaire du client en l’interrogeant avec vos credentials. Ce jeton est valable 90 jours.

Vous et l'établissement bancaire du client, vous devez vous authentifier mutuellement par échange des certificats Eidas QWAC.

Vous présentez ensuite votre jeton d'accès OAUTH2 pour consommer les services de l'API d'information sur compte.



➤ Agréger les données

Cas d'utilisation de l'API d'information sur compte :

 

L'AISP questionne le client (PSU) pour connaître le(s) établissement(s) bancaire(s) à partir du(des)quel(s) il souhaite consulter ses comptes

 



La méthode d'authentification supportée par l'établissement bancaire est le mode REDIRECT :

 

Autorisation d’accès en tant qu'AISP qui vous est donnée par le client connecté - récupération du jeton d'accès initial valable 90 jours et du refresh token

1. Le client est redirigé vers un écran d'identification proposé par son établissement bancaire et dans lequel il saisira son identifiant de banque à distance. Si l'AISP fournit l'identifiant de banque à distance du client dans sa requête, l'étape suivante est directement déclenchée.

2. Le client est redirigé vers un écran d'authentification forte proposé par son établissement bancaire pour valider son identité. La cinématique de cette étape dépend de la méthode d'authentification forte mise à disposition du client par l'établissement bancaire (SMS OTP, secur'pass, etc.). Elle dépend aussi de l'équipement du client sur lequel tourne l'APP de l'AISP utilisée par le client (PC ou mobile/tablette).

3. Le client est redirigé vers l'APP de l'AISP. L'AISP fournit lors de sa demande de récupération de jeton une URL call back : elle sera appelée par l'établissement bancaire.


 

Premier accès pour récupérer la liste des comptes à vue du client

Vous récupérez la liste des comptes à vue du client via un premier accès à la méthode GET /accounts en fournissant votre jeton d'accès pour ce client (cf. cas d'usage "Lister les comptes").

Vous n'avez pas accès aux informations suivantes :

  • les soldes des comptes à vue
  • les URI vers la méthode GET /accounts/balances
  • les URI vers la méthode GET /accounts/transactions
  • les URI vers la méthode GET /end-user-identity
  • l'URI vers la méthode GET /trustedBeneficiaries => ce service n'est pas disponible

 

Tant que vous n’aurez pas transmis les comptes consentis par le client via la méthode PUT /consents :

  • vous pourrez toujours récupérer la liste des comptes à vue du client via la méthode GET /accounts, mais vous n'aurez pas plus d'informations qu'au premier accès avec cette méthode
  • si vous essayez d'utiliser la méthode GET /accounts/transactions, la requête sera rejetée
  • si vous essayez d'utiliser la méthode GET /accounts/balances, la requête sera rejetée
  • si vous essayez d'utiliser la méthode GET /accounts/end-iser-identity, la requête sera rejetée
  • si vous essayer d'utiliser la méthode GET /trustedBeneficiaries, la requête sera rejetée => ce service n'est pas disponible pour les Banques Populaires : code erreur HTTP 501.


 

Le client sélectionne les comptes dont il consent à vous donner l'accès sur votre APP

Vous demandez au client de sélectionner les comptes à vue et les opérations possibles sur ses comptes (récupération des soldes, récupération des transactions, etc.).


 

Transmission du consentement

Vous nous transmettez la liste des comptes à vue que le client vous a consenti via la méthode PUT /consents en fournissant votre jeton d'accès pour ce client (cf. cas d'usage "Gérer le consentement"). Le code http 201 : created est retourné.

Vous précisez la liste des comptes à vue (IBAN) pour lesquels le client a consenti à transmettre les soldes et/ou les transactions

Vous précisez si le client a consenti à la récupération des bénéficiaires de confiance et à la récupération de son nom et prénom

Si vous avez déjà transmis les comptes consentis via la méthode PUT /consents, et que par la suite le client modifie son consentement, vous transmettrez la nouvelle liste des comptes consentis via la méthode PUT /consents, ce qui aura pour effet d'annuler et de remplacer le consentement précédent.

Si vous transmettez une liste vide de compte à vue consentis pour les soldes et pour les transactions et des indicateurs psuIdentity et trustedBeneficiaries à FAUX, cela revient à considérer qu'il n'y a pas de compte consenti.

Vous pouvez transmettre une liste de comptes à vue consentis sans avoir utilisé la méthode GET /accounts au préalable, dans le cas par exemple où le client vous a directement communiquer les IBAN de ses comptes à vue.


 

Second accès pour récupérer la liste des comptes à vue d'un client

Vous récupérez la liste des comptes à vue du client avec leur détail via un second accès à la méthode GET /accounts en fournissant votre jeton d'accès pour ce client (cf. cas d'usage "Lister les comptes").

Vous récupérez les informations suivantes :

  • les comptes à vue consentis
  • les cartes à débit différé adossées aux comptes à vue consentis
  • les soldes des comptes à vue consentis
  • les URI vers la méthode GET /accounts/balances pour les comptes à vue consentis
  • les URI vers la méthode GET /accounts/transactions pour les comptes à vue consentis
  • l'URI vers la méthode GET /end-user-identity si le flag "psuIdentity" = TRUE a été transmis via la méthode "PUT /consents"

Vous ne récupérez pas les informations suivantes :

  • l'URI vers la méthode GET /trustedBeneficiaries => ce service n'est pas disponible.

 

Récupération des soldes et des transactions des comptes à vue consentis, récupération des encours et des facturettes pour les cartes à débit différé adossées aux comptes à vue consentis

Pour chaque compte à vue consenti, vous récupérez les soldes du compte via un accès à la méthode GET /accounts/balances en fournissant votre jeton d'accès pour ce client (cf. cas d'usage "Obtenir les soldes") et en utilisant l'URI communiquée précédemment par la méthode GET /accounts pour le "_links" "balances"

Pour chaque carte à débit différé d'un compte à vue consenti, vous récupérez les encours de la carte via un accès à la méthode GET /accounts/balances en fournissant votre jeton d'accès pour ce client (cf. cas d'usage "Obtenir les soldes") et en utilisant l'URI communiquée précédemment par la méthode GET /accounts pour le "_links" "balances"        

Pour chaque compte à vue consenti, vous récupérez les transactions du compte via un accès à la méthode GET /accounts/transactions en fournissant votre jeton d'accès pour ce client (cf. cas d'usage "Obtenir les transactions") et en utilisant l'URI communiquée précédemment par la méthode GET /accounts pour le "_links" "transactions"

Pour chaque carte à débit différé d'un compte à vue consenti, vous récupérez les facturettes du compte via un accès à la méthode GET /accounts/transactions en fournissant votre jeton d'accès pour ce client (cf. cas d'usage "Obtenir les transactions") et en utilisant l'URI communiquée précédemment par la méthode GET /accounts pour le "_links" "transactions"

Si vous essayez d'utiliser la méthode GET /accounts/transactions pour un compte à vue non consenti ou pour une carte à débit différé adossée à un compte à vue non consenti, la requête sera rejetée

Si vous essayez d'utiliser la méthode GET /accounts/balances pour un compte à vue non consenti ou pour une carte à débit différé adossée à un compte à vue non consenti, la requête sera rejetée


 

Récupération de l’identité du client

Vous récupérez l’identité du PSU connecté via un accès à la m méthode GET /end-user-identity


 

Rafraîchissement des informations des comptes en batch

Pour chaque client et pour chaque compte à vue consenti ou carte à débit différé adossée à un compte à vue de ce client, vous pouvez rafraîchir les données du client (idem étapes "Second accès pour récupérer la liste des comptes à vue d'un client" et "Récupération des soldes et des transactions des comptes à vue consentis")

La limite est de 4 accès batchs quotidiens maximum par PSU pour GET accounts par page d’accès

La limite est de 4 accès batchs quotidiens maximum par PSU/compte pour GET balances

La limite est de 4 accès batchs quotidiens maximum par PSU/compte pour GET transactions par page d’accès

La limite est de 4 accès batchs quotidiens maximum par PSU/carte pour GET balances

La limite est de 4 accès batchs quotidiens maximum par PSU/carte pour GET transactions par page d’accès

La limite est de 4 accès batchs quotidiens maximum par PSU pour GET end-user-identity par page d’accès


 

Rafraîchissement des informations des comptes à la demande du client connecté sur son mobile, pour le client et pour chaque compte consenti de ce client

Pour chaque client et pour chaque compte à vue consenti ou carte à débit différé adossée à un compte à vue de ce client, le client peut demander à rafraîchir ses données depuis votre application (idem étapes "Second accès pour récupérer la liste des comptes à vue d'un client" et "Récupération des soldes et des transactions des comptes à vue consentis").

Pas de limitation d’accès pour ce cas à l'inverse des accès batch.


 

Si le jeton de 90 jours a expiré, vous devez faire une demande de rafraîchissement du jeton pour le client connecté

1. Avec le client connecté sur votre application, vous soumettez une requête de rafraîchissement du jeton pour ce client (cf. cas d'usage "Rafraîchir votre jeton")

2. Le client est redirigé vers un écran d'identification proposé par son établissement bancaire et dans lequel il saisira son identifiant de banque à distance. Si l'AISP fournit l'identifiant de banque à distance du client dans sa requête, l'étape suivante est directement déclenchée.

3. Le client est redirigé vers un écran d'authentification forte proposé par son établissement bancaire pour valider son identité. La cinématique de cette étape dépend de la méthode d'authentification forte mise à disposition du client par l'établissement bancaire (SMS OTP, secur'pass, etc.). Elle dépend aussi de l'équipement du client sur lequel tourne l'APP du PISP utilisée par le client (PC ou mobile/tablette).

4. Le client est redirigé vers l'APP de l'AISP. L'AISP fournit lors de sa demande de récupération de jeton une URL call back : elle sera appelée par l'établissement bancaire.

5. Vous récupérez le jeton rafraîchi pour ce client et vous pourrez à nouveau accéder aux données du client pour 90 jours avec les méthodes de cette API