Natixis – Information sur compte (Norme STET V1.6.2)

Accédez aux données autorisées par les clients

Description des services proposés [NORME STET V1.6.2]

Récupérer son jeton d’autorisation

Le client (PSU) doit indiquer l’identité de sa banque teneuse de compte à l’AISP.

L’AISP initie ensuite la séquence de récupération du jeton d’accès OAUTH2 en redirigeant le client via son navigateur internet vers l’infrastructure informatique d’autorisation de la banque teneuse de compte.

La banque teneuse de compte (ASPSP) va :

• Identifier et authentifier le client PSU par l’une des méthodes d’authentification forte proposée préalablement au client

• Demander le consentement au client par l’intermédiaire d’écrans de saisie d’informations

Une fois ces vérifications effectuées et si elles sont concluantes, la banque va rediriger le client vers le site de l’AISP en utilisant les URL de « call-back » (redirection) transmises précédemment ainsi que certains paramètres.

L’AISP va pouvoir alors demander directement à la banque le jeton d’accès OAUTH2 via un appel de type POST.

La banque teneuse de compte (ASPSP) va alors :

• Identifier l’AISP et l’authentifier en tant que TPP via le certificat X509 mis à disposition pour sécuriser l’échange mutuel

• Effectuer des vérifications liées au profil du TPP (validité des certificats eIDAS et du rôle AISP dans le référentiel de place, non révocation de l’agrément DSP2, etc…)

Une fois ces vérifications effectuées et si elles sont concluantes, la banque va renvoyer une réponse HTTP 200 (OK) à l’AISP avec un certain nombre de données.

Dès que le jeton d’accès OAUTH2 délivré par la banque a été récupéré par l’AISP, celui-ci pourra le présenter pour pouvoir consommer les ressources de l’API.

NB : vous pouvez vous référer au cas d’usage « Comment récupérer son jeton d’accès OAUTH2 ? » pour plus de détails.

Obtenir la liste des comptes à vue d’un client

Description

Cet appel permet de récupérer la liste des comptes à vue du PSU pour lequel l’AISP est connecté.

Chaque compte est retourné avec les liens permettant de consulter les soldes ou les encours ainsi que les transactions associées à celui-ci.

L’identifiant de ressource fourni pour chaque compte servira de paramètre pour les requête de récupération de soldes et de transactions.

Une pagination de la liste renvoyée peut être faite si le nombre de comptes est élevé, dans ce cas des liens donnant accès à la première page,

la précédente, la suivante et la dernière page faciliteront la consultation des résultats.

Les accès à cette méthode sont limités à 4 accès batch maximum par jour calendaire, pour un client ou pour un TPP, hors pagination.

Prérequis

Le TPP est présent dans le référentiel des autorisations avec un rôle d’AISP.

Le TPP et le PSU sont liés à l’ASPSP par un contrat.

Lors de cette étape, un code d’autorisation OAUTH2 (ou jeton/token d’accès) a été délivré au TPP par l’ASPSP.

Le TPP et l’ASPSP se sont mutuellement contrôlés et authentifiés.

Le TPP a fourni son jeton d’accès de façon à ce que l’ASPSP puisse identifier le PSU et récupérer le contexte associé.

L’ASPSP a pris en compte le jeton d’accès qui établit le lien entre le PSU et l’AISP.

Echange de données

Le TPP envoie une requête à l’ASPSP pour récupérer la liste des comptes du PSU. L’ASPSP obtient la liste des comptes du PSU et en constitue une liste.

Le résultat obtenu peut être paginé de façon à répartir les données sur plusieurs pages et rendre l’ensemble plus lisible.

Chaque compte sera détaillé avec ses caractéristiques.

Consultez le cas d’usage « Obtenir la liste des comptes à vue d’un client » sous la rubrique « Cas d’usage AISP ».

Obtenir la liste des soldes d’un client

Description

Cet appel permet de récupérer la liste des soldes d’un compte à vue du PSU pour lequel l’AISP est connecté.

Ce service fait suite à la restitution de la liste des comptes et cartes d’un client : un identifiant de ressource correspondant à un compte doit être fourni pour obtenir la liste des soldes.

D’après les spécifications STET, quatre types de soldes peuvent être retournés dans le cas d’un compte passé en paramètre :

• En valeur (« VALU » dans la norme STET) => non applicable

• Comptable (« CLBD » dans la norme STET) => solde comptable en fin de période (semaine / mois / trimestre / semestre / année)

• Instantané (« XPCD » dans la norme STET) => non applicable

• Autre (« OTHR » dans la norme STET) => non applicable

Une pagination de la liste renvoyée peut être faite s’il y a beaucoup de données à afficher, dans ce cas des liens donnant accès à la première page, la précédente, la suivante et la dernière page faciliteront la consultation des résultats.

Les accès à cette méthode sont limités à 4 accès batch maximum par jour calendaire, pour un client, pour un compte ou pour un TPP.

Prérequis

Le TPP est présent dans le référentiel des autorisations avec un rôle d’AISP.

Le TPP et le PSU sont liés à l’ASPSP par un contrat.

Lors de cette étape, un code d’autorisation OAUTH2 (ou jeton/token d’accès) a été délivré au TPP par l’ASPSP.

Le TPP et l’ASPSP se sont mutuellement contrôlés et authentifiés.

Le TPP a fourni son jeton d’accès de façon à ce que l’ASPSP puisse identifier le PSU et récupérer le contexte associé.

L’ASPSP a pris en compte le jeton d’accès qui établit le lien entre le PSU et l’AISP.

Le TPP a récupéré auparavant la liste des comptes disponibles pour le PSU.

Echange de données

L’AISP sollicite l’ASPSP pour un des comptes à vue ou une des cartes à débit différé du PSU.

L’ASPSP répond en envoyant la liste des soldes du compte.

L’ASPSP doit fournir au minimum le solde comptable du compte.

L’ASPSP peut fournir d’autres soldes si cela est possible.

D’un point de vue DSP2, tous les soldes qui seront proposés par l’ASPSP via son web Banking service devront provenir de l’API Information sur compte.

Consultez le cas d’usage « Obtenir la liste des soldes d’un compte d’un client » sous la rubrique « Cas d’usage AISP ».

Obtenir la liste des transactions d’un client

Description

Cet appel permet de récupérer la liste des opérations d’un compte à vue du PSU pour lequel l’AISP est connecté.

Les transactions obtenues sont inférieures ou égales à 90 jours par rapport à la date du jour.

Une pagination de la liste renvoyée peut être faite s’il y a beaucoup de données à afficher, dans ce cas des liens donnant accès à la première page, la précédente, la suivante et la dernière page faciliteront la consultation des résultats.

Ce service fait suite à la restitution de la liste des comptes à vue d’un client : un identifiant de ressource correspondant à un compte doit être fourni pour obtenir la liste des transactions.

Les accès à cette méthode sont limités à 4 accès batch maximum par jour calendaire, pour un client, pour un compte ou pour un TPP, hors pagination.

Prérequis

Le TPP est présent dans le référentiel des autorisations avec un rôle d’AISP.

Le TPP et le PSU sont liés à l’ASPSP par un contrat.

Lors de cette étape, un code d’autorisation OAUTH2 (ou jeton/token d’accès) a été délivré au TPP par l’ASPSP.

Le TPP et l’ASPSP se sont mutuellement contrôlés et authentifiés.

Le TPP a fourni son jeton d’accès de façon à ce que l’ASPSP puisse identifier le PSU et récupérer le contexte associé.

L’ASPSP a pris en compte le jeton d’accès qui établit le lien entre le PSU et l’AISP.

