Account and Transaction API
The Account and Transaction API Profile describes the flows and common functionality for the Accounts and Transaction API, which allows an Account Information Service Provider ('AISP') to:
- Register an intent 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; and
- Subsequently, retrieve account and transaction data.
This profile should be read in conjunction with a compatible Read/Write Data API Profile which provides a description of the elements that are common across all the Read/Write Data APIs, and compatible individual resources.
Account Access Consent and Security
Security & Access Control
Scopes
The access tokens required for accessing the Account Info APIs must have at least the following scope:
accounts: Ability to read Accounts information
Account Access Consent
The account-access-consent resource is referred to as an account-request resource in v1 and v2 of this specification. For clarity, it has been generalised to 'Consent' in the detail below.
POST
- An AISP must not create a Consent on a newer version, and use it on a previous version
GET
- An AISP must not access a Consent on an older version, via the Id for a Consent created in a newer version:
- An ASPSP must allow a Consent to be accessed in a newer version.
- An ASPSP must ensure Permissions set associated with a Consent are unchanged when accessed in a different version:
- An ASPSP must ensure a Consent's fields are unchanged when accessed in a different version.
- An ASPSP may allow expired Consents to be accessed in a newer version.
- An ASPSP may choose to populate new fields introduced in a resource from previous version sensible defaults (if mandatory) or not populate at all (if not mandatory):
DELETE
- An AISP must not delete a Consent on an older version, via an Id for a Consent created in a newer version:
- An ASPSP must support deleting a Consent from a previous version via a newer version:
Account Information Resources
GET
- An AISP may use a token that is bound to a Consent in a previous version, to access an endpoint of a newer version.
- An AISP may use an Id for a Consent created in a previous version to retrieve Account Information resources in a newer version:
- An AISP must not use an Id for a Consent from a newer version to access Account Information resources in a previous version:
- An AISP must not use an Id for a Consent from a previous version to access a resource introduced in a newer version (as the Consent will not have Permissions required to access the new resource).
- An ASPSP must allow an AISP to use an Id for a Consent from a previous version to access Account Information resource endpoints in a newer version:
- An ASPSP must reject the request to access a resource, for which a Consent's Permissions set does not permit.
- An ASPSP may choose to populate new fields introduced in a resource from previous version sensible defaults (if mandatory) or not populate at all: