Vue d'ensemble
Les bénéfices attendus
Exploitons ensemble les possibilités offertes par l’ouverture des données de paiement de nos clients communs.
Ce produit API AISP DSP2 vous permet d’accéder de façon sécurisée aux données des transactions des comptes de paiement des clients de Natixis Wealth Management.
Accès aux données sécurisé
Accédez aux informations de compte de paiement des clients au travers d’un dispositif sécurisé et conforme à la réglementation.
Création de valeur
Améliorez vos offres et produits pour mieux servir vos clients au travers de cas d’usage innovants.
La connexion se fait au travers d’un dispositif sécurisé conforme aux exigences du régulateur européen.
En accédant à ce service d’information sur les comptes vos clients pourront consulter leurs informations de comptes de paiement au sein de votre environnement : liste des comptes, soldes, transactions (date, description et montant), etc.
Vous serez ainsi en mesure de renforcer la valeur ajoutée de vos produits / services pour servir vos clients au travers de cas d’usage innovants : consolidation des comptes, rapprochement comptable, enrichissement de la connaissance client, analyses et prévisions budgétaires, etc.
Les différents cas d’usage possibles
Ensemble, créons de la valeur pour nos clients communs.
Consolidation
Permettez à vos clients d’agréger leurs comptes de paiement afin de disposer d’une vision consolidée et en temps réel de leurs transactions.
Réconciliation comptable
Permettez à vos clients personnes morales de rapprocher leurs factures et dépenses professionnels avec leurs transactions de paiement.
Connaissance client
Comprenez et apprenez du comportement de paiement de vos clients particuliers ou personnes morales.
Pilotage business
Appuyez-vous sur les données de paiement clients pour construire des tableaux de bord de pilotage à forte valeur ajoutée.
Comment accéder au produit ?
Pour accéder à l'API Information sur Compte, les développeurs et les entreprises doivent suivre les étapes ci-dessous.
Prise de contact
Prenez contact avec les Responsables Produit.
Accès
Enrôlez-vous directement depuis le processus dédié (acteurs régulés).
Intégration & Tests
Intégrez le service dans votre solution et faites-nous part de vos cas d’usage pour assurer la qualité du service
Go Live !
Documentation
Guides
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 ».
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 ».
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 ».
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.
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 « portail developer » 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 :
| Version | Fonctionnalités | Sandbox Date de déploiement API Dev Portal & Sandbox | Live Date de déploiement Live API Gateway |
| Toute version API DSP2 | Fallback (*) | Non applicable | Fin Septembre 2019 |
(*) 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
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)
Publications réglementaires
Comment récupérer son jeton d’accès OAuth2 ?
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 HTTP 400 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 à vue d’un client
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ètres
Aucun paramètre spécifique n’est requis lors de l’appel à ce service (en dehors du jeton OAuth2).
Exemple
Requête
GET www.18919.sandbox.api.89c3.com/stet/psd2/v1.6.2/accounts
Obtenir la liste des soldes d’un compte d’un client
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.18919.sandbox.api.89c3.com/stet/psd2/v1.6.2/accounts/EURFR353000799999A40166510B
Obtenir la liste des transactions d’un compte d’un client
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.18919.sandbox.api.89c3.com/stet/psd2/v1.6.2/accounts/EURFR353000799999A40166510BB25/transactions
Assemblage Sandbox
Sandbox
La sandbox Portail developer API peut être utilisée directement via l’application de l’AISP en appelant les API de la plateforme developer-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.
Gérer 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
| Erreur | Description de l’erreur |
|---|---|
| AC01 (CFONB) | IncorrectAccountNumber : le numéro de compte est incorrect ou inconnu |
| AC04 (CFONB) | ClosedAccountNumber : le compte est clos |
| AC06 (CFONB) | BlockedAccount : le compte est bloqué / fait l’objet d’une opposition |
| BE05 (CFONB) | UnrecognisedInitiatingParty : l’AISP est inconnu |
| BADS | BadScope : l’appel au service a été fait avec un jeton PIISP (AISP attendu) |
| INTE | InternalError : il y a une erreur interne de traitement |
| INTS | InternalServerError : il y a une erreur interne de communication avec le SI |
| IPGN | InvalidPageNumber : le numéro de page est invalide |
| NGAC | NotGrantedAccount : le compte n’est pas consenti |
| NIMP | NotImplemented : le mauvais verbe est appelé (GET attendu) |
| TMRQ | TooManyRequest : le nombre de requêtes possibles a été dépassé |
| IPSU | InvalidPSU : Numéro d’abonné non référencé ou abonnement Cyber résilié |
Roadmap
L’API d’information sur compte fait l’objet d’améliorations et d’évolutions continues tout au long de l’année. Retrouvez ci-dessous notre roadmap prévisionnelle.
| Version API | Version des spécifications STET | Fonctionnalités | Sandbox Date de déploiement API Dev Portal & Sandbox | Live Date de déploiement Live API Gateway |
|---|---|---|---|---|
| v1 | V1.4.0.47 |
| 14 mars 2019 | 15 Octobre 2019 |
| v1.6.2 | V1.6.2.0 | idem v1 | 01 mars 2023 | 1 juin 2023 |
Limitations fonctionnelles
Les limitations de cette API sont les suivantes :
- Ne s’applique qu’aux comptes en espèces en euros, éligibles (non bloqué ou sous séquestre) et accessibles en ligne (cf. texte de la Directive DSP2).
- Ne permet pas de récupérer la liste des bénéficiaires de confiance d’un client (cette notion n’existe pas), ni l’identité du client utilisateur du service de paiement (nom et prénom).
- N’utilise que le mode d’authentification par redirection (Authentification Forte du client demandée et gérée via la banque teneur de compte du client utilisateur du service de paiement).
- La profondeur d’historique des transactions est à l’identique de celle de la banque en ligne internet fixe, soit un maximum de 50 jours.
- Le mode « aisp extended_transaction_history » n’est pas supporté.
- Ne permet l’accès au compte que via l’IBAN du compte de paiement, par contre, L’IBAN n’est pas retourné dans la réponse.
- Limite à 4 accès batch par jour pour chacune des méthodes de cette API (cf. texte de la Directive DSP2).
- La bascule en V1.6.2 ne permettra pas une période de tuilage avce la version STET V1.4.0 (v1 de l’API).
Accès aux données de production
Conformément à la réglementation, les données fournies via le portail et la sandbox d’assemblage ne sont que des données fictives.
Ces données de tests sont décrites dans les cas d’usage « Comment tester l’API ? ».
Pour accéder aux données de production, l’utilisation de l’API Enregistrement DSP2 est un prérequis.
Le code établissement (voir ci-dessous) permettra d’adresser le bon backend via le point d’accès www.<cdetab>.oba-bad-me-live.api.89c3.com (nouvelle url à prendre en compte dès à présent)
(ou www.<cdetab>.live.api.natixis.com aligné sur le nom de domaine de l’accès direct www.natixis.com)
(Pour rappel, l’url 89C3 existante www.<codetab>.live.api.89C3.com ne sera plus disponible à partir du 28/09/2025)
Une fois choisi, ce point d’accès doit être conservé pour toutes les requêtes sous-jacentes.
| Code | Nom abrégé de la banque | Nom de la banque |
|---|---|---|
| 18919 | NWM | Natixis Wealth Management France |
Eligibilité
Les ressources de l’API “Information sur Compte” 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 Enregistrement DSP2 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 Enregistrement DSP2) pour la sandbox
- un autre jeu de certificats QWAC (pour l’authentification mutuelle TLS) et QSEALC (à charger sur notre passerelle via l’API Enregistrement DSP2) 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 éléments de la nouvelle autorité de certification sont bien chargés sur nos infrastructures.
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).
Historique
Historique des versions
Cette API REST est conforme à la spécification interbancaire française STET (https://www.stet.eu/en/psd2/) afin de répondre aux exigences règlementaires de la DSP2. Elle tient compte des limitations fonctionnelles décrites dans la section « Limitations ».
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.
Changements effectués depuis la première version
| Méthode(s) | Date | Description |
|---|---|---|
| POST/paymentRequest GET/paymentRequest | 17 mai 2019 | Documentation : clarification sur des paramètres obligatoires et optionnels |
| Fallback | 26 juillet 2019 | Documentation : rajout des mesures d’urgence (Fallback) |
| Toutes | 18 septembre 2019 | Documentation
|
| Toutes | 21 décembre 2020 | Documentation : rajout d’un point d’accès /section « limitations » |
| Fallback | 29 septembre 2021 | Précision apportée sur le fait que l’identifiant du terminal accédant (TermId) doit être obligatoirement fourni dans les requêtes du fallback |
| App2App | 03 Février 2023 | Ouverture du service de redirection via l’app mobile |