4.0 Account Information Services (AIS)
Contents
4.1 Overview
One of the primary aims of the Guidelines is to provide simplification and consistency throughout each stage of API Standards implementation. Therefore, we have defined a core set of Account Information Services journeys to illustrate the roles played by each party in the the API Standards ecosystem.
The API Standards support Account Information Services. They enable a Third Party to access account information from accounts held at API Providers and to provide account information services to a Customer, provided they have obtained the Customer’s explicit consent.
This section describes the core journeys that support the set-up and management of Account Information Services. The key components are:
Account Information Consent – A Customer giving consent to a Third Party to request account information from their API Provider.
Consent Dashboard and Revocation – Third Party facility to enable a Customer to view and cancel consents given to that Third Party.
Access Dashboard and Revocation – API Provider facility to enable a Customer to view all Third Parties that have access to their account(s) and the ability to cancel that access. This should be available on those channels that the Customer uses to manage their accounts with the API Provider and be easy and intuitive for the Customer to find and use.
This facility should not include unnecessary steps, superfluous information or language which could discourage the use of Third Party services or divert the Customer from the access management process.
Generic guidance around the effective use of re-direction screens (when the Customer is transferred to and from the API Provider’s domain).
NOTE: Limitations of Account Information Services Access for Customers acting with delegated user authority on behalf of Corporate Entities will only be able to use Third Party services, if this is permitted within the parameters of that delegated user authority
4.2 Account Information Services core journeys
4.2.1 Account Information consent
In this journey:
The Third Party presents a description of the service that it is providing and the data that it requires in order to support its service proposition.
The Customer selects the API Provider(s) where their payment account(s) is held.
The Customer is then directed to the domain of their API Provider(s) for authentication and to select the account(s) they want to give access to.
Once the Customer has been authenticated, their API Provider will be able to respond to the Third Party’s request by providing the account information that has been requested.
NOTE: When considering Third Party requests submitted by a Customer acting with delegated user authority on behalf of a corporate entity, the Customer may only be able to use Third Party services if this is permitted within the parameters of that delegated user authority.
4.2.2 Consent dashboard and revocation
A Third Party should provide Customers with a facility to view and cancel on-going consents that they have given to that API Provider. Additionally, they may have consented to share data from several API Providers with a single Third Party. This section describes how these consents should be displayed and how the Customer journey to cancel them should be constructed.
4.2.3 Access dashboard and revocation
API Providers should provide Customers with a facility to view and cancel on-going access that they have given to any Third Parties for each account held at that API Providers. This section describes how Third Party access should be displayed and how the Customer journey to cancel it should be constructed.
4.3 Permissions and data clusters for Account Information Services journeys
4.3.1 Permissions
In the Account Information Services Standards API design, data elements are logically grouped together into "permissions". It is at this level that Third Parties 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 Third Parties to be selective but at the same time creating a consent process that is at an acceptable level of granularity for the Customer. Details of the data elements within each permission are included in the API technical specifications.
4.3.2 Data clusters
OBIE Customer research shows that grouping permissions together and adding another layer of description aids the Customer’s understanding of the data they are being asked to consent to share. This approach also allows a consistency of language across Third Parties and API Providers to provide additional comfort to Customers that they are sharing the dat