GET /accounts

As a recognized TPP, access the user's account information by making a GET request to the /accounts endpoint. Remember to include the base URL.

Here's a simplified example of the bank's response:

{

    "accounts": [

        {

         "id": "a:8DbPteGnytmMbKXdnWTReeRB6cYWKXZ84JgLTBC7fKL4:5zKcENpV",

         "name": "Main Checking",

         "bankId": "xyz-bank",

         "accountFeatures": {

             "supportsInformation": true,

             "supportsPayment": true,

         },

         "accountDetails": {

             "identifier": "MJzqR1A2NSgTg",

             "type": "CHECKING",

             "status": "ACTIVE",

             "metadata": {        // see note on provider metadata

                 "clientId": "1"

             }

         }

        },

        {

         "id": "a:6hLu9jSeDpXV9cWafdQxvxVFgoptZX65hwVWPgzCBBGL:5zKcENpV",

         "name": "xyz Savings",

         "bankId": "xyz-bank",

         "accountFeatures": {

             "supportsInformation": true,

             "supportsSendPayment": true,

             "supportsReceivePayment": true

         },

         "accountDetails": {

             "identifier": "r4KIihP9twv5",

             "type": "CHECKING",

             "status": "ACTIVE",

             "metadata": {        // see note on provider metadata

                 "clientId": "1"

             }

         }

    }

  ]

}

Key bank-dependent fields in the accounts object and their corresponding descriptions are listed in the following table.

Key Fields in the Bank's Account Access Response
Field Subfield Description
accountDetails accountHolderName Name of the individual listed as owner of the account
accountIdentifiers One of four supported categories of bank and account identification – bban, gbDomestic, iban, or token
bic String value representing the bank identification code
providerAccountDetails Specific information regarding the required by the respective Open Banking API standard adopted by the bank. These include additional ASPSP business identifiers and contact information (address, phone, email, etc.) for:
  • CMA9
  • NextGenPSD2
  • PolishAPI
  • STET

The PAN and/or masked PAN are never included in the account details.

See the protobuf reference or Swagger spec (under the Model tab) for object and field details. See also the notes on provider metadata below.

status Provider-dependent string (ex. "Active", "Inactive", etc.)
type Type of provider account; i.e., CHECKING, SAVINGS, LOAN, CARD, OTHER
accountFeatures requiresExternalAuth Boolean. PSU must authenticate using an external (non-bank) mechanism/service
supportsInformation Boolean. Account information may be shared given upon verified customer consent
supportsPayment Boolean. Account supports authorised payment initiation
supportsSendPayment Boolean. Account can send payments
bankId System-generated Bank ID
id System-generated account ID
isLocked Boolean. The account is locked
name User-defined name of the account

 

In the GET /accounts response payload, accountIdentifiers are specified in accountDetails, which include bic and accountHolderName, along with accountNumber and/or sort_code. An example of the JSON for accountIdentifiers might look something like this:

account_details {

    providerAccountDetails {

        cma9AccountDetails {

            accountType: BUSINESS_ACCOUNT

            accountSubtype: CURRENT_ACCOUNT}

    },

    accountIdentifiers: [

    {

       gbDomestic

          {sortCode: "700001",

           accountNumber: "70000005"}

    }

]}

Possible account_identifiers in the bank's response payload comprise:

  • token, for linked accounts
  • iban
  • bban
  • gbDomestic – 8-digit bank account number in the UK.

Only fields supported by the responding bank will be populated.

Previously, TPPs could obtain these data — account identifiers, BIC, and customer name — after a GET /account call with a subsequent GET /account/{account_Id}/transfer-destinations call, wherein the debit-side bank returned its preferred transfer method(s) — SEPA, FPS, Domestic, etc. — along with the bic and CustomerData.

However, to optimise API utilisation and eliminate the additional call to transfer-destinations to get account details, banks are now required to populate accountIdentifiers, bic and accountHolderNname in the accountDetails returned by the GET /accounts call.

More notes on provider metadata: The provider metadata in accountDetails and providerTransactionDetails included in the AIS code samples presented consist of additional fields returned by the bank at its option in response to your particular request. The presence and type of metadata are entirely dependent on the bank to which you submit your request and generally comprise additional information about the account or the transaction pertinent to your specific use case. How you use this information, when included in the bank's response, is entirely up to you.

These metadata are populated in a bank-defined mapping of the transactions object. See metadata object in the response structure of the GET /accounts/{accountId}/transactions/{transactionId} endpoint under Accounts in Swagger Object and Field Definitions.

Please refer to the API's Swagger Object and Field Definitions and Swagger Specification for additional details on all of the above.