Banque Populaire – Account information

How to aggregate data ?

A customer having different accounts in various banks is willing to agregate his data.

Using this API “Account information” setup by banks (ASPSP), you can ask for real-time data authorized by the customer without asking for online banking credentials.

Thanks to the “Account information” API provided by the Banque Palatine, your establishment can retrieve the customer current accounts in each of the Banque Palatine establishments where they are located. For these accounts, depending on the customer consents you will get and you will transmit, you can get their balances, their transactions, the linked delayed debit cards, the outstandings and slips of these delayed debit cards.

You can access this API in a batch way in order to prepare the restitution to our customer on your application (up to 4 times a day). On demand of the customer connected on his application, you can refresh this data (without limitation).

The API resources can only be consumed if you have obtained the Account Information Services Provider (“AISP”) role status. This prerequisite is described in section “Eligibility”.

Once done, the overall process is as follows :

1- The customer agreed to use your service. He needs to select his Banque Palatine bank establishment through your interface.

2- During the first set of data exchanges, you will request for an authorization token (and a refresh one). For this AISP role, you need these token BEFORE consuming API resources. Thes tokens are issued by the Banque Palatine AFTER an identification and authorization process of the bank account holder.

The Banque Palatine will :

• check your certificates and on-going agreement delivered by the Comptent Authority ;
• identify and authorize the customer using the “redirect” mode in order to issue the tokens.

3- If the above access is granted by the customer, you can then get these OAUTH2 tokens thru secure exchanges (see use case “Retrieve your access token”).

4- Whenever you present this token to the BPCE API gateway, you will be able to consume this API resources in order to :

• request for the list of eligible accounts
• forward customer’s consent to the ASPSP
• securely access to granted customer’s data (see use case “Overview”, “Consume the API”)

If the regulated 90-day token validity period expires, this process needs to be started again (see use case “Overview”, “Refresh your access token”)

NB : any ASPSP can refuse the access to customer’s data for any justified reason (non compliant API call, blocked account, …).

Conume the API

The features are described hereafter only from a functional standpoint. The technical aspects are included in the section « use cases ». You also need to be familiar with PSD2 terminology. You may also use the Frequently Asked Questions (FAQ) or our the virtual assistant .

The STET standard proposes two consent management models : the full-AISP model and the mixed model. The mixed model only was implemented.

Description of the services provided

• Introduction – AISP mixed consent vs AISP full consent

The STET standard proposes two consent management models : the full-AISP model and the mixed model. The mixed model only was implemented.

The following process describes the implementation of this model, and especially the use of the PUT /consents request which allows the AISP to forward the details of the PSU consent.

This process summarizes the sequence of the AISP API requests calls from different methods of AISP API and token retrieval, to the accounts, delayed debit cards and their balances / transactions / outstandings and slips retrieval, as well as the customer identity retrieval.

• Prerequisite

As TPP you have to be accredited by a national competent authority for this Account Information Service Provider (“AISP”) role.

To access payment initiation API methods, you have to get an OAUTH2 access token provided by customer’s banking institution, obtained with your credentials.

You and the customer’s banking institution have successfully processed a mutual check and authentication (exchange of eIDAS QWAC certificates).

Then, you present your OAUTH2 access token to consume the account information API’s methods.

• Aggregate data

API account information use case :

The AISP asks the customer (PSU) in which banking institution (ASPSP) is(are) located his account(s).

The authentication method supported by the institution is the REDIRECT approach :

Authorization access as AISP granted by the connected PSU – retrieval of the initial access token valid for 180 days and the refresh token

1) The customer is redirected to identification screen proposed by his banking institution and he will enter his online banking identifier.

If the AISP provides client’s online banking identifier directly in this request, this step will be skipped.

2) The customer is redirected to a an authentication screen proposed by his banking institution to validate its identity.

The process for this step depends on SCA method provided to the customer by his bank (OTP SMS, Secur’pass, etc.).

It also depends on PSU’s device (PC, mobile, smartphone, tablet).

3) The customer is redirected to AISP’s APP.

The AISP provides a “call-back” URL (redirection) when he asks for an access_token : it we be called by customer’s bank.

First access to get the customer accounts list

To get the customer’s accounts list with a first access to the GET /accounts method by providing your access token for this customer (see use case “Get accounts list”).

You don’t have access to following informations:

accounts balances;

URT to GET /accounts/balances method;

URI to GET /accounts/transactions method;

URI to GET /end-user-identity method;

URI to GET /trustedBeneficiaries method => this feature will not be available in 2020.

As long as you don’t transmit accounts consented by the customer by using PUT /consents method:

You can always retrieve the customer accounts list with GET /accounts method, but you won’t have more information than the first access with this method;

if you try to use the GET /accounts/transactions method, the request will be rejected;

if you try to use the GET /accounts/balances method, the request will be rejected;

if you try to use the GET /end-user-identity method, the request will be rejected;

if you try to use the GET /trustedBeneficiaries method, the request will be rejected => this feature will not be available in 2020.

The customer select the accounts he consents to give you your application access

You ask the customer to select the accounts the possible operations on his accounts (balances retrieval, transactions retrieval, …).

Consent transmission

You send us the accounts list the customer consented to you with the PUT /consents method by providing your access token for this customer (see use case “Forward customer’s consent”). The code http 201 : created is returned.

You specify the accounts list (IBAN) the customer has consented to transmit the balances and / or transactions

You specify whether the customer has consented to the trusted beneficiaries retrieval and to his name and given name retrieval

If you already transmitted the customer accounts with the PUT /consents method, and then the customer changes his consent, you send a new consented accounts list with the PUT /consents method, it will cancel and replace the previous consent.

If you send an empty list of consented accounts for the balances and the transactions, and psuIdentity field and trustedBeneficiaries field with FALSE value, then it means there isn’t any consented account.

You can send a consented accounts list without using first the GET /accounts method, in the case for example where the customer gave you directly his accounts IBAN.

Second access for a customer accounts list retrieval

You can retrieve the customer accounts list with all details by doing a second access à to the GET /accounts method byt providing your access token for this customer (see use case “Get accounts list”).

You get the following informations :

the consented accounts

the delayed debit cards linked to consented accounts

the consented accounts balances;

URI to the GET /accounts/balances method for the consented accounts

URI to the GET /accounts/transactions method for the consented accounts

URI to the GET /user-uder-identity method if the flag “psuIdentity” = TRUE has been transmitted with the PUT /consents method

You dont get the following informations :

URI to the GET /trustedBeneficiaries method => this feature will not be available in 2020.

Consented accounts balances and transactions retrieval, delayed debit cards outstandings and slips retrieval for the cards linked to consented accounts

For every consented account, you retrieve the accounts balances with an access to the GET /accounts/balances method by providing your access token for this customer (see use case “Get accounting balance”) and by using the URI previously transmitted by the GET /accounts method for the “_links” “balances”

For every consented account delayed debit card, you retrieve the card outstandings with an access to the GET /accounts/balances method by providing your access token for this customer (see use case “Get accounting balance”) and by using the URI previously transmitted by the GET /accounts method for the “_links” “balances”

For every consented account, you retrieve the account transactions with an access to the GET /accounts/transactions method by providing your access token for this customer (see use case “Get transactions history”) and by using the URI previously transmitted by the GET /accounts method for the “_links” “transactions”

For every consented account delayed debit card, you retrieve the accounts slips with an access to the GET /accounts/transactions method by providing your access token for this customer (see use case “Get transactions history”) and by using the URI previously transmitted by the GET /accounts method for the “_links” “transactions”

If you try to use the GET /accounts/transactions method for a non consented account ou for a non consented account linked delayed debit card, the request will be rejected

If you try to use the GET /accounts/balances method for a non consented account or for a non consented account linked delayed debit card, the request will be rejected

Get the customer’s identity

You retrieve the identity of the connected PSU through an access to the end-user-identity method

Accounts informations refresh in batch mode

For every customer and for every consented account or delayed debit card linked to an account of this customer, you can refresh the customer data (same as step “Second access for a customer accounts list retrieval” and “Consented accounts balances and transactions retrieval“)

The maximum limit of batch calls to GET /accounts method is up to 4 per day for one customer/account per access page

The maximum limit of batch calls to GET /balances method is up to 4 per day for one customer/account

The maximum limit of batch calls to GET /transactions method is up to 4 per day for one customer/account per access page

The maximum limit of batch calls to GET /balances method is up to 4 per day for one customer/card

The maximum limit of batch calls to GET /transactions method is up to 4 per day for one customer/card per access page

The maximum limit of batch calls to GET /end-user-identity method is up to 4 per day for one customer per access page

Accounts informations refresh on customer request from his mobile phone, for the customer and for every customer consented account

For every customer and every consented account or delayed debit card linked to a customer account, our customer can ask to refresh his data from your application (same as step “Second access for a customer accounts list retrieval” and “Consented accounts balances and transactions retrieval“)

No access limit for this case on contrary to the batch accesses

If the 180 days token has expired, you must do a token refresh demand for the customer

1) With our connected customer on your application, you submit a token refresh request for this customer(see use case “Refresh your access token”)

2) The customer is redirected to identification screen proposed by his banking institution and he will enter his online banking identifier.

If the AISP provides client’s online banking identifier directly in this request, this step will be skipped.

3) The customer is redirected to a an authentication screen proposed by his banking institution to validate its identity.

The process for this step depends on SCA method provided to the customer by his bank (OTP SMS, Secur’pass, etc.).

It also depends on PSU’s device (PC, mobile, smartphone, tablet).

4) The customer is redirected to AISP’s APP.

The AISP provides a “call-back” URL (redirection) when he asks for an access_token : it we be called by customer’s bank.

5) You get the refresh token for this customer and you will be able to access customer data for 180 days again with the methods of this API

How to use the fallback mode

Principle

In order to comply with PSD2 regulation, ASPSP from Groupe BPCE available on this BPCE API dev portal have setup contingency measures in case of unplanned unavailability of the dedicated API interface.

The principle of this « fallback » solution is explained below:

This fallback mechanism meets PSD2 regulatory requirements (article 33/RTS). It can be used with the same conditions and prerequisites applicable for the dedicated API interface which are specified in the “Eligibility” use case.

Roadmap

Please do find below our estimated roadmap :

 

Version	Features	Sandbox Deployment date BPCE API Dev Portal & Sandbox	Live Deployment date BPCE Live API Gateway
v1.0	Fallback (*)	Not applicable	October, 2019

(*) Main features :

• Use the same API dedicated interface endpoint. The list of our banking institutions and the possible values ​​of <bankcode> are specified in the “Limitations” use case ;

• A parameter (header ‘fallback’ present or absent) managed directly by the TPP allows do differentiate a « Fallback » request from a dedicated interface PSD2 API request ;

• Use of same TPP eIDAS certificate (QWAC) to be presented for mutual TLS authentication ;

• Use the same PSU authentication procedure and means for accessing online banking services ;

• This fallback solution is always active, even so the dedicated interface API must be used systematically in first priority. Its usage is subject to strict conditions as described in Article 33 of RTS, and can’t be used as the main access for PSD2 features. It will be monitored as such and every abuse will be automatically reported to our national competent authority.

Example

1. If PSD2 API are not available due to unplanned unavailability or due to systems breakdown (see RTS Art. 33), TPP should use the following request (example for bank establishment 13807 [BPGO]) :

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

with :

• its live eIDAS QWAC certificate
• fallback:”1″ parameter in the header

2. If all checks are successful, the online banking login web page will be displayed.

3. TPP can then apply its proprietary login process using PSU credentials.

For more details on the data exchanged, see the use case “How to retrieve your OAUTH2 access token?”.

See also STET V1.4.2.17 / Part I / section 3.4.3

Please note the following constraints which apply on this fallback mechanism :

• No re-use of the API dedicated interface context, neither any of 90-day validity access token generated for AISP role ;

• Only online banking features will be accessible thru fallback mode. As an example, online banking doesn’t propose any e-commerce transactions to customers. PISP could NOT propose this feature in fallback mode.

• The user of payment services (PSU) must be connected to PSP app. So no AISP batch process is possible.

• PSD2 also impose a reinforcement of strong customer authentication (SCA, except exemption use cases) for accessing direct online banking services. Therefore fallback mechanism leverage on reinforced PSU online banking authentication procedures and means such as (non exhaustive list) :

• • Soft token ;
• • OTP SMS ;
• • Physical token (corporate market).

Get your access token

Principle

Access to PSD2 API features is granted by the bank with an authorization token (or access token) issued using OAUTH2 standardized process.

Retrieval of access token sequence

1. Our customer (PSU) provides you the identity of the Banque Palatine which holds his accounts.

2. You initiate the OAUTH2 access token recovery sequence by redirecting the customer thru is web browser to Banque Palatine authorization infrastructure using GET /authorize.

See also STET V1.4.2.17 / Part I / section 3.4

3. The Banque Palatine account manager (ASPSP) will :

• Identifies and authenticates the PSU using one of the strong authentication methods proposed and presented to the customer
• Check your role and validity of your eIDAS certificates and agreement.

4- Once checks are done and correct, ASPS will redirect the PSU to your site using “call-back” URL given in the GET /authorize and to ASPSP for the Go Live process.

Indeed, the AISP must specify for its consuming APP, an URl which will be called by the banking establishment :

• if the customer has authorized the recovery of its data by the AISP;
• or in case of refusal of consent;
• or if the kinematics of identification and authentication are interrupted at one of its stages (example: timeout on the identification screen or on the strong authentication screen).

You will find in the response of this request a one-time-token with a short life period.

5- You can then call the Banque Palatine in order to request the OAUTH2 token “access_token” (and refresh one “refresh_token“) using POST /token with previously received data (include the one-time-token).

Note : these /token requests for getting the Authorization Code flow shall be sent WITHOUT the « scope » parameter.

See also STET V1.4.2.17 / Part I / section 3.4

6- The Banque Palatine account manager (ASPSP) will :

• Check your role (AISP or CBPII) and validity of your eIDAS certificates and agreement
• Checks the direct or indirect matching between the Authorization Number within the eIDAS certificate and the [client_id] value

7- Once checks are done and correct, the Banque Palatine returns a response HTTP200 (OK) with data including the access_token.

See also see STET V1.4.2.17 / Part I / section 3.4

8- As soon as you get the OAUTH2 access_token (and a 90-day valid refresh_token) issued by the bank, you can use it for each API request within the “Authorization” header, prefixed by the token type “Bearer”.

The [client_id] that is linked to the access token must directly or indirectly match with the Authorisation Number that is located within the TPP’s eIDAS certificate (QWAC).

If the access token is expired, the request will be rejected with HTTP401 with an error equal to “invalid_token”.

The request can be replayed once the access token has been refreshed suing the use case “Refresh your access token”. If your refresh token is about to expire, you will have to perform again all this process “Get your access token” (see point 3 above), meaning also redirect to Banque Palatine for customer’s strong autentication (customer SCA). For more details, see also OAUTH 2.0 Authorization Framework : https://tools.ietf.org/html/rfc6749#section-4.1

Example

You can find an example of this request in use case “Sandbox assembly”.

For more details on the data exchanged, see the use case “How to retrieve your OAUTH2 access token?”.

Refresh your access token

Principle

Since the access token has a short validity, it is necessary for the TPP to request its refresh before it expires.

Basic rules

The Banque Palatine account manager (ASPSP) has at most one valid access token and one valid refresh token per customer (PSU)/TPP/Role AISP or CBPII triplet

• The access token has a short validity period (of about one hour) on an isolated device or a client application of our customer.
• The refresh token is valid up to 180 days ;
• The refresh token and the access token must be able to be revoked at any time ;
• If the Authorization token is revoked, then the refresh one is automatically revoked (and the other way round) ;If the Authorization token is revoked, then the refresh one is automatically revoked (and the other way round) ;

This is the sequence of the access token refreshing

1. You asks for the refreshing of the access token to the Banque Palatine.

2. The Banque Palatine initiates the refreshing of the access token.

3. It retrieves the TPP certificate from the registration authority.

4. It checks the validity and non-revocation of the certificate presented.

5. It checks the date of the last authentication (< 180 days).

6. It sends you the new access token and the old refresh token.

7. You store the access token and the old refresh token in a safe place.

8. The Banque Palatine revokes the old access token.

Exemple

You can find an example of this request in use case “Sandbox assembly”.

For more details on the data exchanged, see the use case “How to retrieve your OAUTH2 access token?”.

Trigger App2App feature

Introduction

This service allows you to activate automatically (without PSU action) the banking app on PSU smartphone for identification and authentification process.

Prerequisites

The PSU has to load and to use at leat once the latest retail banking mobile app (V6.4.0 and higher) available on Android and Apple app stores.

Note : PRO & ENT customer segments are not yet activated

The callback universal link (same principe as url callback) shall be definied in advance by the TPP :

• if this link/url already exists on our BPCE API gateways, there is nothing else to do

• otherwise the TPP shall declare it using our API Register

Our “Universal links” links have been declared on iOS & Android platforms. It is not worthwhile to access to them e. g. using https://www.<codetab>.live.api.caisse-epargne.fr/89C3api/accreditation/v2/.well-known/apple-app-site-association which sends back an error code.

Request

PSU banking app activation can be achieved in live production using a current STET API request (initiated by the TPP app on the same smartphone device) with the following endpoints :

 

Brand	App2App endpoint
	www.40978.live.api.palatine.fr/stet/psd2/oauth/authorize
	.live.api.banquepopulaire.fr/stet/psd2/oauth/authorize” >www.<codetab>.live.api.banquepopulaire.fr/stet/psd2/oauth/authorize (see <codetab> values on Banque Populaire API product data sheet)
	www.10548.live.api.banque-de-savoie.fr/stet/psd2/oauth/authorize
	www.<codetab>.live.api.caisse-epargne.fr/stet/psd2/oauth/authorize (see <codetab> values on Caisse d’Epargne API product data sheet)
	www.12579.live.api.banquebcp.fr/stet/psd2/oauth/authorize
	www.42559.live.api.credit-cooperatif.coop/stet/psd2/oauth/authorize
	www.30258.live.api.btp-banque.fr/stet/psd2/oauth/authorize
	www.18919.live.api.natixis.com/stet/psd2/oauth/authorize

Otherwise, a webview will be displayed on PSU smartphone web browser if :

• the banking app is not present on PSU device nor App2App compliant (not the latest version uploaded, see prerequisites)

or

• the other endpoint format is used www.<codetab>.live.api.89c3.com/stet/psd2/oauth/authorize (can be used as a backup in case of App2App problem)

 

Publications réglementaires

 

Period	Document
Availability of DSP2 APIs to date	Load the document
Statistics Q4 2023	Load the document
Statistics Q3 2023	Load the document
Statistics Q2 2023	Load the document
Statistics Q1 2023	Load the document
Statistics Q4 2022	Load the document
Statistics Q3 2022	Load the document
Statistics Q2 2022	Load the document
Statistics Q1 2022	Load the document
Statistics Q4 2021	Load the document
Statistics Q3 2021	Load the document
Statistics Q2 2021	Load the document
Statistics Q1 2021	Load the document
Statistics Q4 2020	Load the document
Statistics Q3 2020	Load the document
Statistics Q2 2020	Load the document
Statistics Q1 2020	Load the document

 

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

accountsBalances

Abstract

Retrieval of an account balances report (AISP)

Description

This call returns a set of balances for a given PSU account that is specified by the AISP through an account resource Identification
– The TPP has been registered by the Registration Authority for the AISP role
– The TPP and the PSU have a contract that has been 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
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 must provide at least the accounting balance on the account. – 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

• extended_transaction_history
• cbpii
• aisp

Parameters

 