Le TPP a récupéré auparavant la liste des comptes à vue disponibles pour le PSU.

Echange de données

L’AISP sollicite l’ASPSP pour un des comptes à vue ou cartes à débit différé du PSU. Il peut fournir certains critères de sélection.

L’ASPSP répond avec une liste de transactions correspondant à la requête.

Le résultat obtenu peut être paginé de façon à répartir les données sur plusieurs pages et rendre l’ensemble plus lisible.

Consultez le cas d’usage « Obtenir la liste des transactions d’un compte d’un client » sous la rubrique « Cas d’usage AISP ».

Gestion du consentement d’un client

Description

Cet appel permet d’enregistrer le consentement d’un PSU (usager d’un service de paiement) pour lequel l’AISP (prestataire de service de paiement) est connecté.

Ce consentement contient le détail des accès consentis par le PSU. Quatre types d’accès peuvent être définis :

• Balances : accès aux soldes d’un ou plusieurs comptes du PSU
• Transactions : accès aux transaction d’un ou plusieurs comptes du PSU
• TrustedBeneficiaries : accès à la liste des bénéficiaires de confiance du PSU

Un enregistrement de consentement est donc réalisé pour un PSU donné, un AISP donné, une opération donnée et un compte donné (sauf pour les accès trustedBeneficiairies).

Chaque nouvel appel de l’AISP au service d’enregistrement du consentement pour un PSU donné, anullera et remplacera le consentement précédent le cas échéant.

Par ailleurs, à la demande du PSU, le consentement pourra être modifié ultérieurement par type d’opération : par exemple, le consentement pour l’accès à l’historique des transactions peut être révoqué alors que le consentement pour les soldes reste actif.

Le consentement est vérifié à chaque requête passée.

Prérequis

Le prestataire est présent dans le référentiel des TPP avec un rôle d’AISP.

Le TPP et le PSU sont liés à l’ASPSP par un contrat.

Lors de cette étape, un code d’autorisation OAUTH2 (ou jeton/token d’accès) a été délivré au TPP par l’ASPSP.

Le TPP et l’ASPSP se sont mutuellement contrôlés et authentifiés.

Le TPP a fourni son jeton d’accès de façon à ce que l’ASPSP puisse identifier le PSU et récupérer le contexte associé.

L’ASPSP a pris en compte le jeton d’accès qui établit le lien entre le PSU et l’AISP.

Echange de données

Le PSU communique à l’AISP la liste des comptes et des fonctionnalités pour lesquels un consentement est donné.

L’AISP transmet ces informations à l’ASPSP.

L’ASPSP répond par un code retour http 201.

Exemple de pagination

Réponse à la requête GET v1.6.2/accounts?page=1

