Operational limitations

These are the operational limitations of this PSD2 API in the version 1.0 :

  • Can be used for all Banques Populaires except BRED
  • Only apply to active payment accounts that are accessible online (cf. PSD2 Directive texts) => only current accounts will be returned
  • Use the REDIRECT authentication  approach only (Strong Customer Authentication required and handled by the bank), which IS NOT an obstacle according to French national competent authority

Note : TPP are not allowed to send to ASPSP the PSU credentials, and only ASPSP SCA redirect screens can be used (no embeding process as clarified by European Banking Authority based on articles PSD2 #95.5 & RTS #31)

  • Implement the mixed AISP consent mode, but not the full AISP consent mode :
    • By default, when no consent has been transmitted, all accounts are available
    • But the accounts balances and transactions detail either the cards outstandings and slips are available only for the accounts the consent was given
  • The limit is up to 4 batch accesses per calendar day for every method of this API(see use cases of every method for more details), but there is no limit when the customer asks directly his accounts online
  • Transmit the PsuIdentity value by retrieving the consented accounts list if the customer has given his consent
  • Access to the list of trusted beneficiaries is NOT available (feature not implemented in Banques Populaires online banking service)
  • "aisp extended_transaction_history" mode is NOT supported
  • Dont allow to get the customer trusted beneficiaries list : it doesnt exist for Banques Populaires (<=> a recorded beneficiary and validated by strong authentication and no strong authentication is needed after for a payment validation and for this beneficiary)
  • As a first step, only the GET /accounts, PUT /consents, GET /balances and GET /transactions methods will be available. The GET /trustedBenficiaries et GET /endUserIdentity will be available later (see "Roadmap" use case)
  • Return data only for active delayed cards which have been used at least once in the past two months


 The table below shows the limitations by method for this API (fields names are in italic) :

Retrieval of the list of accounts and delayed debit cards ("GET /accounts" method):

Retrieval of an account balances report and a delayed debit card outstandings report ( "GET /accounts/balances" method) :

Retrieval of an account transactions set and a delayed debit card slips set("GET /accounts/transactions" method) :

  • In euros only                         [currency]
  • IBAN or encrypted PAN               [iban]   
  • Accounting balance                 [balanceType]         "CLBD"                  
  • Value date balance                  [balanceType]         "VALU"                  
  • Instant balance                            [balanceType]         "OTHR"
  • IBAN or encrypted PAN          [iban]
  • Up to 90 days maximum
  • IBAN or encrypted PAN          [iban]

Pagination of the displayed results :

Two parameters are proposed to customize the pagination of the displayed results :

  • the first one is the number of accounts/cards per page when calling get/accounts request. The default value is set to 5.
  • the second one is the number of transactions per page when calling a get/account/{}/transactions request. The default value is set to 15.


From test to live data :

According to PDS2 regulation, the data set available thru this dev portal, Try-it mode and sandbox are based on fictive data (or non-real ones).These data are described in the use case "Test our API".

In order to access to live data, you will need to request for a GO Live thru the 89C3 API portal after testing your app using Try-it and Sandbox environments as described below : 

étapes test sandbox6 UK

Refer to Art. 30 (5). Account servicing payment service providers shall make available a testing facility, including support, for connection and functional testing to enable authorised payment initiation service providers, payment service providers issuing card-based payment instruments and account information service providers, or payment service providers that have applied for the relevant authorisation, to test their software and applications used for offering a payment service to users.

For live operations, the parameter "bankcode" will allow you to setup the right customer database thru a dedicated « endpoint » for each bank using the following format www.<bankcode> or

Once chosen, this entry point shall also be used for all subsequent requests.

Bank code Bank name Bank short name Available for tryIt and sandbox Available for live operations
10807 B.P Bourgogne Franche Comté BPBFC YES
16807 B.P AUvergne et Rhône-Alpes BPAURA   YES
10207 B.P RIves de Paris + BICS BPRI         YES
18707 B.P Val de France BPVF           YES
13507 B.P du Nord BPN     YES
16607 B.P Sud BPS     YES
10907 B.P Aquitaine Centre Atlantique BPACA     YES
10907 CMM Littoral du Sud Ouest CMSOU YES
14707 B.P Alsace Lorraine Champagne BPALC YES
17807 B.P OCcitane BPOC     YES
13807 B.P Grand Ouest BPGO YES YES
13807 CMM Grand Ouest CMMGO YES YES
14607 B.P Méditerranée BPMED YES
10548 Banque de Savoie BQSAV YES
40978 Banque Palatine BPAL   NO

 Carte France BP 20190107