Authorization (required)	string header Access token to be passed as a header
accountResourceId (required)	string path Identification of account resource to fetch
PSU-IP-Address	string header IP address used by the PSU’s terminal when connecting to the TPP
PSU-IP-Port	string header IP port used by the PSU’s terminal when connecting to the TPP
PSU-HTTP-Method	string header Http method for the most relevant PSU’s terminal request to the TTP
PSU-Date	string header Timestamp of the most relevant PSU’s terminal request to the TTP
PSU-GEO-Location	string header Geographical location of the PSU as provided by the PSU mobile terminal if any to the TPP
PSU-User-Agent	string header “User-Agent” header field sent by the PSU terminal when connecting to the TPP
PSU-Referer	string header “Referer” header field sent by the PSU terminal when connecting to the TPP. Notice that an initial typo in RFC 1945 specifies that “referer” (incorrect spelling) is to be used. The correct spelling “referrer” can be used but might not be understood.
PSU-Accept	string header “Accept” header field sent by the PSU terminal when connecting to the TPP
PSU-Accept-Charset	string header “Accept-Charset” header field sent by the PSU terminal when connecting to the TPP
PSU-Accept-Encoding	string header “Accept-Encoding” header field sent by the PSU terminal when connecting to the TPP
PSU-Accept-Language	string header “Accept-Language” header field sent by the PSU terminal when connecting to the TPP
PSU-Device-ID	string header UUID (Universally Unique Identifier) for a device, which is used by the PSU, if available. UUID identifies either a device or a device dependant application installation. In case of installation identification this ID need to be unaltered until removal from device.
Digest	string header Digest of the body
Signature (required)	string header [http-signature of the request](https://datatracker.ietf.org/doc/draft-cavage-http-signatures/) The keyId must specify the way to get the relevant qualified certificate. It is requested that this identifier is an URL aiming to provide the relevant Qualified Certificate.
X-Request-ID (required)	string header Correlation header to be set in a request and retrieved in the relevant response

Return codes

 

200	The ASPSP answers with a list of account balances
204	No content.
400	Invalid status value
401	Unauthorized, authentication failure.
403	Forbidden, authentication successful but access to resource is not allowed.
404	Not found, no request available.
405	Method Not Allowed.
406	Not Acceptable.
408	Request Timeout.
429	Too many requests.
500	Internal server error.
503	Service unavailable.

Output

application/hal+json; charset=utf-8

application/json; charset=utf-8

Available authentification

OAuth 2.0

/stet/psd2/v1.4.2/accounts

accounts

Abstract

Retrieval of the PSU accounts (AISP)

Description

This call returns all payment accounts that are relevant 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. – The TPP has been registered by the Registration Authority for the AISP role.
– The TPP and the PSU have a contract that has been 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 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

• aisp
• extended_transaction_history
• cbpii

Parameters

 

Authorization (required)	string header Access token to be passed as a header
PSU-IP-Address	string header IP address used by the PSU’s terminal when connecting to the TPP
PSU-IP-Port	string header IP port used by the PSU’s terminal when connecting to the TPP
PSU-HTTP-Method	string header Http method for the most relevant PSU’s terminal request to the TTP
PSU-Date	string header Timestamp of the most relevant PSU’s terminal request to the TTP
PSU-GEO-Location	string header Geographical location of the PSU as provided by the PSU mobile terminal if any to the TPP
PSU-User-Agent	string header “User-Agent” header field sent by the PSU terminal when connecting to the TPP
PSU-Referer	string header “Referer” header field sent by the PSU terminal when connecting to the TPP. Notice that an initial typo in RFC 1945 specifies that “referer” (incorrect spelling) is to be used. The correct spelling “referrer” can be used but might not be understood.
PSU-Accept	string header “Accept” header field sent by the PSU terminal when connecting to the TPP
PSU-Accept-Charset	string header “Accept-Charset” header field sent by the PSU terminal when connecting to the TPP
PSU-Accept-Encoding	string header “Accept-Encoding” header field sent by the PSU terminal when connecting to the TPP
PSU-Accept-Language	string header “Accept-Language” header field sent by the PSU terminal when connecting to the TPP
PSU-Device-ID	string header UUID (Universally Unique Identifier) for a device, which is used by the PSU, if available. UUID identifies either a device or a device dependant application installation. In case of installation identification this ID need to be unaltered until removal from device.
Digest	string header Digest of the body
Signature (required)	string header [http-signature of the request](https://datatracker.ietf.org/doc/draft-cavage-http-signatures/) The keyId must specify the way to get the relevant qualified certificate. It is requested that this identifier is an URL aiming to provide the relevant Qualified Certificate.
X-Request-ID (required)	string header Correlation header to be set in a request and retrieved in the relevant response

Return codes

 

200	The ASPSP return a PSU context – listing the accounts that have been made available to the AISP by the PSU and, – for each of these accounts, the further transactions that have been enabled by the PSU through HYPERMEDIA links.
204	No content.
401	Unauthorized, authentication failure.
403	Forbidden, authentication successful but access to resource is not allowed.
404	Not found, no request available.
405	Method Not Allowed.
406	Not Acceptable.
408	Request Timeout.
429	Too many requests.
500	Internal server error.
503	Service unavailable.

Output

application/hal+json; charset=utf-8

application/json; charset=utf-8

Available authentification

OAuth 2.0

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

accountsTransactions

Abstract

Retrieval of an account transaction set (AISP)

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.
– The TPP has been registered by the Registration Authority for the AISP role
– The TPP and the PSU have a contract that has been 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
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.
The default transaction set, in the absence of filter query parameter, has to be specified and documented by the implementation.

Scopes

• aisp
• cbpii
• extended_transaction_history

Parameters

 

Authorization (required)	string header Access token to be passed as a header
accountResourceId (required)	string path Identification of account resource to fetch
dateFrom	string query Inclusive minimal imputation date of the transactions. Transactions having an imputation date equal to this parameter are included within the result.
dateTo	string query Exclusive maximal imputation date of the transactions. Transactions having an imputation date equal to this parameter are not included within the result.
entryReferenceFrom	string query Specifies the value on which the result has to be computed. Only the transaction having a technical identification greater than this value must be included within the result
entryReferenceto	string query Specifies the value on which the result has to be computed. Only the transaction having a technical identification less than or equal to this value must be included within the result
PSU-IP-Address	string header IP address used by the PSU’s terminal when connecting to the TPP
PSU-IP-Port	string header IP port used by the PSU’s terminal when connecting to the TPP
PSU-HTTP-Method	string header Http method for the most relevant PSU’s terminal request to the TTP
PSU-Date	string header Timestamp of the most relevant PSU’s terminal request to the TTP
PSU-GEO-Location	string header Geographical location of the PSU as provided by the PSU mobile terminal if any to the TPP
PSU-User-Agent	string header “User-Agent” header field sent by the PSU terminal when connecting to the TPP
PSU-Referer	string header “Referer” header field sent by the PSU terminal when connecting to the TPP. Notice that an initial typo in RFC 1945 specifies that “referer” (incorrect spelling) is to be used. The correct spelling “referrer” can be used but might not be understood.
PSU-Accept	string header “Accept” header field sent by the PSU terminal when connecting to the TPP
PSU-Accept-Charset	string header “Accept-Charset” header field sent by the PSU terminal when connecting to the TPP
PSU-Accept-Encoding	string header “Accept-Encoding” header field sent by the PSU terminal when connecting to the TPP
PSU-Accept-Language	string header “Accept-Language” header field sent by the PSU terminal when connecting to the TPP
PSU-Device-ID	string header UUID (Universally Unique Identifier) for a device, which is used by the PSU, if available. UUID identifies either a device or a device dependant application installation. In case of installation identification this ID need to be unaltered until removal from device.
Digest	string header Digest of the body
Signature (required)	string header [http-signature of the request](https://datatracker.ietf.org/doc/draft-cavage-http-signatures/) The keyId must specify the way to get the relevant qualified certificate. It is requested that this identifier is an URL aiming to provide the relevant Qualified Certificate.
X-Request-ID (required)	string header Correlation header to be set in a request and retrieved in the relevant response

Return codes

 

200	Complete transactions response
204	No content.
400	Invalid status value
401	Unauthorized, authentication failure.
403	Forbidden, authentication successful but access to resource is not allowed.
404	Not found, no request available.
405	Method Not Allowed.
406	Not Acceptable.
408	Request Timeout.
429	Too many requests.
500	Internal server error.
503	Service unavailable.

Output

application/hal+json; charset=utf-8

application/json; charset=utf-8

Available authentification

OAuth 2.0

/stet/psd2/v1.4.2/consents

consents

Abstract

Forwarding the PSU consent (AISP)

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.
– The TPP has been registered by the Registration Authority for the AISP role.
– The TPP and the PSU have a contract that has been 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 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

• extended_transaction_history
• cbpii
• aisp

Parameters

 

Authorization (required)	string header Access token to be passed as a header
access (required)	Access body List of consents granted to the AISP by the PSU.
PSU-IP-Address	string header IP address used by the PSU’s terminal when connecting to the TPP
PSU-IP-Port	string header IP port used by the PSU’s terminal when connecting to the TPP
PSU-HTTP-Method	string header Http method for the most relevant PSU’s terminal request to the TTP
PSU-Date	string header Timestamp of the most relevant PSU’s terminal request to the TTP
PSU-GEO-Location	string header Geographical location of the PSU as provided by the PSU mobile terminal if any to the TPP
PSU-User-Agent	string header “User-Agent” header field sent by the PSU terminal when connecting to the TPP
PSU-Referer	string header “Referer” header field sent by the PSU terminal when connecting to the TPP. Notice that an initial typo in RFC 1945 specifies that “referer” (incorrect spelling) is to be used. The correct spelling “referrer” can be used but might not be understood.
PSU-Accept	string header “Accept” header field sent by the PSU terminal when connecting to the TPP
PSU-Accept-Charset	string header “Accept-Charset” header field sent by the PSU terminal when connecting to the TPP
PSU-Accept-Encoding	string header “Accept-Encoding” header field sent by the PSU terminal when connecting to the TPP
PSU-Accept-Language	string header “Accept-Language” header field sent by the PSU terminal when connecting to the TPP
PSU-Device-ID	string header UUID (Universally Unique Identifier) for a device, which is used by the PSU, if available. UUID identifies either a device or a device dependant application installation. In case of installation identification this ID need to be unaltered until removal from device.
Digest	string header Digest of the body
Signature (required)	string header [http-signature of the request](https://datatracker.ietf.org/doc/draft-cavage-http-signatures/) The keyId must specify the way to get the relevant qualified certificate. It is requested that this identifier is an URL aiming to provide the relevant Qualified Certificate.
X-Request-ID (required)	string header Correlation header to be set in a request and retrieved in the relevant response

Return codes

 

201	Created
400	Invalid status value
401	Unauthorized, authentication failure.
403	Forbidden, authentication successful but access to resource is not allowed.
405	Method Not Allowed.
406	Not Acceptable.
408	Request Timeout.
429	Too many requests.
500	Internal server error.
501	Not Implemented. This code should be used when the entry point is implemented but cannot provide a result, given the context. When the entry point is not implemented at all, HTTP400 will be returned.
503	Service unavailable.

Input

application/json

Output

application/hal+json; charset=utf-8

application/json; charset=utf-8

Available authentification

OAuth 2.0

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

endUserIdentity

Abstract

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

Description

This call returns the identity of the PSU (end-user).
– The TPP has been registered by the Registration Authority for the AISP role.
– The TPP and the PSU have a contract that has been 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 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

• extended_transaction_history
• cbpii
• aisp

Parameters

 

Authorization (required)	string header Access token to be passed as a header
PSU-IP-Address	string header IP address used by the PSU’s terminal when connecting to the TPP
PSU-IP-Port	string header IP port used by the PSU’s terminal when connecting to the TPP
PSU-HTTP-Method	string header Http method for the most relevant PSU’s terminal request to the TTP
PSU-Date	string header Timestamp of the most relevant PSU’s terminal request to the TTP
PSU-GEO-Location	string header Geographical location of the PSU as provided by the PSU mobile terminal if any to the TPP
PSU-User-Agent	string header “User-Agent” header field sent by the PSU terminal when connecting to the TPP
PSU-Referer	string header “Referer” header field sent by the PSU terminal when connecting to the TPP. Notice that an initial typo in RFC 1945 specifies that “referer” (incorrect spelling) is to be used. The correct spelling “referrer” can be used but might not be understood.
PSU-Accept	string header “Accept” header field sent by the PSU terminal when connecting to the TPP
PSU-Accept-Charset	string header “Accept-Charset” header field sent by the PSU terminal when connecting to the TPP
PSU-Accept-Encoding	string header “Accept-Encoding” header field sent by the PSU terminal when connecting to the TPP
PSU-Accept-Language	string header “Accept-Language” header field sent by the PSU terminal when connecting to the TPP
PSU-Device-ID	string header UUID (Universally Unique Identifier) for a device, which is used by the PSU, if available. UUID identifies either a device or a device dependant application installation. In case of installation identification this ID need to be unaltered until removal from device.
Digest	string header Digest of the body
Signature (required)	string header [http-signature of the request](https://datatracker.ietf.org/doc/draft-cavage-http-signatures/) The keyId must specify the way to get the relevant qualified certificate. It is requested that this identifier is an URL aiming to provide the relevant Qualified Certificate.
X-Request-ID (required)	string header Correlation header to be set in a request and retrieved in the relevant response

Return codes

 

200	The ASPSP returns the identity of the PSU
204	No content.
401	Unauthorized, authentication failure.
403	Forbidden, authentication successful but access to resource is not allowed.
404	Not found, no request available.
405	Method Not Allowed.
406	Not Acceptable.
429	Too many requests.
500	Internal server error.

Output

application/hal+json; charset=utf-8

application/json; charset=utf-8

Available authentification

OAuth 2.0

/stet/psd2/v1.4.2/funds-confirmations

fundsConfirmations

Abstract

Payment coverage check request (CBPII)

Description

The CBPII can ask an ASPSP to check if a given amount can be covered by the liquidity that is available on a PSU cash account or payment card.
– The TPP has been registered by the Registration Authority for the CBPII role
– The TPP and the PSU have a contract that has been registered by the ASPSP – At this step, the ASPSP has delivered an “Authorization Code”, a “Resource Owner Password” or a “Client Credential” OAUTH2 access token to the TPP (cf. § 3.4.2). – Each ASPSP has to implement either the “Authorization Code”/”Resource Owner Password” or the “Client Credential” OAUTH2 access token model. – Doing this, it will edit the [security] section on this path in order to specify which model it has chosen
– The TPP and the ASPSP have successfully processed a mutual check and authentication – The TPP has presented its OAUTH2 “Authorization Code”, “Resource Owner Password” or “Client Credential” access token which allows the ASPSP to identify the relevant PSU.
The CBPII requests the ASPSP for a payment coverage check against either a bank account or a card primary identifier.
The ASPSP answers with a structure embedding the original request and the result as a Boolean.

Scopes

• extended_transaction_history
• aisp
• cbpii

Parameters

 

Authorization (required)	string header Access token to be passed as a header
paymentCoverage (required)	PaymentCoverageRequestResource body parameters of a payment coverage request
PSU-IP-Address	string header IP address used by the PSU’s terminal when connecting to the TPP
PSU-IP-Port	string header IP port used by the PSU’s terminal when connecting to the TPP
PSU-HTTP-Method	string header Http method for the most relevant PSU’s terminal request to the TTP
PSU-Date	string header Timestamp of the most relevant PSU’s terminal request to the TTP
PSU-GEO-Location	string header Geographical location of the PSU as provided by the PSU mobile terminal if any to the TPP
PSU-User-Agent	string header “User-Agent” header field sent by the PSU terminal when connecting to the TPP
PSU-Referer	string header “Referer” header field sent by the PSU terminal when connecting to the TPP. Notice that an initial typo in RFC 1945 specifies that “referer” (incorrect spelling) is to be used. The correct spelling “referrer” can be used but might not be understood.
PSU-Accept	string header “Accept” header field sent by the PSU terminal when connecting to the TPP
PSU-Accept-Charset	string header “Accept-Charset” header field sent by the PSU terminal when connecting to the TPP
PSU-Accept-Encoding	string header “Accept-Encoding” header field sent by the PSU terminal when connecting to the TPP
PSU-Accept-Language	string header “Accept-Language” header field sent by the PSU terminal when connecting to the TPP
PSU-Device-ID	string header UUID (Universally Unique Identifier) for a device, which is used by the PSU, if available. UUID identifies either a device or a device dependant application installation. In case of installation identification this ID need to be unaltered until removal from device.
Digest	string header Digest of the body
Signature (required)	string header [http-signature of the request](https://datatracker.ietf.org/doc/draft-cavage-http-signatures/) The keyId must specify the way to get the relevant qualified certificate. It is requested that this identifier is an URL aiming to provide the relevant Qualified Certificate.
X-Request-ID (required)	string header Correlation header to be set in a request and retrieved in the relevant response

Return codes

 

200	payment coverage request
400	Invalid status value
401	Unauthorized, authentication failure.
403	Forbidden, authentication successful but access to resource is not allowed.
405	Method Not Allowed.
406	Not Acceptable.
408	Request Timeout.
429	Too many requests.
500	Internal server error.
503	Service unavailable.

Input

application/json

Output

application/hal+json; charset=utf-8

application/json; charset=utf-8

Available authentification

OAuth 2.0

/stet/psd2/v1.4.2/payment-requests/{paymentRequestResourceId}/o-confirmation

paymentRequestOConfirmation

Abstract

Confirmation of a payment request or a modification request using an OAUTH2 Authorization code grant (PISP)

Description

The PISP confirms one of the following requests or modifications:
– payment request on behalf of a merchant
– transfer request on behalf of the account’s owner
– standing-order request on behalf of the account’s owner
The ASPSP answers with a status of the relevant request and the subsequent Credit Transfer. – The TPP has been registered by the Registration Authority for the PISP role
– The TPP was provided with an OAUTH2 “Client Credential” access token by the ASPSP (cf. § 3.4.2).
– The TPP has previously posted a Request which has been saved by the ASPSP (cf. § 4.5.3) – The ASPSP has answered with a location link to the saved Payment Request (cf. § 4.5.4) – The TPP has retrieved the saved request in order to get the relevant resource Ids (cf. § 4.6).
– The PSU has been authenticated by the ASPSP through an OAUTH2 authorization code grant flow (REDIRECT approach) and the PISP got the relevant token
– The TPP and the ASPSP have successfully processed a mutual check and authentication – The TPP has presented its “OAUTH2 Authorization Code” access token Once the PSU has been authenticated through an OAUTH2 authorization code grant flow (REDIRECT approach), it is the due to the PISP to confirm the Request to the ASPSP in order to complete the process flow.
The ASPSP must wait for confirmation before executing the subsequent Credit Tranfer.

Scopes

• extended_transaction_history
• cbpii
• aisp
• pisp

Parameters

 

Authorization (required)	string header Access token to be passed as a header
paymentRequestResourceId (required)	string path Identification of the Payment Request Resource
confirmationRequest (required)	ConfirmationResource body Parameters needed for confirmation of the Payment Request, especially in “EMBEDDED-1-FACTOR” approach Even though there is no parameter, a Json (void) body structure must be provided.
PSU-IP-Address	string header IP address used by the PSU’s terminal when connecting to the TPP
PSU-IP-Port	string header IP port used by the PSU’s terminal when connecting to the TPP
PSU-HTTP-Method	string header Http method for the most relevant PSU’s terminal request to the TTP
PSU-Date	string header Timestamp of the most relevant PSU’s terminal request to the TTP
PSU-GEO-Location	string header Geographical location of the PSU as provided by the PSU mobile terminal if any to the TPP
PSU-User-Agent	string header “User-Agent” header field sent by the PSU terminal when connecting to the TPP
PSU-Referer	string header “Referer” header field sent by the PSU terminal when connecting to the TPP. Notice that an initial typo in RFC 1945 specifies that “referer” (incorrect spelling) is to be used. The correct spelling “referrer” can be used but might not be understood.
PSU-Accept	string header “Accept” header field sent by the PSU terminal when connecting to the TPP
PSU-Accept-Charset	string header “Accept-Charset” header field sent by the PSU terminal when connecting to the TPP
PSU-Accept-Encoding	string header “Accept-Encoding” header field sent by the PSU terminal when connecting to the TPP
PSU-Accept-Language	string header “Accept-Language” header field sent by the PSU terminal when connecting to the TPP
PSU-Device-ID	string header UUID (Universally Unique Identifier) for a device, which is used by the PSU, if available. UUID identifies either a device or a device dependant application installation. In case of installation identification this ID need to be unaltered until removal from device.
Digest	string header Digest of the body
Signature (required)	string header [http-signature of the request](https://datatracker.ietf.org/doc/draft-cavage-http-signatures/) The keyId must specify the way to get the relevant qualified certificate. It is requested that this identifier is an URL aiming to provide the relevant Qualified Certificate.
X-Request-ID (required)	string header Correlation header to be set in a request and retrieved in the relevant response

Return codes

 

200	retrieval of the Payment Request enriched with the status report
400	Invalid status value
401	Unauthorized, authentication failure.
403	Forbidden, authentication successful but access to resource is not allowed.
405	Method Not Allowed.
406	Not Acceptable.
408	Request Timeout.
409	Conflict. The request could not be completed due to a conflict with the current state of the target resource.
429	Too many requests.
500	Internal server error.
503	Service unavailable.

Input

application/json

Output

application/hal+json; charset=utf-8

application/json; charset=utf-8

Available authentification

OAuth 2.0

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

trustedBeneficiaries

Abstract

Retrieval of the trusted beneficiaries list (AISP)

Description

This call returns all trusted beneficiaries that have been 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.
– The TPP has been registered by the Registration Authority for the AISP role.
– The TPP and the PSU have a contract that has been 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 AISP asks for the trusted beneficiaries list.
The ASPSP answers with a list of beneficiary details structure.

Scopes

• extended_transaction_history
• cbpii
• aisp

Parameters

 

Authorization (required)	string header Access token to be passed as a header
PSU-IP-Address	string header IP address used by the PSU’s terminal when connecting to the TPP
PSU-IP-Port	string header IP port used by the PSU’s terminal when connecting to the TPP
PSU-HTTP-Method	string header Http method for the most relevant PSU’s terminal request to the TTP
PSU-Date	string header Timestamp of the most relevant PSU’s terminal request to the TTP
PSU-GEO-Location	string header Geographical location of the PSU as provided by the PSU mobile terminal if any to the TPP
PSU-User-Agent	string header “User-Agent” header field sent by the PSU terminal when connecting to the TPP
PSU-Referer	string header “Referer” header field sent by the PSU terminal when connecting to the TPP. Notice that an initial typo in RFC 1945 specifies that “referer” (incorrect spelling) is to be used. The correct spelling “referrer” can be used but might not be understood.
PSU-Accept	string header “Accept” header field sent by the PSU terminal when connecting to the TPP
PSU-Accept-Charset	string header “Accept-Charset” header field sent by the PSU terminal when connecting to the TPP
PSU-Accept-Encoding	string header “Accept-Encoding” header field sent by the PSU terminal when connecting to the TPP
PSU-Accept-Language	string header “Accept-Language” header field sent by the PSU terminal when connecting to the TPP
PSU-Device-ID	string header UUID (Universally Unique Identifier) for a device, which is used by the PSU, if available. UUID identifies either a device or a device dependant application installation. In case of installation identification this ID need to be unaltered until removal from device.
Digest	string header Digest of the body
Signature (required)	string header [http-signature of the request](https://datatracker.ietf.org/doc/draft-cavage-http-signatures/) The keyId must specify the way to get the relevant qualified certificate. It is requested that this identifier is an URL aiming to provide the relevant Qualified Certificate.
X-Request-ID (required)	string header Correlation header to be set in a request and retrieved in the relevant response

Return codes

 

200	The ASPSP returns the list of whitelisted beneficiaries
204	No content.
401	Unauthorized, authentication failure.
403	Forbidden, authentication successful but access to resource is not allowed.
404	Not found, no request available.
405	Method Not Allowed.
406	Not Acceptable.
429	Too many requests.
500	Internal server error.
501	Not Implemented. This code should be used when the entry point is implemented but cannot provide a result, given the context. When the entry point is not implemented at all, HTTP400 will be returned.

Output

application/hal+json; charset=utf-8

application/json; charset=utf-8

Available authentification

OAuth 2.0

Get accounts list

Use case

This service allows to retrieve the customer accounts list and delayed debit cards list (*).

Each account or card is returned with the links aiming to ease access to the relevant transactions and balances.

The resource ID provided for each account or card will be a parameter for the balances and transactions retrieval requests.

The result may be subject to pagination in case of having too many results. In this case, to make the results easier to read, there will be navigation links to access to the first, the next, the previous or the last page of results.

Access to this method is limited to a maximum of 4 batch accesses per calendar day for one given customer excluding pagination.

This method allows :

• to list all accounts and delayed debit cards linked to this accounts;
• to get the accounts balances;
• to get the delayed debit cards outstandings (*);
• to get the URI for the “GET /end-user-identity“ ;
• to get the URI for the “GET /accounts/balances” and “GET /accounts/transactions” methods.

(*) This API covers active delayed cards which have been used at least once in the past two months.

Prerequisite

In order to process this request it ‘s needed to fill the eligibility and to get the OAUTH2 access token (see the use case “Get your access token”).

Request

Request “get/accounts”

See also STET V1.4.2.17 / Part II / section 4.2 / Page 27

Mandatory or facultative body parameters needed for calling the service

facultative parameter : PSU-IP-ADDRESS => this parameter is mandatory if the customer is connected

Returned result

If you didn’t transmit any customer consented account with the PUT /consents method or that all consented accounts have been revoked since the last call of the PUT /consents method:

• This call allows you
  • to retrieve the customer accounts exclusive list without their balances, without the URI for the GET /accounts/balances, the GET /accounts/transactions and the GET /end-user-identity methods

If you have transmitted at least one customer consented account with the PUT /consents method and that all consented accounts haven’t been revoked following the last call to the PUT /consents method,

• This call allows
  • to retrieve all customer consented accounts with :
    • their balances if the account is included in the balances list transmitted with the PUT /consents method
    • The URI for the GET /accounts/balances method if the account is included in the balances list transmitted with the PUT /consents method
    • The URI for the GET /accounts/transactions method if the account is included in the transactions list transmitted with the PUT /consents method
  • to get the list containing all the delayed debit cards linked to the consented accounts with :
    • their outstandings if the delayed debit card (*) is linked to an account included in the balances list transmitted with the PUT /consents method
    • The URI for the GET /accounts/balances method if the delayed debit card is linked to an account included in the balances list transmitted with the PUT /consents method
    • The URI for the GET /accounts/transactions method if the delayed debit card is linked to an account included in the transactions list transmitted with the PUT /consents method
  • to get the URI for the “GET /end-user-identity” method if the “psuIdentity” field is at TRUE with the PUT /consents method

• This call doesn’t allow you
  • to get the accounts and delayed debit cards for the non consented accounts

The result may be subject to pagination in case of having too many accounts or cards in it. In this case, to make the results easier to read, there will be navigation links to access to the first, the next, the previous or the last page of results.

A self link will also be displayed in order to go back to the page obtained right after the request execution.

Access to this method is limited to a maximum of 4 batch accesses per calendar day, for a given customer (pagination not included). On the contrary, when the online customer asks his accounts directly, the accesses number is not limited.

The property “psuStatus” is given the “Account Co-Holder” value as long as the customer is not the only account’s holder.

For accounts representing a deferred debit card, the data “accountId / other / identification” contains the encrypted identifier of the card. In addition, the “name” object contains at the end of the string the last 4 digits of the card’s PAN preceded by “XX” which allows the PSU to identify its card if it has more than one.

(*) This API covers active delayed cards which have been used at least once in the past two months.

Example without consent registred with PUT /consents

Request

GET /stet/psd2/v1.4.2/accounts/

Result

Status code : 200

Body
{ {

“_links”: { “last”: { “href”: “https://www.rs-sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts?page=last” }, “self”: { “href”: “https://www.rs-sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts” }, “first”: { “href”: “https://www.rs-sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts” }, “endUserIdentity”: { “href”: “https://www.rs-sandbox.api.89c3.com/stet/psd2/v1.4.2/end-user-identity” } }, “accounts”: [ { “cashAccountType”: “CACC”, “accountId”: { “iban”: “FR7613807008043001965409135”, “currency”: “EUR” }, “resourceId”: “038-CPT30019654091”, “product”: “COMPTE COURANT”, “_links”: {}, “usage”: “ORGA”, “psuStatus”: “Account Holder”, “name”: “Tech-N Co”, “bicFi”: “CCBPFRPPNAN”, “details”: “COMPTE COURANT” } ] }

(data set Tech-N Co’s persona – D0999993I0)

Remarks :

• The “currency” field was moved to the “accountId” level

Example with two delayed debit cards et consent registred with PUT /consents

Request

GET /stet/psd2/v1.4.2/accounts/

Result

Status code : 200

Body
{

{

“_links”: {

“last”: { “href”: “https://www.rs-sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts?page=last” }, “self”: { “href”: “https://www.rs-sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts” }, “first”: { “href”: “https://www.rs-sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts” }, “endUserIdentity”: { “href”: “https://www.rs-sandbox.api.89c3.com/stet/psd2/v1.4.2/end-user-identity” } }, “accounts”: [ { “cashAccountType”: “CACC”, “accountId”: { “iban”: “FR7613807008063031966574122”, “currency”: “EUR” }, “resourceId”: “038-CPT30319665741”, “product”: “COMPTE CHEQUE”, “balances”: [ { “balanceType”: “VALU”, “name”: “Solde en Valeur”, “balanceAmount”: { “amount”: “0”, “currency”: “EUR” }, “referenceDate”: “2020-06-05” }, { “balanceType”: “CLBD”, “name”: “Solde Comptable”, “balanceAmount”: { “amount”: “0”, “currency”: “EUR” }, “referenceDate”: “2020-06-04” }, { “balanceType”: “OTHR”, “name”: “Solde TP”, “balanceAmount”: { “amount”: “0”, “currency”: “EUR” } } ], “_links”: { “balances”: { “templated”: false, “href”: “https://www.rs-sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts/038-CPT30319665741/balances” }, “transactions”: { “templated”: false, “href”: “https://www.rs-sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts/038-CPT30319665741/transactions” } }, “usage”: “PRIV”, “psuStatus”: “Account Holder”, “name”: “BARDE ADAM”, “bicFi”: “CCBPFRPPNAN”, “details”: “COMPTE CHEQUE” }, { “cashAccountType”: “CACC”, “accountId”: { “iban”: “FR7613807008063031966574219”, “currency”: “EUR” }, “resourceId”: “038-CPT30319665742”, “product”: “COMPTE COURANT”, “balances”: [ { “balanceType”: “VALU”, “name”: “Solde en Valeur”, “balanceAmount”: { “amount”: “-2894.05”, “currency”: “EUR” }, “referenceDate”: “2020-06-05” }, { “balanceType”: “CLBD”, “name”: “Solde Comptable”, “balanceAmount”: { “amount”: “-2894.05”, “currency”: “EUR” }, “referenceDate”: “2020-06-04” }, { “balanceType”: “OTHR”, “name”: “Solde TP”, “balanceAmount”: { “amount”: “-2894.05”, “currency”: “EUR” } } ], “_links”: { “balances”: { “templated”: false, “href”: “https://www.rs-sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts/038-CPT30319665742/balances” }, “transactions”: { “templated”: false, “href”: “https://www.rs-sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts/038-CPT30319665742/transactions” } }, “usage”: “ORGA”, “psuStatus”: “Account Holder”, “name”: “SARL UNI PICCOLO”, “bicFi”: “CCBPFRPPNAN”, “details”: “COMPTE COURANT” }, { “cashAccountType”: “CARD”, “accountId”: { “other”: { “identification”: “C01WcBfYTK70wJJ5LpsMI3EGQ==”, “schemeName”: “CPAN”, “issuer”: “13807” }, “currency”: “EUR” }, “resourceId”: “038-GFCC01WcBfYTK70wJJ5LpsMI3EGQ”, “product”: “Visa Classic”, “balances”: [ { “balanceType”: “OTHR”, “name”: “Encours”, “balanceAmount”: { “amount”: “0”, “currency”: “EUR” }, “referenceDate”: “2020-06-30” }, { “balanceType”: “OTHR”, “name”: “Dernier encours prélevé”, “balanceAmount”: { “amount”: “78.65”, “currency”: “EUR” }, “referenceDate”: “2020-05-31” } ], “_links”: { “balances”: { “templated”: false, “href”: “https://www.rs-sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts/038-GFCC01WcBfYTK70wJJ5LpsMI3EGQ/balances” }, “transactions”: { “templated”: false, “href”: “https://www.rs-sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts/038-GFCC01WcBfYTK70wJJ5LpsMI3EGQ/transactions” } }, “usage”: “PRIV”, “psuStatus”: “Account Holder”, “name”: “M ADAM BARDE XX9351”, “linkedAccount”: “038-CPT30319665741”, “bicFi”: “CCBPFRPPNAN”, “details”: “CB VISA FACELIA DEBIT DIFFERE” }, { “cashAccountType”: “CARD”, “accountId”: { “other”: { “identification”: “C01mS9kXqK80z5X19/E7WmZjw==”, “schemeName”: “CPAN”, “issuer”: “13807” }, “currency”: “EUR” }, “resourceId”: “038-GFCC01mS9kXqK80z5X19_E7WmZjw”, “product”: “Visa Classic”, “balances”: [ { “balanceType”: “OTHR”, “name”: “Encours”, “balanceAmount”: { “amount”: “0”, “currency”: “EUR” }, “referenceDate”: “2020-06-30” }, { “balanceType”: “OTHR”, “name”: “Dernier encours prélevé”, “balanceAmount”: { “amount”: “156.27”, “currency”: “EUR” }, “referenceDate”: “2020-05-31” } ], “_links”: { “balances”: { “templated”: false, “href”: “https://www.rs-sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts/038-GFCC01mS9kXqK80z5X19_E7WmZjw/balances” }, “transactions”: { “templated”: false, “href”: “https://www.rs-sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts/038-GFCC01mS9kXqK80z5X19_E7WmZjw/transactions” } }, “usage”: “PRIV”, “psuStatus”: “Account Holder”, “name”: “M ADAM BARDE XX4620”, “linkedAccount”: “038-CPT30319665741”, “bicFi”: “CCBPFRPPNAN”, “details”: “VISA INTERNATIONALE DB DIFFERE” } ]}

(data set Adam’s persona – D0999994I0)

Remarks :

• The “connectedPsu” field was deleted and replaced by the “endUserIdentity” link

Example with pagination

Request

GET /stet/psd2/v1.4.2/accounts?page=2

Result

Status code : 200

Body
{

“accounts”: [ { “cashAccountType”: “CACC”,”accountId”: { “iban”: “FR7613807008043099888880699″,”currency”: “EUR” }, “resourceId”: “038-CPT30998888806″,”product”: “COMPTE CHEQUE”,”balances”: [ { “balanceType”: “VALU”,”name”: “Solde en Valeur”,”balanceAmount”: { “amount”: “6.78”, “currency”: “EUR” }, “referenceDate”: “2020-06-05”}, { “balanceType”: “CLBD”,”name”: “Solde Comptable”,”balanceAmount”: { “amount”: “6.78”, “currency”: “EUR” },”referenceDate”: “2020-06-04”}, { “balanceType”: “OTHR”,”name”: “Solde TP”,”balanceAmount”: { “amount”: “6.78”,”currency”: “EUR” } } ], “_links”: { “balances”: { “templated”: false, “href”: “https://www.rs-sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts/038-CPT30998888806/balances” }, “transactions”: { “templated”: false, “href”: “https://www.rs-sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts/038-CPT30998888806/transactions” } }, “usage”: “PRIV”, “psuStatus”: “Nominee”, “name”: “Compte mensualités”, “bicFi”: “CCBPFRPPNAN”, “details”: “COMPTE CHEQUE” }, { “cashAccountType”: “CACC”, “accountId”: { “iban”: “FR7613807008043099888880799”, “currency”: “EUR” }, “resourceId”: “038-CPT30998888807”, “product”: “COMPTE CHEQUE”, “balances”: [ { “balanceType”: “VALU”, “name”: “Solde en Valeur”, “balanceAmount”: { “amount”: “7.6”, “currency”: “EUR” }, “referenceDate”: “2020-06-05” }, { “balanceType”: “CLBD”, “name”: “Solde Comptable”, “balanceAmount”: { “amount”: “7.6”, “currency”: “EUR” },”referenceDate”: “2020-06-04” }, { “balanceType”: “OTHR”, “name”: “Solde TP”, “balanceAmount”: { “amount”: “7.6”, “currency”: “EUR” } } ], “_links”: {“balances”: { “templated”: false, “href”: “https://www.rs-sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts/038-CPT30998888807/balances” },”transactions”: { “templated”: false,”href”: “https://www.rs-sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts/038-CPT30998888807/transactions” } }, “usage”: “PRIV”,”psuStatus”: “Successor On Death”,”name”: “Compte perso”,”bicFi”: “CCBPFRPPNAN”,”details”: “COMPTE CHEQUE” }, { “cashAccountType”: “CACC”,”accountId”: { “iban”: “FR7613807008043099888880899”, “currency”: “EUR” }, “resourceId”: “038-CPT30998888808”, “product”: “COMPTE CHEQUE”, “balances”: [ { “balanceType”: “VALU”, “name”: “Solde en Valeur”,”balanceAmount”: { “amount”: “8.8”, “currency”: “EUR” }, “referenceDate”: “2020-06-05” }, { “balanceType”: “CLBD”,”name”: “Solde Comptable”,”balanceAmount”: {“amount”: “8.8”,”currency”: “EUR”},”referenceDate”: “2020-06-04”},{“balanceType”: “OTHR”,”name”: “Solde TP”,”balanceAmount”: { “amount”: “8.8”,”currency”: “EUR” } } ], “_links”: { “balances”: { “templated”: false, “href”: “https://www.rs-sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts/038-CPT30998888808/balances” }, “transactions”: { “templated”: false, “href”: “https://www.rs-sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts/038-CPT30998888808/transactions” }}, “usage”: “PRIV”, “psuStatus”: “Trustee”, “name”: “Retrait et Cheques”, “bicFi”: “CCBPFRPPNAN”, “details”: “COMPTE CHEQUE 8” }, { “cashAccountType”: “CACC”, “accountId”: { “iban”: “FR7613807008043099888880999”, “currency”: “EUR” }, “resourceId”: “038-CPT30998888809”, “product”: “COMPTE CHEQUE”, “balances”: [ { “balanceType”: “VALU”, “name”: “Solde en Valeur”, “balanceAmount”: { “amount”: “9.9”, “currency”: “EUR” }, “referenceDate”: “2020-06-05” }, { “balanceType”: “CLBD”, “name”: “Solde Comptable”, “balanceAmount”: { “amount”: “9.9”, “currency”: “EUR” },”referenceDate”: “2020-06-04”},{ “balanceType”: “OTHR”,”name”: “Solde TP”,”balanceAmount”: { “amount”: “9.9”,”currency”: “EUR” } } ], “_links”: { “balances”: { “templated”: false, “href”: “https://www.rs-sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts/038-CPT30998888809/balances” }, “transactions”: { “templated”: false, “href”: “https://www.rs-sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts/038-CPT30998888809/transactions” } }, “usage”: “PRIV”, “psuStatus”: “Trustee”,”name”: “Retrait et Cheques”,”bicFi”: “CCBPFRPPNAN”,”details”: “COMPTE CHEQUE 9” }, { “cashAccountType”: “CACC”,”accountId”: {“iban”: “FR7613807008043099888881099″,”currency”: “EUR”}, “resourceId”: “038-CPT30998888810″,”product”: “COMPTE CHEQUE”,”balances”: [ { “balanceType”: “VALU”, “name”: “Solde en Valeur”, “balanceAmount”: { “amount”: “10.10”, “currency”: “EUR” }, “referenceDate”: “2020-06-05” }, { “balanceType”: “CLBD”, “name”: “Solde Comptable”, “balanceAmount”: { “amount”: “10.10”,”currency”: “EUR” },”referenceDate”: “2020-06-04” }, { “balanceType”: “OTHR”, “name”: “Solde TP”, “balanceAmount”: { “amount”: “10.10”, “currency”: “EUR” } } ], “_links”: { “balances”: { “templated”: false, “href”: “https://www.rs-sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts/038-CPT30998888810/balances” }, “transactions”: { “templated”: false, “href”: “https://www.rs-sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts/038-CPT30998888810/transactions” } }, “usage”: “PRIV”, “psuStatus”: “Trustee”, “name”: “Retrait et Cheques”, “bicFi”: “CCBPFRPPNAN”, “details”: “COMPTE CHEQUE 10” } ], “_links”: { “next”: { “href”: “https://www.rs-sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts?page=3” }, “last”: { “href”: “https://www.rs-sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts?page=last” }, “prev”: { “href”: “https://www.rs-sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts” }, “self”: { “href”: “https://www.rs-sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts?page=2” }, “first”: { “href”: “https://www.rs-sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts” }, “endUserIdentity”: { “href”: “https://www.rs-sandbox.api.89c3.com/stet/psd2/v1.4.2/end-user-identity” } } }

A more complex example of request is given in “Sandbox assembly” use case.

Error code

Here is the list of error codes descriptions for each service. There is a red annotation for errors being described in the CFONB codification.

 

Error	Error description
AC01 (CFONB)	IncorrectAccountNumber : account number is invalid or missing
AC04 (CFONB)	ClosedAccountNumber : account has been closed
AC06 (CFONB)	BlockedAccount : account is blocked, prohibiting posting of transactions against it
BE05 (CFONB)	UnrecognisedInitiatingParty : the AISP is not recognised
BADS	BadScope : request with an access token which is not authorized to access to the resource (incorrect CBPII scope, instead of expected AISP scope)
INTE	InternalError : there was an internal processing error
INTS	InternalServerError : there was an internal communication error with the information system
IPGN	InvalidPageNumber : the page number is invalid
NAAC	No avalaible accounts : absence of eligible or granted accounts
NGAC	NotGrantedAccount : access to the account has not been granted
NIMP	NotImplemented : invalid method used (GET method expected)
TMRQ	TooManyRequest : the maximum number of requests has been exceeded
IPSU	InvalidPSU : unregistered subscriber number or terminated Cyber subscription

 

Acceptation tests

The purpose of these tests is to allow you to practice some tests in order to take charge of the API to access it from your application.

 

Test description	Dataset
Retrieve all the accounts of a customer (at least 2 accounts shall be configured in the ASPSP) => Verification of the mandatory hypermedia links (balances, self and transactions)	Persona : Alix – D0999992I0 Prerequisite : scope OAuth2 = aisp Result : response HTTP 200 => OK Retrieval of three accounts and three delayed debit cards
Retrieve plenty of accounts linked to a customer and verify that the ASPSP uses correctly the pagination mechanism =>Verification of the optional hypermedia links prev, next, last.	Persona : Marc – D0999990I0 Prerequisite : scope OAuth2 = aisp Result : response HTTP 200 => OK return three accounts all on the same page
Retrieve plenty of accounts and cards linked to a customer and verify that the ASPSP uses correctly the pagination mechanism =>Verification of the optional hypermedia links first, prev, next, last.	Persona : Adam – D0999994I0 Prerequisite : scope OAuth2 = aisp Result : response HTTP 200 => OK return two accounts and two delayed debit cards
HTTP request with an access token which is not authorized to access to this resource (incorrect scope)	Persona : Marc – D0999990I0 Prerequisite : scope OAuth2 <> aisp Result : response HTTP403 => Access to the resource is not allowed error message : BADS
HTTP request using POST method	Persona : Marc – D0999990I0 Prerequisite : scope OAuth2 = aisp Result : response HTTP405 => method not allowed

Forward customer's consentend accounts lists

Use case

This service allows to record the customer consent.

This consent includes the accesses granted by the customer.

Four access types (or operation types) can be forwarded :

• “balances” => access to one or many customer accounts balances report
• “transactions” => access to one or many customer accounts transaction sets
• “psuIdentity” => access to the customer identity (first name and last name)
• “trustedBeneficiaries” => access to the trusted beneficiaries list that have been set by the customer => this feature is not available on direct access neither via API (see “Limitations” heading in product page).

Therefore, a consent record is made for one given customer.

Each new AISP call to the consent service, for one given customer, replaces any prior consent that was previously sent by the AISP.

Furthermore, upon the customer’s request, the consent may be updated subsequently for an operation type : for example, access to transactions can be revoked while access to balances stay active.

The consent is checked for each request send.

In summary, this service allows you to transmit the IBAN of the demand accounts for which the customer has authorized you to consult the details of balances and / or transactions and its identity.

Prerequisite

You can retrieve the customer’s accounts list after a first call to the GET /accounts request : you will find for each account the linked IBAN, that means “accountId“: {“iban”}.

However if you already know the customer accounts IBANs, you can transmit them directly with the PUT /consents method. In this case, in order to process this request it’s needed to fill eligibility prerequisite and to get the OAUTH2 access token (see the use case “Get your access token”).

Request

Request “put/consents”

Mandatory or facultative body parameters needed for this service

balances– array is mandatory but it can be empty : list of accessible accounts for the “balances” functionality

⇒ iban – mandatory : International Bank Account Number (IBAN)

transactions– array is mandatory but it can be empty : list of accessible accounts for the “transactions ” functionality

⇒ iban – mandatory : International Bank Account Number (IBAN)

trustedBeneficiaries – mandatory : indicator feld indicating whether or not the access to the trusted beneficiaries list was granted to the AISP by the customer (true or false)

psuIdentity – mandatory : indicator field indicating whether or not the access to the customer identity, first name and last name, was granted to the AISP by the customer (true or false)

facultative parameter : PSU-IP-ADDRESS => parameter is mandatory if the customer is connected

Returned result

This call allows to record the consent of the customer (Payment Service User) on behalf of whom the AISP (Account Information Service Providers) is connected..

Four access types (or operation types) can be forwarded :

• “psuIdentity” => access to the customer identity (first name and last name);
  • Customer id is available with the GET /end-user-identity method only if the customer has given his consent;
• “transactions” => access to one or many customer’s accounts transaction and to the linked delayed debit cards slips;
  • The accounts transactions sets and the linked delayed debit cards slips are available with the GET /accounts method and the GET /accounts/balances method for the consented accounts only;
• “balances” => access to one or many customer’s accounts balances report and to the linked delayed debit cards outstandings :
  • The accounts balances and the linked delayed debit cards outstandings are available with the GET /accounts method and the GET /accounts/balances method for the consented accounts only;

• “trustedBeneficiaries” => access to the trusted beneficiaries list that have been set by the customer
  • this feature is not available on direct access neither via API

It is possible to call several times the PUT /consents method if the customer has changed his consent : every new call of the PUT /consents method cancel and replace the previous consents.

The customer consent is checked for every new request with GET /accounts, GET /accounts/balances and GET /accounts/transactions methods.

When an account is consented for the “balances” access :

• The delayed debit cards are available with the GET /accounts method;
• The cards outstandings are available with the GET /accounts method or the GET /accounts/balances method.

When an account is consented for the “transactions” access :

• The delayed debit cards are available with the GET /accounts method;
• The cards slips are available with the GET /accounts/transactions method.

If no account is transmitted with the PUT /consents method and that consent was given for some accounts with a previous call to this method, then it means that the customer is revoking all his accounts.

If no account is consented or if the customer has revoked all this consented accounts, the GET /accounts method allows to get all the accounts list but access to balances and transactions and access to delayed debit cards and to their outstandings and slips isn’t possible anymore.

Example

Request

PUT /stet/psd2/v1.4.2/consents/

A more complete example of request is given in “Sandbox assembly” use case.

See also STET V1.4.2.41 / Part III / section 6.2 / page 7

Result

Status code : 201

The consent service returns a code “201 – Created” when the consent is successfully recorded

The consent service returns a code “403 – Forbidden” in case of record failure

Body

{

“balances”: [{“iban”: “FR7613807008043001965405158”},{“iban”: “FR7613807008043001965405255”},{“iban”: “FR7613807008043001965405352”}],

“transactions”: [{“iban”: “FR7613807008043001965405158”},{“iban”: “FR7613807008043001965405255”},{“iban”: “FR7613807008043001965405352″}],”trustedBeneficiaries”: true,”psuIdentity”: true}

(data set Marc’s persona – D0999990I0)

Remarks :

• The “currency” field was moved to the “AccountIdentification” section

Error code

Here is the list of error codes descriptions for each service. There is a red annotation for errors being described in the CFONB codification.

 

Error	Error description
AC01 (CFONB)	IncorrectAccountNumber : account number is invalid or missing
AC04 (CFONB)	ClosedAccountNumber
AC06 (CFONB)	BlockedAccount
BE05 (CFONB)	UnrecognisedInitiatingParty
BADS	BadScope : request with an access token which is not authorized to access to the resource (incorrect CBPII scope, instead of expected AISP scope)
ENDE	EntriesDatesError
IPGN	InvalidPageNumber
INTE	InternalError : there was an internal processing error
INTS	InternalServerError : there was an internal communication error with the information system
NGAC	NotGrantedAccount
NIMP	NotImplemented
TMRQ	TooManyRequest
RENF	ReferenceNotFound
IPSU	InvalidPSU
FF01	Bad Request : Request’s body format incorrect (empty body, missing mandatory data)
NAAC	NotAvailableAccounts
CDNA	CardNotAvailable

Acceptation tests

These test cases are intended to allow you to perform a minimum of tests to take in hand this API and access it from your application.

 

Test description	Dataset
Add / upate the consent of a customer	Persona : Marc – D0999990I0 Prerequisite : scope OAuth2 = aisp IBANs : FR7613807008043001965405158 FR7613807008043001965405255 FR7613807008043001965405352 Result : response HTTP 201 => OK, consent recorded
Add / upate the consent of a customer	Persona : Adam – D0999994I0 Prerequisite : scope OAuth2 = aisp IBANs : FR7613807008063031966574122 FR7613807008063031966574219 Result : réponse HTTP 201 => OK, consent recorded
HTTP request with an access token which is not authorized to access to this resource (incorrect scope)	Persona : Marc – D0999990I0 Prerequisite : scope OAuth2 <> aisp IBANs : FR7613807008043001965405158 FR7613807008043001965405255 FR7613807008043001965405352 Result : response HTTP 403 => Access to the resource is not allowed error message : BADS
HTTP request using POST method	Persona : Marc – D0999990I0 Prerequisite : scope OAuth2 = aisp IBANs : FR7613807008043001965405158 FR7613807008043001965405255 FR7613807008043001965405352 Result : response HTTP 405 => method not allowed

Get accounting balance

Use case

This service allows to get the account balance report or the outstandings list of the customer delayed debit card.

This service follows the return of the list of current accounts and debit cards for a customer : a resource identifier corresponding to an account or card must be provided to obtain the list of balances / outstandings.

3 balance types will be returned in the case of an account beeing passed as a parameter :

• Value date balance (“VALU” in the STET standard) => value-date balance, displayed balance in relation to a value date
• Accounting balance (“CLBD” in the STET standard) => accounting balance at the end of a period (end of week, end of month, end of quarter, end of year)
• Instant balance (“OTHR” in the STET standard) => instant balance (evolves in real time with each account posting)

3 outstanding types will be returned in the case of a card beeing passed as a parameter :

• Outstandings => card slips amounts reported to the following month
• Undrawn finished outstandings => current month’s card slips amounts that were not already posted
• Drawn finished outstandings => previous month’s card slips amounts

In the case of a lot of data returned a pagination will be done with links giving access to first page, previous one, next one and last one in order to make easier the result consultation.

Access to this method is limited to a maximum of 4 batch accesses per calendar day, for one given TPP.

In summary, this service makes it possible to list the balances of a current account of the customer or to list the outstandings of a deferred debit card backed up by this current account.

Prerequisite

In order to process this request it ‘s needed to fill the eligibility and to get the OAUTH2 access token (see the use case “Get your access token”).

Retrieval of a account balances report :

• The IBAN account should have been transmitted in the balances list of PUT /consents method and shouldn’t be revoked since (<=> no cancel and replace using PUT /consents method without the IBAN in the transactions list) ;
• The “accountResourceId” field as an account parameter of this method, is obtained with the result of the GET /accounts method in the “resourceId” field for the account linked to this IBAN, that means :”accountId“: {“iban” } ;
• URI for this method access is given by the field “_links“: {“balances”: {“href”: …}} result of the GET /accounts request for the “resourceId” field of the account.

In order to get the outstandings of a delayed debit card linked to an account :

• The IBAN account should have been transmitted in the balances list of PUT /consents method and shouldn’t be revoked since (<=> no cancel and replace using PUT /consents method without the IBAN in the transactions list) ;
• The “accountResourceId” field as a delayed debit card parameter of this method, is obtained with the result of the GET /accounts method in the “resourceId” field for the delayed debit card, that means :”accountId“: {“other”: {“schemeName”: “CPAN”}}) with “linkedAccount” wich corresponds to “resourceId” field of the accountwith “resourceId” filed of the account obtained with GET /accounts request and with “accountId“: {“iban” } ;
• URI for this method access is given by the field “_links“: {“balances”: {“href”: …}} result of the GET /accounts request for the “resourceId” field of delayed debit card.

Request

Request “get/accounts/{accountResourceId}/balances”

see also STET V1.4.2.17 / Part II / Section 4.3.4 / page 31

Mandatory or facultative body parameters needed for this service

Mandatory parameter accountResourceId : account we want to consult the balances or delayed debit card we want to consult the outstandings, this data matches with the field “resourceId” obtained in the result page of GET /accounts.

facultative parameter : PSU-IP-ADDRESS => parameter is mandatory if the customer is connected

Returned result

This call allows to get :

• balances list for the account passed as a parameter ;
• or the outstandings list of the delayed debit card passed as a parameter.

3 types of balances will be returned in the case of an account passed as a parameter:

 

Value date balance (“VALU” in the STET standard)	=> value-date balance, displayed balance in relation to a value date
Accounting balance (“CLBD” in the STET standard)	=> accounting balance at the end of a period (end of week, end of month, end of quarter, end of semester, end of year)
Instant balance (“OTHR” in the STET standard)	=> instant balance (evolves in real time with each account posting)

3 types of outstandings will be returned in the case of a card passed as a parameter :

 

Outstandings	=> card slips amounts reported to the following month
Undrawn finished outstandings	=> current month’s card slips amounts that were not already posted
Drawn finished outstandings	=> previous month’s card slips amounts

A self link will also be displayed in order to go back to the page obtained right after the request execution.

Access to this method is limited to a maximum of 4 batch accesses per calendar day for an association of one customer and one account or delayed debit card given (pagination not included). On the contrary, when the online customer asks his accounts directly, the accesses number is not limited.

Example

Request

GET /stet/psd2/v1.4.2/accounts/038-CPT30019654051/balances

A more complete example of a query is provided in the use case “Sandbox assembly”.

See also STET V1.4.2.17 / Part III / Section 6.4 / page 9

Result

Status code : 200

Body
{

“balances”: [

{

“balanceType”: “VALU”,

“name”: “Solde en Valeur”,

“balanceAmount”: {

“amount”: “2165.5”,

“currency”: “EUR”

},

“referenceDate”: “2020-06-08”

},

{

“balanceType”: “CLBD”,

“name”: “Solde Comptable”,

“balanceAmount”: {

“amount”: “2165.5”,

“currency”: “EUR”

},

“referenceDate”: “2020-06-07”

},

{

“balanceType”: “OTHR”,

“name”: “Solde TP”,

“balanceAmount”: {

“amount”: “2165.5”,

“currency”: “EUR”

}

}

],

“_links”: {

“self”: {

“href”: “https://www.13807.sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts/038-CPT30019654053/balances”

},

“transactions”: {

“href”: “https://www.13807.sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts/038-CPT30019654053/transactions”

},

“parent-list”: {

“href”: “https://www.13807.sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts”

}

}

}
(data set Marc’s persona – D0999990I0)

Error code

Here is the list of error codes descriptions for each service. There is a red annotation for errors being described in the CFONB codification.

 

Error	Error description
AC01 (CFONB)	IncorrectAccountNumber : account number is invalid or missing
AC04 (CFONB)	ClosedAccountNumber : account has been closed
AC06 (CFONB)	BlockedAccount : account is blocked, prohibiting posting of transactions against it
BE05 (CFONB)	UnrecognisedInitiatingParty : the AISP is not recognised
BADS	BadScope : request with an access token which is not authorized to access to the resource (incorrect CBPII scope, instead of expected AISP scope)
INTE	InternalError : there was an internal processing error
INTS	InternalServerError : there was an internal communication error with the information system
NGAC	NotGrantedAccount : access to the account has not been granted
NIMP	NotImplemented : invalid method used (GET method expected)
TMRQ	TooManyRequest : the maximum number of requests has been exceeded
IPSU	InvalidPSU : unregistered subscriber number or terminated Cyber subscription

 

Acceptation tests

The purpose of these tests is to allow you to practice some tests in order to take charge of the API to access it from your application.

 

Test description	Dataset
Retrieve all the balances linked to a customer’s account => Verification of the hypermedia links (self, balances and transactions)	Persona : Marc – 038-CPT30019654051 Prerequisite : scope OAuth2 = aisp Result : response HTTP 200 => OK Retrieve the three balances of the PSU’s account
Retrieve all the balances linked to a customer’s account with balances equals to 0 => Verification of the hypermedia links (self, balances and transactions)	Persona : Adam – 038-CPT30319665741 Prerequisite : scope OAuth2 = aisp Result : réponse HTTP 200 => OK Retrieve the three balances of the PSU’s account The balances are equals to 0
Retrieve the balances linked to an unknown account	Persona : Inconnu – 038-CPT30014684067 Prerequisite : scope OAuth2 = aisp Result : response HTTP 404 => unknown account error message : AC01
HTTP resuqest with access token not allowed for the ressource (bad scope)	Persona : Marc – 038-CPT30019654051 Prerequisite : scope OAuth2 <> aisp Result : response HTTP 403 => Access to the resource is not allowed error message : BADS
HTTP POST request execution	Persona : Marc – 038-CPT30019654051 Prerequisite : scope OAuth2 = aisp Result : response HTTP 405 => method not allowed

Get transactions history

Use case

This service allows to get the account transaction set or delayed debit card slips list of our customer.

The transactions returned are transactions with a date within 90 days from the current date.

The result may be subject to pagination in case of having too many results. In this case, to make the results easier to read, there will be navigation links to access to the first, the next, the previous or the last page of results.

This service follows the return of the list of current accounts and debit cards for a customer : a resource identifier corresponding to an account or card must be provided to obtain the list of transactions / card slips.

Access to this method is limited to a maximum of 4 batch accesses per calendar day for one given TPP, pagination not included.

In summary, this service makes it possible to list the transactions of a customer’s current account or to list the slips of a deferred debit card backed up by this current account.

Prerequisite

In order to process this request it ‘s needed to fill the eligibility and to get the OAUTH2 access token (see the use case “Get your access token”).

Retrieval of an account transaction set :

• The IBAN account should have been transmitted in the transactions list of the PUT /consents method and shouldn’t be revoked since (<=> no cancel and replace using PUT /consents method without the IBAN in the transactions list)
• The “accountResourceId” field as an account parameter of this method, is obtained with the result of the GET /accounts method in the “resourceId” field for the account linked to this IBAN, that means : “accountId“: {“iban” } ;
• URI for this method access is given by the field “_links“: {“transactions”: {“href”: …}} result of the GET /accounts request for the “resourceId” field of the account ;

In order to get the slips of a delayed debit card linked to an account :

• The IBAN account whose delayed debit card is linked to should have been transmitted in the transactions list of the PUT /consents method and shouldn’t be revoked since (<=> no cancel and replace using PUT /consents method without the IBAN in the transactions list)
• The “accountResourceId” field as an account parameter of this method, is obtained with the result of the GET /accounts method in the “resourceId” field for the delayde debit card, that means :
  • “accountId“: {“other”: {“schemeName”: “CPAN”}}) with “linkedAccount” wich corresponds to “resourceId” field of the account ;
  • with “resourceId” field of the account obtained with GET /accounts request and with : “accountId“: {“iban” } ;
• URI for this method access is given by the field “_links“: {“transactions”: {“href”: …}} result of the GET /accounts request for the “resourceId” field of delayed debit card

Request

get/account/{accountResourceId}/transactions

See also STET V1.4.0.47 / Part II / section 4.3 / page 12

Mandatory or facultative body parameters needed for this service

Mandatory parameter accountResourceId : account we want to consult the transactions or delayed debit card we want to consult the slips.

Facultative parameters :

• dateFrom=> start date for the sought transactions
• dateTo=> end date for the sought transactions
• EntryReferenceFrom=> minimum value for the incremental technical identification. Only transactions with an entryReference strictly higher than entryReferenceFrom are returned
• EntryReferenceTo=> maximum value for the incremental technical identification. Only transactions with an entryReference less than or equal to entryReferenceTo are returned
• PSU-IP-ADDRESS => parameter is mandatory if the customer is connected

Returned result

This call allows to get :

• The transactions list for the account passed as a parameter
• Or the slips list of the delayed debit card passed as a parameter

The transactions returned are transactions with a date within 90 days from the current date.

The result may be subject to pagination in case of having too many results. In this case, to make the results easier to read, there will be navigation links to access to the first, the next, the previous or the last page of results.

A self link will also be displayed in order to go back to the page obtained right after the request execution.

Access to this method is limited to a maximum of 4 batch accesses per calendar day for an association of one customer and one account or delayed debit card given (pagination not included). On the contrary, when the online customer asks his accounts directly, the accesses number is not limited.

BookingDate is reported in expectedBookingDate when the movement is not counted (status = “PDNG”)

The remittance information contains a new intermediate object “unstructured” (no use of the “structured” object).

Absence of the “entryReference” field for the transactions being processed (status = “PDNG”)

Filling in the “bankTransactionCode” field to categorize transactions.

Filling in the “transactionDate” field with the transaction date (date on which the customer made his transfer or payment).

Filling in the “valueDate” field with the value date (effective debit or credit date).

Filling in the “bookingDate” field with the date on which the transaction entered the accounts

On the account backed by a deferred debit card, the amounts of the card receipts are debited from the account on a day of the month decided by the establishment. Depending on the bank’s configuration, the amounts of the receipts are accumulated in a single debit on the account or, on the contrary, each invoice is debited individually. The invoices not debited on the account are in the status = PDNG state. Once debited, a deferred debit card receipt goes to status = BOOK.

Details on the types of operation

 

Types of operations reported

Transfer issued

Transfer received

Direct debit issued

Direct debit received

Interests

Fees and commissions

Reversal and retrocession

Effects

Financial securities and instruments

Cheques

Cards

Incidents and unpaid bills

Loans

International

Cash, withdrawals and deposits

Others

This is available in the sandbox, in 73 different operation code labels for the 4,500 transactions of the “SARL UNIPERSONNELLE 2640” persona:

 

Operation code label	Type of associated operation
ACHAT PARTS BP	Titres et instruments financiers
ANN VIR SEPA	Virement émis
ANNU EUROVIR	Virement émis
ANNUL FRAIS CB	Extourne et rétrocession
ANNULATION	—
ANNULATION PRLV	—
ARRETE DE CPTE	Intérêts
CASH POOLING	—
CHEQUE BANQUE	Chèques
CHEQUE	Chèques
CHEQUE BANQUE	—
COM.GESTION DEB	—
DEBIT DIFFERE	Cartes
DEPLACE	Chèques
DEPOT ESPECES	Espèces retrait et versement
ECH PRET IMPAYE	—
ECHEANCE PRET	Prêts
ENVOI EXTRAITS	—
EUROPRELEVEMENT	Prélèvement reçu
EUROVIR OCCAS	Virement émis
EUROVIR PERM	Virement émis
EUROVIR SEPA	Virement émis
EUROVIR SEPA	Virement reçu
EUROVIR SEPA RJ	Autres
FACT. CB	—
FACTURE CB	Cartes
FACTURETTES CB	—
FRAIS ANNUL EVI	Virement reçu
FRAIS OU COTIS	Frais et commissions
FRAIS OU COTIS	—
FRAIS VIREMENT	Virement émis
IMP.CARTE BLEUE	Incidents et impayés
IMPAYE EUROPRLV	Virement reçu
INTERETS RETARD	International
LCR DOMICILIEE	Effets
PRELEVEMENT	Prélèvement reçu
RAP COMMERCIAL	International
REGUL.INT.CPTE	—
REM.CARTE BLEUE	Cartes
REM.ENCAISSEMEN	Effets
REMBT EUROPREL	—
REMBT EUROPREL	Virement reçu
REMISE EUROPRL	Prélèvement émis
REMISE EUROPRLV	Prélèvement émis
REMISES CHEQUES	Chèques
RETOUR EUROPREL	—
RETRAIT CAISSE	Espèces retrait et versement
RETRAIT DISTRIB	Cartes
RETRAIT UNIQUE	Espèces retrait et versement
RETRO FR.CHEQUE	—
REVERSEMEN DCC	—
REVRST EUROPREL	Virement reçu
REVRST EUROPRLV	—
REVRST EUROPRV	—
TRANSFERT SOLDE	Espèces retrait et versement
VERST DEPLACE	Espèces retrait et versement
VERST RAPIDE	Espèces retrait et versement
VI TRESORERIE	Virement émis
VI TRESORERIE	Virement reçu
VIR ADMCP CYBER	Virement émis
VIR EURO SIMPLE	Virement reçu
VIR INSTAN EMIS	Virement émis
VIR INSTAN RECU	Virement émis
VIR INTERNAT	Prêts
VIR TRESO CYBER	Virement émis
VIR.AUTOMATIQUE	Virement émis
VIREMENT	Virement émis
VIREMENT	Virement reçu
VIREMENT CREDIT	Virement reçu
VIREMENT DEBIT	Virement émis
VIREMENT EMIS	Virement émis
VIRT PERMANENT	Virement émis

STET v1.4.2.17 is applied: the remittanceInformation field is unstructured => when switching to v1.4.2.17 it is planned to switch to the “structured” format described in this version of the standard.

Example

Request

GET /stet/psd2/v1.4.2/accounts/038-CPT30019654051/transactions?dateFrom=2019-05-01&dateTo=2019-05-16

A more complete example of a query is provided in the use case “Sandbox assembly”.

See also STET V1.4.2.17 / Part III / Section 6.5 / page 10

Result

Status code : 200

Body
{

“_links”: {

“balances”: {

“href”: “https://www.13807.sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts/038-CPT30019654051/balances”

},

“last”: {

“href”: “https://www.13807.sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts/038-CPT30019654051/transactions?page=last&dateFrom=2020-06-03&dateTo=2020-06-09”

},

“self”: {

“href”: “https://www.13807.sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts/038-CPT30019654051/transactions?dateFrom=2020-06-03&dateTo=2020-06-09”

},

“first”: {

“href”: “https://www.13807.sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts/038-CPT30019654051/transactions?dateFrom=2020-06-03&dateTo=2020-06-09”

},

“parent-list”: {

“href”: “https://www.13807.sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts”

}

},

“transactions”: [

{

“resourceId”: “201902000003BD27-4772834”,

“remittanceInformation”: {

“unstructured”: [

“VIR MALLOW MARC”,

“remittance info 2 : libelle perso – CRDT – BOOK”

]

},

“transactionAmount”: {

“amount”: “145”,

“currency”: “EUR”

},

“bankTransactionCode”: {

“subFamily”: “DMCT”,

“code”: “078”,

“domain”: “PMNT”,

“family”: “RCDT”,

“issuer”: “SI EQUINOXE”

},

“bookingDate”: “2020-06-08”,

“valueDate”: “2020-06-09”,

“transactionDate”: “2020-06-07”,

“creditDebitIndicator”: “CRDT”,

“entryReference”: “201902000003BD27-4772834”,

“status”: “BOOK”

},

{

“resourceId”: “201902000003BD27-4772833”,

“remittanceInformation”: {

“unstructured”: [

“VIR M OMAR JAFFRA”,

“remittance info 2 : libelle perso – CRDT – BOOK”

]

},

“transactionAmount”: {

“amount”: “125”,

“currency”: “EUR”

},

“bankTransactionCode”: {

“subFamily”: “DMCT”,

“code”: “078”,

“domain”: “PMNT”,

“family”: “RCDT”,

“issuer”: “SI EQUINOXE”

},

“bookingDate”: “2020-06-08”,

“valueDate”: “2020-06-09”,

“transactionDate”: “2020-06-07”,

“creditDebitIndicator”: “CRDT”,

“entryReference”: “201902000003BD27-4772833”,

“status”: “BOOK”

},

{

“resourceId”: “201902000003BD27-4772832”,

“remittanceInformation”: {

“unstructured”: [

“PRLV SEPA AIDES”,

“remittance info 2 : libelle perso – DBIT – BOOK”

]

},

“transactionAmount”: {

“amount”: “12.23”,

“currency”: “EUR”

},

“bankTransactionCode”: {

“subFamily”: “OTHR”,

“code”: “029”,

“domain”: “PMNT”,

“family”: “RDDT”,

“issuer”: “SI EQUINOXE”

},

“bookingDate”: “2020-06-06”,

“valueDate”: “2020-06-07”,

“transactionDate”: “2020-06-05”,

“creditDebitIndicator”: “DBIT”,

“entryReference”: “201902000003BD27-4772832”,

“status”: “BOOK”

}

]

}
(data set Marc’s persona – D0999990I0)

Request 2

GET /stet/psd2/v1.4.2/accounts/038-CPT30921523550/transactions

Result 2 with pagination

Status code : 200

Body
{

“_links”: {

“next”: {

“href”: “https://www.13807.sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts/038-CPT30921523550/transactions?page=2”

},

“balances”: {

“href”: “https://www.13807.sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts/038-CPT30921523550/balances”

},

“last”: {

“href”: “https://www.13807.sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts/038-CPT30921523550/transactions?page=last”

},

“self”: {

“href”: “https://www.13807.sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts/038-CPT30921523550/transactions”

},

“first”: {

“href”: “https://www.13807.sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts/038-CPT30921523550/transactions”

},

“parent-list”: {

“href”: “https://www.13807.sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts”

}

},

“transactions”: [

{

“expectedBookingDate”: “2020-06-08”,

“resourceId”: “00008BD2B-0000032”,

“remittanceInformation”: {

“unstructured”: [

“COTIS VISA CLASSIC DI”,

“remittance info 2 : libelle perso – DBIT – PDNG”

]

},

“transactionAmount”: {

“amount”: “17”,

“currency”: “EUR”

},

“bankTransactionCode”: {

“subFamily”: “COMM”,

“code”: “358”,

“domain”: “ACMT”,

“family”: “MDOP”,

“issuer”: “SI EQUINOXE”

},

“valueDate”: “2020-06-08”,

“transactionDate”: “2020-06-09”,

“creditDebitIndicator”: “DBIT”,

“entryReference”: “”,

“status”: “PDNG”

},

{

“resourceId”: “050414320765BD2N-0070232”,

“remittanceInformation”: {

“unstructured”: [

“ECHEANCE PRET”,

“remittance info 2 : libelle perso – CRDT – BOOK”

]

},

“transactionAmount”: {

“amount”: “0”,

“currency”: “EUR”

},

“bookingDate”: “2020-06-05”,

“valueDate”: “2020-06-05”,

“transactionDate”: “2020-06-04”,

“creditDebitIndicator”: “CRDT”,

“entryReference”: “050414320765BD2N-0070232”,

“status”: “BOOK”

},

{

“resourceId”: “050414320766BD2N-8242499”,

“remittanceInformation”: {

“unstructured”: [

“VIR Farago”,

“remittance info 2 : libelle perso – CRDT – BOOK”

]

},

“transactionAmount”: {

“amount”: “265.67”,

“currency”: “EUR”

},

“bankTransactionCode”: {

“subFamily”: “DMCT”,

“code”: “078”,

“domain”: “PMNT”,

“family”: “RCDT”,

“issuer”: “SI EQUINOXE”

},

“bookingDate”: “2020-06-05”,

“valueDate”: “2020-06-05”,

“transactionDate”: “2020-06-04”,

“creditDebitIndicator”: “CRDT”,

“entryReference”: “050414320766BD2N-8242499”,

“status”: “BOOK”

},

{

“resourceId”: “201900100001BD27-0000067”,

“remittanceInformation”: {

“unstructured”: [

“COTIS VISA CLASSIC DI”,

“remittance info 2 : libelle perso – DBIT – BOOK”

]

},

“transactionAmount”: {

“amount”: “17”,

“currency”: “EUR”

},

“bankTransactionCode”: {

“subFamily”: “COMM”,

“code”: “358”,

“domain”: “ACMT”,

“family”: “MDOP”,

“issuer”: “SI EQUINOXE”

},

“bookingDate”: “2020-06-05”,

“valueDate”: “2020-06-05”,

“transactionDate”: “2020-06-04”,

“creditDebitIndicator”: “DBIT”,

“entryReference”: “201900100001BD27-0000067”,

“status”: “BOOK”

},

{

“resourceId”: “201900100001BD27-INTSCR”,

“remittanceInformation”: {

“unstructured”: [

“INTS CASH POOL SEP 2019”,

“remittance info 2 : libelle perso – CRDT – BOOK”

]

},

“transactionAmount”: {

“amount”: “763.96”,

“currency”: “EUR”

},

“bookingDate”: “2020-06-05”,

“valueDate”: “2020-06-05”,

“transactionDate”: “2020-06-04”,

“creditDebitIndicator”: “CRDT”,

“entryReference”: “201900100001BD27-INTSCR”,

“status”: “BOOK”

},

{

“resourceId”: “201900100001BD27-LAIZXKL”,

“remittanceInformation”: {

“unstructured”: [

“VIR REJET JOBE SPORTS IN”,

“remittance info 2 : libelle perso – CRDT – BOOK”

]

},

“transactionAmount”: {

“amount”: “336.25”,

“currency”: “EUR”

},

“bankTransactionCode”: {

“subFamily”: “ADJT”,

“code”: “051”,

“domain”: “ACMT”,

“family”: “MCOP”,

“issuer”: “SI EQUINOXE”

},

“bookingDate”: “2020-06-05”,

“valueDate”: “2020-06-05”,

“transactionDate”: “2020-06-04”,

“creditDebitIndicator”: “CRDT”,

“entryReference”: “201900100001BD27-LAIZXKL”,

“status”: “BOOK”

},

{

“resourceId”: “201900100001BD27-WHMAT36”,

“remittanceInformation”: {

“unstructured”: [

“VIR INST ROUSSEAU”,

“remittance info 2 : libelle perso – CRDT – BOOK”

]

},

“transactionAmount”: {

“amount”: “1.00”,

“currency”: “EUR”

},

“bankTransactionCode”: {

“subFamily”: “DMCT”,

“code”: “078”,

“domain”: “PMNT”,

“family”: “RCDT”,

“issuer”: “SI EQUINOXE”

},

“bookingDate”: “2020-06-05”,

“valueDate”: “2020-06-05”,

“transactionDate”: “2020-06-04”,

“creditDebitIndicator”: “CRDT”,

“entryReference”: “201900100001BD27-WHMAT36”,

“status”: “BOOK”

},

{

“resourceId”: “201900100002BD27-0000068”,

“remittanceInformation”: {

“unstructured”: [

“COTIS VISA CLASSIC DI”,

“remittance info 2 : libelle perso – DBIT – BOOK”

]

},

“transactionAmount”: {

“amount”: “17”,

“currency”: “EUR”

},

“bankTransactionCode”: {

“subFamily”: “COMM”,

“code”: “358”,

“domain”: “ACMT”,

“family”: “MDOP”,

“issuer”: “SI EQUINOXE”

},

“bookingDate”: “2020-06-05”,

“valueDate”: “2020-06-05”,

“transactionDate”: “2020-06-04”,

“creditDebitIndicator”: “DBIT”,

“entryReference”: “201900100002BD27-0000068”,

“status”: “BOOK”

},

{

“resourceId”: “201900100002BD27-INTSDE”,

“remittanceInformation”: {

“unstructured”: [

“INTS CASH POOL SEP 2019”,

“remittance info 2 : libelle perso – DBIT – BOOK”

]

},

“transactionAmount”: {

“amount”: “25.51”,

“currency”: “EUR”

},

“bankTransactionCode”: {

“subFamily”: “COMM”,

“code”: “740”,

“domain”: “ACMT”,

“family”: “MDOP”,

“issuer”: “SI EQUINOXE”

},

“bookingDate”: “2020-06-05”,

“valueDate”: “2020-06-05”,

“transactionDate”: “2020-06-04”,

“creditDebitIndicator”: “DBIT”,

“entryReference”: “201900100002BD27-INTSDE”,

“status”: “BOOK”

},

{

“resourceId”: “201900100003BD27-0000069”,

“remittanceInformation”: {

“unstructured”: [

“COTIS VISA CLASSIC DI”,

“remittance info 2 : libelle perso – DBIT – BOOK”

]

},

“transactionAmount”: {

“amount”: “17”,

“currency”: “EUR”

},

“bankTransactionCode”: {

“subFamily”: “COMM”,

“code”: “358”,

“domain”: “ACMT”,

“family”: “MDOP”,

“issuer”: “SI EQUINOXE”

},

“bookingDate”: “2020-06-05”,

“valueDate”: “2020-06-05”,

“transactionDate”: “2020-06-04”,

“creditDebitIndicator”: “DBIT”,

“entryReference”: “201900100003BD27-0000069”,

“status”: “BOOK”

},

{

“resourceId”: “201900100003BD27-INTSDE”,

“remittanceInformation”: {

“unstructured”: [

“INTS CASH POOL SEP 2019”,

“remittance info 2 : libelle perso – DBIT – BOOK”

]

},

“transactionAmount”: {

“amount”: “14.95”,

“currency”: “EUR”

},

“bankTransactionCode”: {

“subFamily”: “COMM”,

“code”: “740”,

“domain”: “ACMT”,

“family”: “MDOP”,

“issuer”: “SI EQUINOXE”

},

“bookingDate”: “2020-06-05”,

“valueDate”: “2020-06-05”,

“transactionDate”: “2020-06-04”,

“creditDebitIndicator”: “DBIT”,

“entryReference”: “201900100003BD27-INTSDE”,

“status”: “BOOK”

},

{

“resourceId”: “201900100004BD27-0000070”,

“remittanceInformation”: {

“unstructured”: [

“COTIS VISA CLASSIC DI”,

“remittance info 2 : libelle perso – DBIT – BOOK”

]

},

“transactionAmount”: {

“amount”: “17”,

“currency”: “EUR”

},

“bankTransactionCode”: {

“subFamily”: “COMM”,

“code”: “358”,

“domain”: “ACMT”,

“family”: “MDOP”,

“issuer”: “SI EQUINOXE”

},

“bookingDate”: “2020-06-05”,

“valueDate”: “2020-06-05”,

“transactionDate”: “2020-06-04”,

“creditDebitIndicator”: “DBIT”,

“entryReference”: “201900100004BD27-0000070”,

“status”: “BOOK”

},

{

“resourceId”: “201900100004BD27-INTSDE”,

“remittanceInformation”: {

“unstructured”: [

“INTS CASH POOL SEP 2019”,

“remittance info 2 : libelle perso – DBIT – BOOK”

]

},

“transactionAmount”: {

“amount”: “51.6”,

“currency”: “EUR”

},

“bankTransactionCode”: {

“subFamily”: “COMM”,

“code”: “740”,

“domain”: “ACMT”,

“family”: “MDOP”,

“issuer”: “SI EQUINOXE”

},

“bookingDate”: “2020-06-05”,

“valueDate”: “2020-06-05”,

“transactionDate”: “2020-06-04”,

“creditDebitIndicator”: “DBIT”,

“entryReference”: “201900100004BD27-INTSDE”,

“status”: “BOOK”

},

{

“resourceId”: “201900100005BD27-0000083”,

“remittanceInformation”: {

“unstructured”: [

“COTIS VISA CLASSIC DI”,

“remittance info 2 : libelle perso – DBIT – BOOK”

]

},

“transactionAmount”: {

“amount”: “17”,

“currency”: “EUR”

},

“bankTransactionCode”: {

“subFamily”: “COMM”,

“code”: “358”,

“domain”: “ACMT”,

“family”: “MDOP”,

“issuer”: “SI EQUINOXE”

},

“bookingDate”: “2020-06-05”,

“valueDate”: “2020-06-05”,

“transactionDate”: “2020-06-04”,

“creditDebitIndicator”: “DBIT”,

“entryReference”: “201900100005BD27-0000083”,

“status”: “BOOK”

},

{

“resourceId”: “201900100005BD27-INTSDE”,

“remittanceInformation”: {

“unstructured”: [

“INTS CASH POOL SEP 2019”,

“remittance info 2 : libelle perso – DBIT – BOOK”

]

},

“transactionAmount”: {

“amount”: “121.55”,

“currency”: “EUR”

},

“bankTransactionCode”: {

“subFamily”: “COMM”,

“code”: “740”,

“domain”: “ACMT”,

“family”: “MDOP”,

“issuer”: “SI EQUINOXE”

},

“bookingDate”: “2020-06-05”,

“valueDate”: “2020-06-05”,

“transactionDate”: “2020-06-04”,

“creditDebitIndicator”: “DBIT”,

“entryReference”: “201900100005BD27-INTSDE”,

“status”: “BOOK”

},

{

“resourceId”: “201900100006BD27-0000084”,

“remittanceInformation”: {

“unstructured”: [

“COTIS VISA CLASSIC DI”,

“remittance info 2 : libelle perso – DBIT – BOOK”

]

},

“transactionAmount”: {

“amount”: “17”,

“currency”: “EUR”

},

“bankTransactionCode”: {

“subFamily”: “COMM”,

“code”: “358”,

“domain”: “ACMT”,

“family”: “MDOP”,

“issuer”: “SI EQUINOXE”

},

“bookingDate”: “2020-06-05”,

“valueDate”: “2020-06-05”,

“transactionDate”: “2020-06-04”,

“creditDebitIndicator”: “DBIT”,

“entryReference”: “201900100006BD27-0000084”,

“status”: “BOOK”

},

{

“resourceId”: “201900100006BD27-INTSDE”,

“remittanceInformation”: {

“unstructured”: [

“INTS CASH POOL SEP 2019”,

“remittance info 2 : libelle perso – DBIT – BOOK”

]

},

“transactionAmount”: {

“amount”: “1.5”,

“currency”: “EUR”

},

“bankTransactionCode”: {

“subFamily”: “COMM”,

“code”: “740”,

“domain”: “ACMT”,

“family”: “MDOP”,

“issuer”: “SI EQUINOXE”

},

“bookingDate”: “2020-06-05”,

“valueDate”: “2020-06-05”,

“transactionDate”: “2020-06-04”,

“creditDebitIndicator”: “DBIT”,

“entryReference”: “201900100006BD27-INTSDE”,

“status”: “BOOK”

},

{

“resourceId”: “201900100007BD27-INTSDE”,

“remittanceInformation”: {

“unstructured”: [

“INTS CASH POOL SEP 2019”,

“remittance info 2 : libelle perso – DBIT – BOOK”

]

},

“transactionAmount”: {

“amount”: “23.63”,

“currency”: “EUR”

},

“bankTransactionCode”: {

“subFamily”: “COMM”,

“code”: “740”,

“domain”: “ACMT”,

“family”: “MDOP”,

“issuer”: “SI EQUINOXE”

},

“bookingDate”: “2020-06-05”,

“valueDate”: “2020-06-05”,

“transactionDate”: “2020-06-04”,

“creditDebitIndicator”: “DBIT”,

“entryReference”: “201900100007BD27-INTSDE”,

“status”: “BOOK”

},

{

“resourceId”: “201900100008BD27-INTSDE”,

“remittanceInformation”: {

“unstructured”: [

“INTS CASH POOL SEP 2019”,

“remittance info 2 : libelle perso – DBIT – BOOK”

]

},

“transactionAmount”: {

“amount”: “49.96”,

“currency”: “EUR”

},

“bankTransactionCode”: {

“subFamily”: “COMM”,

“code”: “740”,

“domain”: “ACMT”,

“family”: “MDOP”,

“issuer”: “SI EQUINOXE”

},

“bookingDate”: “2020-06-05”,

“valueDate”: “2020-06-05”,

“transactionDate”: “2020-06-04”,

“creditDebitIndicator”: “DBIT”,

“entryReference”: “201900100008BD27-INTSDE”,

“status”: “BOOK”

},

{

“resourceId”: “201900100009BD27-INTSDE”,

“remittanceInformation”: {

“unstructured”: [

“INTS CASH POOL SEP 2019”,

“remittance info 2 : libelle perso – DBIT – BOOK”

]

},

“transactionAmount”: {

“amount”: “72.14”,

“currency”: “EUR”

},

“bankTransactionCode”: {

“subFamily”: “COMM”,

“code”: “740”,

“domain”: “ACMT”,

“family”: “MDOP”,

“issuer”: “SI EQUINOXE”

},

“bookingDate”: “2020-06-05”,

“valueDate”: “2020-06-05”,

“transactionDate”: “2020-06-04”,

“creditDebitIndicator”: “DBIT”,

“entryReference”: “201900100009BD27-INTSDE”,

“status”: “BOOK”

}

]

}
(data set SARL Unipersonnelle’s persona – D0999995I0)

Request 3

GET /stet/psd2/v1.4.2/accounts/accounts/038-GFCC01w_pPEk8N32abYfHO0xRDlA/transactions

Result 3

Status code : 200

Body
{

“transactions”: [

{

“resourceId”: “20190311-18040026653”,

“remittanceInformation”: {

“unstructured”: [

“VADE AUTOMOBILE 49SAUMUR”,

“remittance info 2 : libelle perso – DBIT – PDNG”

]

},

“transactionAmount”: {

“amount”: “373.86”,

“currency”: “EUR”

},

“bankTransactionCode”: {

“subFamily”: “POSD”,

“code”: “213”,

“domain”: “PMNT”,

“family”: “CCRD”,

“issuer”: “SI EQUINOXE”

},

“bookingDate”: “2020-06-30”,

“valueDate”: “2020-06-30”,

“transactionDate”: “2020-06-25”,

“creditDebitIndicator”: “DBIT”,

“entryReference”: “”,

“status”: “PDNG”

},

{

“resourceId”: “20190215-17740020330”,

“remittanceInformation”: {

“unstructured”: [

“INFOGREFFE CB 94VINCENNES CED”,

“remittance info 2 : libelle perso – DBIT – BOOK”

]

},

“transactionAmount”: {

“amount”: “3.53”,

“currency”: “EUR”

},

“bankTransactionCode”: {

“subFamily”: “POSD”,

“code”: “213”,

“domain”: “PMNT”,

“family”: “CCRD”,

“issuer”: “SI EQUINOXE”

},

“bookingDate”: “2020-05-31”,

“valueDate”: “2020-05-31”,

“transactionDate”: “2020-06-24”,

“creditDebitIndicator”: “DBIT”,

“entryReference”: “20190215-17740020330”,

“status”: “BOOK”

},

{

“resourceId”: “20190106-17740020329”,

“remittanceInformation”: {

“unstructured”: [

“BRICO DEPOT 49SAUMUR 1952”,

“remittance info 2 : libelle perso – DBIT – BOOK”

]

},

“transactionAmount”: {

“amount”: “66.2”,

“currency”: “EUR”

},

“bankTransactionCode”: {

“subFamily”: “POSD”,

“code”: “213”,

“domain”: “PMNT”,

“family”: “CCRD”,

“issuer”: “SI EQUINOXE”

},

“bookingDate”: “2020-05-31”,

“valueDate”: “2020-05-31”,

“transactionDate”: “2020-06-24”,

“creditDebitIndicator”: “DBIT”,

“entryReference”: “20190106-17740020329”,

“status”: “BOOK”

}

],

“_links”: {

“last”: {

“href”: ” https://www.13807.sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts/038-GFCC01w_pPEk8N32abYfHO0xRDlA/transactions?page=last”

},

“self”: {

“href”: ” https://www.13807.sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts/038-GFCC01w_pPEk8N32abYfHO0xRDlA/transactions”

},

“first”: {

“href”: ” https://www.13807.sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts/038-GFCC01w_pPEk8N32abYfHO0xRDlA/transactions”

},

“parent-list”: {

“href”: ” https://www.13807.sandbox.api.89c3.com/stet/psd2/v1.4.2/accounts”

}

}

}
(data set Alix’s persona – D0999992I0)

Error code

Here is the list of error codes descriptions for each service. There is a red annotation for errors being described in the CFONB codification.

 

Error	Error description
AC01 (CFONB)	IncorrectAccountNumber : account number is invalid or missing
AC04 (CFONB)	ClosedAccountNumber : account has been closed
AC06 (CFONB)	BlockedAccount : account is blocked, prohibiting posting of transactions against it
BE05 (CFONB)	UnrecognisedInitiatingParty : the AISP is not recognised
BADS	BadScope : request with an access token which is not authorized to access to the resource (incorrect CBPII scope, instead of expected AISP scope)
ENDE	EntriesDatesError : one or some of the dates are not correct
INTE	InternalError : there was an internal processing error
INTS	InternalServerError : there was an internal communication error with the information system
IPGN	InvalidPageNumber : the page number is invalid
NGAC	NotGrantedAccount : access to the account has not been granted
NIMP	NotImplemented : invalid method used (GET method expected)
TMRQ	TooManyRequest : the maximum number of requests has been exceeded
RENF	ReferenceNotFound : the transaction reference doesnt exist
IPSU	InvalidPSU : unregistered subscriber number or terminated Cyber subscription

 

Acceptation tests

The purpose of these tests is to allow you to practice some tests in order to take charge of the API to access it from your application.

 

Test description	Dataset
Retrieve of all transactions linked to a customer’s account (under 90 days) => Verification of the mandatory hypermedia links (balances, self, transactions, beneficiaries if any)	Persona : Alix – 038-CPT30019654081 Prerequisite : scope OAuth2 = aisp Result : response HTTP 200 => OK return of the current account transaction set and the delayed debit card slips list
Retrieve of transactions and verify that the ASPSP uses correctly pagination mechanism =>Verification of the optional hypermedia links prev, next, last…	Persona : Alix – 038-CPT30019654081 Prerequisite : scope OAuth2 = aisp Result : response HTTP 200 => OK return of a paginated list of the current account transaction set and the delayed debit card slips, with 3 items per page
Retrieve the transactions linked to an unknown account	Persona : Inconnu – CPT310197919611 Prerequisite : scope OAuth2 = aisp Result : response HTTP 404 => {accountId} is invalid error message : AC01
HTTP request with an access token which is not authorized to access to this resource (incorrect scope)	Persona : Marc – 038-CPT30019654051 Prerequisite : scope OAuth2 <> aisp Result : response HTTP 403 => Access to the resource is not allowed error message : BADS
HTTP request using POST method	Persona : Marc – 038-CPT30019654051 Prerequisite : scope OAuth2 = aisp Result : response HTTP 405 => method not allowed
Retrieve transactions list by passing a dateFrom parameter =>Check that the filter is well applied	Persona : Alix – 038-CPT30019654081 dateFrom : enter “current date – 8 days” Prerequisite : scope OAuth2 = aisp Result : response HTTP 200 => OK return of a list of transactions after the dateFrom passed as a parameter
Retrieve transactions list by passing a dateTo parameter =>Check that the filter is well applied	Persona : Alix – 038-CPT30019654081 dateTo : enter “current date – 1 day” Prerequisite : scope OAuth2 = aisp Result : response HTTP 200 => OK return of a list of transactions before the dateTo passed as a parameter up to the limt of 90 days
Retrieve transactions list by passing an afterEntryReference parameter =>Check that the filter is well applied	Persona : Alix – 038-CPT30019654081 afterEntryReference : 3 Prerequisite : scope OAuth2 = aisp Result : response HTTP 200 => OK return of a list of transactions with an incremental technical identification greater than the afterEntryReference
Retrieve transactions list by passing a dateFrom and a dateTo parameters =>Check that the filter is well applied	Persona : Alix – 038-CPT30019654081 dateFrom : enter “current date – 8 days” dateTo : enter “current date – 2 days” Prerequisite : scope OAuth2 = aisp Result : response HTTP 200 => OK return of a list of transactions within the dateFrom and dateTo passed as parameters
Retrieve transactions list by passing a dateFrom and a afterEntryReference parameters =>Check that the filter is well applied	Persona : Alix – 038-CPT30019654081 dateFrom : enter “current date – 8 days” afterEntryReference : 2 Prerequisite : scope OAuth2 = aisp Result : response HTTP 200 => OK return of a list of transactions with an incremental technical identification greater than the afterEntryReference passed as a parameter and after the dateFrom passed as a parameter
Retrieve transactions list by passing a dateTo and a afterEntryReference parameters =>Check that the filter is well applied	Persona : Alix – 038-CPT30019654081 dateTo : enter “current date – 2 days” afterEntryReference : 2 Prerequisite : scope OAuth2 = aisp Result : response HTTP 200 => OK return of a list of transactions with an incremental technical identification greater than the afterEntryReference passed as a parameter and before the dateTo passed as a parameter, up to the limt of 90 days
Retrieve transactions list by passing a dateFrom and a dateTo and a afterEntryReference parameters =>Check that the filter is well applied	Persona : Alix – 038-CPT30019654081 dateFrom : enter “current date – 8 days” dateTo : enter “current date – 2 days” afterEntryReference : 2 Prerequisite : scope OAuth2 = aisp Result : response HTTP 200 => OK return of a list of transactions with an incremental technical identification greater than the afterEntryReference passed as a parameter and within the dateFrom and dateTo passed as parameters
Request by passing a dateFrom older than 180 days with an “aisp” access token scopes	Persona : Alix – 038-CPT30019654081 dateFrom : enter “current date – 92 days” Prerequisite : scope OAuth2 = aisp Result : response HTTP 400 =>Period out of bound expected error message : ENDE
Request by passing an invalid dateFrom or dateTo	Persona : Alix – 038-CPT30019654081 dateFrom : enter a date with incorrect format Prerequisite : scope OAuth2 = aisp Result : response HTTP 400 => bad request error message : ENDE
Retrieve of transactions with more than 200 transactions in result => Check that 200 transactions are on the first page(pagination)	Persona : Adam – 038-CPT30319665742 Prerequisite : scope OAuth2 = aisp Result : response HTTP 200 => OK 245 transactions are returned in two pages with an historical depth of three months
Retrieve of transactions with 4500 transactions for the 5 accounts and 1 delayed debit card 73 different typologies / operation codes are returned => Check that 200 transactions are on the first page(pagination) when more than 200 transactions are returned	Persona : SARL UNIPERSONNELLE 2640 038-CPT06021917866 => 487 transactions 038-CPT30321656392 => 563 transactions 038-CPT30421008479 => 1 002 transactions 038-CPT30921016530 => 1 230 transactions 038-CPT30921523550 => 1 108 transactions GFCC013iNWXlZ4IXLB6TBcllAPXQ => 110 delayed debit card slips Prerequisite : scope OAuth2 = aisp Result : réponse HTTP 200 => OK

Get trusted beneficiaries list

Use case

This method allows the AISP to retrieve customer”s trusted beneficiaries list through a GET /trustedBeneficiaries request, when the customer has given his consent.

This feature is unavailable yet, a call to this request will return a 405 HTTP code => this feature will not be available in 2020.

Get PSU's identity

Use case

This service allows you to retrieve the customer’s identity who has given you their consent to do so.

Access to this method are limited to a maximum of 4 batch accesses per calendar day, for a given PSU.

To sum up, this service allows you to recover the identity of the PSU.

Prerequisite

To proceed with this request, it is necessary to fulfill the eligibility prerequisites and to have retrieved the OAUTH2 access token (see in the section “Overview” > “Get your access token“).

To get the PSU’s identity, you need :

• The authorization to transmit this identity information to the TPP must have been transmitted to us via the setting to true of the “psuIdentity” attribute of the PUT /consents method and must not have since been revoked (i.e. not cancel and replace via PUT /consents with a “psuIdentity” attribute set to false);
• The URI to access this method is given through the “_links“: {“endUserIdentity”: {“href”: …}} item as a result to the GET /accounts request.

Request

GET /end-user-identity

See also specificationSTET V1.4.2.17 / Part II / section 4.6.4 / page 43

Mandatory or optional settings of the body required to call this service

Mandatory settings : PSU-IP-ADDRESS => to inform if the PSU is connected.

Returned result

This call allows you to get the identity of the end customer

A self link will also be available to return to the page obtained after execution of the request.

Your access to this method are limited to a maximum of 4 batch accesses per calendar day, for a customer. However, when it is the connected customer who directly interrogates his current accounts, the number of accesses is not limited.

Example

Request

GET /stet/psd2/v1.4.2/end-user-identity

A more complete example of a a query is provided in the “Sandbox assembly” use case.

See also specificationSTET V1.4.2.17 / Part III / Section 6.3 / page 8

Result

Status code : 200

Body
{

“connectedPsuNamePrefix”: “MIST”,

“connectedPsu”: “MALLOW MARC”,

“connectedPsuFirstName”: “Marc”,

“connectedPsuLastName”: “MALLOW”,

“_links”: {

“self”: {

“href”: “.sandbox.api.89C3.com/stet/psd2/v1.4.2/end-user-identity” >https://www.<cdetab>.sandbox.api.89C3.com/stet/psd2/v1.4.2/end-user-identity”

},

“parent-list”: {

“href”: “.sandbox.api.89C3.com/stet/psd2/v1.4.2/accounts” >https://www.<cdetab>.sandbox.api.89C3.com/stet/psd2/v1.4.2/accounts”

}

}

}
(data set Marc’s persona – D0999990I0)

Error codes

Here is the list of descriptions of the error codes for this service. There is an annotation for those being defined CFONB.

Link to the description of the method and return codes http

 

Error	Description of the error
BE05(CFONB)	UnrecognisedInitiatingParty : AISP is recognised
BADS	BadScope : the service call was made with a CBPII token (expected AISP)
INTE	InternalError : there is an internet treatment error
INTS	InternalServerError : there is an internet communication error with the IS
NIMP	NotImplemented : the wrong verb is called (GET expected)
IPSU	InvalidPSU : Subscirber number nos listed or remote banking subscription terminated

Acceptance tests

These test cases are intended to allow you to perform a minimum of tests to get started with this API and access it from your application.

 

Description of the test	Data
User identity recovery	Persona : Marc – D0999990I0 Prerequisites : scope OAuth2 = aisp Results : HTTP answer 200 => OK
Recovery of the identity of the user who has not given their consent for this	Persona : Tech’n Co – D0999993I0 Prerequisites : scope OAuth2 = aisp Results : HTTP answer 403 => access to the ressource denied

Try-it console

Process

When you connect on BPCE API portal, you can

• call the Account information API through a form in which you will specify the application, the access / authentication token
• then, you enter the method parameters that you want to test (either headers, either body) the ones with a star are mandatory parameters

Once the parameters entered, you can process the request : either you will get a result, either you will get an error.

For the GET /accounts/transactions and GET /accounts/balances methods, you must first execute the GET /accountsrequest in order to retrieve the current accounts list and the linked delayed debit cards. It will allow you to get the needed “ressourceId” for using these methods.

The data used to make the test in Try-It must come from the provided personas (see the use case “Test data”).

The user can thus choose a specific profile for his test so as to better apprehend the obtained results.

If needed, to make the results easier to read, there will be a navigation with links to the different result pages (see examples in “Get accounts list” and “Get transaction history” use cases).

Creating a test application

The creation of a test application which uses the API stet psd2 v142 on the BPCE API portal is a prerequisite for using the “Try-It” console to test calls to our Account Information API for version v1 .4.2 of the STET standard

If you have already applied for GoLive, then you must create a new application and select the new STET API V1.4.2.

If you have NOT made a GoLive request, you can :

• either modify your existing application to associate it with the new STET V1.4.2 API
• either create a new application, then select the new STET V1.4.2 API

You must have entered the OAuth identifiers with :

• type of application : public
• “*” in the field “Javascript Origins”
• a syntactically valid URL in the “Redirect URLs” field. For example: “https://myapp.com”
• do not put anything in the X.509 Certificate field (just a character “1” for example)

The “test clients” tab allows you to see the identifiers of the personas that will be selectable in the Try-It console.

Preview of the screen allowing to retrieve the Oauth2 token

This screen is accessible when editing the application (dsp2 in our case) ; it allows to generate or edit an Oauth2 token that will be selected in the Try-It execution form.

Overview of the try-it execution form

The Try-It console is available at the top right of the pages presenting the operations available on an API. For example, for the STET v1.4.2 Account Lookup API, if you select an operation in the menu under the STETPSD2V142 block, the description of the operation (from the underlying swagger file) is presented and you can access the Try-It console to test this operation.

We get the display of the form if we click on the “<” button of the console:

In the “Resource Owner” field, you have access to the list of people declared for the API.

Remark: The parameters required in the sense of the API must be completed. However, when you use it via the Try-It console, some mandatory parameters cannot be filled in with meaningful values. In this case, they can be entered with a “1” character.

For example, in the screen below :

Put “1” in the “Signature” field.

Put “1” in the “X-request-ID” field

Click on the run button

Try-it parameters for every Account

For the body data type parameters you can copy paste the examples (left part of the screen) in the form (right part of the screen) by changing only the specific values of the chosen customer.

Common parameters to every Account information API method

 

Parameter	Description	Data type	Parameter type	Mandatory
Authorization	access token in header	Char	Header	Yes
PSU-IP-Address	IP address used by the customer logged-in to you app *mandated if the PSU is connected, otherwise “blank” if you use the batch mode	Char	Header	No*
PSU-IP-Port	IP port of the device used by the PSU connected to your app	Char	Header	No
PSU-HTTP-Method	http method used for the request	Char	Header	No
PSU-Date	Timestamp used for the PSU request	Char	Header	No
PSU-GEO-Location	Geographic location given by the PSU if available	Char	Header	No
PSU-User-Agent	Header “User-Agent” sent by the PSU device connected to your app	Char	Header	No
PSU-Referer	Header “Referer” or “Referrer” sent by the PSU device connected to your app	Char	Header	No
PSU-Accept	Header “Accept” sent by the PSU device connected to your app	Char	Header	No
PSU-Accept-Charset	Header “Accept-Charset” sent by the PSU device connected to your app	Char	Header	No
PSU-Accept-Encoding	Header “Accept-Encoding” sent by the PSU device connected to your app	Char	Header	No
PSU-Accept-Language	Header “Accept-Language” sent by the PSU device connected to your app	Char	Header	No
Digest	Body synthesis	Char	Header	No
Signature	HTTP request signature (see https://datatracker.ietf.org/doc/draft-cavage-http-signatures/) The header field “keyId” should be formatted as KeiId=”SN=XXX,CA=YYYYYYYYYYYYYYYY” in which “XXX” is the serial number (hex format) of the QSEAL certificate QSEAL “YYYYYYYYYYYYYYYY” is the full name of the certification authority having issued this certificate A message HTTP 400 will be returned by the server in case of an invalid or missing signature	Char	Header	Yes
X-Request-ID	Consistency Header parameter to be included in the request, and it has to be returned in the response	Char	Header	Yes

Parameters dedicated to GET /accounts/{}/balances

 

Parameter	Description	Data type	Parameter type	Mandatory
accountResourceId	Main identification of the account resource to fetch and used as input paramater by the request. It is obtained as the “GET /accounts” result in the “ressourceId” field. For a current account such as “accountId”: {“iban”:”” } ; Or for a differed debit card such as “accountId”: {“other”: {“schemeName”: “CPAN”}})	Char	Path	Yes

Parameters dedicated to GET /accounts/{}/transactions

 

Parameter	Description	Data type	Parameter type	Mandatory
accountResourceId	Main identification of the account resource to fetch and used as input paramater by the request. It is obtained as the “GET /accounts” result in the “ressourceId” field	Char	Path	Yes
dateTo	Exclusive maximal imputation date of the transactions (transactions having an imputation date equal to this parameter are NOT included in the result)	Char	Request	No
dateFrom	Inclusive minimal imputation of the transactions (= those having an imputation date equal to this parameter are included in the result)	Char	Request	No
entryReferenceFrom	This parameter provides the value of the criterion which will determine the result of the query. Only transactions with a technical identifier greater than the value provided will be included in the result	Char	Request	No
entryReferenceTo	This parameter provides the value of the criterion which will determine the result of the query. Only transactions with a technical identifier lower than the value provided will be included in the result	Char	Request	No

Sandbox Assembly

Introduction – detailed features of the sandbox

You can use the BPCE API sandbox:

• Via the BPCE dev portal Try-It (see « Try-It console » use case) ;
• Directly through your application : this mode is described hereafter.

In sandbox assembly, there are two types of requests:

• A first request to identify/authentifie the customer, then to retrieve the authorization token (see “Retrieve your access token”) or to refresh this token (see “Refresh your access token” use case);
• A second request to call “Information sur compte” API (see “Get accounts list“, “Forward customer’s consent“, “ Get accounting balances“, “Get transactions history“, “Get trusted beneficiaries list” and “Get PSU’s identity“).

In the sandbox assembly, your APP consuming the “Account Information” API will need to retrieve an access token via its authentication key from AS (Authentication Server).

Thus your application will be able to consume the methods GET /accounts, PUT /consents, GET /accounts/transactions, GET /accounts/balances, GET /trustedBeneficiaries and GET /endUserIdentity thanks to its access token.

API method calls can be chained:

• By executing the GET /accounts request you retrieve the account list at first;
• Then, executing the PUT /consents request, you transmit customer’s consents ;
• Then, by executing the GET /accounts/{accountResourceId}/balances request,you recover accounting balance, passing in parameter “resourceId” of one of the accounts recovered from the result of the first request.
• You can also recover transactions history by executing GET /accounts/{accountResourceId}/transactions request;
• Then, by executing the GET /trustedbeneficiaries request, you retrieve the list of customer’s trusted beneficiaries => these methods will not be available in 2020.
• Finally, by executing the GET /endUserIdentity request, you recovery the customer’s identity.

The data used in the tests are based on persona (see “Test data” use case). This will enable you to choose specific profiles according to the tests so as to better understand the results.

If necessary, a pagination of results will be made to facilitate readability and navigation links between different pages of results will be present (see the examples in the use cases “Forward customer’s consent” and “Get transactions history”), which implies that the consuming application can handle this pagination correctly.

Prerequisites

You must declare your APP on BPCE API portal (see “My apps” menu) and send us :

• Your organizationId ;
• QWAC and QSEALC test certificates public key ;
• Callback URI that will be called by ASPSP ;
  • If the customer has authorized the recovery of its data by the AISP;
  • In case of refusal of consent by customer ;
  • If the kinematics below is interrupted (for example: timeout on the screens)

Please note that as a TPP, you must be accredited (or in the on-going accreditation process) by any european competent authority (ACPR in France) for this Account Information Service Provider role (“AISP”).

Sequence steps to test access to the AISP API from your APP

• First step : Ask for an access token thru redirection

This call allows you to trigger the identification of the customer in the Banque Palatine that holds its accounts, prerequisites for obtaining an access token for this bank. This is to ask the connected customer to give his contentment to access his data for 180 days.

The description of the feature is given in the use case “Get your access token”.

NB: The customer can domicile its accounts in several banks of Groupe BPCE, you will need a different token to access each of our banks if the customer wants to aggregate accounts from each of them => this call and the following calls will be therefore to be repeated for each of the bank concerned.

In order to be able to query the right backend, in the customer journey, it is therefore necessary that you plan to ask the customer in advance on its (their) Banque Palatine(s) of attachment.

For access to the sandbox assembly, the entry point depends on the institution code: « www.<bankcode>.sandbox.api.89C3.com ».

The only Banques Palatines that can be used in sandbox assembly for this API are the following (bank code <bankcode> used in URLs) :

 

Bank code	Bank name	Bank short name
13807	B.P Grand Ouest	BPGO
13807	CMM Grand Ouest	CMMGO

Redirection request to the login page:

GET https://www.13807.sandbox.api.89C3.com/stet/psd2/oauth/authorize

Headers :

Content-Type:application/x-www-form-urlencoded; charset=utf-8

Params :

redirect_uri:https://myAPP.fr/Home/OAuth2Callback

client_id:PSDFR-ACPR-13807

response_type:code

scope:AISP

Notes on parameters :

client_id : your agreement number as defined by your national competent authority. (PSDXX-YYYY-ZZZZZ)

redirect_uri : callback URL as declared in your APP

AND

to be forwarded to ASPSP for each sandbox and Go Live requests to be forwarded to ASPSP for each sandbox and Go Live requests

• Second step : Redirection to screens

Nominal kinematics of the sequences of identification and strong authentication screens:

Sequence of identification and strong authentication screens:

1) The customer is redirected to an identification screen offered by his bank and in which he will enter his remote banking identifier.

The remote banking identifier of the customer is to be entered (see “Test data” use case for the data sets of the banking institution), example for the persona “Marc” of the Banques Palatines :

NB: If the AISP provides the remote banking identifier of the customer in its request (setting : “login hint”), the following step is directly triggered. For example :

GET /stet/psd2/oauth/authorize?client_id ={{_CLIENT_ID}}&response_type=code&scope=aisp offline_access&redirect_uri={{_REDIRECT_URI_AISP}}&login_hint=D0999990I0

2) The customer is redirected to a first authentication screen proposed by its banking institution to validate its identity.

The SMS code for authentication is to be entered (see “Test data” use case for the data sets of the banking institution), example for the persona “Marc” of the Banques Palatines :

The cinematic of this step depends on the strong authentication method made available to the customer by the bank (SMS OTP, secur’pass, etc.).

It also depends on the equipment connected to the AISP APP used by the customer (PC or mobile / smartphone / tablet).

In some cases, a notification may be sent to the customer to activate its strong authentication means, and to complete this step.

Sequence of the identification and strong authentication screens when the remote bank identifier of the customer is transmitted in the request:

When the access identifier for the remote bank for the customer (field “login hint”) is filled in, the call to the identification screen of the customer is not performed, cf. drawing below. For example :

Get/stet/psd2/oauth/authorize?client_id ={{_CLIENT_ID}}&response_type=code&scope=aisp offline_access&redirect_uri={{_REDIRECT_URI_AISP}}&login_hint=D0999990I0

• Third step : Get an access_token

This call allows AISP to recover the token to access data from the AISP registered callback URL in its consuming application.

Sample : https://bred.demoseo.turbosa.banquepopulaire.fr/Home/OAuth2Callback?code=NnZx1hqHY2CLkCFjiTwhJeflgNnCrB

If the customer has allowed you to retrieve data for a Banque Palatine, you will find in the response to the previous call, the one-time code that retrieves an access_token.

This access_token is valid for 1 hour and is a prerequisite for each access to one of the methods of the account information API. The description of the functionality and the fields of the request is described in the use case “Get your access token”.

This token is accompanied by a refresh_token valid for 180 days that you must keep. When your access_token expires, you can request a new one by following the kinematics “Refresh your access_token” below.

After 180 days your refresh_token expires. To recover a new one, you need to follow again the kinematics “Get your access token”and go through a new step of strong authentication of the customer with the bank.

Request:

POST https://www.13807.sandbox.api.89C3.com/stet/psd2/oauth/token

Headers :

Content-Type:application/x-www-form-urlencoded; charset=utf-8

Params :

redirect_uri:https://myAPP.fr/Home/OAuth2Callback

client_id:PSDFR-ACPR-13807

grant_type:authorization_code

code:NnZx1hqHY2CLkCFjiTwhJeflgNnCrB

Notes on parameters :

client_id : your agreement number as defined by your national competent authority. (PSDXX-YYYY-ZZZZZ)

Code : recovered in the callback URL.

redirect_uri : callback URL as declared in your APP

AND

to be forwarded to ASPSP for each sandbox and Go Live requests to be forwarded to ASPSP for each sandbox and Go Live requests

It is necessary that the redirect_uri is the same as for the GET / authorize request

Response :

{

“access_token”: “KXZyspFBZ1R6NqWQdmsZhfdo1nbjK7MoI0Kr2rSi1mSCFNehAs6iLw”,

“token_type”: “Bearer”,

“expires_in”: 3600,

“scope”: “aisp offline_access”,

“refresh_token”: “KUZyspFBZ1R6NqWQdmsZhfdo1nbjK7MoD0Kr2rSi1mSCFNehAs6iLa”

}

• Fourth step : Consume the methods of the API

Get the list of the customer current accounts and delayed debit cards

This call allows you to list the accounts of the customer connected or not.

The description of the functionality and fields of the request are described in the use case “Get accounts list”.

Example of a request to retrieve the list of accounts in sandbox assembly:

Request :

GET https://www.13807.sandbox.api.89C3.com/stet/psd2/v1.4.2/accounts

Headers :

Authorization:Bearer KXZyspFBZ1R6NqWQdmsZhfdo1nbjK7MoI0Kr2rSi1mSCFNehAs6iLw

Signature : keyId=\”MZGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDCFENGw33yGihy92pDjZQhl0C36rPJj+CvfSC8+q28hxA161QFNUd13wuCTUcq0Qd2qsBe/2hFyc2DCJJg0h1L78+6Z4UMR7EOcpfdUE9Hf3m/hs+FUR45uBJeDK1HSFHD8bHKD6kv8FPGfJTotc+2xjJwoYi+1hqp1fIekaxsyQIDAQAB\”,algorithm=\”rsa-sha256\”,headers=\”(request-target) psu-ip-address psu-ip-port psu-http-method psu-date psu-user-agent psu-referer psu-accept psu-accept-charset psu-accept-encoding psu-accept-language digest\”,signature=\”LbkxgICM48J6KdWNaF9qT7OWEorNlAwWNo6R+KkP7cP4TIGkk8wxcsGQXJ9ZnC+ZiA8mjL5S8WQyL41M7iPt+vJX4xh679gdGwmlKzn7E+ZtZ1I4qalRxcdLp4gBL7fll+C2lVBNJrViMJBezFK7AYVjnSWH7t1QxiMVg3CmoRM=\

X-request-id:id-1234567890111121 1

Psu-Ip-Address:192.168.0.1

Notes on parameters :

Authorization:Bearer => access_token

Psu-Ip-Address => allows to distinguish between the batch calls and the calls with the connected customer : this field is to feed for a connected customer.

Response : 200 OK

Headers :

X-request-id:id-1234567890111121 1

Notes on parameters :

X-request-id: transmitted as input

Body :

{

“_links”: {

“last”: {

“href”: “https://www.<cdetab>.sandbox.api.89C3.com/stet/psd2/v1.4.2/accounts?page=last”

},

“self”: {

“href”: “https://www.<cdetab>.sandbox.api.89C3.com/stet/psd2/v1.4.2/accounts”

},

“first”: {

“href”: “https://www.<cdetab>.sandbox.api.89C3.com/stet/psd2/v1.4.2/accounts”

}

},

“accounts”: [

{

“cashAccountType”: “CACC”,

“accountId”: {

“iban”: “FR7613807008043001965409135”,

“currency”: “EUR”

},

“resourceId”: “038-CPT30019654091”,

“product”: “COMPTE COURANT”,

“_links”: {},

“usage”: “ORGA”,

“psuStatus”: “Account Holder”,

“name”: “Tech-N Co”,

“bicFi”: “CCBPFRPPNAN”,

“details”: “COMPTE COURANT”

}

]

}

(case of persona Tech-N Co – D0999993I0 for which no consent was given via the method PUT /consents)
{

“_links”: {

“last”: {

“href”: “https://www.<cdetab>.sandbox.api.89C3.com/stet/psd2/v1.4.2/accounts?page=last”

},

“self”: {

“href”: “https://www.<cdetab>.sandbox.api.89C3.com/stet/psd2/v1.4.2/accounts”

},

“first”: {

“href”: “https://www.<cdetab>.sandbox.api.89C3.com/stet/psd2/v1.4.2/accounts”

},

“endUserIdentity”: {

“href”: “https://www.<cdetab>.sandbox.api.89C3.com/stet/psd2/v1.4.2/end-user-identity”

}

},

“accounts”: [

{

“cashAccountType”: “CACC”,

“accountId”: {

“iban”: “FR7613807008043001965405158”,

“currency”: “EUR”

},

“resourceId”: “038-CPT30019654051”,

“product”: “COMPTE CHEQUE”,

“balances”: [

{

“balanceType”: “VALU”,

“name”: “Solde en Valeur”,

“balanceAmount”: {

“amount”: “4321.95”,

“currency”: “EUR”

},

“referenceDate”: “2020-06-12”

},

{

“balanceType”: “CLBD”,

“name”: “Solde Comptable”,

“balanceAmount”: {

“amount”: “4179.95”,

“currency”: “EUR”

},

“referenceDate”: “2020-06-11”

},

{

“balanceType”: “OTHR”,

“name”: “Solde TP”,

“balanceAmount”: {

“amount”: “4348.95”,

“currency”: “EUR”

}

}

],

“_links”: {

“balances”: {

“templated”: false,

“href”: “https://www.<cdetab>.sandbox.api.89C3.com/stet/psd2/v1.4.2/accounts/038-CPT30019654051/balances”

},

“transactions”: {

“templated”: false,

“href”: “https://www.<cdetab>.sandbox.api.89C3.com/stet/psd2/v1.4.2/accounts/038-CPT30019654051/transactions”

}

},

“usage”: “PRIV”,

“psuStatus”: “Account Holder”,

“name”: “Compte perso”,

“bicFi”: “CCBPFRPPNAN”,

“details”: “COMPTE CHEQUE”

},

{

“cashAccountType”: “CACC”,

“accountId”: {

“iban”: “FR7613807008043001965405255”,

“currency”: “EUR”

},

“resourceId”: “038-CPT30019654052”,

“product”: “COMPTE CHEQUE”,

“balances”: [

{

“balanceType”: “VALU”,

“name”: “Solde en Valeur”,

“balanceAmount”: {

“amount”: “459.56”,

“currency”: “EUR”

},

“referenceDate”: “2020-06-12”

},

{

“balanceType”: “CLBD”,

“name”: “Solde Comptable”,

“balanceAmount”: {

“amount”: “459.56”,

“currency”: “EUR”

},

“referenceDate”: “2020-06-11”

},

{

“balanceType”: “OTHR”,

“name”: “Solde TP”,

“balanceAmount”: {

“amount”: “459.56”,

“currency”: “EUR”

}

}

],

“_links”: {

“balances”: {

“templated”: false,

“href”: “https://www.<cdetab>.sandbox.api.89C3.com/stet/psd2/v1.4.2/accounts/038-CPT30019654052/balances”

},

“transactions”: {

“templated”: false,

“href”: “https://www.<cdetab>.sandbox.api.89C3.com/stet/psd2/v1.4.2/accounts/038-CPT30019654052/transactions”

}

},

“usage”: “PRIV”,

“psuStatus”: “Account Holder”,

“name”: “Retrait et Cheques”,

“bicFi”: “CCBPFRPPNAN”,

“details”: “COMPTE CHEQUE”

},

{

“cashAccountType”: “CACC”,

“accountId”: {

“iban”: “FR7613807008043001965405352”,

“currency”: “EUR”

},

“resourceId”: “038-CPT30019654053”,

“product”: “COMPTE CHEQUE”,

“balances”: [

{

“balanceType”: “VALU”,

“name”: “Solde en Valeur”,

“balanceAmount”: {

“amount”: “2165.5”,

“currency”: “EUR”

},

“referenceDate”: “2020-06-12”

},

{

“balanceType”: “CLBD”,

“name”: “Solde Comptable”,

“balanceAmount”: {

“amount”: “2165.5”,

“currency”: “EUR”

},

“referenceDate”: “2020-06-11”

},

{

“balanceType”: “OTHR”,

“name”: “Solde TP”,

“balanceAmount”: {

“amount”: “2165.5”,

“currency”: “EUR”

}

}

],

“_links”: {

“balances”: {

“templated”: false,

“href”: “https://www.<cdetab>.sandbox.api.89C3.com/stet/psd2/v1.4.2/accounts/038-CPT30019654053/balances”

},

“transactions”: {

“templated”: false,

“href”: “https://www.<cdetab>.sandbox.api.89C3.com/stet/psd2/v1.4.2/accounts/038-CPT30019654053/transactions”

}

},

“usage”: “PRIV”,

“psuStatus”: “Account Holder”,

“name”: “Compte mensualités”,

“bicFi”: “CCBPFRPPNAN”,

“details”: “COMPTE CHEQUE”

}

]

}
(case of persona Marc – D0999990I0 for which a consent was already transmitted via the method PUT /consents)

Forward customer’s consented accounts list for the balances consultation and/or transactions

Same principle of passage of the access token as in the paragraph above “Get the list of the customer current accounts and delayed debit cards“.

The description of the functionality and fields of the request are described in the use case “Forward customer’s consent“.

Request :

PUT https://www.13807.sandbox.api.89C3.com/stet/psd2/v1.4.2/consents

Headers :

Authorization : Bearer KXZyspFBZ1R6NqWQdmsZhfdo1nbjK7MoI0Kr2rSi1mSCFNehAs6iLw

Signature : keyId=\”MZGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDCFENGw33yGihy92pDjZQhl0C36rPJj+CvfSC8+q28hxA161QFNUd13wuCTUcq0Qd2qsBe/2hFyc2DCJJg0h1L78+6Z4UMR7EOcpfdUE9Hf3m/hs+FUR45uBJeDK1HSFHD8bHKD6kv8FPGfJTotc+2xjJwoYi+1hqp1fIekaxsyQIDAQAB\”,algorithm=\”rsa-sha256\”,headers=\”(request-target) psu-ip-address psu-ip-port psu-http-method psu-date psu-user-agent psu-referer psu-accept psu-accept-charset psu-accept-encoding psu-accept-language digest\”,signature=\”LbkxgICM48J6KdWNaF9qT7OWEorNlAwWNo6R+KkP7cP4TIGkk8wxcsGQXJ9ZnC+ZiA8mjL5S8WQyL41M7iPt+vJX4xh679gdGwmlKzn7E+ZtZ1I4qalRxcdLp4gBL7fll+C2lVBNJrViMJBezFK7AYVjnSWH7t1QxiMVg3CmoRM=\

X-request-id:id-1234567890111121 2

Psu-Ip-Address : 192.168.0.1

Notes on parameters :

Authorization:Bearer => access_token

Psu-Ip-Address => allows to distinguish between the batch calls and the calls with the connected customer : this field is to feed for a connected customer.

Body (with an IBAN of the customer) :
{

“balances”: [

{

“iban”: “FR7613807008043001965405158”

}

],

“transactions”: [

{

“iban”: “FR7613807008043001965405158”

}

],

“trustedBeneficiaries”: true,

“psuIdentity”: true

}
Response :

Headers :

X-request-id:id-1234567890111121 2

Notes on parameters :

X-request-id: transmitted as input

No body but a response code « 201 – Created »

• Get customer’s account balances report or outstandings list of the linked delayed debit card

Same principle of passage of the access token as in the paragraph above “Get the list of the customer current accounts and delayed debit cards“.

The description of the functionality, an example and fields of the request are described in the use case “Get accounting balance“.

• Get current account transactions or deferred debit card receipts backed by it

Same principle of passage of the access token as in the paragraph above “Get the list of the customer current accounts and delayed debit cards“.

The description of the functionality, an example and fields of the request are described in the use case “Get transactions history“.

• Get the list of trusted beneficiaries of a PSU

Same principle of passage of the access token as in the paragraph above “Get the list of the customer current accounts and delayed debit cards“.

The description of the functionality, an example and fields of the request are described in the use case “Get trusted beneficiaries” => this feature will not be not available in 2020.

• Get PSU’s identity

Same principle of passage of the access token as in the paragraph above “Get the list of the customer current accounts and delayed debit cards“.

The description of the functionality, an example and fields of the request are described in the use case “Get PSU’s identity”

• Refresh access_token with refresh_token

Request :

POST https://www.13807.sandbox.api.89C3.com/stet/psd2/oauth/token

Headers :

Content-Type:application/x-www-form-urlencoded; charset=utf-8

Params :

client_id:PSDFR-ACPR-13807

grant_type:refresh_token

refresh_token:KUZyspFBZ1R6NqWQdmsZhfdo1nbjK7MoD0Kr2rSi1mSCFNehAs6iLa

Notes on parameters :

client_id : your agreement number as defined by your national competent authority. (PSDXX-YYYY-ZZZZZ)

Response:

{

“access_token”: “4s2Bt3MRL7nlPUZcRTPe5Tjs0v8p7ZOXOyEKs1juYesj9pPaU7hXFA”,

“token_type”: “Bearer”,

“expires_in”: 3600,

“scope”: “aisp offline_access”,

“refresh_token”: “KUZyspFBZ1R6NqWQdmsZhfdo1nbjK7MoD0Kr2rSi1mSCFNehAs6iLa”

}

Test data

As required by PSD2 regulation (see RTS Art. -30 (5)), we deliver a testing facility, including support, for connection and functional testing using non-real test data.

This page presents the datasets for testing the API :

• Fictional customers, by customer segment (student, executive, business etc.) with either individual or professionial accounts that represent the populations of Banque Palatine’s customers (retail ; business ; corporate).
  • The individual is a natural person categorized as “capable adult”. The individual can also have activities within the framework of a sole proprietorship = a company directed by only one person, and which does not have a legal personality, although it is registered in the trades directory or in the Commercial Register and of Companies (RCS). Examples: craftsman or liberal profession. In this case, the IE is considered an individual.
  • The categories “professional” and “business” cover legal persons.
• Their accounts and deferred debit cards characteristics are described (single-account, multi-accounts, multi-bank accounts, presence of a debit card, account balance)
• Useful data expected in input by the API are enumerated (remote banking identifier, SMS code for authentication, IBAN)
• THESE PSU ID & TEST DATA CANNOT BE USED IN PRODUCTION LIVE ENVIRONMENT

Persona	Segment	Remote banking identifier	SMS code for authentication	Institution Code	IBAN	Account number- accountId	Current account	Balance	Currency	Consent given for transaction history?	Consent given for accounting balance?
Marc	Senior executive (individual)	D0999990I0	12345678	13807	FR7613807008043001965405158	038-CPT30019654051	Current	4 179.00	EUR	OK	OK
					FR7613807008043001965405255	038-CPT30019654052	Current	459.56	EUR	OK	OK
					FR7613807008043001965405352	038-CPT30019654053	Current	2 165.50	EUR	OK	OK
Marie	Retiee (individual)	D0999991I0	12345678	13807	FR7613807008043001965406128	038-CPT30019654061	Current	1 754.03	EUR	OK	OK
					FR7613807008043001965406225	038-CPT30019654062	Current	11 429.00	EUR	OK	OK
Thomas	Student (individuel)	D0999980	12345678	13807	FR7613807008043001965407195	038-CPT30019654071	Current	749.27	EUR	OK	OK
					FR7613807008043001965407292	038-CPT30019654072	Current	-20 000.00	EUR	KO	OK
Alix	Executive (individual)	D0999992I0	12345678	13807	FR7613807008043001965408165	038-CPT30019654081	Current	52.00	EUR	OK	KO
					FR7613807008043001965408262	038-CPT30019654082	Current	395.45	EUR	KO	OK
					FR7613807008043001965408359	038-CPT30019654083	Current	298.19	EUR	OK	OK
Tech’n Co	Company (professional)	D0999993I0	12345678	13807	FR7613807008043001965409135	038-CPT30019654091	Current	63 917.00	EUR	KO	KO
Adam	Entrepreneur (indivual and professional)	D0999994I0	12345678	13807	FR7613807008063031966574122	038-CPT30319665741	Current	0.00	EUR	OK	OK
					FR7613807008063031966574219	038-CPT30319665742	Current	-2 894.05	EUR	OK	OK
Lea	executive (individual)	755238649	12345678	13807	FR7617515000920400430518020	038-CPT04004305180	Current	-150.00	EUR	OK	OK
SARL UNIPERSONNELLE 2640	Merchant (business)	D0999995I0	12345678	13807	FR7613807008063042100847972	038-CPT30421008479	Current	0.00	EUR	OK	OK
					FR7613807008060602191786661	038-CPT06021917866	Current	139 613 054.35	EUR	OK	OK
					FR7613807002353032165639297	038-CPT30321656392	Current	701 246 591.14	EUR	OK	OK
					FR7613807002353092101653050	038-CPT30921016530	Current	99 792.13	EUR	OK	OK
					FR7613807002353092152355047	038-CPT30921523550	Current	1 015 745.35	EUR	OK	OK

---

Marc 42 years old – Nantes Single – Executive in the public Service – 18 years experience 3 current accounts Life / History / Work Account in his name Urban worker, wishing to facilitate his everyday life, passionate about his work and his leisure activities Goals Wish to buy and settle in the city center to get closer to his friends and charities in which he gives his time

Use practices He uses contactless left and right, by phone or by card He has multiple accounts in several different institutions of the group Brakes and potential frustrations He doesn’t like paperwork The management of the invoices of his pour future move What might influence Simple invoice management and credit alert services More on-line services The good surprise Addicted to his smartphone (account consultation, e-commerce, payment, etc… )

---

Marie 73 years old – Nantes Married – Retired from the private sector 2 current accounts Life / History / Work Married, account in Mrs or Mr name After 40 years working, she enjoyes a well-deserved retirement traveling around the globe with her husband and family Goals Wishes to please her children and grandchildren by traveling with them Wishes to give more time for charity

Use practices Except for a few shy purchases on the internet, Marie still has some cash on her Has a joint account in BPCE group Brakes and potential frustrations She doesn’t trust the internet Her smartphone is rarely in her pocket What might influence Ultra secure services, but still easy to use The good surprise Her children and grandchildren teach her the magic of tablets

---

Thomas 21 years old – Nantes Student – Ecole d’ingénieur informatique privée 2 current accounts Life / History / Work Account in his name Thomas had to make a loan to pay for his five years of private school Since he is no longer in preparatory class Thomas has a student job Goals Finish his studies quickly so that he can finally enter to an active working life Be able to spend what he earns to enjoy the joys of student life

Use practices He uses contactless left and right, by phone or by card Thomas, however, pays attention to his spendings Brakes and potential frustrations/span> Do not exceed the withdrawal and payment limits he has authorized himsefl Doesn’t really like to remember his passwords What might influence Authentication services using its smartphone (Touch ID, authenticator, …) Real-time alerts on its spendings, a visualization month by month The good surprise Thomas is very focused on new technologies

---

Alix 32 ans – Nantes Married – 3 children Executive – Private sector employee 3 current accounts 3 delayed debit cards Life / History / Work Married , compte à Mme ou Mr In love with her native country village, Alix works in the nearest big city Goals Wishes to renovate a large part of her family home Already thinks about future major studies of her children, not to mention the expenses involded

Use practices Far from everything, internet orders and deliveries are her everyday life She is heading more and more to Chinese websites Brakes and potential frustrations The security of her online payments The assurance of receiving products in accordance with what she ordered No retail banking What might influence Insurance to secure her payments Savings plans to ensure the best education for her children Greater proximity with her bank The good surprise Online shopping is her hobby, tablet or computer are her most faithful servants

---

Tech’n Co Created by Dominique – Nantes 37 years old – Married – 2 children 1 current account 1 delayed debit card Life / History / Work Tech’n Co is a small IT service company, infrastructure and network management in SMEs Dominique is an active entrepreneur who dedicates his life to his work and his family Goals Have a consolidated view of all his accounts on one device (smartphone, pc, …) Continue to grow his business by reaching more customers Develop his activity on other services

Use practices He deals himself with his treasury Multi banked Brakes and potential frustrations Follow his cutomer payments following the creation of a new service Keep his family free from want What might influence Simple and cheap business services The assurance of keeping a stable standard of living even in case of a hard blow The good surprise Constantly on the move, he never leaves his bank application

---

Adam 29 years old– Montpellier Single – Contractor – 4 years experience 2 current accounts 2 delayed debit cards Life / History / Work Adam leads a small private company SARL UNI PICCOLO Adam is a young and active contractor, he is increasing his knowledge in his sector Goals Get easily his cards and accounts transactions history Recruit in his company Develop his activity on other services

Use practices Daily connections to his accounts in order to have a fine management Multi banked Brakes and potential frustrations Research technology solutions giving reactivity His company size is small What might influence Simple and cheap business services To increase his company size without taking risks The good surprise Always search for digital solutions

---

Léa 35 ans – Lyon Married – Executive in an insurance company- 10 years experience 1 current account Life / History / Work Married, she hikes a lot with her husband Léa is very comfortable with her job and her company Goals Get her current account balance in a fast and secure way She wants to have kids and build a family

Use practices Online shopping in a regular way Loyal to her bank, she doesnt want to change it Brakes and potential frustrations Slow connections to her current account Research of minimal expenses for her account management What might influence Better proximity with her bank Access to her account everywhere The good surprise Listen to advices of the bank sector professionals

---

SARL UNIPERSONNELLE 2640 Dijon 5 current accounts 1 delayed debit card Life / History / Work Large trader Goals Develop it’s online sales business

Use practices Account monitoring by an accounting firm Consolidation of accounts in several banks Brakes and potential frustrations Slow connection to it’s account Looking for a minimum of bank charges What might influence Access to it’s account from anywhere The good surprise An account situation accessible in real time

Authentification and OAUTH2 access token

Diagram of the OAUTH2 access token retrieval principle

As a developer of an application wishing to use this API resources, you need to get an OAUTH2 access token following the steps below :

Note: the acronym “PIISP” used by STET v1.4.0 whose image above is taken from the documentation becomes “CBPII” from version STET DSP2 v1.4.2. This role provides access to the account coverage service.

References

• Section 3.4.3 of STET standard v1.4.2.17 – Part 1 Framework: https://www.stet.eu/en/psd2/
• OAuth 2.0 Authorization Framework : https://tools.ietf.org/html/rfc6749#section-4.1

Step by step development

1. Our customer specifies to you the identity of the Banque Palatine which holds his accounts.

2. You initiate the OAUTH2 access token recovery sequence by redirecting our customer to the bank’s authorization infrastructure, through the following URL pattern and parametersd’autorisation :

See also [STET Framework page 21]

GET /authorize?response_type=code&client_id={clientId}&redirect_uri={redirectUri}&scope={scope}[&state={state}]

 

Name		Data	Type
response_type	[1..1]	Expected type of token	String[10] Must be valued with “code”
client_id	[1..1]	TPP identification	String[36] Must be equal or linked to the OrganizationIdentifier part of the Distinguished Name of the eIDAS certificate, according to ETSI specification
redirect_uri	[0..1] [1..1]	Call-back URL of the TPP	String [140] => mandatory field for Banques Palatines
scope	[0..1]	Specifies the generic accreditations that both the PSU and the TPP agreed on : For AISP aisp extended_transaction_history => this scope is not authorized for the Banques Palatines _ for CBPII : cbpii.	String [140] => Space delimited roles list
state	[0..1]	Internal state that you can used for context management	String [1024]

3. The Banque palatine account holder (ASPSP) will :

• Identify and authenticate the customer using one of the strong authentication methods proposed and presented to the customer;
• Performs checks about your AISP or CBPII function (QWAC and QSealc certificates validity and your role validity, non-revocation of your profile etc.).

4. Afterwards, the Banque Palatine will redirect the customer to your website, using the previously given call-back URL and the following parameters. Please note that you will need to communicate this URL when you will fill the subscription form for the live on API BPCE dev portal.

See also [STET Framework page 25]

 

Name		Data	Type
code	[1..1]	Short-time code to use in order to get the access token	String [36]
state	[0..1]	Internal state if you provided it	String [1024]

5. You will then be able to call, through a POST request, the bank’s authorization infrastructure with the following :

See also [STET Framework page 25]

 

Name		Data	Type
grant_type	[1..1]	Requested authorization type	String [36] => Must be valued with “authorization_code”
code	[1..1]	Short-time code previously provided by the ASPSP	String [36]
redirect_uri	[1..1]	Call-back URL of the TPP	String [140] => must be equal to the redirect_uri provided in the GET / token request.
client_id	[1..1]	TPP identification	String [36] => Must be equal or linked to the OrganizationIdentifier part of the Distinguished Name of the eIDAS certificate, according to ETSI specification

Example

POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb &client_id={clientId}

6. The Banque Palatine account holder (ASPSP) will :

• Performs checks about your AISP or CBPII function (QWAC and QSealc certificates validity and your role validity, non-revocation of your profile etc.
• Identify and authenticate your AISP or CBPII role through the X509 certificate that you present for safety of the mutual authentication

7. Once these verifications done and if they are conclusive, the bank will answer through a HTTP200(OK) response that embeds the following data :

See also [STET Framework page 23]

 

Name		Data	Type
access_token	[1..1]	Access token provided by the ASPSP to the TPP	String [140]
token_type	[1..1]	Type of the provided access token (“Bearer” or “MAC”)	String [10] => Must be values with “Bearer”
expires_in	[0..1]	Token lifetime, in seconds. The token can be used several times as far as it is not expired.	Numéric
refresh_token	[0..1]	Refresh token that can be used for a future token renewal request.	String [140]

Example

HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { “access_token”:”2YotnFZFEjr1zCsicMWpAA”, “token_type”:”example”, “expires_in”:3600, “refresh_token”:”tGzv3JOkF0XG5Qx2TlKWIA” }

8. As soon as the OAUTH2 access token has been provided by the Banque Palatine (valid for 180 days), you will be able to present it to consume the resources of the API (see the use cases for the API methods).

Authentication of our customer.

Identification methods of our customer

There are three different methods for customer identification wich should be relevant for the l’ASPSP (bank).

These three approaches are implemented in different ways, depending on the relevant use case :

• either during the authorisation process, mostly for AISP and CBPII use cases (cf. § 3.4;
• either during the consent management process, for instance in case of Payment Request (cf. § 3.5)

Redirect approach principle => This method doesn’t apply for the Banques Palatines

Through the Redirect approach, the customer authentication process is fully processed by the ASPSP.

In order to allow this, the TPP has to redirect the customer to the ASPSP authentication service, meaning the customer will leave temporarily the TPP interface for authenticating towards the ASPSP interface.

The TPP might have already captured a customer identifier that can be handled by the ASPSP for unambiguously recognizing the customer. In this case this identifier might be forwarded through the redirection, when the redirect protocol allows the forwarding of this identifier.

After finalisation of the authentication, the ASPSP redirects the PSU back to the TPP interface.

Exemptions to the strong customer authentication

Exemptions to the strong customer authentication are specified by the EBA (European Banking Authority) RTS on SCA, especially for Payment Initiation Services portant.

In this context, the API allows the TPP to forward to the ASPSP any useful information.

Eventually, the ASPSP keeps the final decision to apply or not this exemption.

Version history

STET Compliance

This REST-based API is compliant with the STET specifications developed by the French market initiative (https://www.stet.eu/en/psd2/), version V1.4.2.17, in order to comply with PSD2 regulatory requirements. It takes into account functional limitations specific to this retail bank network (see use case “Limitations“).

As a reminder :

• payment services directive (PSD2, (UE) 2015/2366 of 25/11/2015) went into force on january 13, 2018:
  • https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32015L2366
• it is supplemented by regulatory technical standards for strong customer authentication (RTS, Commission Delegated Regulation (EU) No 2018/389) and common and secure open standards of communication that will apply on september14, 2019. These standards are called RTS (Rules Technical Standards) :
  • https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32018R0389

In France, the ordinance n° 2017-1252 of August 9, 2017 implements the PSD2 directive into the regulatory section of the monetary and financial code. This ordinance has been supplemented by two decrees (n° 2017-1313 and n° 2017-1314 on August 31, 2017), and five orders that were published on August 31, 2017

You can also consult the virtual assistant on this portal.

Description of user support + duration of support

According to Article 30 (5) of the RTS, a support for third-party providers is available. This support can be joined via the form on this BPCE API portal (https://www.api.89c3.com/en/contact-us). Responses are sent during office opening hours (09:00 – 18:00 Central European local Time) even so a 24h/7d monitoring process of our IT systems exists.

Its general principle is shown below, taking into account delays of Article 30 (4) of the RTS :

API versioning

 

Our API version	STET standard version
v1	v1.4.0.47
v1.4.2	v1.4.2.17

You can consult the virtual assistant about the STET standard.

Important changes made since the first version delivered

 

Use case(s) / Method(s)	Effective date	Description of the evolution
All	December 30, 2019	Creation of the portal documentation
Limits / Roadmap	March 31, 2020	Modification of the versioning of the API following the postponement of the migration for the Palatine bank.
All the documentation of the STET Account Information API	July 8, 2020	Portal documentation : Switching of the DSP2 STET API documentation from version v1 to version v1.4.2 Switching of the DSP2 STET API documentation from version v1 to version v1.4.2
Overview	August 28,2022	Editorial issues and App2App updates

Roadmap

API deprecation process

According to API product life cycle, an API version can be deprecated (meaning this API is not any more accessible on gateways and sandbox). An overlap period between two major API releases is provided as described below :

The communication around the decommissioning process of a version N will be done at the release date of version N+1 through this portal / “roadmap” section.

Roadmap

This API can evolve. Please note that API modifications can occur out of the three-month regulatory notice period (art. 30 des RTS / paragraphe 4). We apply this in case of :

• urgent functional issue to solve impacting all PSU of at least one major customers segment

• security issue

• evolutions requested by the national competent authority

Please do find below our forecast roadmap :

 

Our API versions	STET Standard versions	Features	Sandbox Deployment date BPCE API Dev Portal & Sandbox	Live Deployment date BPCE Live API Gateway	Live Deprecation date BPCE Live API Gateway
v1	v1.4.0.47	List current accounts and deferred debit cards of a PSU; Manage the PSU’s consent for viewing balances and / or transactions ; Retrieve accounting balances or delayed deferred card outstandings list ; Retrieve transactions history or delayed debit card slips list	March 14, 2019 (first version)	October 7, 2019	To be announced
v1.4.2	v1.4.2.17	List current accounts and deferred debit cards of a PSU; Manage the PSU’s consent for viewing balances and / or transactions, retrieve the customer’s identity Retrieve accounting balances or delayed deferred card outstandings list ; Retrieve transactions history or delayed debit card slips list Obtain the PSU’s identity (NB: the transition to the STET v1.4.2.x standard requires the implementation of this service, the data having already been moved from the “List the accounts” service)	June, 2020	October, 2020	To be announced

Limits

Operational limitations

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

• 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

• Access to the list of trusted beneficiaries is NOT available (feature not implemented in Banques Populaires online banking service : a recorded beneficiary using SCA require also a SCA validation for payment as of the first euro for this beneficiary)

• “aisp extended_transaction_history” mode is NOT supported

• Only the GET /accounts, PUT /consents, GET /balances, GET /transactions and GET /endUserIdentity methods are available

• Return data only for active delayed cards which have been used at least once in the past two months.

Limitations related to customer segments:

• The individual (IND) is a natural person categorized as a “capable adult”. The IND can also have activities within the framework of a sole proprietorship (SP) = a company managed by a single person, and which has no legal personality, although it is registered in the directory of trades or in the Register of Commerce and Companies (RCC). Examples: craftsman or liberal profession. In this case, the SP is considered a IND

• The categories “professional” (PRO) and “company” (COMP) cover legal persons

Limitations related to the types of accounts accessible:

• The accounts accessible via the AISP API are those available on remote banking, namely:
  • capable major
  • joint account Mr and Mrs
  • joint account Mrs and Mr
  • freelance
  • enrtreprise
  • attached minor
  • emancipated minor

• As the following account is not accessible on remote banking, it is not via the AISP API either
  • adult under guardianship

Limitations related to strong authentication means depending on the customer segment :

• Classic customer (CLA): equipment with SMS OTP and / or Sécur’pass. Secur’pass is triggered as a priority if necessary

• Professional customer (PRO): equipment with SMS OTP and / or Sécur’pass. Secur’pass is triggered as a priority if necessary

• Business customer (BUS): equipment with OTP SMS

The table below summarizes the limitations by method for this API (the field names are given in italics):

 

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 BPCE API portal after testing your app using Try-it and Sandbox environments as described below :

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.

Only one TPP app can be declared so far per OID (= client_Id) knowing that it is possible to :

• apply white-labelled partnerships as well as third parties models
• declare many sets of certificats (and redirect URL)

Please note that a weekly slot is reserved for a programmed maintenance (all IT infrastructure incl’d backends and API gateways) Sunday morning from 02:00 to 06:00 am, and could generate some perturbations during this period.

As in test mode, the institution code (see the list of accessible banking institutions below) will allow you to address the correct customer repository via an “endpoint” in the format : www.<bankcode>.live.api.89c3.comor

• www.<bankcode>.live.api.banquepopulaire.fraligned on direct access domain name www.banquepopulaire.fr

• www.10548.live.api.banque-de-savoie.fraligned on direct access domain name www.banque-de-savoie.fr

• www.40978.live.api.palatine.fraligned on direct access domain name www.palatine.fr

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

Eligibility

The “Account Information” API resources can only be used by Payment Service Providers (PSP) having a Account Information Service Providers (AISP) role.

In order to provide a service to users of payment informations services under PSD2 directive, you must be a licenced PSP such as credit institution, electronic money institution, and payment institution. This status is delivered by the financial authorities of the country where the request is made ; in France it is the “Autorité de Contrôle Prudentiel et de Résolution (ACPR), under the supervision of the Banque de France regulatory body :

https://acpr.banque-france.fr/sites/default/files/medias/documents/jch_20180403_conference_securite_des_paiements.pdf

Obtaining and maintaining such agreement requires rigorous procedures in order to give strong guarantees to the account informations services users. The forms are provided on the ACPR website : https://acpr.banque-france.fr/en/authorisation/banking-industry-procedures/all-forms

Once the agrement is granted, the Organisation Identifier (OID) given by the national authority has the following format :

PSDXX-YYYYYYYY-ZZZZZZZZ

“PSD” as 3 character legal person identity type reference;

2 character ISO 3166 country code representing the NCA country;

hyphen-minus “-” (0x2D (ASCII), U+002D (UTF-8)); and

2-8 character NCA identifier (A-Z uppercase only, no separator)

hyphen-minus “-” (0x2D (ASCII), U+002D (UTF-8)); andPSP identifier (authorization number as specified by NCA).

This OID is very important to identify yourself as a TPP :

• using STET API requests as OID is included in the parameter “client_ID”

• using mutual authentication (TLS) as OID is included in eIDAS certificates to be delivered to the bank (see below)

Please note that if you are using our API “Register”, an internal OID will be generated & shall be used for subsequent API requests.

You also need eIDAS (electronic IDentification And trust Services) compliant certificates delivered by a Qualified Certification Service Provider (QTSP, see list available on https://webgate.ec.europa.eu/tl-browser/#/).

In order to be able to consume PSD2 API published on our BPCE Portal, the TPP has to enroll its app and to use live certificates signed by a QTSP while sending API Register requests :

• a set of QWAC (for securing the TLS) and QSEALC (to be stored in our gateway) certificates for the sandbox

• another set of (for securing the TLS) and QSEALC (to be stored in our gateway) certificates for the live environment

A keyID shall also be provided with a correct STET format integrating the SHA256 certificate fingerprint after “_” char, see example STET V1.4.2 / Documentation Part 3: Interaction Examples / section 6. AISP Use cases / Signature : keyId=https://path.to/myQsealCertificate_612b4c7d103074b29e4c1ece1ef40bc575c0a87e

Please embed only public keys. Controls on other data will be based on European Banking Association TPP register (https://euclid.eba.europa.eu/register/pir/disclaimer).

You can also refer to the FAQ section or our virtual assistant for any further question.