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 8 Next »

Some content in this documentation is subject to the MIT Open Licence. For further information, see Copyright and Licence.

This API includes the account information and transaction API flows and payloads. The Account Information Service Provider (AISP) can use the endpoints described in this section to do the following:

  • Register a consent 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.
  • Subsequently, retrieve account and transaction data.

Basic flow

The diagram below shows the basic flow of a request for account information using the account information API.

  1. Request account information - The PSU consents to allow an AISP to access account information data.
  2. Setup account request - The AISP creates an account-request resource by connecting to the ASPSP that services the PSU's account(s). The ASPSP gets alerted that a PSU has granted access to account and transaction information to an AISP. The ASPSP responds with an identifier for the resource (the AccountRequestId, which is the intent identifier). 
    1. A POST request is sent to the /account-requests endpoint.
    2. The setup payload includes the following fields that the PSU consents to share with the AISP:
      1. Permissions - a list of data clusters that have been consented for access
      2. Expiration Date - an optional expiration for when the AISP will no longer have access to the PSU's data
      3. Transaction Validity Period - the From/To date range that specifies a transaction history period, which can be accessed by the AISP
    3. An AISP may be a broker for data to other 4th parties, and so it is valid for a customer to have multiple account-requests for the same accounts, with different consent/authorisation parameters agreed. 
  3. Authorise consent - The AISP redirects the PSU to the ASPSP. The redirect includes the AccountRequestId generated in the previous step. This allows the ASPSP to correlate the account-request that was setup. The ASPSP authenticates the PSU. The ASPSP updates the state of the account-request resource internally to indicate that the account request has been authorised. It is agreed that the consent is managed between the PSU and the AISP, so the account-request details cannot be changed (with the ASPSP) in this step. The PSU will only be able to authorise or reject the account-request details in its entirety. During authorisation, the PSU selects accounts that are authorised for the AISP request (in the ASPSP's banking interface). The PSU is redirected back to the AISP.
  4. Request data - A GET request is sent to the relevant resource. The unique AccountId(s) that are valid for the account-request are 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.1account-access-consents

POST /account-access-consents

GET /account-access-consents/{ConsentId}

DELETE /account-access-consents/{ConsentId}

Mandatory

Mandatory

Mandatory

Accountsv3.0, v3.1accounts

GET /accounts

GET /accounts/{AccountId}

Mandatory

Mandatory

Balancesv3.0, v3.1balances

GET /accounts/{AccountId}/balances

GET /balances

Mandatory

Optional

Transactionsv3.0, v3.1transactions

GET /accounts/{AccountId}/transactions

GET /transactions

Mandatory

Optional

Beneficiariesv3.0, v3.1beneficiaries

GET /accounts/{AccountId}/beneficiaries

GET /beneficiaries

Conditional

Optional

Direct Debitsv3.0, v3.1direct-debits

GET /accounts/{AccountId}/direct-debits

GET /direct-debits

Conditional

Optional

Standing Ordersv3.0, v3.1standing-orders

GET /accounts/{AccountId}/standing-orders

GET /standing-orders

Conditional

Optional

Productsv3.0, v3.1products

GET /accounts/{AccountId}/product

GET /products

Conditional

Optional

Offersv3.0, v3.1offers

GET /accounts/{AccountId}/offers

GET /offers

Conditional

Optional

Partyv3.0, v3.1party

GET /accounts/{AccountId}/party

GET /party

Conditional

Conditional

Scheduled Paymentsv3.0, v3.1scheduled-payments

GET /accounts/{AccountId}/scheduled-payments

GET /scheduled-payments

Conditional

Optional

Statementsv3.0, v3.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