Account Information Services
This version is:
Published 4 years ago 25 Jun 2020In the Open Banking API design, data elements are logically grouped together into “permissions”. It is at this level that AISPs request data access. If they request access to a specific permission they will have access to all the data elements in the permission.
Other pages in this section
Permissions
In the Open Banking API design, data elements are logically grouped together into “permissions”. It is at this level that AISPs request data access. If they request access to a specific permission they will have access to all the data elements in the permission. This provides a pragmatic approach, allowing AISPs to be selective but at the same time creating a consent process that is at an acceptable level of granularity for the PSU. Details of the data elements within each permission are included in the API technical specifications.
Data Clusters
OBIE customer research found that grouping permissions together and adding another layer of description aided the PSU’s understanding of the data they were being asked to consent to share. This approach also allows a consistency of language across AISPs and ASPSPs to provide additional comfort to PSUs that they are sharing the data they intended to. If consistent language is used across all Participants this will drive PSU familiarity and adoption. These groups of permissions are known as Data Clusters. Data Clusters are not reflected in the API specifications, they are purely a presentational layer on top of permissions to aid PSU understanding.
Data Cluster Structure & Language
The following table describes how permissions should be grouped into Data Clusters and the language that must be used to describe the data at each of these levels (Checklist item 13a and 13b). Both AISPs and ASPSPs must describe the data being shared at a Data Cluster level and allow the PSU to “drill-down” to see the detail at Permission level using the permission language set-out in the table below.
Where both Basic and Detail permissions are available from the same API end point, the Detail permission contains all data elements of the Basic permission plus the additional elements described in the table.
| Data Cluster Language | API End Points | Permissions | Permissions Language | Information available |
|---|---|---|---|---|
| Your Account Details | Accounts | Accounts Basic | Any other name by which you refer to this account | Currency of the account, Nickname of account (e.g. ‘Jakes Household account’). |
| Accounts Detail | Your account name, number and sort-code | Account Name, Sort Code, Account Number, IBAN, Roll Number (used for Building Society) (plus all data provided in Accounts Basic). | ||
| Balances | Balances | Your account balance | Amount, Currency, Credit/Debit, Type of Balance, Date/Time, Credit Line. | |
| All where PAN is available | PAN | Your long card number | PAN masked or unmasked depending on how ASPSP displays online currently. | |
| Your Regular Payments | Beneficiaries | Beneficiaries Basic | Payee agreements you have set up | List of Beneficiaries. |
| Beneficiaries Detail | Details of Payee agreements you have set up | Details of Beneficiaries account information (Name, Sort Code, Account) (plus all data provided in Beneficiaries Basic). | ||
| Standing Orders | Standing Order Basic | Your Standing Orders | SO Info, Frequency, Creditor Reference Info, First/Next/Final Payment info. | |
| Standing Order Detail | Details of your Standing Orders | Details of Creditor Account Information (Name, Sort Code, Account) (plus all data provided in Standing Order Basic). | ||
| Direct Debits | Direct Debits | Your Direct Debits | Mandate info, Status, Name, Previous payment information. | |
| Scheduled Payments | Scheduled Payments Basic | Recurring and future dated payments from your card account | Scheduled dates, amount, reference. Does not include information about the beneficiary. | |
| Scheduled Payments Detail | Details of recurring and future dated payments from your card account | Scheduled dates, amount, reference. Includes information about the beneficiary. | ||
| Your Account Transactions | Transactions | Transactions Basic Credits | Your incoming transactions | Transaction Information on payments made into the customer’s account (Reference, Amount, Status, Booking Data Info, Value Date info, Transaction Code). Does not include information about the entity that made the payment. |
| Transactions Basic Debits | Your outgoing transactions | Same as above, but for debits. | ||
| Transactions Detail Credits | Details of your incoming transactions | Transaction Information on payments made into the customer’s account (Reference, Amount, Status, Booking Data Info, Value Date info, Transaction Code). Includes information about the entity that made the payment. | ||
| Transactions Detailed Debits | Details of your outgoing transactions | Same as above but for debits. | ||
| Transactions Basic | Your transactions | Transaction Information on payments for both credits in and debits out of the customer’s account (Reference, Amount, Status, Booking Data Info, Value Date info, Transaction Code). Does not include information about the payer/payee. | ||
| Transactions Detail | Details of your transactions | Transaction Information on payments made both credits in and debits out of the customer’s account (Reference, Amount, Status, Booking Data Info, Value Date info, Transaction Code). Includes information about the payer/payee. | ||
| Your Statements | Statements | Statements Basic | Information contained in your statement | All statement information excluding specific amounts related to various balance types, payments due etc. |
| Statements Detail | Details of information contained in your statement | All statement information including specific amounts related to various balance types, payments due etc. | ||
| Your Card Features and Benefits | Products | Product | Product details – fees, charges, interest, benefits/rewards | Refers to customer account product details defined in the Open data API ( the fees, charges, interest, benefits/rewards). Applicable to PCA and BCA. |
| Offers | Offers | Offers available on your card account | Balance transfer, promotional rates, limit increases, start & end dates. | |
| Contact and party details | Party | PartyPSU | The name of the account and your full legal name. Optionally this can also include your address, telephone number and email address. | The name of the account. Full Legal Name, Address, telephone numbers and email address of the PSU as held by the bank/card issuer and party type (sole/joint etc.). |
| Account specific: Parties Party | Party | The name of the account and the full legal name(s) of all parties. Optionally this can also include their address or addresses, telephone | The name of the account. Full Legal Name(s), Account Role(s), Beneficial Ownership, Legal Structure, Address or addresses, telephone numbers and email address as held by the bank/card issuer and party type (sole/joint etc.). |
Note
With respect to the clusters and permissions language, ASPSPs should consider whether the language that is displayed to the PSU is appropriate when the information being accessed relates to more than one party. For example, “Your data” may need to be adapted to just “data” to indicate to the PSU that the account information being displayed may not be solely specific to them. As is the case of joint accounts when the account information of both parties is requested.
* Include or delete as appropriate
Optional Data
If an AISP requests additional information (e.g. Party) and the ASPSP chooses to provide this information to the AISP, both parties must ensure that they consider GDPR in the processing of this request i.e. both parties must ensure that they have a legal basis for processing.
Relevance of data cluster against product type
The AISP must ensure they have business rules that manage the relationship between data cluster to product type and omit access to data clusters that are irrelevant to a product type, as well as their service offering. If an AISP requests a cluster of data that is irrelevant to the product type associated to the payment account e.g. Direct Debit cluster requested for a Savings Account product type, the ASPSP may provide that cluster as empty.
What the research says
“If an AISP is asking for data access to Bank and cards they should adjust the language they use to describe the ASPSP (e.g. “card provider” rather than “bank”) and certain data clusters and permissions.”
Click for customer research