Access data authorized by customers       

Description of the services offered [STET STANDARD V1.4]

  • Retrieve your authorization token

The client (PSU) must indicate the identity of their account-keeping bank to AISP.

The AISP then initiates the retrieval sequence of the OAUTH2 access token by redirecting the client via its internet browser to the authorization IT infrastructure of the account-keeping bank.The AISP then initiates the retrieval sequence of the OAUTH2 access token by redirecting the client via its internet browser to the authorization IT infrastructure of the account-keeping bank.

The account-holding bank (ASPSP) will:

  • Identify and authenticate the PSU client by one of the strong authentication methods that it presented and proposed beforehand to the clientIdentify and authenticate the PSU client by one of the strong authentication methods that it presented and proposed beforehand to the client
  • Request consent from the client via information entry screensRequest consent from the client via information entry screens
  • Perform checks related to AISP as TPP (validity of certificates and your role in the repository, non-revocation of your profile, etc.)Perform checks related to AISP as TPP (validity of certificates and your role in the repository, non-revocation of your profile, etc.)

Once these verifications have been carried out and if they are conclusive, the bank will redirect the client to the AISP site using the "call-back" URLs forwarded as well as certain parameters. The AISP will then be able to request the OAUTH2 access token directly from the bank via a POST call.Once these verifications have been carried out and if they are conclusive, the bank will redirect the client to the AISP site using the "call-back" URLs forwarded as well as certain parameters. The AISP will then be able to request the OAUTH2 access token directly from the bank via a POST call.

The account-holding bank (ASPSP) will::

  • Identify AISP and authenticate it as TPP via the X509 certificate made available to secure mutual exchangeIdentify AISP and authenticate it as TPP via the X509 certificate made available to secure mutual exchange
  • Perform checks related to the profile of the AISP as TPP (validity of certificates and your role in the repository, non-revocation of your profile, etc.)Perform checks related to the profile of the AISP as TPP (validity of certificates and your role in the repository, non-revocation of your profile, etc.)

Once these verifications have been carried out and if they are conclusive, the bank will send an HTTP200 (OK) response to the AISP with a certain amount of data.Once these verifications have been carried out and if they are conclusive, the bank will send an HTTP200 (OK) response to the AISP with a certain amount of data.

As soon as the OAUTH2 access token issued by the bank (valid for 90 days) has been recovered by the AISP, the latter may present it in order to consume the API resources.As soon as the OAUTH2 access token issued by the bank (valid for 90 days) has been recovered by the AISP, the latter may present it in order to consume the API resources.

 

  • Get the list of current accounts of a TTS client (AISP)

Description : 

This call is used to retrieve the list of current accounts of the PSU for which the AISP is connected.

Each account is returned with the links allowing to consult the balances or the outstanding as well as the transactions associated with this one.

The resource identifier provided for each account will be used as a parameter for requests to retrieve balances and transactions.

A pagination of the returned list can be done if the number of accounts is high, in this case links giving access to the first page, the previous one, the next one and the last page will facilitate the consultation of the results.

Access to this method is limited to a maximum of 4 batch accesses per calendar day, for a client or for a TPP, excluding pagination.

 

Prerequisite :

The TPP is present in the authorization repository with an AISP role.

The TPP and the PSU are linked to the ASPSP by a contract.

During this step, an OAUTH2 authorization code (or access token / token) was issued to the TPP by the ASPSP.

The TPP and the ASPSP have mutually checked and authenticated.

The TPP provided its access token so that the ASPPSP can identify the PSU and retrieve the associated context.

The ASPSP has taken into account the access token which establishes the link between the PSU and the AISP.

 

Data exchange: :

The TPP sends a request to the ASPSP to retrieve the list of accounts from the PSU. The ASPSP obtains the list of accounts of the PSU and compiles a list.

The result obtained can be paginated so as to spread the data over several pages and make the whole more readable.

Each account will be detailed with its characteristics.Each account will be detailed with its characteristics.

  

  •  Retrieve the list of balances of a TTS client (AISP)

Description :

This call allows you to retrieve the list of balances of a current account of the PSU for which the AISP is connected.

