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

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 will not be available in 2020 (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"

See also STET V1.4.0.47 / Part II / section 4.4 / page 15

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 

transactions - array is mandatory but it can be empty : list of accessible accounts for the "transactions " functionality

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 /accounts 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 will not be available in 2020.

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/consents/

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

See also STET V1.4.0.47 / Part III / section 5.3 / 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

  (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.

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.