Version Control

Endpoints

If an ASPSP has implemented the bulk retrieval endpoints - an AISP may optionally retrieve the transactions in bulk. 

This will retrieve the resources for all authorised accounts linked to the account-request.

Data Model

The OBReadTransaction3 object will be used for the call to:

• GET /accounts/{AccountId}/transactions
• GET /transactions
• GET /accounts/{AccountId}/statements/{StatementId}transactions

Resource Definition

A resource that describes a posting to an account that results in an increase or decrease to a balance.

For a specific date range - an account (AccountId) may have no transactions booked, or may have multiple transactions booked.

UML Diagram

Notes:

• The use of the term "Transaction" has been made consistently in the Transaction endpoint payload (instead of "Entry" which is the ISO20022 element name)

• A DateTime element has been used instead of a complex choice element of Date and DateTime. Where time elements do not exist in ASPSP systems - the time portion of the DateTime element will be defaulted to 00:00:00+00:00

• The BookingDateTime has been set to mandatory - as all ASPSPs must provide this field for pagination and filtering. The BookingDateTime is the date the transaction is booked (or posted) and becomes immutable - which is not the date the transaction took place.

• Either the BankTransactionCode (which is the ISO transaction code list), or ProprietaryBankTransactionCode, or both may be populated. While the expectation is that at least one of BankTransactionCode or ProprietaryBankTransactionCode are populated - we have decided not to enforce this behaviour in the payload structure - as this would require nesting elements, and introducing complex choice elements.

• The BankTransactionCode (ISO) code-list is documented on the ISO20022 website: https://www.iso20022.org/external_code_list.page; and External Code Sets spreadsheet.

  • The ISO 20022 BankTransactionCode Code and SubCode are specified as a 4 letter codes. However - the principle we have applied for the code lists is to have longer more descriptive codes.
  • The BankTransactionCode Code and SubCode will be populated with the long form description of the ISO 20022 code, with delimiters removed. E.g., the Family Code "CNTR" has a description of "Counter Transactions" which is populated as "CounterTransactions"
• ASPSPs must have the ability to provide transactions through APIs for a period that at least equals the period provided through their online channels.

Filtering

Limited support for filtering is provided on the transactions resource.

Transactions may be filtered based on their BookingDateTime using the fromBookingDateTime and toBookingDateTime parameters

The ASPSP must treat the following as valid input:

• Non-working days (e.g. a Sunday or a Bank holiday) or any other days on which no transactions are recorded
• Dates that fall outside the range for which transaction information is provided through APIs
• Dates that fall outside the range for which a consent authorisation is available
• Timezone may be included in the filter request - but must be ignored by the ASPSP

In the above situations, the ASPSP must return data for the remaining valid period specified by the filter.

// All transactions from 1st Jan, 2015
GET /transactions?fromBookingDateTime=2015-01-01T00:00:00

// All transactions in 2016
GET /transactions?fromBookingDateTime=2016-01-01T00:00:00&toBookingDateTime=2016-12-31T23:59:59

// All transactions in a specific account up to 31-Mar-2017
GET /accounts/1/transactions?toBookingDateTime=2017-03-31T23:59:59

Permission Codes

The resource differs depending on the permissions (ReadTransactionsBasic and ReadTransactionsDetail) used to access resource. In the event the resource is accessed with both ReadTransactionsBasic and ReadTransactionsDetail, the most detailed level (ReadTransactionsDetail) must be used.

• These objects must not be returned without the ReadTransactionsDetail permission:
  • OBReadTransaction3/Data/Transaction/TransactionInformation
  • OBReadTransaction3/Data/Transaction/Balance
  • OBReadTransaction3/Data/Transaction/MerchantDetails
  • OBReadTransaction3/Data/Transaction/CreditorAccount
  • OBReadTransaction3/Data/Transaction/DebtorAccount
• If the ReadTransactionsDetail is granted by the PSU:
  • OBReadTransaction3/Data/Transaction/TransactionInformation may be returned if applicable to the transaction and ASPSP (0..1)
  • OBReadTransaction3/Data/Transaction/Balance may be returned if applicable to the transaction and ASPSP (0..1)
  • OBReadTransaction3/Data/Transaction/MerchantDetails may be returned if applicable to the transaction and ASPSP (0..1)
  • OBReadTransaction3/Data/Transaction/CreditorAccount may be returned if applicable to the transaction and ASPSP (0..1)
  • OBReadTransaction3/Data/Transaction/DebtorAccount may be returned if applicable to the transaction and ASPSP (0..1)

If the ReadPAN permission is granted by the PSU - the ASPSP may choose to populate the unmasked PAN - if the PAN is being populated in the response for these fields:

• OBReadTransaction3/Data/Transaction/CreditorAgent/Identification
• OBReadTransaction3/Data/Transaction/DebtorAccount/Identification
• OBReadTransaction3/Data/Transaction/CardInstrument/Identification

Data Dictionary

Usage Examples

Specific Account

Bulk

None of the transactions included in the payload are Ecommerce transactions - so MerchantDetails are not included in the examples.

No Access

In this example - the AISP does not have access to call the transactions endpoint. This will result in a 403 error.