{« accounts »: [ { « ressourceId »: « EURFR353000799999A40166510BB25 », « bicFi »: « NATXFRPP », « accountId »: { « other »: { « identification »: « EURFR353000799999A40166510BB25 », « schemeName »: « BANK » } }, « name »: « Compte client 1 », « usage »: « ORGA », « cashAccountType »: « CACC », « currency »: « EUR », « balances »: { « name »: « Solde en capital au 04/02/2019 », « balanceAmount » : { « currency »: « EUR », « amount »: « 22042776.82 » }, « balanceType » : « CLBD », « referenceDate » : « 2019-02-04 » }, « _links »: { « balances »: { « href »: « v1.6.2/accounts/EURFR353000799999A40166510BB25/balances », « templated »: false }, « transactions »: { « href »: « v1.6.2/accounts/EURFR353000799999A40166510BB25/transactions », « templated »: false } } }, { « ressourceId »: « EURFR203000799999A40166510CC89 », « bicFi »: « NATXFRPP », « accountId »: { « other »: { « identification »: « EURFR203000799999A40166510CC89 », « schemeName »: « BANK » } }, « name »: « Compte client 2 », « usage »: « ORGA », « cashAccountType »: « CACC », « currency »: « EUR », « _links »: { « balances »: { « href »: « v1.6.2/accounts/EURFR203000799999A40166510CC89/balances », « templated »: false }, « transactions »: { « href »: « v1.6.2/accounts/EURFR203000799999A40166510CC89/transactions », « templated »: false } } }, { « ressourceId »: « EURFR053000799999A40166510DD56 », « bicFi »: « NATXFRPP », « accountId »: { « other »: { « identification »: « EURFR053000799999A40166510DD56 », « schemeName »: « BANK » } }, « name »: « Compte client 3 », « usage »: « ORGA », « cashAccountType »: « CACC », « currency »: « EUR », « _links »: { « balances »: { « href »: « v1.6.2/accounts/EURFR053000799999A40166510DD56/balances », « templated »: false }, « transactions »: { « href »: « v1.6.2/accounts/EURFR053000799999A40166510DD56/transactions », « templated »: false } } }, { « ressourceId »: « USDFR533000799999A661665104443 », « bicFi »: « NATXFRPP », « accountId »: { « other »: { « identification »: « USDFR533000799999A661665104443 », « schemeName »: « BANK » } }, « name »: « Compte client 4 », « usage »: « ORGA », « cashAccountType »: « CACC », « currency »: « EUR », « _links »: { « balances »: { « href »: « v1.6.2/accounts/USDFR533000799999A661665104443/balances », « templated »: false }, « transactions »: { « href »: « v1.6.2/accounts/USDFR533000799999A661665104443/transactions », « templated »: false } } }, { « ressourceId »: « EURFR823000700999A40166510EE50 », « bicFi »: « NATXFRPP », « accountId »: { « other »: { « identification »: « EURFR823000700999A40166510EE50 », « schemeName »: « BANK » } }, « name »: « Compte client 5 », « usage »: « ORGA », « cashAccountType »: « CACC », « currency »: « EUR », « _links »: { « balances »: { « href »: « v1.6.2/accounts/EURFR823000700999A40166510EE50/balances », « templated »: false }, « transactions »: { « href »: « v1.6.2/accounts/EURFR823000700999A40166510EE50/transactions », « templated »: false } } } ], »_links »: { « self »: { « href »: « http://localhost:8080/v1.6.2/accounts?page=1 » }, « first »: { « href »: « http://localhost:8080/v1.6.2/accounts » }, « last »: { « href »: « http://localhost:8080/v1.6.2/accounts?page=last » }, « next »: { « href »: « http://localhost:8080/v1.6.2/accounts?page=2 » }, « prev »: { « href »: « http://localhost:8080/v1.6.2/accounts?page=1 » } }}

Publications réglementaires

/stet/psd2/v1.6.2/accounts/{accountResourceId}/balances

accountsBalances

Résumé

Retrieval of an account balances report (AISP)

Description

^{Description
This call returns a set of balances for a given PSU account that is specified by the AISP through an account resource Identification}
Prerequisites
– The TPP was registered by the Registration Authority for the AISP role
– The TPP and the PSU have a contract that was enrolled by the ASPSP – At this step, the ASPSP has delivered an OAUTH2 « Authorization Code » or « Resource Owner Password » access token to the TPP (cf. § 3.4.2).
– The TPP and the ASPSP have successfully processed a mutual check and authentication
– The TPP has presented its OAUTH2 « Authorization Code » or « Resource Owner Password » access token which allows the ASPSP to identify the relevant PSU and retrieve the linked PSU context (cf. § 3.4.2) if any.
– The ASPSP takes into account the access token that establishes the link between the PSU and the AISP.
– The TPP has previously retrieved the list of available accounts for the PSU
### Business flow
The AISP requests the ASPSP on one of the PSU’s accounts.
The ASPSP answers by providing a list of balances on this account.
– The ASPSP should provide at least one balance on the account. – For cash account, this balance should be the accounting balance (CACC) – For card transactions account, the accounting balance is meaningless and must be replaced by an other type of balance (OTHR).
– Case of no registered transaction on the account, this balance will have an amount equal to zero.
– The ASPSP can provide other balance restitutions, e.g. instant balance, as well, if possible.
– Actually, from the PSD2 perspective, any other balances that are provided through the Web-Banking service of the ASPSP must also be provided by this ASPSP through the API.

Scopes

• pisp
• aisp
• cbpii
• extended_transaction_history

Paramètres

Codes retour

Sorties

application/hal+json; charset=utf-8

application/json; charset=utf-8

Authentifications disponibles

OAuth 2.0

/stet/psd2/v1.6.2/accounts

accounts

Résumé

Retrieval of the PSU accounts (AISP)

Description

^{Description
This call returns all payment accounts that are relevant for the PSU on behalf of whom the AISP is connected.
Thanks to HYPERMEDIA, each account is returned with the links aiming to ease access to the relevant transactions and balances.
The result may be subject to pagination (i.e. retrieving a partial result in case of having too many results) through a set of pages by the ASPSP. Thereafter, the AISP may ask for the first, next, previous or last page of results.} Prerequisites – The TPP was registered by the Registration Authority for the AISP role.
– The TPP and the PSU have a contract that was enrolled by the ASPSP – At this step, the ASPSP has delivered an OAUTH2 « Authorization Code » or « Resource Owner Password » access token to the TPP (cf. § 3.4.2).
– The TPP and the ASPSP have successfully processed a mutual check and authentication
– The TPP has presented its OAUTH2 « Authorization Code » or « Resource Owner Password » access token which allows the ASPSP to identify the relevant PSU and retrieve the linked PSU context (cf. § 3.4.2) if any.
– The ASPSP takes into account the access token that establishes the link between the PSU and the AISP. ### Business Flow
The TPP sends a request to the ASPSP for retrieving the list of the PSU payment accounts.
The ASPSP computes the relevant PSU accounts and builds the answer as an accounts list.
The result may be subject to pagination in order to avoid an excessive result set.
Each payment account will be provided with its characteristics.

Scopes

• pisp
• cbpii
• aisp
• extended_transaction_history

Paramètres

Codes retour

Sorties

application/hal+json; charset=utf-8

application/json; charset=utf-8

Authentifications disponibles

OAuth 2.0

/stet/psd2/v1.6.2/accounts/{accountResourceId}/overdrafts

accountsOverdrafts

Résumé

Retrieval of an account overdraft (AISP)

Description

^{Description
This call returns the overdrafts that can be used for a given PSU account that is specified by the AISP through an account resource identification.
The request may use some filter parameter in order to restrict the query}
Prerequisites
– The TPP was registered by the Registration Authority for the AISP role
– The TPP and the PSU have a contract that was enrolled by the ASPSP – At this step, the ASPSP has delivered an OAUTH2 « Authorization Code » or « Resource Owner Password » access token to the TPP (cf. § 3.4.2).
– The TPP and the ASPSP have successfully processed a mutual check and authentication
– The TPP has presented its OAUTH2 « Authorization Code » or « Resource Owner Password » access token which allows the ASPSP to identify the relevant PSU and retrieve the linked PSU context (cf. § 3.4.2) is any.
– The ASPSP takes into account the access token that establishes the link between the PSU and the AISP.
– The TPP has previously retrieved the list of available accounts for the PSU
^{Business flow
The AISP requests the ASPSP on one of the PSU’s accounts.
The ASPSP answers by the overdraft that can be applied.}

Scopes

• pisp
• extended_transaction_history
• cbpii
• aisp

Paramètres

Codes retour

Sorties

application/hal+json; charset=utf-8

application/json; charset=utf-8

Authentifications disponibles

OAuth 2.0

/stet/psd2/v1.6.2/accounts/{accountResourceId}/owners

accountsOwners

Résumé

Retrieval of an account owners (AISP)

Description

Description
This call returns the owners identities for a given PSU account that is specified by the AISP through an account resource identification.
This call cannot be used when the account is owned by a legal entity where the identity of this entity is directly available in the account structure (field [company]).
### Prerequisites
– The TPP was registered by the Registration Authority for the AISP role
– The TPP and the PSU have a contract that was enrolled by the ASPSP – At this step, the ASPSP has delivered an OAUTH2 « Authorization Code » or « Resource Owner Password » access token to the TPP (cf. § 3.4.2).
– The TPP and the ASPSP have successfully processed a mutual check and authentication
– The TPP has presented its OAUTH2 « Authorization Code » or « Resource Owner Password » access token which allows the ASPSP to identify the relevant PSU and retrieve the linked PSU context (cf. § 3.4.2) is any.
– The ASPSP takes into account the access token that establishes the link between the PSU and the AISP.
– The TPP has previously retrieved the list of available accounts for the PSU
^{Business flow
The AISP requests the ASPSP on one of the PSU’s accounts.
The ASPSP answers by the identities of the account owners.}

Scopes

• extended_transaction_history
• cbpii
• pisp
• aisp

Paramètres

Codes retour

Sorties

application/hal+json; charset=utf-8

application/json; charset=utf-8

Authentifications disponibles

OAuth 2.0

/stet/psd2/v1.6.2/accounts/{accountResourceId}/transactions/{transactionResourceId}/details

accountsTransactionsDetails

Résumé

Retrieval of transaction details (AISP)

Description

Description
This call returns the details of a transaction from a given PSU account.
The AISP has to specified
– the account through an account resource identification
– the transaction through a transaction resource identifcation
### Prerequisites
– The TPP was registered by the Registration Authority for the AISP role
– The TPP and the PSU have a contract that was enrolled by the ASPSP – At this step, the ASPSP has delivered an OAUTH2 « Authorization Code » or « Resource Owner Password » access token to the TPP (cf. § 3.4.2).
– The TPP and the ASPSP have successfully processed a mutual check and authentication
– The TPP has presented its OAUTH2 « Authorization Code » or « Resource Owner Password » access token which allows the ASPSP to identify the relevant PSU and retrieve the linked PSU context (cf. § 3.4.2) is any.
– The ASPSP takes into account the access token that establishes the link between the PSU and the AISP.
– The TPP has previously retrieved the list of available accounts for the PSU and the transactions from one given account
– A transaction includes a « details » hyperlink which indicates that detailed information is available for this transaction.
^{Business flow
The AISP requests the ASPSP on one of the transactions.
The ASPSP answers by the details on this transaction.}

Scopes

• pisp
• cbpii
• aisp
• extended_transaction_history

Paramètres

Codes retour

Sorties

application/hal+json; charset=utf-8

application/json; charset=utf-8

Authentifications disponibles

OAuth 2.0

/stet/psd2/v1.6.2/accounts/{accountResourceId}/transactions

accountsTransactions

Résumé

Retrieval of an account transaction set (AISP)

Description

Description
This call returns transactions for an account for a given PSU account that is specified by the AISP through an account resource identification.
The request may use some filter parameter in order to restrict the query – on a given imputation date range – past a given incremental technical identification
The result may be subject to pagination (i.e. retrieving a partial result in case of having too many results) through a set of pages by the ASPSP. Thereafter, the AISP may ask for the first, next, previous or last page of results.
### Prerequisites
– The TPP was registered by the Registration Authority for the AISP role
– The TPP and the PSU have a contract that was enrolled by the ASPSP – At this step, the ASPSP has delivered an OAUTH2 « Authorization Code » or « Resource Owner Password » access token to the TPP (cf. § 3.4.2).
– The TPP and the ASPSP have successfully processed a mutual check and authentication
– The TPP has presented its OAUTH2 « Authorization Code » or « Resource Owner Password » access token which allows the ASPSP to identify the relevant PSU and retrieve the linked PSU context (cf. § 3.4.2) is any.
– The ASPSP takes into account the access token that establishes the link between the PSU and the AISP.
– The TPP has previously retrieved the list of available accounts for the PSU
### Business flow
The AISP requests the ASPSP on one of the PSU’s accounts. It may specify some selection criteria.
The ASPSP answers by a set of transactions that matches the query.
– The result may be subject to pagination in order to avoid an excessive result set.
– Case of no registered transaction on the account, this result will be an empty list.
The default transaction set, in the absence of filter query parameter, has to be specified and documented by the implementation.
The sort order of transaction might be specific to each ASPSP, due to each Information System constraints.

Scopes

• extended_transaction_history
• cbpii
• aisp
• pisp

Paramètres

Codes retour

Sorties

application/hal+json; charset=utf-8

application/json; charset=utf-8

Authentifications disponibles

OAuth 2.0

/stet/psd2/v1.6.2/consents

consents

Résumé

Forwarding the PSU consent (AISP)

Description

### Description
In the mixed detailed consent on accounts
– the AISP captures the consent of the PSU
– then it forwards this consent to the ASPSP
This consent replaces any prior consent that was previously sent by the AISP.
### Prerequisites
– The TPP was registered by the Registration Authority for the AISP role.
– The TPP and the PSU have a contract that was enrolled by the ASPSP – At this step, the ASPSP has delivered an OAUTH2 « Authorization Code » or « Resource Owner Password » access token to the TPP (cf. § 3.4.2).
– The TPP and the ASPSP have successfully processed a mutual check and authentication
– The TPP has presented its OAUTH2 « Authorization Code » or « Resource Owner Password » access token which allows the ASPSP to identify the relevant PSU and retrieve the linked PSU context (cf. § 3.4.2) if any.
– The ASPSP takes into account the access token that establishes the link between the PSU and the AISP.
^{Business Flow
The PSU specifies to the AISP which of his/her accounts will be accessible and which functionalities should be available.
The AISP forwards these settings to the ASPSP.
The ASPSP answers by HTTP201 return code.}

Scopes

• cbpii
• extended_transaction_history
• aisp
• pisp

Paramètres

Codes retour

Entrées

application/json

Sorties

application/hal+json; charset=utf-8

application/json; charset=utf-8

Authentifications disponibles

OAuth 2.0

/stet/psd2/v1.6.2/end-user-identity

endUserIdentity

Résumé

Retrieval of the identity of the end-user (AISP)

Description

Description
This call returns the identity of the PSU (end-user).
### Prerequisites
– The TPP was registered by the Registration Authority for the AISP role.
– The TPP and the PSU have a contract that was enrolled by the ASPSP – At this step, the ASPSP has delivered an OAUTH2 « Authorization Code » or « Resource Owner Password » access token to the TPP (cf. § 3.4.2).
– The TPP and the ASPSP have successfully processed a mutual check and authentication
– The TPP has presented its OAUTH2 « Authorization Code » or « Resource Owner Password » access token which allows the ASPSP to identify the relevant PSU and retrieve the linked PSU context (cf. § 3.4.2) if any.
– The ASPSP takes into account the access token that establishes the link between the PSU and the AISP.
^{Business Flow The AISP asks for the identity of the PSU. The ASPSP answers with the identity, i.e. first and last names of the end-user.}

Scopes

• aisp
• pisp
• cbpii
• extended_transaction_history

Paramètres

Codes retour

Sorties

application/hal+json; charset=utf-8

application/json; charset=utf-8

Authentifications disponibles

OAuth 2.0

/stet/psd2/v1.6.2/trusted-beneficiaries

trustedBeneficiaries

Résumé

Retrieval of the trusted beneficiaries list (AISP)

Description

Description
This call returns all trusted beneficiaries that were set by the PSU.
Those beneficiaries can benefit from an SCA exemption during payment initiation.
The result may be subject to pagination (i.e. retrieving a partial result in case of having too many results) through a set of pages by the ASPSP. Thereafter, the AISP may ask for the first, next, previous or last page of results.
### Prerequisites
– The TPP was registered by the Registration Authority for the AISP role.
– The TPP and the PSU have a contract that was enrolled by the ASPSP – At this step, the ASPSP has delivered an OAUTH2 « Authorization Code » or « Resource Owner Password » access token to the TPP (cf. § 3.4.2).
– The TPP and the ASPSP have successfully processed a mutual check and authentication
– The TPP has presented its OAUTH2 « Authorization Code » or « Resource Owner Password » access token which allows the ASPSP to identify the relevant PSU and retrieve the linked PSU context (cf. § 3.4.2) if any.
– The ASPSP takes into account the access token that establishes the link between the PSU and the AISP.
### Business Flow
The AISP asks for the trusted beneficiaries list.
The ASPSP answers with a list of beneficiary details structure.

Scopes

• cbpii
• aisp
• extended_transaction_history
• pisp

Paramètres

Codes retour

Sorties

application/hal+json; charset=utf-8

application/json; charset=utf-8

Authentifications disponibles

OAuth 2.0

Obtenir un jeton d'accès

1- Vous envoyez directement une requête vers l’infrastructure informatique d’autorisation de la banque teneuse de compte, le détail des liens et des paramètres se trouvent ci-après :

2 -La banque teneuse de compte (ASPSP) va effectuer des vérifications liées à votre profil en tant que TPP (validité des certificats et de votre rôle dans le référentiel de place, non révocation de votre profil, etc…).

3 -Une fois ces vérifications effectuées et si elles sont concluantes, la banque va vous répondre via un code HTTP200 (OK) et les données suivantes :

Le jeton d’accès doit être utilisé dans toutes les requêtes au niveau du header « Authorization » préfixé par le type de jeton « Bearer ». Si le jeton a expiré, la requête sera rejetée avec un code HTTP400 et des données indiquant « Token invalide ». Cette requête pourra être renvoyée une fois un nouveau jeton d’accès de type Client Credential demandé et obtenu.

A noter que la durée de vie maximale d’un jeton d’accès est à ce jour de 180 jours calendaires.

Obtenir la liste des comptes

Obtenir la liste des comptes

Ce service permet de lister tous les comptes éligibles* à la DSP2.

NB (*) : comptes de paiements actifs et accessibles en ligne, soit des comptes à vue pour les professionnels et entreprises gérés par ce teneur de compte.

Prérequis

Cet appel permet de récupérer la liste des comptes paiement du PSU (usager d’un service de paiement) pour lequel l’AISP (prestataire de service de paiement) est connecté.

Chaque compte est retourné avec les liens permettant de consulter les soldes ou les encours ainsi que les transactions associées à celui-ci.

Une pagination de la liste renvoyée peut être faite si le nombre de comptes est élevé, dans ce cas des liens de navigation donnant accès à la première page, la précédente, la suivante et la dernière page faciliteront la consultation des résultats.

Un lien self sera également présent pour revenir à la page obtenue juste après exécution de la requête.

Les accès à cette méthode sont limités à 4 accès batch maximum par jour calendaire, pour un TPP sans connexion du client, hors pagination.

Requête

« GET /accounts »

Paramètre

Aucun paramètre spécifique n’est requis lors de l’appel à ce service (en dehors du jeton oauth2).

Exemple

Requête

GET www.30007.sandbox.api.89c3.com/stet/psd2/v1.6.2/accounts

Résultat

Status code : HTTP 200

Body

{ « _links »: { « last »: { « href »: « https://www.30007.sandbox.api.89c3.com/stet/psd2/v1.6.2/accounts?page=last » }, « self »: { « href »: « https://www.30007.sandbox.api.89c3.com/stet/psd2/v1.6.2/accounts » }, « first »: { « href »: « https://www.30007.sandbox.api.89c3.com/stet/psd2/v1.6.2/accounts » } }, « accounts »: [ { « cashAccountType »: « CACC », « accountId »: { « iban »: « FR353000799999A40166510BB25 » }, « balances »: { « balanceType »: « CLBD », « name »: « Solde en capital », « referenceDate »: « 2019-3-5 », « balanceAmount »: { « amount »: « 18217563.75 », « currency »: « EUR » } }, « ressourceId »: « EURFR353000799999A40166510BB25 », « usage »: « ORGA », « name »: « Compte client 1 », « bicFi »: « NATXFRPP », « currency »: « EUR », « links »: { « balances »: { « templated »: false, « href »: « https://www.30007.sandbox.api.89c3.com/stet/psd2/v1.6.2/accounts/EURFR353000799999A40166510BB25/balances » }, « transactions »: { « templated »: false, « href »: « https://www.30007.sandbox.api.89c3.com/stet/psd2/v1.6.2/accounts/EURFR353000799999A40166510BB25/transactions » } } }, { « cashAccountType »: « CACC », « accountId »: { « iban »: « FR203000799999A40166510CC89 » }, « balances »: { « balanceType »: « CLBD », « name »: « Solde en capital », « referenceDate »: « 2019-3-5 », « balanceAmount »: { « amount »: « 7255.44 », « currency »: « EUR » } }, « ressourceId »: « EURFR203000799999A40166510CC89 », « usage »: « ORGA », « name »: « Compte client 2 », « bicFi »: « NATXFRPP », « currency »: « EUR », « links »: { « balances »: { « templated »: false, « href »: « https://www.30007.sandbox.api.89c3.com/stet/psd2/v1.6.2/accounts/EURFR203000799999A40166510CC89/balances » }, « transactions »: { « templated »: false, « href »: « https://www.30007.sandbox.api.89c3.com/stet/psd2/v1.6.2/accounts/EURFR203000799999A40166510CC89/transactions » } } }, { « cashAccountType »: « CACC », « accountId »: { « iban »: « FR053000799999A40166510DD56 » }, « balances »: { « balanceType »: « CLBD », « name »: « Solde en capital », « referenceDate »: « 2019-3-5 », « balanceAmount »: { « amount »: « 158789.33 », « currency »: « EUR » } }, « ressourceId »: « EURFR053000799999A40166510DD56 », « usage »: « ORGA », « name »: « Compte client 3 », « bicFi »: « NATXFRPP », « currency »: « EUR », « links »: { « balances »: { « templated »: false, « href »: « https://www.30007.sandbox.api.89c3.com/stet/psd2/v1.6.2/accounts/EURFR053000799999A40166510DD56/balances » }, « transactions »: { « templated »: false, « href »: « https://www.30007.sandbox.api.89c3.com/stet/psd2/v1.6.2/accounts/EURFR053000799999A40166510DD56/transactions » } } }, { « cashAccountType »: « CACC », « accountId »: { « iban »: « FR533000799999A661665104443 » }, « balances »: { « balanceType »: « CLBD », « name »: « Solde en capital », « referenceDate »: « 2019-3-5 », « balanceAmount »: { « amount »: « 56754.45 », « currency »: « USD » } }, « ressourceId »: « USDFR533000799999A661665104443 », « usage »: « ORGA », « name »: « Compte client 4 », « bicFi »: « NATXFRPP », « currency »: « USD », « links »: { « balances »: { « templated »: false, « href »: « https://www.30007.sandbox.api.89c3.com/stet/psd2/v1.6.2/accounts/USDFR533000799999A661665104443/balances » }, « transactions »: { « templated »: false, « href »: « https://www.30007.sandbox.api.89c3.com/stet/psd2/v1.6.2/accounts/USDFR533000799999A661665104443/transactions » } } }, { « cashAccountType »: « CACC », « accountId »: { « iban »: « FR823000700999A40166510EE50 » }, « balances »: { « balanceType »: « CLBD », « name »: « Solde en capital », « referenceDate »: « 2019-3-5 », « balanceAmount »: { « amount »: « -4367.78 », « currency »: « EUR » } }, « ressourceId »: « EURFR823000700999A40166510EE50 », « usage »: « ORGA », « name »: « Compte client 5 », « bicFi »: « NATXFRPP », « currency »: « EUR », « links »: { « balances »: { « templated »: false, « href »: « https://www.30007.sandbox.api.89c3.com/stet/psd2/v1.6.2/accounts/EURFR823000700999A40166510EE50/balances » }, « transactions »: { « templated »: false, « href »: « https://www.30007.sandbox.api.89c3.com/stet/psd2/v1.6.2/accounts/EURFR823000700999A40166510EE50/transactions » } } } ], « connectedPsu »: « Marc »}

Tests d’acceptance

Ces tests ont pour objectif de s’assurer que l’API respecte la norme STET. Ils devraient être validés avant tout déploiement applicatif.

Obtenir les soldes

Prérequis

Cet appel permet de récupérer le solde d’un compte de paiement du PSU (usager d’un service de paiement) pour lequel l’AISP (prestataire de service de paiement) est connecté.

Ce service fait suite au retour de la liste des comptes de paiement d’un client: un identifiant de ressource correspondant à un compte doit être fourni pour obtenir la liste des soldes.

Un type de solde est retourné dans le cas d’un compte passé en paramètre: le solde comptable (« CLBD » dans la norme STET) à J-1.

Un lien self sera présent pour revenir à la page obtenue juste après l’exécution de la demande.

L’accès à cette méthode est limité à un maximum de 4 accès par lots par jour calendaire, pour un client, pour un compte ou pour un TPP.

Requête

« GET /accounts/{accountRessourceId}/balances »

Paramètres

Paramètre « accountRessourceId » : compte de paiement dont nous voulons consulter les soldes, ces données correspondent à la section « resourceId » obtenue dans la page de résultat de la requête get /accounts.

Exemple

Requête

GET www.30007.sandbox.api.89c3.com/stet/psd2/v1.6.2/accounts/EURFR353000799999A40166510BB25/balances

Résultat

Status code : HTTP 200

Body

{ « balances »: [ { « balanceType »: « CLBD », « name »: « Solde en capital au 2019-3-6 », « balanceAmount »: { « amount »: « 18217563.75 », « currency »: « EUR » }, « referenceDate »: « 2019-03-06 » } ], « _links »: { « self »: { « href »: « https://www.30007.sandbox.api.89c3.com/stet/psd2/v1.6.2/accounts/EURFR353000799999A40166510BB25/balances » } }}

Tests d’acceptance

Le but de ces tests est de s’assurer que l’API est conforme à la norme STET. Ils doivent être validés avant tout déploiement d’application

Obtenir la liste des transactions

Prérequis

Cet appel permet de récupérer la liste des opérations d’un compte de paiement du PSU (usager d’un service de paiement) pour lequel l’AISP (prestataire de service de paiement) est connecté.

Les transactions obtenues sont inférieures ou égales à 90 jours par rapport à la date du jour.

Une pagination de la liste renvoyée peut être faite s’il y a beaucoup de données à afficher, dans ce cas des liens de navigation donnant accès à la première page, la précédente, la suivante et la dernière page faciliteront la consultation des résultats (voir la section « Limitations » pour le nomber de résultats max retourné par page).

Un lien self sera également présent pour revenir à la page obtenue juste après exécution de la requête.

Ce service fait suite à la restitution de la liste des comptes de paiement d’un client : un identifiant de ressource correspondant à un compte doit être fourni pour obtenir la liste des transactions.

Les accès à cette méthode sont limités à 4 accès batch maximum par jour calendaire, pour un client, pour un compte ou pour un TPP, hors pagination.

Requête

« GET /accounts/{accountRessourceId}/transactions »

Paramètres

Paramètre accountRessourceId : compte paiement pour lequel on veut consulter les opérations, cette donnée correspond à la rubrique « ressourceId » obtenue dans la page de résultat de la requête get/accounts.

Paramètres facultatifs :

• dateFrom (date limite de début pour les transactions recherchées)

• dateTo (date limite de fin pour les transactions recherchées)

• afterEntryReference (référence d’incrément minimum pour l’identifiant technique)

Exemple

Requête

GET www.30007.sandbox.api.89c3.com/stet/psd2/v1.6.2/accounts/EURFR353000799999A40166510BB25/transactions

Résultat

Status code : HTTP 200

Body

{ « _links »: { « last »: { « href »: « https://www.30007.sandbox.api.89c3.com/stet/psd2/v1.6.2/accounts/EURFR353000799999A40166510BB25/transactions?page=last » }, « self »: { « href »: « https://www.30007.sandbox.api.89c3.com/stet/psd2/v1.6.2/accounts/EURFR353000799999A40166510BB25/transactions » }, « first »: { « href »: « https://www.30007.sandbox.api.89c3.com/stet/psd2/v1.6.2/accounts/EURFR353000799999A40166510BB25/transactions » } }, « transactions »: [ { « resourceId »: « USD04139485000 », « remittanceInformation »: « INTERETS PAYES », « transactionAmount »: { « amount »: « 12486.60 », « currency »: « USD » }, « bookingDate »: « 2019-02-24 », « creditDebitIndicator »: « CRDT », « entryReference »: « USD04139485000 », « status »: « BOOK » }, { « resourceId »: « EUR04097970000 », « remittanceInformation »: « INTERETS ENCAISSES », « transactionAmount »: { « amount »: « 57.60 », « currency »: « EUR » }, « bookingDate »: « 2019-02-27 », « creditDebitIndicator »: « DBIT », « entryReference »: « EUR04097970000 », « status »: « BOOK » }, { « resourceId »: « GBP04097970003 », « remittanceInformation »: « INTERETS ENCAISSES », « transactionAmount »: { « amount »: « 7.82 », « currency »: « EUR » }, « bookingDate »: « 2019-03-01 », « creditDebitIndicator »: « DBIT », « entryReference »: « GBP04097970003 », « status »: « BOOK » }, { « resourceId »: « JPY04097970001 », « remittanceInformation »: « INTERETS ENCAISSES », « transactionAmount »: { « amount »: « 22.64 », « currency »: « EUR » }, « bookingDate »: « 2019-02-26 », « creditDebitIndicator »: « DBIT », « entryReference »: « JPY04097970001 », « status »: « BOOK » }, { « resourceId »: « USD04097970002 », « remittanceInformation »: « INTERETS ENCAISSES », « transactionAmount »: { « amount »: « 287.44 », « currency »: « EUR » }, « bookingDate »: « 2019-03-02 », « creditDebitIndicator »: « DBIT », « entryReference »: « USD04097970002 », « status »: « BOOK » }, { « resourceId »: « TOP924H5J0000705 », « remittanceInformation »: « TRANSFERT BANCO INTERNACIONAL », « transactionAmount »: { « amount »: « 1850.00 », « currency »: « USD » }, « bookingDate »: « 2019-03-03 », « creditDebitIndicator »: « DBIT », « entryReference »: « TOP924H5J0000705 », « status »: « BOOK » } ]}

Tests d’acceptance

Ces tests ont pour objectif de s’assurer que l’API respecte la norme STET. Ils devraient être validés avant tout déploiement applicatif.

Obtenir les bénéficiaires

Prérequis

Cet appel permet de récupérer la liste des bénéficiaires de confiance du PSU (usager d’un service de paiement) pour lequel l’AISP (prestataire de service de paiement) est connecté.

Ce service nécessite que le PSU soit abonné aux services portail de la banque en ligne « Consultation de la listes des bénéficaires (VLCB)» ou « Modification de la listes des bénéficaires (SLCB)».

Un lien self sera présent pour revenir à la page obtenue juste après exécution de la requête.

Les accès à cette méthode sont limités à 4 accès batch maximum par jour calendaire, pour un client, pour un compte ou pour un TPP.

Requête

« GET /trusted-beneficiaries »

Paramètre

Aucun paramètre spécifique n’est requis lors de l’appel à ce service (en dehors du jeton OAUTH2).

Exemple

Requête

GET www.30007.sandbox.api.89c3.com/stet/psd2/v1.6.2/trusted-beneficiaries

Résultat

Status code : HTTP 200

Body

{ « _links »: { « self »: { « href »: « https://www.30007.sandbox.api.89c3.com/stet/psd2/v1.6.2/trusted-beneficiaries » } }, « beneficiaries »: [ { « creditorAgent »: { « bicfi »: « NATXFRPP » }, « creditorAccount »: { « iban »: « FR7630007999999401665105511 » }, « creditor »: { « postalAddress »: { « country »: « FR », « addressLine »: « Adresse du beneficiaire 75000 PARIS » }, « name »: « Tiers1 » } }, { « creditorAgent »: { « bicfi »: « NATXFRPP » }, « creditorAccount »: { « iban »: « FR7630007999990661665104493 » }, « creditor »: { « postalAddress »: { « country »: « FR », « addressLine »: « Adresse du beneficiaire 75000 PARIS » }, « name »: « Tiers2 » } }, { « creditorAgent »: { « bicfi »: « NATXFRPP » }, « creditorAccount »: { « iban »: « FR963000799999866166510BB50 » }, « creditor »: { « postalAddress »: { « country »: « FR », « addressLine »: « Adresse du beneficiaire 75000 PARIS » }, « name »: « Tiers3 » } }, { « creditorAgent »: { « bicfi »: « NATXFRPP » }, « creditorAccount »: { « iban »: « FR813000799999866166510CC17 » }, « creditor »: { « postalAddress »: { « country »: « FR », « addressLine »: « Adresse du beneficiaire 75000 PARIS » }, « name »: « Tiers4 » } }, { « creditorAgent »: { « bicfi »: « NATXFRPP » }, « creditorAccount »: { « iban »: « FR663000799999866166510DD81 » }, « creditor »: { « postalAddress »: { « country »: « FR », « addressLine »: « Adresse du beneficiaire 75000 PARIS » }, « name »: « Tiers5 » } }, { « creditorAgent »: { « bicfi »: « NATXFRPP » }, « creditorAccount »: { « iban »: « FR643000799999A66166510EE10 » }, « creditor »: { « postalAddress »: { « country »: « FR », « addressLine »: « Adresse du beneficiaire 75000 PARIS » }, « name »: « Tiers6 » } }, { « creditorAgent »: { « bicfi »: « NATXFRPP » }, « creditorAccount »: { « iban »: « FR7630007999999661665109960 » }, « creditor »: { « postalAddress »: { « country »: « FR », « addressLine »: « Adresse du beneficiaire 75000 PARIS » }, « name »: « Tiers7 » } }, { « creditorAgent »: { « bicfi »: « NATXFRPP » }, « creditorAccount »: { « iban »: « FR7630007999990771665109968 » }, « creditor »: { « postalAddress »: { « country »: « FR », « addressLine »: « Adresse du beneficiaire 75000 PARIS » }, « name »: « Tiers8 » } }, { « creditorAgent »: { « bicfi »: « NATXFRPP » }, « creditorAccount »: { « iban »: « FR983000799999077166510A044 » }, « creditor »: { « postalAddress »: { « country »: « FR », « addressLine »: « Adresse du beneficiaire 75000 PARIS » }, « name »: « Tiers9 » } }, { « creditorAgent »: { « bicfi »: « NATXFRPP » }, « creditorAccount »: { « iban »: « FR373000799999A77166510A091 » }, « creditor »: { « postalAddress »: { « country »: « FR », « addressLine »: « Adresse du beneficiaire 75000 PARIS » }, « name »: « Tiers10 » } } ]}

Tests d’acceptance

Ces tests ont pour objectif de s’assurer que l’API respecte la norme STET. Ils devraient être validés avant tout déploiement applicatif.

Utiliser le fallback

Principe

Conformément à la réglementation, les établissements du Groupe BPCE ont mis en place une interface dédiée aux prestataires de services de paiement : il s’agit des API REST DSP2 publiées.

Si l’infrastructure de production « passerelle 89C3 API Live » exposant les API DSP2 est défaillante, le prestataire des services de paiements pourra utiliser la solution couvrant les « mesures d’urgence applicables à une interface dédiée » (ou « fallback ») dont le principe est le suivant :

Cette solution répond aux exigences règlementaires de la DSP2 (article 33 des RTS). Vous pourrez l’utiliser avec les mêmes conditions et pré-requis décrits dans la rubrique « Eligibilité« .

Roadmap

Retrouvez ci-dessous les éléments de notre trajectoire prévisionnelle :

(*) Fonctionnalités Principales :

• Utilisation par le TPP du même endpoint que l’interface dédiée.

• Un paramètre de requête (header « fallback:1 » présent ou absent) ajouté par le TPP permet de distinguer une requête « Fallback » d’une requête API via l’interface dédiée qui doit être utilisée systématiquement

• Authentification du TPP via authentification mutuelle TLS par un certificat eIDAS (QWAC)

• Sécurisation identique à celle d’un accès à la banque en ligne du PSU (même interface utilisée par le PSU qu’en accès direct, et mêmes moyens d’authentification du client)

• Dans le cadre de la montée en charge de l’usage de l’interface dédiée (API), il n’est pas mis en place de bascule dynamique : la solution fallback est toujours active

• La solution de fallback est une solution de secours ne devant pas être utilisée comme moyen principal d’accès pour proposer les services DSP2. Son usage en est monitoré et tout usage abusif par un/des TPP sera automatiquement reporté auprès de l’autorité nationale compétente.

Exemple

1. Dans le cas où les API DPS2 sont indisponible de façon imprévue ou le système tomberait en panne (voir critères dans le texte RTS Art. 33), le TPP peut alors envoyer la requête :

POST https://www.17515.live.api.89c3.com/stet/psd2/oauth/token

avec :

• son certificat eIDAS QWAC de production

• le paramètre header (fallback: »1″)

POST /stet/psd2/oauth/token HTTP/1.1

Content-Type: application/x-www-form-urlencoded

X-Request-ID: 1234

fallback: 1

User-Agent: PostmanRuntime/7.16.3

Accept: */*

Cache-Control: no-cache

Host: www.17515.live.api.caisse-epargne.fr

Accept-Encoding: gzip, deflate

Content-Length: 67

Connection: keep-alive

client_id=PSDFR-ACPR-12345&grant_type=client_credentials&scope=aisp

2. Si les vérifications sont positives, nous allons vous renvoyer dans le header une url de type à utiliser dans le cadre de la redirection vers l’environnement de la banque en ligne, et qui contient un jeton JWT (champs « &fallback= ») qui doit être aussi utilisé dans ce cadre :

HTTP/1.1 302 Found

Date: Tue, 25 May 2021 21:46:59 GMT

Location: https://www.caisse-epargne.fr/se-connecter/sso?service=dei&cdetab=17515&fallback=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImhF…

Content-Length: 870

Connection: close

Content-Type: text/html; charset=iso-8859-1

</head><body>

<h1>Found</h1>

<p>The document has moved <a >here</a>.</p>

</body></html>

3. Une fois redirigé, le TPP doit utiliser ensuite les identifiants du PSU via sa méthode propriétaire

Pour plus de détails sur la requête POST, voir spécifications STET

Limites

Les contraintes de cette solution sont les suivantes :

• Pas de réutilisation du contexte de l’interface dédiée, ni du jeton d’accès (valable 180 jours actuellement)

• Seules les fonctionnalités DSP2 présentes sur la banque en ligne (référence: banque à distance sur internet fixe) sont accessibles via le fallback. Par exemple, les services de banque en ligne ne proposent pas de paiement e-commerce (cette fonctionnalité PISP n’est donc pas disponible en mode fallback)

• Le client utilisateur des services (PSU) doit être connecté à l’application du TPP (pas de possibilité de traitement batch AISP pour venir récupérer les données consenties du client). La DSP2 imposant également un renforcement des moyens d’authentification forte (AF/SCA) systématique pour les accès à la banque à distance/en ligne, les moyens d’authentification fournis aux clients PSU seront utilisés (liste non exhaustive) :
  • Soft token Sécur’Pass
  • OTP SMS
  • Clé physique (pour les entreprises)

Assemblage sandbox

Sandbox

La sandbox 89C3 API peut être utilisée directement via l’application de l’AISP en appelant les API de la plateforme 89c3-API (assemblage sandbox).

En assemblage sandbox, il y a 2 appels :

• Le premier pour récupérer le jeton d’autorisation

• Le second pour faire l’appel à l’API

Explications

L’application consommatrice des APIs de la Sandbox va devoir récupérer un jeton d’accès via sa clé d’authentification auprès de l’AS (Authentification Server).

Ainsi l’application pourra consommer les APIs grâce à son jeton d’accès.

Les appels d’API pourront être enchaînés : en récupérant une liste de comptes à vue dans un premier temps puis en exécutant une seconde requête pour obtenir le solde d’un des comptes de la liste en passant en paramètre le « ressourceId » récupéré du résultat de la première requête.

Les données utilisées pour faire les tests seront issues des personnas ce qui permettra de choisir des profils spécifiques selon les tests de façon à mieux appréhender les résultats obtenus.

En cas de nécessité, une pagination des résultats sera faite pour faciliter la lisibilité et des liens de navigation entre les différentes pages de résultats seront présents (voir les exemples présents dans les cas d’utilisation pour les obtentions de comptes, soldes et transactions), ce qui implique que l’application consommatrice puisse gérer correctement cette pagination.

Données de test

Cette page présente les jeux de données qui permettent de tester l’API :

• Les clients fictifs proposés par NATIXIS Global Trade sont des clients corporates

• Les caractéristiques de leurs comptes y sont déclinées (mono-compte, multi-comptes, solde du compte)

• Les données utiles attendues en entrée par les API y sont énumérées (identifiant Portail Natixis Global Trade, IBAN)

Gérez les erreurs

Voici la liste de descriptions des codes erreurs pour chaque méthode (il y a une annotation en rouge pour ceux étant recensés dans la norme définie par le CFONB (Codification CFONB) :

• Obtenir la liste des comptes : get/accounts

• Obtenir la liste des soldes : get/accounts/{accountRessourceId}/balances

• Obtenir la liste des transactions : get/accounts/{accountRessourceId}/transactions

Historique des versions

Cette API est conforme à la spécification STET (https://www.stet.eu/en/psd2/) avec des limitations fonctionnelles afin de répondre aux exigences règlementaires de la DSP2.

Pour rappel :

• les textes de la directive de paiement numéro 2 (DSP2, référence UE 2015/2366 du 25/11/2015) sont rentrés en application le 13 janvier 2018 : http://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:32015L2366

• ils ont été compétés par les normes techniques de réglementation (NTR, règlement délégué UE 2018/389) relatives à l’authentification forte du client et à des normes ouvertes communes et sécurisées de communication dont la date d’application se situe au 14 septembre 2019. Ces normes sont les RTS (Rules Technical Standards) : https://eur-lex.europa.eu/legal-content/FR/TXT/?toc=OJ%3AL%3A2018%3A069%3ATOC&uri=uriserv%3AOJ.L_.2018.069.01.0023.01.FRA

En France, l’ordonnance n° 2017-1252 du 9 août 2017 transpose la directive DSP2 dans la partie législative du code monétaire et financier. L’ordonnance est complétée au plan réglementaire par les décrets n° 2017-1313 et n° 2017-1314 du 31 août 2017 et les cinq arrêtés du 31 août 2017.

Vous pouvez consulter les spécifications STET sur le site internet de cette entité.

Roadmap

Politique de décommissionnement des versions de l’API

La politique du décommissionnement (= arrêt d’une version d’une API sur les environnements de production et sandbox) est fonction du cycle de vie des API, et il est prévu une phase de tuilage entre deux versions majeures d’API comme indiqué dans le schéma ci-dessous :

La communication du décommissionnement d’une version N se fera à la date de déploiement de la version N+1. Le canal de communication privilégié est le portail 89C3 API dans la partie « Roadmap » de l’API impactée. Une communication via courriel vers les correspondants des prestataires enrôlés sur le portail 89C3 API pourra venir compléter ce dispositif.

Planning des évolutions fonctionnelles à venir de l’API

L’API d’Information sur compte fait l’objet d’améliorations et d’évolutions continues tout au long de l’année*.

(*) NB : l’article 30 (4) des RTS précise que des changements significatifs de l’API peuvent intervenir sans délai. Nous appliquons cette clause dans les cas suivants :

• problème bloquant impactant de façon généralisée au moins l’un des segments de clients majeur (particuliers, professionnels, entreprises),
• problème de sécurité,
• évolutions demandées par les autorités nationales compétentes pour répondre à la trajectoire réglementaire.

Retrouvez ci-dessous notre roadmap prévisionnelle.

Limitations

Contexte

Les limitations de cette API DSP2 sont les suivantes :

• Applicable à toutes les clients disposant d’un abonnement au portail Natixis avec le service de consultation des comptes en ligne

• Ne s’applique qu’aux comptes paiement des clients (cf. texte de la Directive DSP2)

• N’utilise que le mode d’authentification par redirection (Authentification Forte du client demandée et gérée via la banque)

• L’accès aux données du client est possible uniquement si celui-ci l’autorise
• La liste des bénéficiaires est uniquement disponible pour ceux qui ont souscrits un abonnements portail Natixis Global Trade permettant la gestion des listes ouvertes

Une seule app consommatrice peut être déclarée à ce jour par le TPP (même OID = client_Id) sachant qu’il y a possibilité de gérer :

• les modèles de partenariat en marque blanche et en tiers-utilisateur

• plusieurs certificats par app consommatrice / client_Id TPP et plusieurs URL de redirection

Limitations techniques

(cf RTS dans la page Historique)

[Nom des champs dans la norme STET]

Pagination des résultats affichés

Deux paramètres sont disponibles pour personnaliser la pagination des résultats affichés à l’écran :

• le premier concerne le nombre de comptes par pages lors d’une requête de type get/accounts. La valeur par défaut est fixée à 10

• le deuxième concerne le nombre de transactions par pages lors d’une requête de type get/account/{]/transactions. La valeur par défaut est fixée à 1000

Limitations sur les données de production

Le code établissement (<cdetab>) vous permet d’adresser le bon référentiel client via le « endpoint » www.<cdetab>.live.api.89c3.com(ou www.<codetab>.live.api.natixis.com).

Une fois choisi, ce point d’accès doit être conservé pour toutes les requêtes sous-jacentes.

Eligibilité

Les ressources de l’API “Agrégation de comptes” ne peuvent être consommées que par des PSP ayant le rôle d’agrégateur (AISP). Ce statut est délivré par les autorités financières du pays dans lequel la demande est effectuée ; en France il s’agit de l’Autorité de Contrôle Prudentiel et de Résolution (ACPR), liée à la Banque de France.

L’obtention et la conservation d’un agrément relèvent de procédures rigoureuses afin d’apporter des garanties fortes aux utilisateurs des services de paiements, les formulaires étant disponibles sur le site de l’ACPR : https://acpr.banque-france.fr/autoriser/procedures-secteur-banque/tous-les-formulaires.

Une fois l’agrément donné, le format de cet identifiant (Organisation Identifier = OID) fourni par l’autorité compétente est :

PSDXX-YYYYYYYY-ZZZZZZZZ:

XX =>code ISO 3166 du pays de l’autorité compétente hyphen-minus « – » (0x2D (ASCII), U+002D (UTF-8))YYYYYYYY => 2-8 caractères du l’identifiant de l’autorité compétente (A-Z, pas de séparateur)hyphen-minus « – » (0x2D (ASCII), U+002D (UTF-8))ZZZZZZZZ => identifiant du PSP spécifié par l’autorité nationale compétente (sans restriction sur le nombre – ou sur le type – de caractère utilisé)

Cet identifiant OID est important à 2 titres :

• il servira à vous identifier lors des appels dans les requêtes des API STET (via le paramètre « client_id »)

• il devra être présent dans les certificats eIDAS que vous fournirez au teneur de compte (voir ci-dessous)

De plus, vous devez disposer de certificats délivrés par une autorité de certification reconnue (Qualified Certification Service Providers – QTSP: https://webgate.ec.europa.eu/tl-browser/#/) conformes au règlement eIDAS (electronic IDentification And trust Services : https://www.ssi.gouv.fr/entreprise/reglementation/confiance-numerique/le-reglement-eidas/) et respectant la norme ETSI (https://www.etsi.org/deliver/etsi_ts/119400_119499/119495/01.02.01_60/ts_119495v010201p.pdf).

Afin de consommer les API DSP2 proposées sur ce portail, le TPP doit enrôler son app et nous transmettre via notre API Register des certificats de production signés par une autorité de certification agréée :

• un premier jeu de certificats QWAC (pour l’authentification mutuelle TLS) et QSEALC (à charger sur notre passerelle via l’API Register) pour la sandbox

• un autre jeu de certificats QWAC (pour l’authentification mutuelle TLS) et QSEALC (à charger sur notre passerelle via l’API Register) pour la production

NB IMPORTANT : en cas de renouvellement de certificat, et si l’autorité de certification (QTSP) est différente (ou c’est la même entreprise QTSP mais qui utilise des clés racines différentes), le TPP doit avertir le support API disponible via ce site de 2 mois avant à toutes fins de vérifier que les élements de la nouvelle autorité de certification sont bien chargés sur nos infrastuctures.

Un identifiant keyID devra aussi être fourni dans un format conforme à la spécification STET intégrant une empreinte SHA256 après le caractère « _ » char, voir exemple dans la documentation STET Part 3 / Interaction Examples : keyId=https://path.to/myQsealCertificate_612b4c7d103074b29e4c1ece1ef40bc575c0a87e.

Seules les clés publiques au format .pem sont nécessaires. Des contrôles sur les données des certificats seront effectués à partir des registres Français (REGAFI : https://www.regafi.fr) et Européen (ABE ou EBA : https://euclid.eba.europa.eu/register/pir/disclaimer).