Versions Compared

Version Old Version 22 New Version 23
Changes made by

CBB Admin

Girish (Unlicensed)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The transactions resource is used by an AISP to retrieve the transactions for a specific AccountId or to retrieve the transactions in bulk for account(s) that the user/ customer has authorised to access.

...

S. No.

Resource

HTTP Operation

Endpoint

Mandatory

Scope

Grant Type

Idempotency Key

Parameters

Request Object

Response Object

2.1

transactions

GET

GET/accounts/{AccountId}/transactions

Mandatory

accounts

Authorisation Code

No

Pagination filtering

 

OBReadTransaction

2.2

transactions

GET

GET/transactions

optionalOptional

accounts

Authorisation Code

No

Pagination filtering

 

OBReadTransaction

...

An AISP may retrieve the transaction resource for a specific AccountId (which is retrieved in the call to GET /accounts) 

2.2 GET /transactions

 If 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.

...

The OBReadTransaction object will be used for the call to:       

  • GET /accounts/{AccountId}/transactions

  • GET /transactions

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

...

  • 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+03: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.

  • For CreditCard transactions that are not yet booked, ASPSPs must populate the BookingDateTime field with an expected booking date

  • 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 it is 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: here; and External Code Sets spreadsheet.

    • The ISO 20022 BankTransactionCode Code and SubCode are specified as 4 letter codes. However, the principle we have applied for the code lists is to have longer more descriptive codes.a longer descriptive codes are used

    • 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

...

  • 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 may be ignored by the ASPSP.

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

...

  • These objects must not be returned without the ReadTransactionsDetail permission:

    • OBReadTransaction/Data/Transaction/TransactionInformation

    • OBReadTransaction/Data/Transaction/Balance

    • OBReadTransaction/Data/Transaction/MerchantDetails

    • OBReadTransaction/Data/Transaction/CreditorAgent

    • OBReadTransaction/Data/Transaction/CreditorAccount

    • OBReadTransaction/Data/Transaction/DebtorAgent

    • OBReadTransaction/Data/Transaction/DebtorAccount

  • If the ReadTransactionsDetail is granted by the user/ customer:

    • OBReadTransaction/Data/Transaction/TransactionInformation may be returned if applicable to the transaction and ASPSP (0..1)

    • OBReadTransaction/Data/Transaction/Balance may be returned if applicable to the transaction and ASPSP (0..1)

    • OBReadTransaction/Data/Transaction/MerchantDetails may be returned if applicable to the transaction and ASPSP (0..1)

    • OBReadTransaction/Data/Transaction/CreditorAgent may be returned if applicable to the transaction and ASPSP (0..1)

    • OBReadTransaction/Data/Transaction/CreditorAccount may be returned if applicable to the transaction and ASPSP (0..1)

    • OBReadTransaction/Data/Transaction/DebtorAgent may be returned if applicable to the transaction and ASPSP (0..1)

    • OBReadTransaction/Data/Transaction/DebtorAccount may be returned if applicable to the transaction and ASPSP (0..1)

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

...