Account Information Services Resource

GET /v1/accounts

Read the identifiers of the available payment account together with booking balance information, depending on the consent granted. It is assumed that a consent of the PSU to this access is already given and stored on the ASPSP system. The addressed list of accounts depends then on the PSU ID and the stored consent addressed by consentId. Returns all identifiers of the accounts, to which an account access has been granted to through the /consents endpoint by the PSU. In addition, relevant information about the accounts and hyperlinks to corresponding account information resources are provided if a related consent has been already granted.

POST /v1/consents

This method creates a consent resource, defining access rights to dedicated accounts of a PSU. There are two ways to create a consent. Either the accounts must be explicitly specified as parameters within the access structure. Alternatively, it is possible to pass the parameters accounts, balances and transactions empty. In this case, the PSU can make a selection from its accounts after authentication within the redirect UI. The accounts for which a consent has been issued can subsequently be retrieved by the TPP via GET.

It is not possible to accept access rights on all available accounts (parameters availableAccounts and allPsd2 will be ignored).

It is not necessary to pass a PSU identifier (the corresponding values will be ignored). The identification of the PSU takes place when the SCA is executed.

Since the authentication process is implicitly started, the parameter TPP-Redirect-URI is always mandatory.

Side Effects: When this Consent Request is a request where the recurringIndicator equals true, and if it exists already a former consent for recurring access on account information for the addressed PSU, then the former consent automatically expires as soon as the new consent request is authorised by the PSU.

GET /v1/accounts/{account-id}

Reads details about an account, with balances where required. It is assumed that a consent of the PSU to this access is already given and stored on the ASPSP system. The addressed details of this account depends then on the stored consent addressed by consentId.

DELETE /v1/consents/{consentId}

The TPP can delete an account information consent object if needed.

GET /v1/consents/{consentId}

Returns the content of an account information consent object. This is returning the data for the TPP especially in cases, where the consent was directly managed between ASPSP and PSU e.g. in a re-direct SCA Approach.

GET /v1/accounts/{account-id}/balances

Reads account data including balances from a given account addressed by {account-id}.

GET /v1/accounts/{account-id}/transactions

Read transaction lists of a given account addressed by {account-id}, depending on the steering parameter bookingStatus; together with balances. For a given account, additional parameters are e.g. the attributes dateFrom and dateTo.

Valid values for the parameter bookingStatus are:

• booked
• pending
• both
• information

If bookingStatus equals "information", the service will return standing order reports. In this case the query parameters dateFrom and dateTo aren't supported.

GET /v1/consents/{consentId}/authorisations

Return a list of all authorisation sub-resource IDs which have been created. This function returns an array of hyperlinks to all generated authorisation sub-resources.

POST /v1/consents/{consentId}/authorisations

Create an authorisation sub-resource and start the authorisation process of a consent. The usage of this access method is unnecessary and will be denied since the authorisation process is implicitly started.

GET /v1/consents/{consentId}/status

Read the status of an account information consent resource addressed by {consentId}.

GET /v1/consents/{consentId}/authorisations/{authorisationId}

This method returns the SCA status of a consent initiation's authorisation sub-resource.