Forward Customer's Consent

This service is mandatory as required by Caisse d'Epargne ASPSP as part of the "Mixed" model.

The PSU specifies to the AISP which of his/her accounts will be granted and which functionalities should be available : it gives his consent and included four access types (or operation types) :

  • balances : access to one or many PSU accounts balance report

  • transactions : access to one or many PSU accounts transactions history

  • psuIdentity : access to the PSU identity (first and last name) => this feature is not supported. So whatever value is used (True/False), it won't be used.

  • trustedBeneficiaries : access to the trusted beneficiaries list that have been set by the PSU => this feature is not supported by the ASPSP online banking. So whatever value is used (True/False), it won't be used.

 

The AISP forwards details of PSU consent to the ASPSP thru this call. The consent is recorded by the ASPSP for one given PSU, one given AISP, one given operation and one given account (except for the psuIdentity and the trustedBeneficiairies access types).

Each new API request calls the ASPSP consent service, for one given PSU, replaces any prior consent that was previously sent by the AISP.

Furthermore, upon the PSU'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.

  • 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 related data (balances, transactions) is NOT possible anymore.
  • In order to get any new account, a PUT /consents request with no data is necessary before a GET /accounts method.  

 

épingle See also :

STET specification V1.4.0.47 / Part I / section 3.4.3.6. "PSU context model" / page 28

STET specification V1.4.0.47 / Part II / section 4.4. / page 14.

 

 Request

"put/consents"

 

Mandatory or optional body parameters required for this service call :

Balances : list of accessible accounts for the "balances" functionality 

⇒ iban : International Bank Account Number (IBAN)
⇒ other : Unique identification of an account, a person or an organisation
=> identification : API identifier
=> schemeName : Name of the identification scheme (BANK, COID, SREN, SRET, NIDN, OAUT, CPAN)
=> issuer :  Entity that assigns the identification

 Transactions: list of accessible accounts for the "transactions " functionality

⇒ iban : International Bank Account Number (IBAN)
⇒ other : Unique identification of an account, a person or an organisation
=> identification : API identifier
=> schemeName : Name of the identification scheme (BANK, COID, SREN, SRET, NIDN, OAUT, CPAN)
=> issuer : Entity that assigns the identification

 

TrustedBeneficiaries : indicator field indicating whether or not the access to the trusted beneficiaries list was granted to the AISP by the PSU (true or false)

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

  

Example 

You can find an example of this request in section "Test our API" and then "Use our sandbox".

épingleSee also STET specification V1.4.0.47 / Part III / section 5.3 / page 7 

 

Acceptance tests :

The purpose of these tests is to ensure that the API complies with the STET standard. They should be validated before any application deployment.

Test description Nature of the test Data set
 Add / upate the consent of a customer

=> HTTP code 201 is returned

Mandatory

Persona : 

LEA

 

IBANs :

FRxxx

FRxxx

 

Result : HTTP code 201 is returned

HTTP request with an access token which is not authorized to access to this resource (incorrect scope)

=>Access to the resource is not allowed (HTTP code 403)

Mandatory

Persona : 

LEA

 

Result : HTTP code 403 is returned

 

HTTP request using POST method

=>HTTP code 405 is returned

Mandatory

Persona : 

LEA

Result : HTTP code 403 is returned