➤ Limitations fonctionnelles

Limitations de cette API DSP2

• Ne s'applique qu'aux comptes de paiements (le critère déterminant réside dans la faculté d’exécuter des opérations de paiement quotidiennes à partir d’un tel compte géré par le système d’information central "backend", source des informations remontées par les API), en euros et éligibles (compte de paiements actif - non bloqué ni sous séquestre-, et accessible en ligne, 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 teneur de compte du client utilisateur du service de paiement)

NB : le TPP n'a pas la possibilité de fournir à l'ASPSP les données de sécurité personnalisées du client à des fins d'authentification, et donc, seuls les écrans de redirection et d'authentification forte (SCA) de l'ASPSP doivent être utilisés (l'encapsulage de ces écrans par le TPP est interdit au regard des articles PSD2 #97.5 et RTS #31)

• N'implémente que le mode de consentement "mixte AISP" via la méthode PUT /consents qui devient obligatoire :
  • tous les comptes à vue sont remontés (y compris les nouveaux)
  • le détail des soldes et des transactions exécutées n'est accessible que pour les comptes de paiements dont le consentement a été transmis par le TPP

• Ne fixe pas de limite d'accès (rate limit) lorsque c'est le PSU connecté qui interroge ses comptes de paiements (PSU-IP-ADDRESS fourni), sinon limité à 4 accès à l’initiative du TPP (cf. texte de la Directive DSP2) :

  • par jour calendaire (00h00:00:000 - 23h59:59:999)
  • par TPP OID
  • par ASPSP / point d'accès
  • par PSU ID
  • par IBAN
  • par méthode API AIS (/!\ méthode /transactions avec ou sans dateFrom / dateTo = considérée une seule et même méthode)

• Ne permet l'accès au compte que via l'IBAN du compte de paiement

• Seules les méthodes GET /accounts, PUT /consents, GET /balances, GET /transactions, GET /details, GET /overdrafts, GET /end-user-identity sont disponibles :
  • le mode "aisp extended_transaction_history" n'est pas supporté : la profondeur d'historique des transactions est à l'identique de celle de la banque en ligne internet fixe, soit un maximum de 62 jours pour les PRO (pas de pagination gérée par l’API), et 90 jours pour les ENT (limitation à 500 comptes, pas de pagination gérée par l’API)
  • ne permet pas de récupérer la liste des bénéficiaires de confiance d'un client (cette notion n'existe pas pour les établissements listés ci-dessous)
  • ne permet pas de récupérer la liste des propriétaires d'un compte via GET /owners (fonctionnalité non supportée)

• Pas de gestion des données optionnelles "dateType" et "entryReference" (via les paramètres "entryReferenceFrom" / "entryReferenceTo")  

Limitations liées aux segments de clientèle 

Sont couverts par l'API les segments clients suivants :

• Client "particulier" (y compris compte joint et mineur rattaché) ayant un abonnement à la banque en ligne "DEI PART" ou "DEI PRO" et un compte commençant par 04

NB 1 : le particulier (PART) est une personne physique catégorisée comme « majeur capable ». Le PART peut aussi avoir des activités dans le cadre d’une entreprise individuelle (EI) = une entreprise dirigée par une seule personne, et qui n'a pas le statut de "persone morale", bien qu'elle soit inscrite au répertoire des métiers ou au Registre du Commerce et des Sociétés (RCS, exemples : artisan ou profession libérale). Dans ce cas, l’EI est considéré comme un PART

NB 2 : est non compris à ce jour le tuteur de personne protégée/sous tutelle ou curatelle utilisant la solution Web Protexion 

• Client "gros professionnel", "entreprise" et "association" ayant un accès direct à la banque en ligne "CE Net" (ayant un abonnement "CE Net Compte" et un compte commençant par 08 autorisant les virement et prélèvements électroniques)

NB 3 : les catégories "entreprise" (ENT) et "association" (ASSOC) couvrent les personnes morales.   

Limitations liées aux moyens d’authentification forte

Il est de la responsabilité de l'ASPSP d'équiper ses clients avec un ou des moyens d'authentification forte : 

• PART :       Accès aux comptes PART et Opération sensible / Dynamic linking (DL) :                                  (Sécur'Pass) ou (lecteur CAP) ou (Mot de Passe + OTP SMS)

• PRO/ENT : Accès aux comptes PART et Opération sensible / Dynamic linking (DL) : (certificat matériel) ou (Sécur'Pass) ou (lecteur CAP) ou (Mot de Passe + OTP SMS)

          NB 4 : le certificat matériel n'est pas proposé aux client sur mobile/smartphone 

➤ Accès aux données de production

Conformément à la réglementation, les modes de test Assemblage n'utilisent que des données fictives. Ces données de tests sont décrites dans la rubrique "Comment tester l'API ?".

Pour accéder aux données de production, l'utilisation de l'API REGISTER est un prérequis (voir la fiche www.api.89c3.com/fr/component/bpceportal/products/522/usecases/523).

NB : La plage hebdomadaire du lundi matin de minuit à 06h00 est utilisée pour la maintenance des infrastructures des systèmes d'information (tous composants, y compris le système central/backend, les passerelles, etc...) et peut engendrer des requêtes API en erreur ou des indisponibilités le temps des interventions (de même pour des traitements bancaires programmés en début et fin de journée/mois/trimestre/année).

Le code établissement (voir ci-dessous) permettra d'adresser le bon backend via le "endpoint" www.<cdetab>.live.api.89c3.com (ou www.<cdetab>.live.api.caisse-epargne.fr aligné sur le nom de domaine de l'accès direct www.caisse-epargne.fr). Une fois choisi, ce point d'accès doit être conservé pour toutes les requêtes sous-jacentes.

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