This service follows the restitution of the list of accounts and cards of a client: a resource identifier corresponding to an account must be provided to obtain the list of balances.

4 types of balances can be returned in the case of an account passed as a parameter:

  • Balance in value ("VALU" in the STET standard) => balance displayed in relation to a value date
  • Accounting balance ("CLBD" in the STET standard) => accounting balance at the end of the period (weekend, end of month, end of quarter, end of semester, end of year)
  • Instant Balance ("XPCD" in the STET standard) => instant balance (changes in real time with each writing to the account)
  • Balance Other ("OTHR" in the STET standard) => NA

A pagination of the returned list can be done if there is a lot of data to display, in this case links giving access to the first page, the previous one, the next one and the last page will facilitate the consultation of the results.

Access to this method is limited to a maximum of 4 batch accesses per calendar day, for a client, for an account or for a TPP

Prerequisite :

The TPP is present in the authorization repository with an AISP role.

The TPP and the PSU are linked to the ASPSP by a contract.

During this step, an OAUTH2 authorization code (or access token / token) was issued to the TPP by the ASPSP

The TPP and the ASPSP have mutually checked and authenticated.

The TPP provided its access token so that the ASPPSP can identify the PSU and retrieve the associated context.

The ASPSP has taken into account the access token which establishes the link between the PSU and the AISP.

The TPP previously retrieved the list of accounts available for the PSU.

 

Data exchange :

AISP requests the ASPSP for one of the current accounts or one of the deferred debit cards of the PSU.

The ASPSP responds by sending the list of account balances.

The ASPSP must provide at least the accounting balance of the account.

The ASPSP may provide other balances if possible.

From a DSP2 point of view, all the balances which will be offered by the ASPSP via its web Banking service must come from the Account Information API.

  •  Get the list of transactions from a TTS client (AISP)

 Description :

This call allows you to retrieve the list of operations of a current account of the PSU for which the AISP is connected.

The transactions obtained are less than or equal to 90 days from today's date.

A pagination of the returned list can be done if there is a lot of data to display, in this case links giving access to the first page, the previous one, the next one and the last page will facilitate the consultation of the results.

This service follows the restitution of the list of sight accounts of a client: a resource identifier corresponding to an account must be provided to obtain the list of transactions.

Access to this method is limited to a maximum of 4 batch accesses per calendar day, for a client, for an account or for a TPP, excluding pagination.

 

Prerequisite:

The TPP is present in the authorization repository with an AISP role.

The TPP and the PSU are linked to the ASPSP by a contract.

During this step, an OAUTH2 authorization code (or access token / token) was issued to the TPP by the ASPSP.

The TPP and the ASPSP have mutually checked and authenticated.

The TPP provided its access token so that the ASPPSP can identify the PSU and retrieve the associated context.

The ASPSP has taken into account the access token which establishes the link between the PSU and the AISP.

The TPP previously retrieved the list of current accounts available for the PSU.

 

Data exchange :

AISP requests the ASPSP for one of the current accounts or deferred debit cards of the PSU. It can provide certain selection criteria.

The ASPSP responds with a list of transactions corresponding to the request.

The result obtained can be paginated so as to spread the data over several pages and make the whole more readable.

 

  • Record the consent of a TTS client (AISP)Record the consent of a TTS client (AISP)

Description :

This call records the consent of a PSU (payment service user) for which the AISP (payment service provider) is connected.

This consent contains the details of the access granted by the PSU. Four types of access can be defined:

  • Balances: access to balances of one or more PSU accounts

  • Transactions: access to transactions from one or more PSU accounts

  • TrustedBeneficiaries: access to the list of PSU trusted beneficiaries

Consent registration is therefore carried out for a given PSU, a given AISP, a given operation and a given account (except for trustedBeneficiairies access).

Each new AISP call to the Consent Registration Service for a given PSU will void and replace the previous consent if applicable.

In addition, at the request of the PSU, the consent may be modified later by type of transaction: for example, the consent for access to the transaction history can be revoked while the consent for the balances remains active.

Consent is checked with each request made.

 

Prerequisite:

The TPP is present in the authorization repository with an AISP role.

