...

Overview

This specification describes the Account Information and Transaction API flows and payloads.

...

GET

• An AISP must not access a Consent on an older version, via the Id for a Consent created in a newer version:
  • E.g., An account-access-consent created in v3 accessed via v2 account-request.
• 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:
  • E.g., An account-request created in v2 will have the same details when accessed via v2 and v3 (as an account-access-consent).
• 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):
  • E.g., OBReadResponse1/Data/StatusUpdateDateTime introduced in v2 accessed with v1 AccountRequestId can be populated with Last accessed date time, if not already available in the system of records.

...

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:
  • E.g., AccountRequestId from v2 can be used as ConsentId in v3, to GET /accounts.
• An AISP must not use an Id for a Consent from a newer version to access Account Information resources in a previous version:
  
  • E.g., ConsentId for an account-access-consent created in v3, must not be used to access v2 Account Information endpoints.
• 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:
  • E.g., AccountRequestId created in v2 must be allowed to access Account Information resource endpoints in v3.
• 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:
  • E.g., OBReadResponse1/Data/StatusUpdateDateTime introduced in Version2 accessed with V1 AccountRequestId can be populated with Last accessed date time, if not already available in the system of records.

...

AISPs must use a client credentials grant to obtain a token to access the account-access-consents resource. In the specification, this grant type is referred to as "Client Credentials".

AISPs must use an authorization code grant using a redirect or decoupled flow to obtain a token to access all other resources. In the specification, this grant type is referred to as "Authorization Code".

...

...

In addition the ReadStatementsDetail is required to access the statement file download via: /accounts/{AccountId}/statements/{StatementId}/file

...

• The camt.052 header section and trailer sections have been removed as these are not required for a RESTful API.
• Resources have been identified and payload structures have been designed for these resources rather than a full message (i.e., camt.052) that encompasses all resources in a report format. This has meant we have designed separate endpoints and payloads to cover:
  • accounts
  • balances
  • beneficiaries
  • direct-debits
  • offers
  • party
  • products
  • standing-orders
  • statements
  • transactions
  • scheduled-payments
• New payloads have been designed for beneficiaries, direct-debits, standing-orders, and products resources as these are not in the ISO 20022 standard (or the camt.052 message).
• A DateTime element has been used instead of a complex choice element of Date and DateTime (across all API endpoints). Where time elements do not exist in ASPSP systems, the expectation is the time portion of the DateTime element will be defaulted to 00:00:00+00:00.
• Variations for the accounts structure include: 
  • Standardised inline with the Payment API account structures.
  • Contains elements to identify an account Nickname, SecondaryIdentification.
• Variations for the balances structure include:
  • Adding a Type into the CreditLine section to allow for multiple credit line types affecting the available balance.
  • DateTime element has been specified instead of a complex choice of Date and DateTime.

• Variations for the transactions structure include:

  • Renaming "entry" to "transaction" for consistency as this is the language used in the CMA Order and PSD2.

  • DateTime elements used instead of a complex choice of Date and DateTime.

  • Flattening of the structure for BankTransactionCode and ProprietaryBankTransactionCode.

  • Additional information for an AddressLine, MerchantDetails and a running Balance.

...

The Swagger Specification for Account Information APIs can be downloaded from the following links:

• JSON
• YAML