...
This API includes the account information and transaction API flows and payloads. The Account Information Service Provider (AISP) can use the endpoints described below in this section to do the following:
- Register an intent to a consent to retrieve account information by creating an account access consent. This registers the data permissions, expiration and historical period allowed for transactions/statements that the customer (PSU) has consented to provide to the AISP.
- Subsequently, retrieve account and transaction data.
...
Endpoint Name | Supported Version | Resource | Endpoint URL | Mandatory/Optional |
---|---|---|---|---|
Account Access Consents | v3.0, v3.1 | account-access-consents | POST /account-access-consents GET /account-access-consents/{ConsentId} DELETE /account-access-consents/{ConsentId} | Mandatory Mandatory Mandatory |
Accounts | v3.0, v3.1 | accounts | GET /accounts GET /accounts/{AccountId} | Mandatory Mandatory |
Balances | v3.0, v3.1 | balances | GET /accounts/{AccountId}/balances GET /balances | Mandatory Optional |
Transactions | v3.0, v3.1 | transactions | GET /accounts/{AccountId}/transactions GET /transactions | Mandatory Optional |
Beneficiaries | v3.0, v3.1 | beneficiaries | GET /accounts/{AccountId}/beneficiaries GET /beneficiaries | Conditional Optional |
Direct Debits | v3.0, v3.1 | direct-debits | GET /accounts/{AccountId}/direct-debits GET /direct-debits | Conditional Optional |
Standing Orders | v3.0, v3.1 | standing-orders | GET /accounts/{AccountId}/standing-orders GET /standing-orders | Conditional Optional |
Products | v3.0, v3.1 | products | GET /accounts/{AccountId}/product GET /products | Conditional Optional |
Offers | v3.0, v3.1 | offers | GET /accounts/{AccountId}/offers GET /offers | Conditional Optional |
Party | v3.0, v3.1 | party | GET /accounts/{AccountId}/party GET /party | Conditional Conditional |
Scheduled Payments | v3.0, v3.1 | scheduled-payments | GET /accounts/{AccountId}/scheduled-payments GET /scheduled-payments | Conditional Optional |
Statements | v3.0, v3.1 | statements | GET /accounts/{AccountId}/statements GET /accounts/{AccountId}/statements/{StatementId} GET /accounts/{AccountId}/statements/{StatementId}/file GET /accounts/{AccountId}/statements/{StatementId}/transactions GET /statements | Conditional Conditional Optional Conditional Optional |
Security and access control
API scopes
The access tokens required for accessing the Account Info APIs must have at least the following scope:
Code Block |
---|
accounts |
Grants types
AISPs must use a client credentials grant to obtain a token to access the account-requests resource.
AISPs must use a authorization code grant to obtain a token to access all other resources.
Consent authorisation
OAuth 2.0 scopes are coarse-grained and the set of available scopes are defined at the point of client registration. There is no standard method for specifying and enforcing fine-grained scopes (e.g. a scope to specify that account information should only be provided for certain time periods).
A consent authorisation is used to define the fine-grained scope that is granted by the PSU to the AISP.
The AISP must create an account-request resource through a POST operation. This resource indicates the consent that the AISP claims it has been given by the PSU to retrieve account and transaction information. At this stage, the consent is not yet authorised as the ASPSP has not yet verified this claim with the PSU.
The ASPSP responds with an AccountRequestId. This is the intent-id that is used when initiating the authorization code grant.
As part of the authorization code grant:
- The ASPSP authenticates the PSU.
- The ASPSP plays back the consent (registered by the AISP) back to the PSU to get consent authorisation. The PSU may accept or reject the consent in its entirety (but not selectively).
- The ASPSP presents the PSU with a list of accounts to which the consent will apply.
Once these steps are complete, the consent is considered to have been authorised by the PSU.
Consent elements
The Account Request resource consists of the following fields that together form the elements of the consent provided by the PSU to the AISP:
- Permissions: The set of data clusters that the PSU has consented to allow the AISP to access
- ExpirationDateTime: The date-time up to which the consent is valid.
- TransactionFromDateTime: The earliest booking date of transactions that the PSU has consented to provide access to the AISP.
- TransactionToDateTime: The last booking date of transactions that the PSU has consented to provide access to the AISP.
Consent revocation
A PSU can revoke consent for accessing account information at any point in time.
The PSU can revoke authorisation directly with the ASPSP. The mechanisms for this are in the competitive space and are up to each ASPSP to implement in the ASPSP's banking interface. ASPSPs are under no obligation to notify AISPs regarding the revocation of authorisation in v1.0.
The PSU can request the AISP to revoke consent that it has authorised. If consent is revoked with the AISP:
- The AISP must cease to access the APIs at that point (otherwise it may be in breach of GDPR).
- The AISP should call the DELETE operation on the account-request resource to indicate to the ASPSP that the PSU has revoked consent.
Changes to selected account(s)
The PSU can select the accounts to which the consent should be applied at the point of consent authorisation.
Subsequent changes to the set of accounts to which the consent authorisation applies can be carried out directly with the ASPSP. The method for doing this lies in the competitive space and is not part of this specification.
Additionally, the set of selected accounts may also change due to external factors. This includes (but not limited to):
- The account being closed.
- The PSU's mandate to operate the account is revoked.
- The account is barred or frozen.
...