Permissions & Data Clusters for AIS journeys
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.
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
Address(es), telephone number(s) and email address(es)*
* Include or delete as appropriate
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.