API Register
-
Overview
Main Features
This API allows to register (or to modify) PSD2 TPP apps, and is based on :
- STET specifications version V1.4.2 / paragraphe 3.4.2.1
- RFC 7591, 7592 et 7517, completed by this document
- « DSP2 Oauth2 » swagger TechnicalSetup_1.0.5_OAS2.yaml, completed by this document
It is for an exlusive usage of :
- TPP which has not yet registered its app
or
- TPP willing to modify data of an already registered app using this API.
Details are listed in the “Use case” and “Limits” sections.
Catégories
-
Overview
registrationDelete
/stet/setting/v1/register/{clientId}
ABSTRACT
Delete the actual registration for a given client_id
DESCRIPTION
[From RFC7592] To deprovision itself on the authorization server, the client makes an HTTP DELETE request to the client configuration endpoint. This request is authenticated by the registration access token issued to the client.
SCOPES
- manageRegistration
PARAMÈTRES
| clientId (required) |
string
path
REQUIRED. OAuth 2.0 client identifier string. It SHOULD NOT be currently valid for any other registered client, though an authorization server MAY issue the same client identifier to multiple instances of a registered client at its discretion.
|
| Signature (required) |
string
header
http-signature of the request (cf. 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 – either an URL aiming to provide the relevant Qualified Certificate. – or the kid parameter retrieved through the certificate registration during a previous OAUTH2 Technical Setup
|
| X-Request-ID (required) |
string
header
Correlation header to be set in a request and retrieved in the relevant response
|
RETURN CODES
| 204 | No content. Deletion of the relevant registration |
| 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. |
AVAILABLE AUTHENTIFICATION
OAuth 2.0
registrationGet
/stet/setting/v1/register/{clientId}
ABSTRACT
Retrieve the actual registration for a given client_id
DESCRIPTION
[From RFC7592] To read the current configuration of the client on the authorization server, the client makes an HTTP GET request to the client configuration endpoint, authenticating with its registration access token.
SCOPES
- manageRegistration
PARAMETERS
| clientId (required) |
string
path
REQUIRED. OAuth 2.0 client identifier string. It SHOULD NOT be currently valid for any other registered client, though an authorization server MAY issue the same client identifier to multiple instances of a registered client at its discretion.
|
| Signature (required) |
string
header
http-signature of the request (cf. 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 – either an URL aiming to provide the relevant Qualified Certificate. – or the kid parameter retrieved through the certificate registration during a previous OAUTH2 Technical Setup
|
| 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 registration |
| 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. |
AVAILABLE AUTHENTIFICATION
OAuth 2.0
registrationPost
/stet/setting/v1/register
ABSTRACT
Client Registration request
DESCRIPTION
[From RFC7591] This operation registers a client with the authorization server. Theauthorization server assigns this client a unique client identifier, optionally assigns a client secret, and associates the metadata provided in the request with the issued client identifier. The request includes any client metadata parameters being specified for the client during the registration. The authorization server MAY provision default values for any items omitted in the client metadata. To register, the client or developer sends an HTTP POST to the client registration endpoint with a content type of “application/json”. The HTTP Entity Payload is a JSON [RFC7159] document consisting of a JSON object and all requested client metadata values as top-level members of that JSON object.
SCOPES
- manageRegistration
PARAMETERS
| access (required) |
RegistrationRequest
body Registration data submitted by a given client.
|
| Digest (required) |
string
header
Digest of the body
|
| Signature (required) |
string
header
http-signature of the request (cf. 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 – either an URL aiming to provide the relevant Qualified Certificate. – or the kid parameter retrieved through the certificate registration during a previous OAUTH2 Technical Setup
|
| 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. |
| 403 | Service unavailable. |
INPUT
application/json
AVAILABLE AUTHENTIFICATION
OAuth 2.0
registrationPut
/stet/setting/v1/register/{clientId}
ABSTRACT
Update the actual registration for a given client_id
DESCRIPTION
[From RFC7592] To update a previously registered client’s registration with an authorization server, the client makes an HTTP PUT request to the client configuration endpoint with a content type of “application/json”. The HTTP entity payload is a JSON [RFC7159] document consisting of a JSON object and all parameters as top-level members of that JSON object. This request is authenticated by the registration access token issued to the client. This request MUST include all client metadata fields as returned to the client from a previous registration, read, or update operation. The updated client metadata fields request MUST NOT include the “registration_access_token”, “registration_client_uri”, “client_secret_expires_at”, or “client_id_issued_at” fields described in Section 3. Valid values of client metadata fields in this request MUST replace, not augment, the values previously associated with this client. Omitted fields MUST be treated as null or empty values by the server, indicating the client’s request to delete them from the client’s registration. The authorization server MAY ignore any null or empty value in the request just as any other value. The client MUST include its “client_id” field in the request, and it MUST be the same as its currently issued client identifier. If the client includes the “client_secret” field in the request, the value of this field MUST match the currently issued client secret for that client. The client MUST NOT be allowed to overwrite its existing client secret with its own chosen value. For all metadata fields, the authorization server MAY replace any invalid values with suitable default values, and it MUST return any such fields to the client in the response.
SCOPES
- manageRegistration
PARAMETERS
| clientId (required) |
string
path
REQUIRED. OAuth 2.0 client identifier string. It SHOULD NOT be currently valid for any other registered client, though an authorization server MAY issue the same client identifier to multiple instances of a registered client at its discretion.
|
| access (required) |
RegistrationRecord
body
Registration data updated by a given client.
|
| Digest (required) |
string
header
Digest of the body
|
| Signature (required) |
string
header
http-signature of the request (cf. 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 – either an URL aiming to provide the relevant Qualified Certificate. – or the kid parameter retrieved through the certificate registration during a previous OAUTH2 Technical Setup
|
| 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 updated registration |
| 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
AVAILABLE AUTHENTIFICATION
OAuth 2.0
Catégories
Main API Methods
The main uses cases leading to API methods are described below :
1) First TPP app enrolment
- This step is necessary for all new TPP willing to access for the first time to our PSD2 API
- All TPP having already used our PSD2 API can also use this API REGISTER in order to be self autonomous for updating their new apps
- The TPP agents can also be registered using this API with a different name from TPP’s one (one request per agent)
2) Extract data of an already existing registered app
3) Modify a registered app data e.g. if eIDAS certificats are about to expire
4) Remove all registered app data e.g. if the app is obsolete (full deletion)
Get the access token
Prerequisites
In order to be able to use this API, all PSD2 TPP need to have a national EU agreement delivered by a NCA, as well as a Unique Reference Number of Organization Identifier (OID).
For any further information, ETSI international standard specifies this OID as described in « Eligibility » section.
This OID is also included in eIDAS certificates (QWAC & QSealC) used for PSD2 API access and mutual authentication process (between TPP and ASPSP).
How to use this API ?
The POST /token method of this API is mandatory in first row and allows TPP to get a new client_id which will be used for the other API REGISTER methods.
The following entry points for the POST /token are as follows :
The generic client_id to be used to get the access token is “9d8711ec-f1b4-45e4-8072-2b3aa49793f0″
- Production Live : https://www.<codetab>.live.api.89C3.com/stet/psd2/oauth/token
The generic client_id to be used to get the access token is “PSD2_TPPRegister“
Please note that any valid value of one of ASPSP available on this BPCE API Portal can be used, see product sheets per brand. Even if one ASPSP is used, the registration applies to all ASPSP.
Example (sandbox)
POST https://www.17515.sandbox.api.89C3.com/stet/psd2/oauth/token
Header : Content-type : application/x-www-form-urlencoded; charset=utf-8
Params :
- client_id : 9d8711ec-f1b4-45e4-8072-2b3aa49793f0
- grant_type : client_credentials
- scope : manageRegistration
Note : TPP needs to use a TLS mutual authentication based on QWAC certificate with this POST /token method.
Response :
{
“access_token” : “KXyZabcdefghijklmopqrstuvw1234567890”
}
Once this temporary access token is received, the following API methods are available:
| MÉTHODE | PATH | DESCRIPTION / USE CASE |
| POST | /register | 1 – Method to register an app or an agent |
| PUT | /register/${client_id} | 2 – Method to change an app data |
| GET | /register/${client_id} | 3 – Method to extract app data |
| DELETE | /register/${client_id} | 4 – Method to remove an app |
Self enroll an app or an agent
Prerequisites
In order to be able to use this method, you need to fulfill the eligibility criteria.
POST /register
Example (sandbox) : POST https://www.17515.sandbox.api.89C3.com/stet/setting/v1/register (see swager “setting” in documentation section of this portal)
HTTP Headers
| NAME | (O)PTIONNAL / (R)EQUIRED | DESCRIPTION |
| x-request-id | R | Request correlation id. This id must be a string generated by the TPP. |
| Signature | R | One of the main information of this registration is the TPP QSEALC certificate which will used by BPCE to verify the signature of all the DSP2 streams.
As registration requests must also provide a signature, the TPP must sign this request with the private key corresponding to the QSEALC certificate. As TPP identification is not yet known at the time of this initial request, TPP has to provide the certificate in the body itself, in the first item of the keys table. The certificate information will be retrieved from this form and will be used to verify the signature of the initial request and all future DSP2 requests. Please note that a TPP agent cannot use directly this API set, reserved for the TPP acting on behalf of an agent (only the TPP certificate is authenticated). In case of agents, flows must also be signed with a TPP QSEALC valid certificate. |
| Digest | R | SHA256 body digest base64 encoded. |
| Authorization | R | bearer access_token previously received. |
HTTP Body
| NAME | (O)PTIONNAL / (R)EQUIRED / (F)ORBIDDEN | DESCRIPTION |
| redirect_uris | R | String array.
It contains all URIs (scheme and authority according to RFC 3986, comma separated) that TPP can use in DSP2 redirect requests. Any URI used afterwards in PSD2 API but not provided in this registration process will be refused. |
| software_statement | O | String.
JSON Web Token (JWT). Not used. |
| token_endpoint_auth_method | R | String.
Value shall be “tls_client_auth”. |
| grant_types | R | String array.
Value shall be “client_credentials”. |
| response_types | R | String array.
Value shall be “code”. |
| client_name | R | String.
This is the TPP unique legal name. |
| client_uri | O | String.
TPP or agent Web page URI. Not used. |
| logo_uri | O | String.
TPP or agent logo URI. Not used. |
| scope | R | String.
TPP scopes are comma separated, and possible values are : “aisp” and/or “pisp” and/or “cbpii” Example : “aisp” Example : “aisp, pisp” Note : the scope is also mandatory for agents. In that case, the values included in this field shall be the ones from the TPP. |
| contact | R | String.
Data for mandatory contact details : “contact”: { “contact_name”: “string”, “email”: “string”, “phone_number”: “string” } |
| tos_uri | O | String.
Data for mandatory contact details : “contact”: { “contact_name”: “string”, “email”: “string”, “phone_number”: “string” } |
| policy_uri | O | String.
URI that points to a human-readable policy document for the client. Not used. |
| jwks_uri | O | String.
URL referencing the client JSON Web Key (JWK) document containing the client public keys. Not used. |
| provider_legal_id | R | String.
TPP National Authorization number according to ETSI specification on eIDAS certificates for PSD2 (OID = PSDXX-YYYYYYYY-ZZZZZZZZ, see “Eligibility” section). |
| client_legal_id | R/O(*) | String.
(*) Optional for a TPP / Mandatory (required) for an agent. This identifier is therefore left to the discretion of the TPP for an agent. However, its format should comply with the ETSI specification on DSP2 eiDAS certificates with “AGT” suffix + a serial number, e.g. “AGTFR-ACPR-12345001”. Note : in order to avoid rejection due to a duplicated alues, we strongly advise to base it on truncated OID TPP number (= no PSD prefix) before the serial number. |
| logo | O | String.
Not used. |
| jwks | R | Object.
This object contains the following array and shall contain at least one public key (QSEALC) without the chain link to the certification authority. |
| keys | R | JWK objects array.
This array shall contain only one item (JWK). |
| kty | R | String.
Key type. Value shall be “RSA”. |
| use | R | String.
Key usage. Vallue shall be “sig”. |
| alg | R | String.
Value shall be “RS256”. |
| key_ops | R | String array.
Value shall be “verify”. |
| kid | R | String.
key id. |
| x5u | F | Not used. |
| x5c | R | String array.
Must not contain more than one item representing the QSEALC certificate in DER format based on 64. |
| x5t | F | Not used. |
| x5t#S256 | R | String.
SHA256 fingerprint of X509 DER certificate. |
| software_id | R | String.
Mandatory name of the TPP app OR brand name OR agent name which will be displayed to PSU (it can be different from the client_name). This parameter is dispayed in priority to PSU during SCA redirect process. |
| software_version | R | String.
Mandatory name of the TPP app OR brand name OR agent name which will be displayed to PSU (it can be different from the client_name). This parameter is dispayed in priority to PSU during SCA redirect process. |
Response
A correct response returns a HTTP 201 status. The TPP will also receive its client_id to be used in all PSD2 methods, incl’d methods 2 to 4) of this document.
Errors
| HTTP STATUS | DESCRIPTION |
| 400 | Bad request. Error is supplied in fields error and error_description. |
| 404 | Resource not allowed. |
| 405 | Method not allowed. A method other than those described here was used. |
| 500 | Internal server error. |
Change an app data
Prerequisites
In order to be able to use this method, you need to fulfill the eligibility criteria.
To modify at least one app data; the “client_id” is the one received using the method POST /register.
PUT /register/{client_id}
Example (sandbox) : PUT https://www.17515.sandbox.api.89C3.com/stet/setting/v1/register/AGTFR-ACPR-12345001 (see swager “setting” in documentation section of this portal)
with the client_id = the one the TPP received in our response of the enrolment (using the POST /register).
HTTP Headers
| NAME | (O)PTIONNAL / (R)EQUIRED | DESCRIPTION |
| x-request-id | R | Request correlation id. This id must be a string generated by the TPP. |
| Signature | R | As registration requests must also provide a signature, the TPP must sign this request with the private key corresponding to the QSEALC certificate. |
| Digest | R | SHA256 body digest base 64 encoded. |
| Authorization | R | bearer access_token previously received. |
HTTP Body
| NAME | (O)PTIONNAL / (R)EQUIRED / (F)ORBIDDEN | DESCRIPTION |
| redirect_uris | R | String array.
It contains all URIs (scheme and authority according to RFC 3986, comma separated) that TPP can use in DSP2 redirect requests. Any URI used afterwards in PSD2 API but not provided in this registration process will be refused. |
| token_endpoint_auth_method | R | String.
Value shall be “tls_client_auth”. |
| grant_types | R | String array.
Value shall be “client_credentials”. |
| response_types | R | String array.
Value shall be “code”. |
| client_name | R | String.
This is the TPP unique legal name. |
| client_uri | O | String.
TPP or agent Web page URI. Not used. |
| logo_uri | O | String.
TPP or agent logo URI. Not used. |
| scope | R | String.
TPP scopes are comma separated, and possible values are : “aisp” and/or “pisp” and/or “cbpii” Example : “aisp” Example : “aisp, pisp” Note : the scope is also mandatory for agents. In that case, the values included in this field shall be the ones from the TPP. |
| contact | R | String.
Data for mandatory contact details : “contact”: { “contact_name”: “string”, “email”: “string”, “phone_number”: “string” } |
| tos_uri | O | String.
URI that points to a human-readable terms of service document for the client. Not used. |
| policy_uri | O | String.
URI that points to a human-readable policy document for the client. Not used. |
| provider_legal_id | R | String.
TPP National Authorization number according to ETSI specification on eIDAS certificates for PSD2 (OID = PSDXX-YYYYYYYY-ZZZZZZZZ, see “Eligibility” section). |
| client_legal_id | R/O(*) | String.
(*) Optional for a TPP / Mandatory (required) for an agent. This identifier is therefore left to the discretion of the TPP for an agent. However, its format should comply with the ETSI specification on DSP2 eiDAS certificates with “AGT” suffix + a serial number, e.g. “AGTFR-ACPR-12345001”. Note : in order to avoid rejection due to a duplicated alues, we strongly advise to base it on OID TPP number before the serial number. |
| logo | O | String.
Not used. |
| jwks | R | Object.
This object contains the following array and shall contain at least one he public key (QSEALC) without the chain link to the cartification authority. |
| keys | R | JWK objects array.
This array should only contain one item (JWK). |
| kty | R | String.
Key type. Value shall be “RSA”. |
| use | R | String.
Key usage. Vallue shall be “sig”. |
| alg | R | String.
Value shall be “RS256”. |
| key_ops | R | String array.
Value shall be “verify”. |
| kid | R | String.
key id. |
| x5u | F | Not used. |
| x5c | R | String array.
Must not contain more than one item representing the QSEALC certificate in DER format based on 64. |
| x5t | F | Not used. |
| x5t#S256 | R | String.
SHA256 fingerprint of X509 DER certificate. |
| software_id | R | String.
Mandatory name of the TPP app OR brand name OR agent name which will be displayed to PSU (it can be different from the client_name). This parameter is dispayed in priority to PSU during SCA redirect process. |
| software_version | O | String.
Not used. |
Response
A correct response returns a HTTP 201 status.
Errors
| HTTP STATUS | DESCRIPTION |
| 400 | Bad request. Error is supplied in fields error and error_description. |
| 404 | Resource not found. |
| 405 | Method not allowed. A method other than those described here was used. |
| 500 | Internal server error. |
Extract app data
Prerequisites
In order to be able to use this method, you need to fulfill the eligibility criteria.
To modify at least one app data; the “client_id” is the one received using the method POST /register.
GET /register/{client_id}
Example (sandbox) : GET https://www.17515.sandbox.api.89C3.com/stet/setting/v1/register/AGTFR-ACPR-12345001(see swager “setting” in documentation section of this portal)
with the client_id = the one the TPP received in our response of the enrolment (using the POST /register).
HTTP Headers
| NAME | (O)PTIONNAL / (R)EQUIRED | DESCRIPTION |
| x-request-id | R | Request correlation id. This id must be a string generated by the TPP. |
| Signature | R | As registration requests must also provide a signature, the TPP must sign this request with the private key corresponding to the QSEALC certificate. |
| Authorization | R | bearer access_token previously received. |
Response
A correct response returns a HTTP 200 status.
Errors
| HTTP STATUS | DESCRIPTION |
| 400 | Bad request. Error is supplied in fields error and error_description. |
| 404 | Resource not found. |
| 405 | Method not allowed. A method other than those described here was used. |
| 500 | Internal server error. |
Remove app data
Prerequisites
In order to be able to use this method, you need to fulfill the eligibility criteria.
To modify at least one app data; the “client_id” is the one received using the method POST /register.
DELETE /register/{client_id}
Example (sandbox) : DELETE https://www.17515.sandbox.api.89C3.com/stet/setting/v1/register/AGTFR-ACPR-12345001 (see swager “setting” in documentation section of this portal)
with the client_id = the one the TPP received in our response of the enrolment (using the POST /register).
HTTP Headers
| NAME | (O)PTIONNAL / (R)EQUIRED | DESCRIPTION |
| x-request-id | R | Request correlation id. This id must be a string generated by the TPP. |
| Signature | R | The TPP must sign this request with the private key corresponding to the QSEALC certificate. |
| Authorization | R | bearer access_token previously received. |
Response
A correct response returns a HTTP 204 status.
Errors
| HTTP STATUS | DESCRIPTION |
| 400 | Bad request. Error is supplied in fields error and error_description. |
| 404 | Resource not found. |
| 405 | Method not allowed. A method other than those described here was used. |
| 500 | Internal server error. |
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/) 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), and five orders that were published on August 31, 2017.
You can also refer to the FAQ section and the virtual assistant about STET specifications.
Description of TPP 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 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 :
Important changes made since the first version of this documentation was published :
| USE CASE / METHOD(S) | EFFECTIVE DATA | DESCRIPTION OF THE EVOLUTION |
| All | March 17, 2021 | Editorial Changes |
Roadmap
This API is subject to continual reviews and improvements throughout the year. Please do find below our forecast roadmap :
| API VERSION | STET VERSION | MAIN FEATURES | 
SANDBOX DEPLOYMENT DATE BPCE API DEV PORTAL & SANDBOX |
LIVE DDEPLOYMENT DATE BPCE LIVE API GATE WAY |
DECOMMISSIONING
DATE |
| v1.4.2 | v1.4.2.17 |
|
March 2021 | March 2021 | (to be defined) |
limits
This API can’t be used to modify an already existing app which has been enroled using the BPCE dev portal. In this case, TPP has to perform the full process using this API, and will receive a new client_id.
Please note that if a TPP requires a new profile (= new cliend_ID), it has to use another set of eIDAS certifciates.
An agent which doesn’t have its own OID and eIDAS certificates can’t use this API. The TPP (linked to the agent) will have to use this API based on his own OID and eIDAS certificates in order to declare the app of its agent.
If the API is correctly used and returns http 20x code, the newly generated client_id (or data modifications) will be automatically taken into account the next working day @02:00 pm continental time (or on the very same day if the 09:59 am deadline is not reached) except if at least one elligibility criteria doesn’t apply (it could generate additional delays – see next section).
Please also note that:
- eIDAS certificates signed with “rsassaPss” cryptographic algorihtm are not accepted ;
- the access token validity is limited to 1 hour.
Eligibility
The 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 national 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, see 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 (UPPER case): 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)) and PSP 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)
You also need eIDAS (electronic IDentification And trust Services) compliant certificates delivered by a valid 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, you have to use eIDAS valide certificates signed by a QTSP with production “live” keys :
- a set of QWAC and et QSEALC of certificates for the sandbox environment
- another set of QWAC and et QSEALC certificates for the live production environment
In case of access problems due to certificates, we will check if your QWAC certificates are signed with a new Certification Authority (CA) or with a new root (from an existing CA). In both cases, an additional delay is expected (est’d 2 weeks) for loading it on our infrastructure.
Please embed only public keys in .pem format. Controls on data included in the certificates 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.