The TPP and the PSU are linked to the ASPSP by a contract.

During this step, an OAUTH2 authorization code (or access token / token) was issued to the TPP by the ASPSP.

The TPP and the ASPSP have mutually checked and authenticated.

The TPP provided its access token so that the ASPPSP can identify the PSU and retrieve the associated context.

The ASPSP has taken into account the access token which establishes the link between the PSU and the AISP.

 

Data exchange :

The PSU communicates to AISP the list of accounts and functionalities for which consent is given.

AISP transmits this information to the ASPSP.

The ASPSP responds with an http return code 201.

 

  •   Example of pagination

Response to request GET v1 / accounts?Page = 1


{

"accounts": [

{

"ressourceId": "EURFR353000799999A40166510BB25",

"bicFi": "NATXFRPP",

"accountId":

{

"other":

{

"identification": "EURFR353000799999A40166510BB25",

"schemeName": "BANK"

}

},

"name": "Compte client 1",

"usage": "ORGA",

"cashAccountType": "CACC",

"currency": "EUR",

"balances":

{

"name": "Solde en capital au 04/02/2019",

"balanceAmount" :

{

"currency": "EUR",

"amount": "22042776.82"

},

"balanceType" : "CLBD",

"referenceDate" : "2019-02-04"

},

"_links":

{

"balances":

{

"href": "v1/accounts/EURFR353000799999A40166510BB25/balances",

"templated": false

},

"transactions":

{

"href": "v1/accounts/EURFR353000799999A40166510BB25/transactions",

"templated": false

}

}

},

{

"ressourceId": "EURFR203000799999A40166510CC89",

"bicFi": "NATXFRPP",

"accountId":

{

"other":

{

"identification": "EURFR203000799999A40166510CC89",

"schemeName": "BANK"

}

},

"name": "Compte client 2",

"usage": "ORGA",

"cashAccountType": "CACC",

"currency": "EUR",

"_links":

{

"balances":

{

"href": "v1/accounts/EURFR203000799999A40166510CC89/balances",

"templated": false

},

"transactions":

{

"href": "v1/accounts/EURFR203000799999A40166510CC89/transactions",

"templated": false

}

}

},

{

"ressourceId": "EURFR053000799999A40166510DD56",

"bicFi": "NATXFRPP",

"accountId":

{

"other":

{

"identification": "EURFR053000799999A40166510DD56",

"schemeName": "BANK"

}

},

"name": "Compte client 3",

"usage": "ORGA",

"cashAccountType": "CACC",

"currency": "EUR",

"_links":

{

"balances":

{

"href": "v1/accounts/EURFR053000799999A40166510DD56/balances",

"templated": false

},

"transactions":

{

"href": "v1/accounts/EURFR053000799999A40166510DD56/transactions",

"templated": false

}

}

},

{

"ressourceId": "USDFR533000799999A661665104443",

"bicFi": "NATXFRPP",

"accountId":

{

"other":

{

"identification": "USDFR533000799999A661665104443",

"schemeName": "BANK"

}

},

"name": "Compte client 4",

"usage": "ORGA",

"cashAccountType": "CACC",

"currency": "EUR",

"_links":

{

"balances":

{

"href": "v1/accounts/USDFR533000799999A661665104443/balances",

"templated": false

},

"transactions":

{

"href": "v1/accounts/USDFR533000799999A661665104443/transactions",

"templated": false

}

}

},

{

"ressourceId": "EURFR823000700999A40166510EE50",

"bicFi": "NATXFRPP",

"accountId":

{

"other":

{

"identification": "EURFR823000700999A40166510EE50",

"schemeName": "BANK"

}

},

"name": "Compte client 5",

"usage": "ORGA",

"cashAccountType": "CACC",

"currency": "EUR",

"_links":

{

"balances":

{

"href": "v1/accounts/EURFR823000700999A40166510EE50/balances",

"templated": false

},

"transactions":

{

"href": "v1/accounts/EURFR823000700999A40166510EE50/transactions",

"templated": false

}

}

}

],

"_links":

{

"self":

{


},

"first":

{


},

"last":

{


},

"next":

{


},

"prev":

{


}

}

}