This site contains the documentation that is relevant to older WSO2 product versions and offerings.
For the latest WSO2 documentation, visit https://wso2.com/documentation/.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Current »

This document explains the Account Information and Transaction API flows along with the payloads. The Account Information Service Provider (AISP) can use the API endpoints described here to do the following.

  • Register a resource to retrieve account information by creating an account access consent. This registers data that the customer (PSU) has consented to provide to the AISP such as data permissions, expiration and historical period allowed for transactions/statements
  • Subsequently, retrieve account and transaction data

Basic flow

The diagram below provides a general outline of an account information request and flow using the Account Info APIs.

  1. Request account information  - The PSU consents to allow an AISP(in this case a TPP) to access account information data. 
  2. Create account request -  The AISP connects to the ASPSP that services the PSU's accounts and creates an account-access-consent resource. This informs the ASPSP that one of its PSUs is granting access to account and transaction information to an AISP.    

    1. The AISP makes a POST request to ASPSP's /account-access-consents endpoint

    2. The ASPSP responds with an identifier for the resource (the ConsentId). The account-access-consent resource will include the following fields which describe the data that the PSU has consented with the AISP:

      • Permissions - a list of data clusters that have been consented for access

      • Expiration Date - an optional expiration for when the AISP will no longer have access to the PSU's data

      • Transaction Validity Period - the From/To date range which specifies a historical period for transactions and statements which may be accessed by the AISP
    3. An AISP can be a broker for data to other parties, so it is valid for a PSU to have multiple account-access-consents for the same accounts, with different consent/authorisation parameters agreed

  3. Authorise consent - The AISP requests the PSU to authorise the consent. The ASPSP uses the redirection flow for this.

    1. In a redirection flow, the AISP redirects the PSU to the ASPSP

    2. The redirect includes the ConsentId generated in the previous step

    3. This allows the ASPSP to correlate the account-access-consent that was setup

    4. The ASPSP authenticates the PSU

    5. The ASPSP updates the state of the account-access-consent resource internally to indicate that the account access consent has been authorised

    6. Once the consent has been authorised, the PSU is redirected back to the AISP

  4. Request Data - The AISP makes a GET request the relevant resource. The unique AccountIds that are valid for the account-access-consent will be returned with a call to GET /accounts. This will always be the first call once an AISP has a valid access token.

Sequence Diagram

Endpoints

To access account information and transaction data, you can use the following available API endpoints:

Endpoint NameSupported VersionResourceEndpoint URLMandatory/Optional
Account Access Consentsv3.0, v3.1, v3.1.1account-access-consents

POST /account-access-consents

GET /account-access-consents/{ConsentId}

DELETE /account-access-consents/{ConsentId}

Mandatory

Mandatory

Mandatory

Accountsv3.0, v3.1, v3.1.1accounts

GET /accounts

GET /accounts/{AccountId}

Mandatory

Mandatory

Balancesv3.0, v3.1, v3.1.1balances

GET /accounts/{AccountId}/balances

GET /balances

Mandatory

Optional

Transactionsv3.0, v3.1, v3.1.1transactions

GET /accounts/{AccountId}/transactions

GET /transactions

Mandatory

Optional

Beneficiariesv3.0, v3.1, v3.1.1beneficiaries

GET /accounts/{AccountId}/beneficiaries

GET /beneficiaries

Conditional

Optional

Direct Debitsv3.0, v3.1, v3.1.1direct-debits

GET /accounts/{AccountId}/direct-debits

GET /direct-debits

Conditional

Optional

Standing Ordersv3.0, v3.1, v3.1.1standing-orders

GET /accounts/{AccountId}/standing-orders

GET /standing-orders

Conditional

Optional

Productsv3.0, v3.1, v3.1.1products

GET /accounts/{AccountId}/product

GET /products

Conditional

Optional

Offersv3.0, v3.1, v3.1.1offers

GET /accounts/{AccountId}/offers

GET /offers

Conditional

Optional

Partyv3.0, v3.1party

GET /accounts/{AccountId}/party

GET /party

Conditional

Conditional

Partiesv3.1.1parties

GET /accounts/{AccountId}/parties

GET /accounts/{AccountId}/party

GET /party

Conditional

Conditional

Conditional

Scheduled Paymentsv3.0, v3.1, v3.1.1scheduled-payments

GET /accounts/{AccountId}/scheduled-payments

GET /scheduled-payments

Conditional

Optional

Statementsv3.0, v3.1, v3.1.1statements

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

  • No labels